How to choose CRA compliance software

01Short answer

• The CRA does not require you to buy software. It requires outputs: an SBOM, vulnerability handling, a technical file, Article 14 reports and security updates throughout the support period.
• For embedded products, the first criterion is whether the software can find components in your own firmware image and says clearly what it could not find.
• One vulnerability source is not enough. What triggers Article 14 is evidence of active exploitation, not a probability score.
• A list of findings is not enough on its own. The decision you take on each finding must be kept as VEX, and the technical file must be kept per version.
• No software makes a product CRA compliant by itself; conformity is assessed for the product.

02Start by writing down what you need

Start the selection by listing the work the CRA creates for your products. For a manufacturer placing products on the EU market, the core tasks are:

• Vulnerability handling (Annex I Part II): identify components, draw up an SBOM covering at least the top-level dependencies, remedy vulnerabilities without delay and distribute security updates.
• Technical file (Annex VII): risk assessment, how each Annex I requirement is met, the SBOM and test evidence. The technical documentation and the EU declaration of conformity are kept for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13(13)).
• Reporting (Article 14): report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform (SRP) within the 24-hour, 72-hour and final report deadlines. This obligation has applied since 11 September 2026.
• Support period (Article 13(8)): monitor and remedy vulnerabilities for a support period that reflects the time the product is expected to be in use.

Decide which of these your own team will do, which a piece of software will do, and which needs outside help. If you do not know your product class yet, start with the CRA class check; the class sets the conformity assessment route and how much outside support you are likely to need.

03Eight selection criteria

1. SBOM from firmware

For embedded products the problem is rarely that there is no SBOM; it is that the SBOM is incomplete. Statically linked libraries, the RTOS and the chip vendor's SDK, and components delivered as binaries by suppliers may not appear in the list your build system produces. More in What is an SBOM?.

• Can the software open your image formats (raw binary, file system, Intel HEX, ELF)?
• Does it say clearly which components it could not find or could not pin to a version?
• Can it import the SBOM from your build system and compare it with the image?
• Can it export the result as CycloneDX and SPDX?

2. Vulnerability sources

Matching against a single database misses vulnerabilities. NVD does not add product identifiers (CPE) to every record, and vulnerabilities in embedded libraries and chip SDKs are often published first in the project's or vendor's own advisories.

• Which sources are used: NVD, OSV, CVE Program records, vendor advisories?
• Is every finding linked to its source?
• How often are the sources updated, and does the software tell you when a source could not be updated?

3. Evidence of active exploitation

