Ask most engineering or security leads when their organisation needs to comply with the Cyber Resilience Act, and the answer almost always comes back the same: December 2027. That answer is incomplete in a way that matters. A separate set of obligations under the regulation — vulnerability reporting on a 24-hour clock — becomes enforceable on September 11, 2026, and it applies to products already shipped, not just future releases. The September date is easy to miss because most CRA coverage leads with the 2027 deadline and treats everything else as a footnote.

There is also a dependency between the two dates that doesn’t get discussed enough: reporting a vulnerability within 24 hours of becoming aware of it is only possible if you already know, with certainty, whether that vulnerability exists somewhere in your product. That certainty comes from an SBOM. Without one in place well before September, the reporting clock starts running on a product you effectively cannot see into. This guide walks through what an SBOM is, the three CRA deadlines that actually matter, and how to build a readiness plan that treats SBOM generation as an operational system rather than a one-time compliance document.

What an SBOM Actually Is

An ingredient list for software

A Software Bill of Materials is exactly what the name suggests: a complete, structured inventory of every component, library, and dependency that makes up a piece of software. Think of it the way you’d think of an ingredient list on packaged food — except instead of listing flour, sugar, and preservatives, an SBOM lists every open-source library, third-party package, and internal module that was compiled into your application. When a vulnerability is disclosed in a widely used library, an organisation with an accurate SBOM can check exposure in minutes. An organisation without one has to manually audit every codebase to find out whether they’re affected — a process that, for major open-source vulnerabilities affecting widely embedded libraries, has historically taken many teams weeks, during which the vulnerability was actively being exploited.

The modern enterprise application is built from a large amount of third-party code, and that share keeps growing every year. An SBOM is the only practical way to maintain visibility into a codebase that size without manually tracking every dependency by hand.

CycloneDX vs SPDX — which format matters for the CRA

Two machine-readable formats dominate SBOM generation today: CycloneDX and SPDX. CycloneDX has emerged as the more widely used standard for security-focused use cases, while SPDX remains strong for license compliance documentation. The CRA does not mandate a specific format, but it does require that SBOMs be machine-readable and commonly used — both formats qualify, and the European Commission retains the authority to specify exact format requirements as implementation guidance matures.

The practical advice for teams starting now: pick one, standardise on it across every product, and avoid switching later. Inconsistent formats across a product portfolio create exactly the kind of fragmentation that makes vulnerability correlation slow and unreliable — the opposite of what an SBOM is supposed to deliver.

The Three CRA Deadlines That Matter

The Cyber Resilience Act entered into force on December 10, 2024, but its obligations apply on a staggered timeline — and most of the public conversation has focused on the wrong one.

June 11, 2026 — conformity assessment bodies designated

The first procedural deadline requires EU member states to designate the conformity assessment bodies that will eventually certify higher-risk products under the CRA. For most software teams, this date passed quietly and changed little day to day — but it marks the point at which the regulatory infrastructure behind the CRA becomes operational rather than theoretical.

What this actually means in practice is that the certification ecosystem is now standing up. Higher-risk products — those classified as Class I or Class II under the CRA, which includes things like network management software, VPNs, operating systems, and certain industrial control interfaces — will need third-party conformity assessment before they can carry the CE marking required for EU market access. The designation of assessment bodies is what makes that process possible. For teams building products that fall into those higher-risk categories, June 2026 is the moment to start identifying which notified body will eventually assess their product and what that process will require, rather than treating it as someone else’s problem until December 2027 is approaching.

September 11, 2026 — the deadline hiding in plain sight

This is the date that actually matters for engineering and security teams right now. From September 11, 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe security incidents on a strict escalating timeline: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days once a fix or mitigation exists. Critically, this obligation applies to products already on the market — it doesn’t matter if your product shipped in 2019. If it’s still in use and a vulnerability in it is being actively exploited, you must detect and report it starting this September.

December 11, 2027 — full compliance, SBOM mandatory in technical documentation

