Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›EU Cyber Resilience Act (CRA)
EU · Regulation (EU) 2024/2847

EU Cyber Resilience Act (CRA)

the first horizontal law to mandate an SBOM, vulnerability handling and security-by-design for every product with digital elements.

The Cyber Resilience Act, Regulation (EU) 2024/2847, makes cybersecurity a condition of selling any product with digital elements in the EU. Its headline obligation for engineering teams sits in Annex I, Part II, point (1): manufacturers must identify and document the components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. This is the first time an SBOM is a binding legal requirement anywhere, not just a recommendation.

The CRA entered into force on 10 December 2024 and applies in stages. Article 14 reporting of actively exploited vulnerabilities starts 11 September 2026, and full applicability of the essential requirements and conformity assessment lands on 11 December 2027. This page explains how to meet each obligation, article by article.

Talk to our advisory team Read it on EUR-Lex
At a glance
11 Dec 2027Full applicability of CRA essential requirements
24 hoursEarly warning to ENISA for actively exploited vulnerabilities (Art. 14)
€15M / 2.5%Maximum fine, or 2.5% of global annual turnover
Annex I Part II(1)The binding SBOM mandate
Regulation (EU) 2024/2847 (Cyber Resilience Act)
Why the CRA matters

An SBOM is no longer a best practice. Under the CRA it is the law to sell software in Europe.

The CRA is horizontal: it covers nearly every product with digital elements placed on the EU market, from connected consumer devices to standalone software and components. Manufacturers, importers and distributors are all in scope. The essential requirements in Annex I are not optional guidance; failing to meet them blocks CE marking and the right to sell, and exposes manufacturers to fines of up to (Art. 64) €15 million or 2.5% of worldwide annual turnover.

Two obligations dominate the engineering workload. First, Annex I Part II(1) requires a machine-readable software bill of materials covering at least top-level dependencies, kept current and available to market surveillance authorities on request. Second, Annex I Part I requires products to ship with no known exploitable vulnerabilities, a secure-by-default configuration, and a minimised attack surface. Together they force continuous component inventory and vulnerability management across the entire support period.

The clock is real. Article 14 reporting of actively exploited vulnerabilities and severe incidents to ENISA and the relevant CSIRT begins 11 September 2026, with a 24-hour early warning. The full set of essential requirements and conformity assessment applies from 11 December 2027. Teams that wait until 2027 to build SBOM pipelines and a coordinated vulnerability disclosure process will not pass.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

Early warning of an actively exploited vulnerability or severe incident to ENISA / CSIRT (Art. 14)24 hours
Vulnerability / incident notification with initial details (Art. 14)72 hours
Final report once the vulnerability is remediated or the incident handled (Art. 14)14 days
Annex I Part II(1)

How to produce the SBOM the CRA requires

The SBOM is the CRA's signature engineering obligation. Annex I Part II point (1) requires manufacturers to identify and document components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies, and to keep it up to date for the support period.

Annex I, Part II, point (1)Recital 78
Generate an SBOM in a recognised machine-readable format. The CRA does not mandate a specific standard, so use CycloneDX or SPDX, both of which market surveillance authorities recognise.
Cover at least top-level dependencies as the floor, but aim deeper. Transitive components are where most known vulnerabilities hide, so a full dependency tree is the safer reading of the obligation.
Regenerate the SBOM on every build so it stays current across the whole support period, not just at release. Bind each SBOM to a specific version and build.
Store SBOMs so they can be supplied to market surveillance authorities on request, and feed them into your vulnerability monitoring so a new CVE in any listed component raises an alert.
Where O3 helps

O3 generates CycloneDX SBOMs on every build, enriches them with deps.dev and VEX, and keeps a versioned component inventory that maps directly to the Annex I Part II(1) requirement. The same pipeline also emits CBOM, QBOM, AIBOM and HBOM for products with cryptographic, quantum-exposed, AI or hardware components.

Annex I Part II

How to handle vulnerabilities across the support period

Annex I Part II sets out a full vulnerability handling lifecycle, not a one-time check. Manufacturers must address and remediate vulnerabilities without delay (point 2), test and review security regularly (point 3), and publish information about fixed vulnerabilities (point 4).