The 24-hour clock in Article 14 starts when you become aware that a vulnerability is being actively exploited. The software should therefore keep exploitation evidence (the CISA KEV catalogue, the list of exploited vulnerabilities in ENISA's EUVD) apart from probability scores. FIRST EPSS estimates how likely a vulnerability is to be exploited; it helps with prioritisation, but it is not evidence of exploitation.

• Are findings with exploitation evidence marked separately?
• Who takes the decision on a finding that may need an Article 14 report?

4. VEX and analyst decisions

Some of the vulnerabilities found in an embedded image concern code that is not compiled into the product or never runs. Telling them apart is an analyst's decision and should be recorded with its justification. VEX (Vulnerability Exploitability eXchange) states in machine-readable form whether a vulnerability affects the product.

• Is a decision and justification recorded for every finding, with who decided and when?
• Are CSAF VEX or OpenVEX documents produced, and are they validated against the official schema?
• Are earlier decisions carried over correctly to a new firmware version?

5. Technical file

The technical file is what a market surveillance authority can ask for. What the software produces should not be a report but a file that follows the structure of Annex VII and is tied to a product version.

• Is the status, decision and evidence recorded for each Annex I requirement?
• Does it produce the technical file and a draft EU declaration of conformity?
• Can the file be frozen as it stood on a given day (signature, timestamp) and exported in formats that will still open years later (PDF, JSON)?

6. Article 14 reporting

Reports are made through ENISA's Single Reporting Platform (SRP). The first version of the platform has no API; reports are entered through the web interface (SRP guide). Software therefore cannot submit a report for you; it can track the deadlines and prepare the form.

• Are the 24-hour, 72-hour and final report deadlines tracked from the moment of awareness?
• Are the form fields prepared in the order the SRP uses, and is there help choosing the coordinating CSIRT under Article 14(7)?
• Is a dated copy of every submitted report kept?

7. Hosting and data

The CRA does not require data to be kept in the EU. But firmware images and unfixed vulnerabilities are your most sensitive data in terms of trade secrets and security, and incident records and device telemetry may also contain personal data. That is why your customers ask where the data is processed; for the parts that contain personal data, you also need to assess the GDPR's and the KVKK's rules on transfers abroad.

• In which country's data centre is the data kept, and who are the sub-processors?
• How is data kept apart between customers?
• When the contract ends, in what format and how quickly is your data returned and deleted?

8. Versions and the support period

CRA obligations do not end when the product ships. The software should keep each firmware version separately, keep monitoring the components of released versions for new vulnerabilities and remind you when the support period is about to end.

04Types of software and who they suit

Solutions on the market fall roughly into three groups. The lines are not sharp, and one product can cover more than one group. The table shows general tendencies, not any particular product.

Most manufacturers combine these: they set up processes with a consultant and leave the work that needs continuity (SBOM, vulnerability monitoring, decisions, documents, reporting deadlines) to software. When choosing, look less at the type and more at which of the criteria above are met.

05Questions to ask a vendor

1. Can we run a trial with our own firmware image, and see which components were not found?
2. Which vulnerability sources do you use, and how do we see the source of a finding?
3. How do you keep evidence of active exploitation apart from probability scores such as EPSS?
4. In what format is your VEX output, and which validator does it pass?
5. Which parts of Annex VII does the technical file cover, and which parts do we write ourselves?
6. From what moment do you start the Article 14 deadlines, and which fields of the report form do you prepare?
7. In which country is our data kept, and who are your sub-processors?
8. If the contract ends, in what format do we get our data and documents?
9. How do you keep roadmap features apart from features that are live?

06Claims to read carefully

• "CRA-certified software": the CRA does not approve or certify compliance software. Conformity is assessed for the product, by the manufacturer or a notified body.
• "Automatic compliance": software collects evidence and prepares documents; the manufacturer takes the risk decisions, the vulnerability decisions and signs the declaration of conformity.
• "Automatic submission to the SRP": the first version of the SRP has no API. If that changes, ENISA will announce it; compare the claim with ENISA's own page.
• A quality score is not conformity: an SBOM with every field filled is not necessarily correct.

07Our approach

We built TegmenSoft around these criteria. Live on the platform today:

• SBOM from firmware: opens raw binary, file system, Intel HEX, S-record and ELF images and states clearly what it could not find; imports your build system's CycloneDX or SPDX SBOM and compares it with the analysis.
• Sources: NVD, OSV, CVE Program records and vendor advisories; every finding links to its source, and a source that could not be updated is reported with its date.
• Exploitation evidence: vulnerabilities known to be exploited in CISA KEV or ENISA EUVD are moved up and marked as Article 14 candidates; EPSS is used for ranking only. The decision stays with you.
• VEX: analyst decisions are recorded with their justification; CSAF VEX and OpenVEX documents pass the official validator.
• Technical file: Annex I requirement cards, risk assessment and a draft EU declaration of conformity; the Annex VII technical file is signed as PDF and JSON and frozen with an RFC 3161 timestamp.
• Article 14: the 24-hour, 72-hour and final report deadlines are tracked, the SRP form is prepared and a coordinating CSIRT is suggested under Article 14(7); every submission is archived signed and timestamped.
• Hosting: the platform runs in a data centre in Germany, and every query is limited to your tenant.
• Support period: each product's support period is recorded, with a warning as the end approaches.

There are things we do not do: we do not carry out conformity assessment, we do not replace a notified body, and we do not replace consultancy when you first set up your processes. You can try an SBOM in the free SBOM checker, or apply for the pilot programme with your own firmware.

08Frequently asked questions