This is the deadline most teams have correctly identified as significant, but incorrectly treated as the only one. By this date, the CRA’s full set of obligations apply: secure-by-design requirements, conformity assessment, CE marking, mandatory SBOM generation as part of technical documentation, and the formal duty to provide security updates for the product’s expected support lifetime. An SBOM must be in a machine-readable format covering, at minimum, the top-level dependencies of the product, and must be retained for ten years after the product is placed on the market.

Why SBOM Readiness Can’t Wait for 2027

The 24-hour clock assumes an inventory that may not exist

This is the dependency that connects the September 2026 deadline directly back to SBOM readiness. To report an actively exploited vulnerability within 24 hours, your team needs to know, immediately, whether that vulnerable component exists anywhere in your product — the same blind spot that makes supply chain attacks so effective in the first place. Without an SBOM and a vulnerability monitoring process already in place, that determination can take days or weeks of manual investigation — time the CRA’s reporting clock does not pause for. In practice, this means SBOM readiness is effectively required at least a year before its formal 2027 deadline, because the infrastructure it provides is the only thing that makes the September 2026 reporting obligation achievable at all.

The penalty structure mirrors GDPR

The financial exposure for getting this wrong is severe: fines can reach €15 million, or 2.5% of a company’s global annual turnover, whichever figure is larger. That scale of fine puts CRA enforcement in the same bracket as GDPR — and European regulators have shown, repeatedly, that they enforce GDPR-scale penalties aggressively rather than treating them as theoretical ceilings. For any organisation selling software or connected products into the EU market, this is not a regulation that rewards a wait-and-see approach.

Scope is broader than most teams assume

One of the most common mistakes in early CRA planning is assuming the regulation only applies to companies headquartered in the EU, or only to traditional software vendors. Neither assumption holds. The CRA applies to manufacturers, importers, and distributors of any product with digital elements placed on the EU market — regardless of where the manufacturer is based. A company in the United States or Asia selling a connected device or a SaaS platform to European customers falls squarely within scope, as does any business that imports or distributes someone else’s digital product under its own brand.

The definition of “product with digital elements” is also wider than most teams expect at first read: it covers not just standalone software, but firmware, IoT devices, industrial control systems, and software embedded in otherwise non-digital products. Before assuming a product sits outside CRA scope, it is worth checking that assumption explicitly — the cost of being wrong, discovered after September 2026, is considerably higher than the cost of checking now.

From Static Document to Operational System

The shift from “checkbox SBOM” to continuous vulnerability correlation

A significant portion of organisations that already generate SBOMs do so as the last step in a build process — producing a document that satisfies a compliance checkbox but isn’t actually integrated into how vulnerabilities get detected or triaged. That approach technically produces an SBOM, but it doesn’t produce the operational capability the CRA’s reporting deadline actually requires. The distinction that matters in 2026 is between a static SBOM — a point-in-time export nobody looks at again until the next audit — and an operational one, continuously correlated against live vulnerability feeds so that when a new CVE is disclosed, your team knows within minutes, not weeks, whether it affects a product you’ve shipped.

The practical difference shows up clearly when a new vulnerability is disclosed in a widely used library. With a static, checkbox SBOM, the typical response is reactive: someone sees a security bulletin, manually searches old release documentation to check whether the affected library version was used, and reports back days later — often after escalation, several Slack messages, and at least one person digging through a build log from six months ago. With an operational SBOM connected to a vulnerability feed, the same disclosure triggers an automatic match against every current SBOM in the portfolio, surfacing affected products within minutes rather than days. That difference is not a nice-to-have efficiency gain — for products in CRA scope, it is the only realistic way to meet a 24-hour reporting window once that obligation becomes enforceable.

Where SBOM fits with supply chain security practices already in place

For teams that have already invested in container security and broader software supply chain protections , SBOM generation is a natural extension rather than a new discipline. Container images, in particular, are a natural point to generate SBOMs automatically, since the build process already has full visibility into every layer and dependency being packaged. Teams running mature container security practices are typically closer to CRA readiness than they realise, because the visibility infrastructure largely already exists — it just needs to be connected to a vulnerability reporting workflow rather than left as a standalone artifact.

It is also worth knowing that SBOM is not the final word on supply chain transparency, even if it is the part the CRA makes mandatory first. The Linux Foundation’s SLSA framework (Supply-chain Levels for Software Artifacts) extends the same principle from “what is in this software” to “how was this software built” — verifying that build pipelines themselves are secure, not just cataloguing their output.

