The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024, and most roadmaps filed it as a "2027 problem": every requirement — secure-by-design, conformity assessment, CE marking, a mandatory SBOM and security updates across the whole support period — applies from 11 December 2027. But there is an earlier date that is easy to miss, and it is the one that turns an SBOM from a roadmap line into an operational necessity.
The real deadline is 11 September 2026
The reporting obligations take effect on 11 September 2026. A manufacturer of a product with digital elements must report actively exploited vulnerabilities and severe incidents: an early warning to ENISA within 24 hours, a full notification within 72 hours, and a final report no later than 14 days after a fix becomes available. Formally, the SBOM is not yet mandatory at that point. But look at the mechanics: a report lands about an exploited CVE in a popular library, and you have a day to work out whether a single one of your products is affected. Without a machine-readable inventory of components that is not a 24-hour task — it is a panic with grep across repositories. Reporting without an SBOM is physically impossible, which is why the real deadline for an inventory is not December 2027 but September 2026.
What the CRA actually requires of an SBOM
Two myths have grown around the requirement, and both are expensive. The first: "you will have to publish the SBOM." You will not. The CRA (Annex I, Part II) puts the SBOM into the technical documentation, and it is disclosed only to market surveillance authorities on a reasoned request. It is a compliance artefact for the regulator, not a marketing document on your website. The second myth: "you must list everything down to the last transitive dependency." The law asks for the minimum — top-level dependencies in a commonly used machine-readable format. Listing nested sub-components is good engineering and the basis for real vulnerability tracking, but the depth is your call, not the letter of the regulation.
The practical takeaway: the format is SPDX (ISO 5962) or CycloneDX (OWASP), both machine-readable and industry-accepted. CycloneDX leans toward security workflows (it carries a vulnerability model and VEX), SPDX toward license and legal. Generation itself is the solved part: syft or trivy produce an SBOM from an image in a single command.
Generating the SBOM is 20% of the work
The temptation to close the task with one CI line is misleading. syft image:tag -o spdx-json is the easy 20%. The other 80% is operational:
- Storage and binding. An SBOM left as a CI-job artefact is undiscoverable from the deployment. Bind it to the image as a signed attestation (
cosign attest --type spdxjson) or keep it centrally in Dependency-Track / GUAC. - Continuous scanning. An SBOM captures the composition at build time; vulnerabilities are disclosed later. Re-scan stored SBOMs (Grype, Trivy) on a schedule, not only during the build — that is how you find the affected product within 24 hours.
- VEX against the noise. Without a Vulnerability Exploitability eXchange the security backlog drowns in false positives, and the one real exploited CVE is lost among hundreds of inapplicable ones. The note "not affected because the code is not on the execution path" is what makes the 24-hour report achievable.
An SBOM is "what's inside," but the CRA also looks at "how it was built"
An SBOM answers the question "what is the artefact built from." The secure-by-design and tamper-resistance requirements push toward a second question — "how was it built." This is where SLSA-style provenance works: a verifiable chain from commit to image (who, on which commit, in which builder, signed by what). SBOM and provenance complement each other — together they deliver the supply chain transparency the CRA was conceived for. The good news: OpenSSF and the regulators are moving toward unifying SBOM standards, so investing in the CNCF stack (Syft/Grype, Cosign, Sigstore) is not throwaway work but a bet aligned with the common direction.
What to do before September 2026
Reduce the task to four points that are verifiable today. First, SBOM generation on every build as a mandatory pipeline stage, in CycloneDX or SPDX. Second, storage and attestation, so the SBOM is discoverable from the deployment rather than dying in CI. Third, continuous re-scanning of stored SBOMs plus VEX, to separate the exploitable from the noise. Fourth, the organizational process: who receives the signal about an actively exploited CVE, who checks exposure within 24 hours, and who presses the report button at ENISA. The first three are tools you can stand up in a sprint. The fourth is a runbook, and it is usually the one that lags. There is less time before September 2026 than it seems: "we have an SBOM" and "with the SBOM we can answer the regulator within a day" are different levels of readiness.