On November 20, 2024, the European Union published Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA) — in its Official Journal, creating the first EU-wide law that imposes binding cybersecurity requirements on hardware and software products themselves, rather than on how companies handle data. The regulation entered into force on December 10, 2024, and phases in over three years: incident-reporting duties begin September 11, 2026, and the full set of obligations — security-by-design engineering, vulnerability-handling processes, SBOM maintenance, and CE marking — applies from December 11, 2027. It covers an estimated tens of thousands of vendors selling "products with digital elements" into the EU, from smart thermostats to open-source-heavy enterprise software. Penalties reach €15 million or 2.5% of global annual turnover, whichever is higher. For any company shipping software that touches the EU market, the CRA has turned cybersecurity compliance into a product-engineering deadline, not a legal footnote.
What Is the EU Cyber Resilience Act?
The EU Cyber Resilience Act is Regulation (EU) 2024/2847, the first EU law that mandates cybersecurity requirements across the entire lifecycle of "products with digital elements" (PDEs) — any hardware or software product whose intended use includes a direct or indirect data connection to a device or network. Where GDPR regulates personal data processing and NIS2 regulates critical-infrastructure operators, the CRA regulates the product itself: manufacturers must build in security by design and by default, ship products free of known exploitable vulnerabilities at the point of sale, maintain a documented vulnerability-handling process, and provide security updates for a defined "support period" — a minimum of 5 years by default, unless the product's expected lifetime is shorter. It also requires manufacturers to produce and maintain a Software Bill of Materials (SBOM) covering at least top-level dependencies, so both the vendor and market surveillance authorities can trace what's actually inside a product.
Which Products Does the CRA Cover?
The CRA covers almost any product with digital elements sold into the EU, sorted into three risk tiers: default, "important," and "critical." Important products — split into Class I (e.g., password managers, browsers, network management software, firewalls that aren't for critical infrastructure) and Class II (e.g., firewalls and intrusion detection systems for industrial use, VPNs, identity management systems, SIEM platforms) — require conformity assessment against harmonized standards, with Class II generally needing third-party assessment. Critical products, such as hardware security modules and smart card readers, require certification under an EU cybersecurity certification scheme. A handful of categories are excluded because sector-specific rules already apply, including medical devices, in-vehicle systems, and aviation equipment, along with SaaS offerings unless the cloud service is a "remote data processing solution" the product depends on to function. Open-source software developed outside a commercial context is also carved out, though that exemption narrows quickly once a project is monetized.
What Are the CRA's Reporting Deadlines?
The CRA sets three hard deadlines for reporting a vulnerability or incident once a manufacturer becomes aware of it: 24 hours for an early-warning notification of any actively exploited vulnerability or severe incident, 72 hours for a more detailed follow-up notification, and 14 days for a final report once a corrective measure or patch is available. These notifications go to ENISA and the relevant national CSIRT (Computer Security Incident Response Team), and ENISA in turn shares relevant data with other member states' authorities. This is the part of the law that arrives first in practice: the reporting obligation under Article 14 becomes enforceable on September 11, 2026, more than a year before the CRA's remaining requirements take full effect.
When Does the CRA Take Effect?
The CRA takes effect in three stages, not one single date. December 10, 2024 marked entry into force, starting the clock on the transition period. September 11, 2026 (21 months later) activates the vulnerability and incident reporting obligations under Article 14, which is the first enforcement checkpoint most manufacturers will face. December 11, 2027 (36 months after entry into force) brings full application: CE marking, conformity assessments, technical documentation, and the complete set of essential cybersecurity requirements in Annex I become mandatory for any covered product placed on the EU market. Products already on the market before that date aren't automatically grandfathered — substantial changes to a product's software or hardware after the deadline can trigger a new conformity assessment.
What Happens If a Company Doesn't Comply?
Non-compliance with the CRA's essential requirements can cost a company up to €15 million or 2.5% of its global annual turnover, whichever figure is higher — a penalty structure deliberately modeled on GDPR's fine schedule. Smaller violations, such as failing to cooperate with a market surveillance authority or providing incomplete technical documentation, carry lower fines, generally up to €10 million or 2% of turnover. Beyond fines, national market surveillance authorities have the power to order a product's withdrawal or recall from the EU market entirely, which for a software vendor can mean an abrupt loss of EU customers rather than a slow-burning legal dispute. Because the CRA applies to the manufacturer regardless of where they're headquartered, a U.S. or Asia-based vendor selling into the EU faces the same exposure as an EU-domiciled one.
How Does the CRA Affect Open Source Software?
The CRA exempts open-source software that is developed and supplied outside the course of a commercial activity, but that protection disappears the moment a company packages, sells, or monetizes a project built on it. To handle the space in between, the regulation introduces the concept of an "open-source software steward" — typically a foundation, like the ones behind major Linux distributions or Apache projects — which faces lighter, more proportionate obligations focused on having a cybersecurity policy and cooperating with authorities, rather than full conformity assessment. For commercial vendors, this doesn't create an escape hatch: if a company ships a product that bundles open-source components, it remains fully responsible for the security of those components under the CRA, which is precisely why accurate SBOM coverage of upstream and transitive open-source dependencies — not just direct, top-level ones — has become a practical necessity rather than a nice-to-have.
How Safeguard Helps
Safeguard maps CRA compliance directly onto the software you're already shipping. Our platform generates and ingests SBOMs across your build pipeline, giving you the component-level inventory the CRA's Annex I documentation requirements demand, including transitive open-source dependencies that a top-level manifest would miss. Reachability analysis then tells you which of those flagged vulnerabilities are actually exploitable in your running code, so your 24-hour and 72-hour incident-reporting clocks under Article 14 start on real risk instead of every CVE that happens to match a package name. Griffin AI, Safeguard's security reasoning engine, triages incoming vulnerabilities against your codebase and prioritizes the ones that matter for your support-period obligations, while auto-fix PRs let your engineering team close out patchable findings before they ever become a reportable incident. Instead of building a separate CRA compliance program from scratch, Safeguard turns your existing SBOM, dependency, and vulnerability data into the audit trail regulators will expect.