SBOM Compliance Checklist 2026 — Five Phases to CRA Conformity

Product inventory — map the digital landscape (Q2 2026)

Before an SBOM can be generated, the organisation needs a clear picture of which products actually fall under the CRA. This sounds trivial but rarely is: many companies lack a complete inventory of their products with digital elements, particularly when firmware, embedded components or OEM software are involved.

• Identify all products with digital elements (hardware with software, standalone software, firmware)
• Classify each product by CRA category: default, important Class I, important Class II, critical (Annexes III and IV)
• Check whether sector-specific exemptions apply (medical devices, vehicles, aviation, defence)
• Determine the responsible manufacturer in the CRA sense for each product (Art. 3(16))
• Define the support period per product (Art. 13(8): expected useful life, minimum 5 years)
• Assess existing dependency management: are lock files, manifest files or dependency scans already in use?

The deliverable of this phase is a product register with CRA classification. Without it, there is no basis for the conformity assessment under Art. 32 — and therefore no CE marking.

Set up the toolchain — format, generator, signing (Q2–Q3 2026)

The SBOM toolchain consists of three elements: a format standard, a generator, and a signing mechanism. All three must be aligned before the first production SBOM is created.

• Choose SBOM format: CycloneDX (OWASP, built-in VEX support) or SPDX (ISO/IEC 5962:2021, stronger license metadata)
• Integrate SBOM generator into CI/CD: Syft (containers), cdxgen (Node.js, Java, polyglot), Trivy (containers + filesystem), CycloneDX plugins (Maven, Gradle, pip)
• Define namespace and versioning scheme (Package-URL/purl as identifier, product version as SBOM reference)
• Set up signing with cosign — SBOM is signed alongside the release artefact
• Select artefact repository for SBOM storage (OCI registry, Nexus, Artifactory)
• Pilot run: generate SBOM for one product, sign it, store it, scan it with Grype/Trivy against NVD

Recommendation for greenfield projects: choose CycloneDX. Its integrated VEX support significantly simplifies the vulnerability reporting workflow in Phase 4. Teams already using SPDX (e.g. Yocto-based embedded Linux) should stay on SPDX — a format migration creates more friction than benefit. For companies that must comply with both the CRA and US EO 14028, note that NTIA minimum elements align well with both CycloneDX and SPDX, so the format choice does not affect US compliance.

Establish the SBOM process — automation and retention (Q3 2026)

A manually maintained SBOM has no regulatory value. The CRA demands traceability: which components were in which build, when was the SBOM generated, who signed it. That is only achievable with a fully automated process.

• Automate SBOM generation on every build (CI pipeline step, no manual intervention)
• Couple SBOM to release artefact: same version number, same signing cycle
• Ensure versioning in the artefact repository (each SBOM uniquely mapped to a product release)
• Implement retention: archive SBOMs for at least 5 years or the product's support period
• Maintain an internal full transitive dependency graph, even if the shipped SBOM only covers top-level dependencies
• Wire vulnerability monitoring: SBOM data flows automatically into scanners (Dependency-Track, Grype, Trivy)

A common mistake at this stage: the SBOM is generated in CI but never archived long-term. CI artefact retention is typically 30 days — nowhere near the 5-year obligation. Retention belongs in release management, not in the CI system. For global companies, consider that US federal contracts under EO 14028 may require SBOMs to be delivered to the acquiring agency on request, adding a distribution requirement on top of retention.

Vulnerability reporting goes live (by 11 September 2026)

The reporting obligations under Art. 14 CRA take effect on 11 September 2026 — fifteen months before full CRA application. From that date, manufacturers must report actively exploited vulnerabilities to the relevant CSIRT within 24 hours. ENISA coordinates the EU-wide single reporting platform; each member state designates a national CSIRT. For companies selling into multiple EU markets, reports go to the CSIRT of the member state where the manufacturer has its main establishment.

• Make the SBOM operational for CSIRT reporting: given a vulnerability in component X, immediately determine which products and versions are affected
• Define the 24-hour response chain: vulnerability detected → affected products identified (via SBOM) → initial report to CSIRT
• Set up reporting channels (ENISA single reporting platform, expected live September 2026)
• Produce VEX documents (Vulnerability Exploitability eXchange) for each reported vulnerability: product affected / not affected / under investigation
• Document the internal escalation process: who decides on exploitability, who files the report, who notifies customers
• Run a dry-run: simulate a vulnerability in a component, execute the full process chain through to CSIRT notification

Full documentation and CE conformity (by 11 December 2027)

From 11 December 2027, only CRA-compliant products may be placed on the EU market. The SBOM is one element of the technical documentation required under Annex II. Without complete technical documentation there is no EU declaration of conformity — and without the declaration, no CE marking. For companies also serving US federal customers, the SBOM simultaneously satisfies EO 14028 requirements if it includes NTIA minimum elements.

• Integrate the SBOM into the technical documentation under Annex II
• Perform conformity assessment under Art. 32: default products via self-assessment (Module A), Class I via harmonised standards or third-party audit, Class II and critical products require a notified body
• Draft the EU declaration of conformity per Annex V
• Affix CE marking (Art. 28)
• Establish coordinated vulnerability disclosure (CVD) per Art. 15
• Publish contact details for third-party vulnerability reports (Art. 13(6))

For products classified as important Class II or critical, lead time is decisive: notified bodies have limited capacity, and the first audits against harmonised standards are not expected to be available before mid-2027. Late starters risk market access delays. Organisations operating globally should plan for parallel compliance with the US Cybersecurity and Infrastructure Security Agency (CISA) SBOM guidance and the Japanese METI software transparency initiative, both of which are converging on the same SBOM baseline.