The EU Cyber Resilience Act (CRA) is not a future concern for software teams — it's a regulation with binding deadlines, and the first one lands on September 11, 2026. Formally Regulation (EU) 2024/2847, the CRA entered into force on December 10, 2024, and applies to nearly every "product with digital elements" placed on the EU market, from IoT firmware and industrial routers to commercial software that bundles open-source components. It requires manufacturers to ship a machine-readable Software Bill of Materials, patch known-exploited vulnerabilities before release, maintain security updates for a minimum support period, and report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. Non-compliance with the core security requirements carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. For developers, the CRA turns SBOM generation, vulnerability triage, and coordinated disclosure from optional hygiene into a legal obligation with a hard clock attached.
What is the EU Cyber Resilience Act?
The CRA is Regulation (EU) 2024/2847 — the first EU-wide law that sets mandatory, horizontal cybersecurity requirements for hardware and software products sold anywhere in the European Union. It was published in the Official Journal on November 20, 2024, and entered into force twenty days later, on December 10, 2024. The law exists to close two gaps the European Commission identified in its impact assessment: a persistently low level of cybersecurity baked into commercial products, and a lack of information for buyers about the security properties of what they're purchasing. Annex I lays out the essential requirements: products must be designed with "security by design and by default," ship without any known exploitable vulnerabilities at the time of release, and receive security updates automatically where technically feasible. The scope is broad by design — a smart thermostat, a CI/CD plugin, a payment SDK, and an npm package embedded in a paid SaaS product can all fall under the same rulebook depending on how they're distributed.
Who does the CRA apply to?
The CRA applies to any manufacturer, importer, or distributor that places a "product with digital elements" (PDE) on the EU market, and it sorts those products into three risk tiers with different obligations. Most software falls into the "default" category with baseline requirements. A subset is classified "important" — Class I covers things like password managers, identity management systems, standalone and embedded browsers, and VPN clients; Class II covers higher-risk categories like firewalls, intrusion detection systems, SIEM platforms, and industrial control components — and these require a third-party conformity assessment rather than pure self-assessment. A small "critical" tier (smartcards, hardware security modules, smart meter gateways) faces the strictest certification path. Pure SaaS is generally out of scope unless it's a "remote data processing solution" the manufacturer relies on for a core function of the product, in which case it gets pulled back in. Medical devices, motor vehicles, and products already covered by sector-specific EU rules (aviation, in-vitro diagnostics) are excluded to avoid double regulation.
What are the key compliance deadlines?
There are three dates that matter, all measured from the December 10, 2024 entry into force. June 11, 2026 (18 months in) is when member states must have designated market surveillance authorities and notified conformity assessment bodies operational. September 11, 2026 (21 months in) is when the reporting obligations become enforceable: manufacturers must notify ENISA and the relevant CSIRT of an actively exploited vulnerability within 24 hours of becoming aware of it, follow up with a more detailed notification within 72 hours, and submit a final report within 14 days of a fix becoming available. December 11, 2027 (36 months in) is when the CRA applies in full — CE marking, conformity assessments, technical documentation, and every Annex I essential requirement become legally enforceable for products placed on the market. Teams that wait until late 2027 to start will be building an SBOM and vulnerability-handling process for the first time under a live regulatory deadline, which is a bad position to be in.
What do developers actually need to build to comply?
Compliance comes down to four concrete engineering deliverables, not a policy document. First, a Software Bill of Materials covering at minimum the top-level dependencies of the product, in a commonly used machine-readable format such as CycloneDX or SPDX, kept current for the support period. Second, a documented vulnerability handling process that includes a coordinated vulnerability disclosure (CVD) policy and a designated contact point — the same muscle that made Log4Shell (CVE-2021-44228) so damaging in December 2021 was the absence of clear disclosure and patching pipelines at thousands of downstream vendors, exactly what the CRA is trying to prevent industry-wide. Third, security updates for a minimum of five years or the product's expected lifetime, whichever is shorter, delivered automatically by default where feasible. Fourth, and easy to underestimate: "no known exploitable vulnerabilities at the time of release" means vulnerability scanning has to run pre-release against a known-CVE database, not just as a post-incident cleanup step, and the results have to be part of the technical documentation an auditor can request.
Does the CRA apply to open-source software?
Yes, but with a deliberately lighter-touch regime for non-commercial open source, and a separate category for the organizations that steward it. Individual developers and volunteer contributors publishing free and open-source software outside the course of a commercial activity are excluded from manufacturer obligations. Foundations and similar not-for-profit entities that provide sustained support for OSS used in commercial products — the CRA calls them "open-source software stewards" — get a reduced obligation set under Article 24: a cybersecurity policy, cooperation with market surveillance authorities, and voluntary reporting of vulnerabilities they discover. The obligation shifts back to full manufacturer status the moment someone commercializes that code: a company that takes an open-source library, bundles it into a paid product, and places that product on the EU market is the manufacturer of record for CRA purposes — including for vulnerabilities that originate in the upstream dependency it didn't write.
What happens if a company doesn't comply?
Penalties are tiered by which obligation was breached, and the top tier is steep enough to reach board-level attention: up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher, for non-compliance with the essential cybersecurity requirements in Annex I. A second tier of up to €10 million or 2% of turnover applies to other obligations, such as registration and documentation retention failures. A third tier of up to €5 million or 1% of turnover applies to supplying incorrect, incomplete, or misleading information to a market surveillance authority or notified body. Beyond fines, national market surveillance authorities have the power to order a product withdrawn or recalled from the EU market entirely — a remedy that can be far more commercially damaging than the fine itself for a vendor selling into Europe.
How Safeguard Helps
Safeguard maps directly onto the engineering work the CRA actually demands, rather than treating compliance as a paperwork exercise. Griffin AI continuously ingests SBOMs from your build pipeline (or generates them if you don't have one) in CycloneDX and SPDX format, and cross-references every component against known-CVE data so you can demonstrate "no known exploitable vulnerabilities at release" with an audit trail, not an assertion. Reachability analysis then narrows that CVE list down to the vulnerabilities your code actually calls at runtime, cutting the noise that would otherwise bury a five-person team trying to hit a 24-hour reporting clock. When a reachable, exploitable issue is confirmed, Safeguard opens an auto-fix pull request with the minimal version bump or patch needed, so the fix — and the documentation of it — exists before a market surveillance authority ever asks to see it.