Cyber Resilience Act guide
CRA requirements, step by step
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 September 23, 2026
Where things stand
- Reporting applies now. Since September 11, 2026, manufacturers report actively exploited vulnerabilities and severe incidents, including for products already on the market.
- Everything else applies from December 11, 2027. Products placed on the market before then fall under the rest of the CRA only if they are substantially modified.
- Guidance is out. The Commission's non-binding guidance C(2026) 5252 of July 27, 2026 explains scope, substantial modification, support periods and reporting, and Implementing Regulation (EU) 2025/2392 describes the important and critical product categories.
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 roadmap: ten steps
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.
- 1
Confirm scope and your role
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 → - 2
Classify each product
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.
- 3
Assess cybersecurity risk
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.
- 4
Set the support period
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.
- 5
Produce an SBOM from every release build
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.
- 6
Monitor what you shipped and fix without delay
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.
- 7
Publish a vulnerability disclosure policy
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.
- 8
Rehearse the 24-hour reporting clock
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.
- 9
Build the essential requirements into development
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 signs provenance that links each artifact to the build that produced it, and enforces an egress policy on what builds may download.
- 10
Assemble the documentation and pass the conformity assessment
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, vulnerability records and signed provenance as PDF, HTML, CSV, Excel or JSON for your technical documentation. The assessment and the declaration stay your process.
Requirements and the evidence behind them
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 | Evidence exports for the documentation |
CRA checklist
The roadmap on one page. Print it or save it as a PDF.
- Products in scope listed, with your role for each
- Each product classified: default, important class I or II, or critical
- Cybersecurity risk assessment written per product
- Support period set and published
- SBOM produced from every release build
- Released versions monitored for new vulnerabilities
- Triage and fix process with named owners
- Vulnerability disclosure policy and contact published
- 24-hour reporting runbook written and rehearsed
- Security testing part of every release
- Technical documentation assembled as you go
- Conformity assessment route chosen for each product
CRA requirements FAQ
Practical questions teams ask when they start on the CRA
What are the main CRA requirements for manufacturers?
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.
Where should we start?
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.
What goes in the CRA technical documentation?
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.
Does the SBOM have to be public?
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.
Is there official guidance on applying the CRA?
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.
Are small companies treated differently?
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.
Can a tool make us CRA compliant?
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.
Get the evidence your CRA process needs
See how CRACI records an SBOM from every build, monitors what you shipped and submits CRA notifications on your behalf