Cyber Resilience Act guide
A practical roadmap for the teams that build products with digital elements: what to do, who owns it, and what evidence to keep. For what the law says, read what the Cyber Resilience Act is.
Last updated October 15, 2026
What the Cyber Resilience Act asks manufacturers to do
The scope of Regulation (EU) 2024/2847, the dates it takes effect, the reporting deadlines, and where the SBOM and vulnerability handling obligations sit.
Petteri Pulkkinen and Erika Marttinen at Kubernetes Community Days Helsinki 2026, 8:03 to 15:20 of SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
The steps run roughly in order, but steps 5 to 8 matter first for products already on the market, because reporting applies to them now.
List every product with digital elements you make available in the EU, including software sold on its own and the cloud backends products need to work. For each, confirm it is not excluded (medical devices, vehicles, aviation, marine equipment, defense) and whether you are its manufacturer, importer or distributor.
Check a product with the CRA Checker →Most products are default category. Compare yours with the important (Annex III) and critical (Annex IV) lists; Implementing Regulation (EU) 2025/2392 gives their technical descriptions. The category decides whether you may self-assess or need a notified body or certification.
Write a cybersecurity risk assessment for each product. It decides how the essential requirements in Annex I apply, and it belongs in the technical documentation. Update it when the product or the threats change.
Decide how long you handle vulnerabilities for each product: at least five years unless the product is expected to be in use for less. Tell users when support ends, and keep each security update available for at least 10 years.
The CRA asks for a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies. Generating it in the build that produces the release, rather than once by hand, keeps it true to what shipped.
Where CRACI fits: CRACI records the SBOM while each build runs, including transitive dependencies and packages restored from caches, and exports it as CycloneDX or SPDX.
Watch released versions, not only the main branch, for new vulnerabilities throughout the support period. Fix them without delay, ship security updates free of charge and, where feasible, separately from feature updates.
Where CRACI fits: CRACI re-checks monitored SBOMs against new vulnerabilities after you ship, and security teams triage findings and send them to the teams that own the fix. Policy gates can block a build on findings.
Give researchers and customers a contact for reporting vulnerabilities and a coordinated vulnerability disclosure policy. Once an update is available, publish information about the vulnerabilities it fixes.
Since September 11, 2026, an actively exploited vulnerability or severe incident needs an early warning within 24 hours, a notification within 72 hours and a final report, through the Single Reporting Platform. Name who confirms active exploitation, who files, and who informs users. The hard part is knowing within hours which products and releases contain the vulnerable component.
Where CRACI fits: CRACI's build history shows which builds contained a vulnerable dependency, its inventory view shows which versions are deployed to which products, and CRACI submits the CRA notifications on your behalf.
Ship with no known exploitable vulnerabilities and a secure by default configuration, protect data and access, limit the attack surface, and make security updates possible, automatic by default where applicable. Test and review security regularly.
Where CRACI fits: CRACI enforces an egress policy on what builds may download, and policy gates can block a build on findings.
Collect the technical documentation described in Annex VII, run the conformity assessment for your category, draw up the EU declaration of conformity and affix the CE marking. Keep the documentation and declaration for at least 10 years or the support period, whichever is longer.
Where CRACI fits: CRACI exports SBOMs as CycloneDX or SPDX, including the vulnerabilities found in their components, and its API returns SBOMs, network traces and provenance for your technical documentation. The assessment and the declaration stay your process.
Market surveillance authorities can ask for your technical documentation. This is what each requirement leaves behind, and where CRACI records it from your builds.
| Requirement | Where | Evidence to keep | From CRACI |
|---|---|---|---|
| Cybersecurity risk assessment | Article 13, Annex I | Documented assessment per product | Your process |
| No known exploitable vulnerabilities at release | Annex I, Part I | Vulnerability status of the release build | Release build SBOM checked against advisories; policy gates |
| Software bill of materials | Annex I, Part II | Machine-readable SBOM per release | Recorded from every build, CycloneDX or SPDX |
| Vulnerability handling for the support period | Article 13, Annex I, Part II | Findings, triage decisions, fixes, advisories | Continuous re-evaluation, triage, VEX |
| Due diligence on third-party components | Article 13 | Component records, including bought-in software | Vendor SBOMs monitored with your own; declared licenses |
| Reporting exploited vulnerabilities and severe incidents | Article 14 | Early warnings, notifications, final reports | Submits the notifications on your behalf |
| Support period | Article 13 | Published end-of-support date | Your process |
| Technical documentation and declaration | Article 13, Annex VII | Kept for 10 years or the support period | SBOM export and API data for the documentation |
Cyber Resilience Act
Use this checklist to assign ownership and collect evidence as you prepare products with digital elements for the CRA.
Practical questions teams ask when they start on the CRA
Meet the essential requirements in Annex I based on a cybersecurity risk assessment, keep an SBOM, handle vulnerabilities for a support period of at least five years, report actively exploited vulnerabilities and severe incidents, keep technical documentation, pass a conformity assessment and affix the CE marking.
With scope and reporting. Find out which products the CRA covers, then make sure you could meet the 24-hour early warning for an actively exploited vulnerability, because reporting has applied since September 11, 2026, including for products already on the market. The rest applies from December 11, 2027.
Annex VII lists it. It includes the product's cybersecurity risk assessment, the SBOM and information on how the manufacturer handles vulnerabilities. It is kept for at least 10 years or the support period, whichever is longer, and given to market surveillance authorities on request.
No. The SBOM is part of the technical documentation and goes to a market surveillance authority on request. The regulation does not require publishing it.
Yes. On July 27, 2026 the European Commission published non-binding guidance, C(2026) 5252, with 67 practical examples. It covers remote data processing, free and open-source software, substantial modification, support periods, reporting and risk assessment. Implementing Regulation (EU) 2025/2392 describes the important and critical product categories.
The obligations are the same, but micro and small enterprises are not fined for missing the 24-hour early warning deadline, and the Commission guidance is written with microenterprises and SMEs in mind.
No. Meeting the CRA is the manufacturer's process, including the risk assessment, the conformity assessment and the declaration. CRACI automates a significant part of the supply chain visibility and evidence that process needs: SBOMs from every build, vulnerability tracking after release, and the CRA notifications.
See how CRACI records an SBOM from every build, monitors what you shipped and submits CRA notifications on your behalf