The EU Cyber Resilience Act (CRA) is the first law to make software bills of materials a legal obligation rather than a best practice. If your product contains "digital elements" and touches the EU market, you will need to produce and maintain an SBOM covering at least the top-level dependencies of every release — and be ready to report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. Reporting obligations phase in on September 11, 2026, with the bulk of the regulation applying from December 11, 2027. Many teams evaluating how to close this gap are already comparing tools like Mend.io, which built its reputation on open-source dependency scanning, against newer platforms built specifically for continuous, machine-readable compliance. This post breaks down what the CRA actually requires, where SBOM-adjacent tools fall short, and how Safeguard closes the gap between "we generated an SBOM once" and "we can prove compliance on demand."
What Does the CRA Actually Require for SBOMs?
The CRA requires manufacturers of products with digital elements to produce a software bill of materials covering, at minimum, the top-level dependencies of the product — this comes from Annex I, Part II, point 1, which lists SBOM generation as one of the mandatory vulnerability-handling requirements. The obligation isn't a one-time document: manufacturers must maintain the SBOM across the product's expected lifetime, or a minimum of five years, whichever is shorter, and update it whenever the software composition changes. The regulation doesn't mandate a single schema, but recital 61 and the harmonized standards being developed under it point toward SPDX and CycloneDX as the "commonly used, machine-readable formats" that will satisfy the requirement in practice. Critically, the CRA treats the SBOM as an input to a broader obligation: manufacturers must use it to actively track known vulnerabilities in components (including third-party and open-source ones) and remediate or patch them, not just list them.
When Do the SBOM and Reporting Deadlines Actually Hit?
The CRA entered into force on December 10, 2024, but its obligations phase in over three years, so the clock is already running even though most requirements aren't enforceable yet. The first deadline is September 11, 2026, when the incident- and vulnerability-reporting duties under Article 14 become applicable — manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of awareness, followed by a more detailed report within 72 hours. The full set of essential cybersecurity and SBOM-documentation requirements, covering nearly every article, becomes enforceable on December 11, 2027. That gives most vendors roughly 18 months from today (mid-2026) to have SBOM generation, vulnerability correlation, and reporting workflows operating in production, not just in a pilot. Waiting until late 2027 to start is not a realistic compliance strategy given how long it takes to instrument build pipelines across a real product portfolio.
What Format and Depth Does an SBOM Need to Satisfy the CRA?
An SBOM that satisfies the CRA needs to be machine-readable, cover top-level dependencies at minimum, and be regenerated whenever the software changes — a PDF exported once at release time does not meet this bar. In practice this means CycloneDX 1.5+ or SPDX 2.3+/3.0 documents that include component names, versions, licenses, and known vulnerability references, generated automatically as part of the build rather than assembled by hand. The European Commission's supporting guidance also expects manufacturers to go beyond a flat dependency list and be able to answer, for any given CVE, which of their shipped products actually include the affected component and version. That requires linking the SBOM to a live vulnerability feed and, increasingly, to VEX (Vulnerability Exploitability eXchange) statements that tell downstream customers whether a listed vulnerability is actually exploitable in the shipped configuration. A static SBOM without VEX context creates exactly the kind of alert fatigue regulators are trying to eliminate.
How Does Mend.io Handle CRA-Style SBOM Compliance Today?
Mend.io approaches this primarily as an extension of its software composition analysis (SCA) product, generating SBOMs as a byproduct of dependency scanning rather than as a first-class compliance artifact. That's a reasonable foundation for open-source license and vulnerability visibility, which is Mend's original core strength (it was rebranded from WhiteSource in 2022), but CRA compliance asks for more than a dependency inventory: it asks for continuous SBOM freshness tied to every build, VEX generation, and audit-ready reporting mapped to specific regulatory articles. Teams using Mend.io for CRA readiness often report needing to stitch together separate tooling for build provenance and attestation (SLSA-style signing), since Mend's strength is in the composition-analysis layer rather than the full software supply chain. For organizations with dozens of products and multiple release trains, that gap shows up as manual reconciliation work every time an auditor or a customer asks "prove this SBOM matches what actually shipped."
What Are the Penalties for Getting SBOM Compliance Wrong?
Non-compliance with the CRA's essential cybersecurity requirements — which include the SBOM and vulnerability-handling obligations — can result in fines of up to €15 million or 2.5% of a company's total worldwide annual turnover, whichever is higher. Failing to meet other obligations, including inadequate documentation or reporting, carries fines up to €10 million or 2% of global turnover. Market surveillance authorities in EU member states can also order products withdrawn from the market or recalled if a manufacturer can't demonstrate compliance, which is a materially higher-stakes outcome than the fine itself for companies dependent on EU revenue. Given that the reporting clock (24-hour exploited-vulnerability notification) starts in September 2026, the realistic exposure window for a company that hasn't automated its SBOM and vulnerability-correlation pipeline is not "eventually" — it's a little over a year away as of mid-2026.
Does an SBOM Alone Satisfy the CRA, or Is More Required?
An SBOM alone does not satisfy the CRA — it's one component of a broader vulnerability-handling and incident-reporting program that the regulation treats as a single obligation. Manufacturers also need a coordinated vulnerability disclosure policy, a way to distribute security updates for at least the product's support period, and the operational capability to detect, triage, and report actively exploited vulnerabilities within the 24-hour/72-hour windows set by Article 14. This is where many organizations discover that "we can export a CycloneDX file" and "we can meet a CRA audit" are two very different bars. The SBOM has to be queryable in near-real time against new CVE disclosures, and the resulting findings have to route into a workflow that produces the reports ENISA and national CSIRTs expect, in the format they expect them.
How Safeguard Helps
Safeguard is built around the assumption that compliance artifacts have to be continuous outputs of your build and deployment pipeline, not periodic exports someone remembers to generate. Safeguard automatically produces CycloneDX and SPDX SBOMs at build time, keeps them versioned against every release artifact, and continuously reconciles them against live CVE feeds so you always know which shipped products are affected by a newly disclosed vulnerability — not just which components are theoretically in scope. Where tools like Mend.io stop at dependency scanning, Safeguard extends the chain: build provenance and signing, VEX statement generation so you can tell customers and auditors which findings are actually exploitable, and tenant-aware reporting that maps directly to CRA articles (14 for incident reporting, Annex I Part II for SBOM and vulnerability handling) rather than generic SCA output. For security and compliance teams racing the December 2027 deadline, that means the difference between assembling evidence manually every quarter and being able to answer an auditor's question — or a customer's procurement questionnaire — in minutes, with a live, verifiable record instead of a snapshot. If you're mapping your CRA readiness timeline now, Safeguard can show you exactly where your current SBOM and vulnerability-management setup has gaps before September 2026 makes that a reporting problem instead of a planning one.