Software makers selling into the EU now have a hard deadline attached to a three-letter acronym they may have treated as optional: SBOM. The EU Cyber Resilience Act (CRA) entered into force on December 10, 2024, and its full obligations apply from December 11, 2027. Buried in Annex I, Part II is a requirement that manufacturers of "products with digital elements" produce and maintain a software bill of materials covering, at minimum, the top-level dependencies of the product. That single clause touches everyone shipping connected software or hardware into the European market — from a smart thermostat vendor to an enterprise SaaS platform with an EU customer base.
Teams that already generate SBOMs for U.S. Executive Order 14028 or NTIA guidance might assume they're covered. They're not automatically. The CRA layers on vulnerability disclosure timelines, conformity assessment, and penalties up to €15 million. Here's what the regulation actually requires, when it bites, and how to get ahead of it.
What Is the EU Cyber Resilience Act and Who Does It Apply To?
The CRA applies to any "product with digital elements" (PDE) placed on the EU market — meaning hardware or software with a direct or indirect data connection to a device or network. That's an intentionally broad net: it covers IoT devices, industrial control systems, mobile apps, desktop software, firmware, and cloud-connected products sold by manufacturers, importers, or distributors. Regulation (EU) 2024/2847 exempts a narrow set of categories already regulated elsewhere — medical devices under MDR, in-vehicle systems under existing automotive rules, and aviation equipment — but for most software vendors, if your product touches the network and ships to an EU customer, the CRA applies regardless of where your company is headquartered. Free and open-source software maintained by non-commercial stewards gets a lighter-touch regime, but commercial distributions of open-source components still fall under full manufacturer obligations.
What Does the CRA Actually Require in an SBOM?
The CRA requires manufacturers to identify and document, at minimum, the top-level dependencies of a product in a "commonly used and machine-readable format." Annex I, Part II, Section 1 pairs this with a broader technical documentation requirement: manufacturers must assess and document all components integrated into the product, including the origin, version, and known vulnerability status of each. Recitals reference SPDX and CycloneDX as examples of formats regulators consider acceptable, but the law doesn't mandate a single standard — it mandates traceability. In practice, "top-level" documentation is the floor, not the ceiling: European standards bodies (CEN/CENELEC) are drafting harmonized standards that are widely expected to push toward transitive dependency coverage, since a top-level-only SBOM can't answer the question regulators actually care about — is a known-vulnerable component, at any depth, present in this product.
When Do the CRA's SBOM and Reporting Deadlines Take Effect?
Two dates matter more than any other in your compliance calendar. The first is September 11, 2026 — 21 months after entry into force — when the CRA's incident and vulnerability reporting obligations become enforceable. From that date, manufacturers must notify ENISA and the relevant CSIRT of any actively exploited vulnerability within 24 hours of becoming aware of it, follow up with a detailed report within 72 hours, and deliver a final report within 14 days of a fix becoming available. The second date is December 11, 2027, when the full set of CRA obligations — CE marking, conformity assessment, SBOM documentation, and market surveillance — applies to essential and important product categories, with the remainder following shortly after. If your SBOM pipeline can't produce an accurate, current inventory fast enough to support a 24-hour disclosure clock, the deadline that matters isn't 2027 — it's whenever your first reportable vulnerability lands.
Which Products Face the Strictest SBOM Scrutiny?
Products classified as "important" or "critical" under CRA Annex III face third-party conformity assessment instead of self-assessment. Annex III splits into Class I (roughly 90 product categories including password managers, VPN clients, firewalls, and identity management software) and the smaller Class II (critical infrastructure components like industrial firewalls, secure elements, and certain operating systems). Class II products require conformity assessment by a notified body — an external auditor — while most Class I products can self-certify but must still produce full technical documentation, including the SBOM, on request. A vendor building a VPN client or an identity provider should assume auditors will ask for dependency-level evidence, not a PDF summary, and that "we can generate one if asked" is not the same as "we maintain one continuously."
What Happens If You Don't Comply?
Non-compliance carries penalties of up to €15 million or 2.5% of global annual turnover, whichever is higher — mirroring the enforcement structure of GDPR rather than a fixed, easily-budgeted fine. Market surveillance authorities in each EU member state can also order products withdrawn from sale or recalled, which for a SaaS vendor or device manufacturer is often more costly than the fine itself. Enforcement bodies are expected to prioritize products in the Annex III critical categories first, but the CRA gives every member state authority to investigate complaints and conduct spot checks across any covered product, so "we're a small player, they won't notice us" is a weaker bet under the CRA's decentralized enforcement model than it was under earlier EU cybersecurity directives like NIS2.
What Format and Tooling Approach Actually Works?
CycloneDX and SPDX are both viable, but the tooling decision that matters more than format is whether your SBOM is generated once at release or continuously as dependencies change. Point-in-time SBOM generation — the model most build-scanning tools default to — produces a document that's accurate on the day it's created and stale the next time a transitive dependency ships a patch. The CRA's 24-hour disclosure clock assumes you already know what's in your product when a new CVE drops; teams regenerating SBOMs manually or only at release time will be scrambling to answer "are we affected" instead of already knowing. This is the same operational gap that pushed SBOM tooling vendors like Anchore, Syft, and Grype into the market: generating a compliant document is the easy 80%, and keeping it accurate as dependencies drift is the hard 20% that actually determines whether you can meet a regulatory deadline.
How Safeguard Helps
Safeguard treats the SBOM as a living artifact tied to your build and deployment pipeline, not a document you generate for an audit and file away. Every build produces a CycloneDX- and SPDX-compatible SBOM automatically, mapped to transitive dependencies — not just the top-level minimum the CRA sets as a floor — so your documentation already exceeds where CEN/CENELEC's harmonized standards are heading, rather than needing rework in 2027.
When a new CVE is disclosed, Safeguard continuously correlates your existing SBOM inventory against live vulnerability feeds, so "are we affected" is answered in minutes across your full product portfolio, not researched from scratch after the fact. That matters directly for the CRA's 24-hour actively-exploited-vulnerability notification window and the 72-hour follow-up report: the evidence you need for ENISA and your CSIRT is already assembled, timestamped, and exportable, rather than something your security team has to reconstruct under deadline pressure.
For teams preparing Annex III conformity assessment — whether self-certifying Class I products or working with a notified body on Class II — Safeguard produces audit-ready documentation showing component origin, version history, and vulnerability disposition over time, which is what auditors ask for beyond a static SBOM file. And because Safeguard tracks SBOMs across your entire product line rather than one project at a time, compliance teams get a single view of CRA readiness — which products are covered, which have open critical vulnerabilities, and which are still generating SBOMs manually — instead of piecing that picture together from individual engineering teams ahead of the December 2027 deadline.
If your SBOM process today means someone running a scanner before a release, the CRA's reporting clocks will find that gap quickly. Building continuous, dependency-complete SBOM generation into your pipeline now — well before the 2026 and 2027 deadlines — is the difference between a routine compliance exercise and a scramble under regulatory pressure.