Annex I, Part II, points (2)–(4)Article 13
Run continuous SCA against your SBOM so newly disclosed vulnerabilities in shipped components surface automatically, then patch them without delay as point (2) requires.
Prioritise remediation by real exploitability. Combine EPSS scores and the CISA KEV catalogue with reachability analysis so you fix what is actually exploitable first, not just what scores highest by CVSS.
Test and review security regularly (point 3) with SAST, DAST and dependency scanning wired into CI, and gate releases on no known exploitable vulnerabilities.
Once a fix ships, disseminate security advisories and information about remediated vulnerabilities (point 4), ideally as machine-readable VEX so downstream users can act.
Where O3 helps

O3 pairs SCA against OSV with function-level reachability and EPSS plus KEV scoring, so vulnerability handling focuses on components that are both vulnerable and reachable. SAST and agentic DAST cover the regular security testing in point (3), and autofix raises remediation PRs.

Annex I Part I

How to build security-by-design and secure-by-default

Annex I Part I lists the essential requirements products must meet by design. Point (2) requires products to be delivered with no known exploitable vulnerabilities, a secure-by-default configuration, protection of confidentiality and integrity (including via encryption), data minimisation, a minimised attack surface, and least privilege.

Annex I, Part I, point (2)Annex VII
Ship with no known exploitable vulnerabilities by gating every release on a clean SCA and SAST run against the current SBOM.
Default to the most secure configuration out of the box: no default passwords, secure protocols on, unnecessary services off, so users are protected without extra steps.
Protect confidentiality and integrity with encryption in transit and at rest, and apply least privilege and a minimised attack surface across components and interfaces.
Document the security architecture and the design decisions in the technical documentation required for conformity assessment under Annex VII.
Where O3 helps

O3 SAST uses code-property-graph taint tracking to find source-to-sink flows interprocedurally, and secret scanning catches hardcoded credentials that break the secure-by-default requirement before a product ships.

Article 14

How to meet the 24-hour vulnerability and incident reporting duty

From 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform on a strict cadence: a 24-hour early warning, a 72-hour notification, and a final report within 14 days.

Article 14Article 14(1)–(3)
Stand up an internal escalation path now so a confirmed active exploitation reaches the reporting owner within hours, not days.
Send the early warning within 24 hours of becoming aware, then the fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available.
Route reports through ENISA's single reporting platform to the relevant CSIRT, and keep evidence of timing to demonstrate compliance.
Build detection that tells you when a known vulnerability is actually being exploited in your deployed product, since the clock starts at awareness of active exploitation.
Where O3 helps

O3's eBPF runtime agent (kayo) builds kernel-level process trees and detects attack chains, and L7 deep packet inspection (ecapture) flags exfiltration and anomalous egress, giving early signal that a vulnerability is being actively exploited so the 24-hour clock can start on time.

Articles 13, 31–33

How to prove conformity and apply CE marking

Article 13 sets manufacturer obligations, and Articles 31 to 33 govern conformity assessment and CE marking. Products cannot carry CE marking, and therefore cannot be sold, until the essential requirements are demonstrably met and an EU declaration of conformity is drawn up.

Article 13Articles 31–33Annex VII
Classify your product. Default products self-assess, while important products (Annex III) and critical products (Annex IV) face stricter routes including third-party assessment.
Compile the technical documentation in Annex VII, including the SBOM, risk assessment, and evidence that Annex I requirements are met.
Draw up the EU declaration of conformity and affix the CE marking only once assessment is complete.
Define and publish a support period (minimum five years unless the expected use is shorter) during which vulnerability handling continues.
Where O3 helps

O3 produces the SBOM and the vulnerability and reachability evidence that feed directly into the Annex VII technical documentation, reducing the manual effort of assembling conformity files.

Annex I Part II(5)

How to run a coordinated vulnerability disclosure policy

Annex I Part II point (5) requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure, so external researchers and users have a clear, safe channel to report flaws.

Annex I, Part II, point (5)Article 13(8)
Publish a coordinated vulnerability disclosure policy and a contact point (a security.txt file and a dedicated address are the common pattern).
Define how reports are triaged, acknowledged and remediated, and the timeline within which reporters can expect a response.
Share information about potential vulnerabilities in third-party components you ship back to the upstream maintainers.
Link disclosed and fixed vulnerabilities to the advisories you publish under point (4) so the loop is closed and auditable.
The whole framework

Every major CRA obligation, mapped to how you meet it.

All 22 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

