The EU Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is the first horizontal EU law that sets mandatory cybersecurity requirements for products with digital elements throughout their lifecycle. In plain terms: if you sell software or connected hardware in the European Union, you now have legal obligations for how securely you build it, how you handle vulnerabilities, and what security information you hand to customers. The regulation entered into force on 10 December 2024, with the core obligations becoming applicable from 11 December 2027 and the vulnerability and incident reporting duties applying earlier, from 11 September 2026.
This guide answers the questions engineering and compliance teams ask most often, then gives you a practical checklist to start from.
Who does the CRA apply to?
The CRA applies to "products with digital elements" (PDEs) — any software or hardware product, and its remote data-processing solutions, that connects directly or indirectly to a device or network. That definition is deliberately broad: it captures operating systems, mobile and desktop applications, firmware, network appliances, smart-home devices, industrial IoT, and even standalone software libraries placed on the market commercially.
The obligations fall primarily on manufacturers — the party that develops or has a product developed and markets it under their own name. Importers and distributors carry secondary duties to verify that the products they place on the EU market carry the required conformity marking and documentation. Open source software developed outside a commercial activity is largely out of scope, and the Act introduces a lighter-touch category of "open source software steward" with reduced obligations, recognising that maintainers of community projects are not the same as commercial vendors.
Non-EU companies are not exempt. If your product reaches EU users, the CRA applies regardless of where your company is headquartered.
What does the CRA require for software?
The CRA's essential requirements sit in its annexes and translate into several concrete engineering obligations:
- Secure-by-design and secure-by-default. Products must be shipped without known exploitable vulnerabilities and configured securely out of the box.
- A software bill of materials (SBOM). Manufacturers must produce and maintain an SBOM covering at least the top-level dependencies of the product, in a commonly used and machine-readable format, and make it available to authorities on request.
- Vulnerability handling. Manufacturers must identify and document vulnerabilities, provide security updates for the defined support period, and have a coordinated vulnerability disclosure policy.
- Reporting duties. Actively exploited vulnerabilities and severe incidents must be reported through the ENISA single reporting platform, with an early-warning notification due within 24 hours of awareness.
- Support period. Security updates must be provided for the product's expected lifetime, with a default expectation of at least five years unless the product's use suggests otherwise.
Higher-risk categories — described as "important" (classes I and II) and "critical" products in the Act — face stricter conformity assessment, potentially requiring third-party evaluation rather than self-assessment. Most mainstream software will fall in the default category and can self-assess, affixing the CE marking once requirements are met.
The CRA compliance checklist
| Requirement | What you need to demonstrate |
|---|---|
| Product classification | Documented determination of whether your product is default, important, or critical |
| SBOM | Machine-readable inventory of at least top-level components, kept current per release |
| Vulnerability management | A documented process to triage, remediate, and track known vulnerabilities |
| Coordinated disclosure | A published policy and contact channel for receiving vulnerability reports |
| Security updates | Committed support period and a mechanism to deliver signed updates |
| Reporting readiness | Runbook for 24-hour early warning and follow-up reports via ENISA |
| Technical documentation | Risk assessment, conformity evidence, and instructions for secure use |
| CE marking | Declaration of conformity once assessment is complete |
Treat the September 2026 reporting date as the first hard deadline: your disclosure policy, incident runbook, and vulnerability tracking need to be operational before then, even though full conformity is not required until December 2027.
Why the SBOM requirement is the hard part
Most teams underestimate the SBOM and vulnerability-handling obligations because they are continuous, not one-time. An SBOM produced once for an audit is stale the moment a dependency updates. To satisfy the CRA credibly, you need an SBOM regenerated on every build and continuously matched against new vulnerability disclosures, so that "no known exploitable vulnerabilities at time of release" is a claim you can actually back up with evidence.
This is also where the reporting clock bites. If a component in your dependency tree becomes actively exploited, the 24-hour early-warning obligation only works if you already know that component is in your product and which releases it affects. That requires provenance data linking a specific SBOM to a specific shipped artifact — the kind of trail auditors and regulators will expect.
How Safeguard helps
Safeguard is built for exactly the continuous, evidence-backed model the CRA rewards. SBOM Studio generates and versions a machine-readable SBOM (CycloneDX or SPDX) on every build, so the "top-level components" inventory the CRA requires is always current rather than reconstructed under deadline. Software composition analysis continuously matches those components against new vulnerability disclosures, giving you the ongoing "no known exploitable vulnerabilities" evidence the Act expects — and the early signal you need to hit the 24-hour reporting window when an active exploit lands in your dependency tree.
Because the Safeguard CLI runs the same checks in your pipeline that the platform runs centrally, the SBOM tied to a release and the vulnerability state at ship time become part of one queryable record — the provenance trail regulators ask for. Griffin AI triages incoming findings against your actual code paths so your team spends its remediation hours on what is genuinely exploitable, not the full raw CVE list. And our compliance framework pages map these controls to the CRA's essential requirements so you can show an assessor which capability satisfies which obligation.
The CRA is not a checkbox you clear once — it is an ongoing obligation to know what is in your software and to act quickly when something in it goes wrong. Start building that muscle now, well ahead of the 2027 deadline.
Ready to make CRA evidence a byproduct of your normal build? Create a free account or read the Safeguard documentation to see how SBOM generation and continuous vulnerability handling fit into your pipeline.