SLSA is not currently a CRA requirement, but it represents the direction supply chain security is heading, and organisations that build SBOM generation into a properly secured CI/CD pipeline from the start are effectively laying the groundwork for SLSA adoption later, rather than treating each new framework as a separate project.

Building Your SBOM Readiness Plan

Inventory every in-scope product first

Before generating a single SBOM, map every product, service, and software offering your organisation ships into the EU market against the CRA’s definition of a “product with digital elements.” This includes embedded firmware, mobile applications, and any remote data processing components — the scope is broader than most teams initially assume, and missing a product during this inventory stage means missing it for the entire compliance programme.

A practical way to run this inventory is to work backwards from your distribution channels rather than forwards from your engineering teams. Start with everything your organisation sells, licenses, or makes available in the EU market — then apply the CRA scope criteria to each item. This approach tends to surface products that engineering teams wouldn’t naturally think of as “software products,” such as devices with embedded firmware or SaaS platforms with client-side components, precisely because it starts from the commercial reality rather than the technical one. Assign a named owner to each in-scope product at this stage too — the CRA’s obligations attach to the manufacturer, which means accountability needs to be clear before the compliance programme goes any further.

Choose CycloneDX or SPDX and stay consistent

Once scope is defined, standardise on one SBOM format across the entire portfolio. Switching formats partway through a compliance programme creates exactly the kind of fragmentation that slows down vulnerability correlation — the operational capability the whole exercise is meant to deliver.

If you’re starting from scratch with no existing tooling preferences, CycloneDX is the more pragmatic default choice for security-focused use cases in 2026 — it has broader tooling support, stronger integration with vulnerability databases, and a more active development community around security-specific extensions. SPDX remains the right choice if license compliance is as important to your programme as vulnerability management, since its license expression syntax is more mature. Either way, the consistency of the choice matters more than the choice itself — a portfolio of mixed-format SBOMs is harder to query, harder to correlate against vulnerability feeds, and harder to present to an auditor than a uniform set of files in one format, even if that format is technically the less optimal one for your specific use case.

Automate generation in the CI/CD pipeline, don’t bolt it on at release

SBOMs generated manually at release time are already out of date by the time they’re produced, and they reinforce the checkbox mentality rather than the operational one. Generating SBOMs automatically as part of the CI/CD pipeline — at build time, for every release — keeps the inventory current and removes the dependency on someone remembering to run the process manually. This is the same automation discipline that mature DevSecOps pipelines already apply to security scanning more broadly, and SBOM generation fits naturally alongside it rather than as a separate workflow.

Connect SBOM data to a vulnerability feed before September

Generating accurate SBOMs is necessary but not sufficient — the readiness plan isn’t complete until those SBOMs are actually wired into a vulnerability monitoring process that can flag exposure automatically. This means connecting your SBOM inventory to sources like the CISA Known Exploited Vulnerabilities catalogue, GitHub Security Advisories, or a commercial vulnerability intelligence feed, and setting up alerting so that a new disclosure against a known component triggers a review without anyone needing to go looking for it.

Teams that complete the first three steps but skip this one often end up with an accurate, current SBOM that nobody is actually watching — which technically satisfies the December 2027 documentation requirement, but does nothing for the September 2026 reporting obligation that depends on knowing about exposure in near real time. Building this connection now, while the deadline is still months away, is considerably less stressful than trying to wire it together during an active incident.

The Runway Is Shorter Than It Looks

The CRA will reshape how European software is built and shipped the same way GDPR reshaped data handling — and the organisations that treat SBOM generation as a forcing function for genuine supply chain visibility, rather than a paperwork exercise, will be the ones that aren’t scrambling when September arrives. Most organisations need well over a year to build the engineering, documentation, and reporting capability the regulation actually requires. Counted from today, that runway to September 11, 2026 is already short — and the work of inventorying products, standardising formats, and automating generation takes real time to embed properly into existing pipelines.

If your team needs help assessing CRA readiness, building SBOM generation into your pipeline, or connecting it to a working vulnerability reporting process, contact us.