10Annex I
Security-by-design and vulnerability handling
5Articles 13–20
Manufacturer, importer and distributor duties
4Articles 7–8, 31–33
Classification, conformity and CE marking
3Article 14
Reporting obligations
Requirement area
Software bill of materials (machine-readable, top-level dependencies)Annex I, Part II(1)Generate CycloneDX/SPDX SBOM every build
No known exploitable vulnerabilities at releaseAnnex I, Part I(2)Gate releases on clean SCA and SAST
Secure-by-default configurationAnnex I, Part I(2)Ship hardened defaults, no default passwords
Confidentiality and integrity (encryption)Annex I, Part I(2)Encrypt data in transit and at rest
Minimised attack surface and least privilegeAnnex I, Part I(2)Disable unused services, scope permissions
Address and remediate vulnerabilities without delayAnnex I, Part II(2)Continuous SCA with prioritised patching
Regular security testing and reviewsAnnex I, Part II(3)SAST, DAST and SCA wired into CI
Disseminate information on fixed vulnerabilitiesAnnex I, Part II(4)Publish advisories, ideally as VEX
Coordinated vulnerability disclosure policyAnnex I, Part II(5)Publish CVD policy and contact point
Secure update mechanismAnnex I, Part II(6)–(8)Ship signed, timely security updates
Manufacturer obligations and risk assessmentArticle 13Document cybersecurity risk assessment
Support period (minimum five years)Article 13(8)Define and publish support period upfront
Report actively exploited vulnerabilitiesArticle 14(1)24h early warning to ENISA / CSIRT
Notification with detailsArticle 14(2)72-hour follow-up notification
Final report after remediationArticle 14Final report within 14 days
Importer obligationsArticle 19Verify CE marking and documentation
Distributor obligationsArticle 20Check conformity before making available
Classification of important productsArticle 7, Annex IIIApply stricter assessment route
Classification of critical productsArticle 8, Annex IVUse European certification where required
Conformity assessment and CE markingArticles 31–33Assess, declare conformity, affix CE
Technical documentationAnnex VIICompile SBOM, risk, and design evidence
Penalties for non-complianceArticle 64Up to €15M or 2.5% of turnover

Build CRA evidence into your pipeline, not your deadline week

O3 generates the CycloneDX SBOM the CRA mandates, ranks vulnerabilities by real reachability and EPSS plus KEV, and gives runtime signal when a flaw is actually being exploited. That covers Annex I Part II(1), the vulnerability handling lifecycle, and the awareness trigger for Article 14 reporting from one platform.

Read it on EUR-Lex
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • Yes. Annex I, Part II, point (1) of Regulation (EU) 2024/2847 requires manufacturers to identify and document product components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It is the first binding SBOM mandate in law, and it must be kept current across the support period.
  • The CRA entered into force on 10 December 2024 and applies in stages. Conformity assessment body notification rules apply from 11 June 2026, Article 14 vulnerability and incident reporting from 11 September 2026, and the full set of essential requirements and conformity assessment from 11 December 2027.
  • The CRA does not name a specific standard. Annex I, Part II(1) only requires a commonly used, machine-readable format. In practice that means CycloneDX or SPDX, both of which are widely recognised and accepted by market surveillance authorities. The minimum scope is top-level dependencies, though a full dependency tree is the safer reading.
  • From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days once a corrective measure is available.
  • Under Article 64, breaching the essential cybersecurity requirements or the SBOM and vulnerability handling obligations in Annex I can trigger fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other breaches and supplying incorrect information carry lower caps.
  • The CRA applies to manufacturers, importers and distributors of products with digital elements placed on the EU market. Manufacturers carry the bulk of the obligations, including the SBOM, security-by-design and vulnerability handling. Importers and distributors must verify conformity and CE marking before making products available.
  • Annex I, Part I, point (2) requires products to ship with no known exploitable vulnerabilities, a secure-by-default configuration, protection of confidentiality and integrity through encryption, data minimisation, a minimised attack surface, and least privilege. These properties must be designed in and demonstrated in the Annex VII technical documentation.
  • The CRA regulates products with digital elements and their manufacturers, requiring an SBOM, secure design and vulnerability handling before a product can be CE marked. NIS2 regulates the cybersecurity risk management of essential and important operators. CRA-compliant products help organisations meet NIS2 supply chain expectations, but they are distinct laws.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.