The EU Cyber Resilience Act (CRA) entered into force on December 10, 2024, and it changes the compliance calculus for every company that sells "products with digital elements" into the European market — which, in practice, means almost every software vendor with EU customers. The law's reporting obligations kick in on September 11, 2026: manufacturers must notify ENISA of actively exploited vulnerabilities within 24 hours of becoming aware of them. Full essential-requirements enforcement, including CE marking and conformity assessments, begins December 11, 2027. Penalties reach €15 million or 2.5% of global annual turnover, whichever is higher. Vendors like Endor Labs have started marketing SBOM and dependency-risk tooling against this deadline, but SBOM generation alone doesn't satisfy the CRA's vulnerability-handling, incident-reporting, and lifecycle-support requirements. Here's what the law actually requires, when it applies, and how to build a compliance program instead of a checkbox.
What Is the Cyber Resilience Act, and Who Does It Apply To?
The CRA is an EU regulation that sets mandatory cybersecurity requirements for hardware and software products sold in the European Union, covering roughly 90% of software products on the EU market according to the European Commission's own impact assessment. It applies to "manufacturers" — a term the regulation defines broadly to include any company that develops or has developed a product with digital elements and markets it under its own name, whether that's a commercial ISV, a SaaS vendor shipping an on-prem agent, or a device maker bundling firmware. The regulation carves out specific exemptions: SaaS delivered purely as a remote service (unless it's a remote data-processing solution tied to a covered product), medical devices already regulated under the MDR, and products already covered by sector-specific rules like the automotive or aviation frameworks. It also creates a lighter-touch regime for individual open-source maintainers who aren't acting "in the course of a commercial activity," while still expecting open-source stewards (foundations, entities that provide sustained support) to meet a subset of obligations. If you sell software into the EU and don't fit one of those narrow exemptions, the CRA applies to you.
What Are the CRA's SBOM Requirements for Software Vendors?
The CRA requires manufacturers to produce and maintain a Software Bill of Materials covering at least the top-level dependencies of a product, in a commonly used machine-readable format such as SPDX or CycloneDX. This isn't a one-time artifact filed at launch — Annex I, Part II requires manufacturers to identify and document vulnerabilities and components, including in third-party components, for the entire "support period" they define for the product, which the regulation expects to reflect realistic usage but caps default support periods for follow-up security updates at a maximum of 10 years unless the product's expected lifetime is shorter. In practice, that means an SBOM generated at build time and never touched again fails the requirement the moment a new CVE lands against a transitive dependency six months later. Vendors need SBOMs that regenerate on every release and reconcile against a live vulnerability feed, not a PDF exported for an audit. This is the exact gap where point-tools that produce a static SBOM snapshot — the kind of report several SCA vendors, including Endor Labs, generate as an export — fall short of what auditors will expect to see as evidence of ongoing "due diligence" under Article 13.
When Are the CRA's Compliance Deadlines?
There are three dates that matter, and all three are already on the calendar. December 10, 2024 is when the CRA entered into force, starting the clock. September 11, 2026 (21 months later) is when the vulnerability-handling and incident-reporting obligations become enforceable — this is the date manufacturers must be able to send an early warning to ENISA within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report within 14 days of a fix becoming available. December 11, 2027 (36 months after entry into force) is when the full set of essential cybersecurity requirements applies, including CE marking, technical documentation, and conformity assessment for "important" and "critical" product classes. Products classified as Class I "important" — think password managers, VPN clients, network management software, SIEM systems, and identity management software — can in many cases self-assess, but Class II products (firewalls, intrusion detection systems, tamper-resistant microprocessors) require third-party conformity assessment by a notified body. Given notified-body capacity constraints already reported across the EU, vendors in Class II categories who wait until 2027 to start the assessment process are likely to find themselves in a queue.
How Does the CRA's 24-Hour Vulnerability Reporting Rule Actually Work?
The rule requires manufacturers to report actively exploited vulnerabilities to ENISA and the relevant national CSIRT within 24 hours of becoming aware of exploitation, not within 24 hours of the vulnerability being disclosed or patched. That distinction matters operationally: it means a vendor needs continuous exploitation monitoring tied to its own dependency graph, not just a subscription to NVD or GitHub Security Advisories. The reporting cascade has three stages — an early warning within 24 hours containing basic information (affected product, nature of exploitation, availability of a fix), a follow-up notification within 72 hours with an assessed severity and, where available, mitigation guidance, and a final report within 14 days of a fix or mitigating measure becoming available, or one month after the initial notification if no fix exists yet. A vendor running quarterly SCA scans has no realistic path to a 24-hour detection window; the requirement effectively forces continuous, automated correlation between "what's in my product" and "what's being exploited in the wild right now," which is a materially different capability than a periodic dependency audit.
What Happens If a Vendor Doesn't Comply?
Non-compliance carries fines of up to €15 million or 2.5% of the company's total worldwide annual turnover from the preceding financial year, whichever figure is higher — the same enforcement structure the EU used for GDPR, and market surveillance authorities are empowered to order products withdrawn from the EU market entirely. Lower-tier violations, such as failing to maintain adequate technical documentation, top out at €10 million or 2% of turnover, while supplying incorrect or incomplete information to authorities during an investigation caps at €5 million or 1% of turnover. Beyond direct fines, distributors and importers in the EU are required under Article 13 to verify that a product carries CE marking and CRA-compliant documentation before they can legally place it on the market — meaning non-compliant vendors risk losing distribution channels well before a regulator ever issues a penalty. For a mid-market software vendor with EU revenue, a single vulnerability-reporting failure discovered during a post-incident review could plausibly cost more than several years of compliance tooling spend.
How Safeguard Helps
Safeguard is built around the assumption that CRA compliance isn't a document you generate once — it's a continuously verified state of your software supply chain. Where a static SBOM export answers "what did we ship on release day," Safeguard maintains a live, versioned SBOM for every build, automatically reconciled against new CVE disclosures and exploitation intelligence as they land, so the artifact an auditor reviews in 2027 reflects the product as it actually exists in production, not a snapshot from the last quarterly scan.
That continuous view is what makes the CRA's 24-hour early-warning requirement achievable in practice. Safeguard correlates your dependency graph against active exploitation signals in near real time and routes alerts into the workflows your security team already uses, so the clock on ENISA's 24/72-hour/14-day reporting cascade starts when the vulnerability is actually relevant to your product — not days later when someone happens to re-run a scan. We also generate the technical documentation trail the CRA expects under Annex I and Article 13: component provenance, patch history, and support-period tracking tied to each product line, so you're not reconstructing that evidence by hand when a market surveillance authority or a notified body asks for it.
For vendors evaluating Safeguard against dependency-scanning tools like Endor Labs, the practical difference shows up at audit time: reachability-focused SCA tools are good at telling you which vulnerabilities matter for prioritization, but the CRA doesn't just ask you to prioritize — it asks you to prove, with a documented trail, that you detected, assessed, reported, and remediated within fixed statutory windows across the entire support period you've committed to. Safeguard is built to produce that evidence continuously, across your full product portfolio, rather than as a one-off export you assemble when the deadline gets close.
If your EU revenue, product classification, or support commitments put you inside the CRA's scope, the practical move now — well ahead of the September 2026 and December 2027 deadlines — is to get a continuously updated SBOM and exploitation-monitoring pipeline in place, and to map your product catalog against the CRA's Class I/Class II categories so you know which products will need third-party conformity assessment and can get in line before notified-body capacity tightens further. Talk to Safeguard's team to see how your current SBOM and vulnerability workflows map against the CRA's specific reporting and documentation requirements.