The CRA SBOM Mandate — What to Do Before 11 September 2026

The Divergence: One Regulation Advances as Another Retreats

In the first half of 2026, the two largest software markets in the world moved in opposite directions on supply-chain transparency.

On 23 January 2026, the White House Office of Management and Budget issued Memorandum M-26-05, revoking M-22-18 and M-23-16. Those two memoranda had required federal software suppliers to complete a standardised self-attestation form and, in many cases, provide a Software Bill of Materials. After M-26-05, both the attestation requirement and the SBOM provision became agency-discretionary — individual agencies may still ask for them, but there is no government-wide mandate. That shift was reinforced by Executive Order 14306, signed on 6 June 2025, which withdrew the enhanced software-attestation machinery introduced by EO 14144.

The practical effect: as of early 2026, there is no federal US requirement for software suppliers to provide an SBOM. Agencies that built procurement workflows around M-22-18 compliance must now decide individually whether to continue requiring it.

In Brussels, the trajectory is the opposite. The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — was adopted on 23 October 2024, published in the Official Journal on 20 November 2024, and entered into force on 10 December 2024. It imposes binding SBOM obligations on manufacturers of products with digital elements that are placed on the EU market. These are not voluntary guidance or agency-level discretion. They are legal requirements backed by a penalty regime that extends to 2.5% of global annual turnover.

The divergence matters for any manufacturer that sells software or hardware to both markets. What was converging toward a common transatlantic baseline has split. US federal compliance may become lighter-touch; EU compliance will become more demanding. Organisations operating across both jurisdictions cannot treat their supply-chain transparency programmes as a single exercise. They now need to understand exactly what the CRA requires, from whom, and by when.

CRA Scope: Products With Digital Elements

The CRA applies to "products with digital elements" — a broad category that the regulation defines to cover any software or hardware product and its remote data processing solutions, provided it is intended to be connected directly or indirectly to another device or network.

This reaches far beyond traditional software vendors. The regulation covers:

• Software products sold, licensed, or made available, including software as a service where the SaaS component is integral to the product's functionality and is supplied alongside it
• Hardware products that contain embedded software — industrial controllers, consumer IoT devices, routers, medical devices with network connectivity, and connected components
• Open-source software that is commercialised — where a natural or legal person places software in the course of commercial activity (including through monetisation, technical support, or integration into a commercial product)

Three categories of economic operator bear obligations: manufacturers (who develop or substantially modify the product and place it on the market), importers (who place a product manufactured outside the EU on the EU market under their own name), and distributors (who make the product available on the EU market). The deepest obligations — including the SBOM requirement — sit with manufacturers. Importers and distributors carry lighter duties but must verify manufacturer compliance and act when they discover non-conformity.

Free and open-source software that is not commercialised is explicitly outside the CRA's scope for the developer. A company that integrates open-source components into a commercial product, however, is acting as a manufacturer in respect of that product — and the SBOM obligation applies to what they ship.

The regulation does carve out certain categories: medical devices (already regulated under MDR/IVDR), civil aviation products (covered by EASA), motor vehicles (under the type-approval framework), and national security and defence products. Software exclusively designed for research and development prototyping is also excluded, provided it is not yet placed on the market.

For anyone else building connected products — enterprise software, operational technology, network infrastructure, consumer electronics, or cloud-connected devices — the CRA applies.

The Timeline: Three Dates That Define Your Obligation

The CRA's phase-in structure is deliberate. Three dates define what is required and when.

The 11 September 2026 date — less than three months away — is the first hard deadline with enforcement teeth for most manufacturers. Article 14 requires manufacturers to notify ENISA without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability in their product. A detailed notification with remediation information follows within 72 hours. Severe incidents affecting the security of the product carry the same 24-hour initial notification requirement. These are not aspirational timelines. They require operational readiness: a vulnerability management programme that can detect exploitation, a process that can generate a ENISA-format notification within a working day, and clear internal ownership of that process.

The 11 December 2027 deadline governs the full set of essential requirements, which includes the Annex I SBOM obligation. However, manufacturers who wait until late 2027 to start SBOM work face two practical problems. First, harmonised standards to support SBOM generation are expected to finalise around August 2026 (Standardisation Request M/606 deadline); the window between standard publication and CRA full application is roughly fifteen months — not long if tooling, processes, and supplier agreements need to be built from scratch. Second, notified-body conformity assessment for Class II products can take 6 to 12 months. Manufacturers who need third-party assessment cannot start that process in autumn 2027 and expect to meet the December deadline.

The 11 September 2026 horizon is the more immediate pressure point. But the work needed to meet it — vulnerability tracking, incident management, ENISA reporting infrastructure — is foundational to the full CRA compliance programme that culminates in December 2027.

The SBOM Mandate: What the Regulation Actually Requires

The SBOM requirement sits in Annex I, Part II, point (1) of the CRA, under the heading "Vulnerability handling requirements." It states that manufacturers must:

draw up and maintain a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.

Several elements of this text deserve attention.

"Commonly used and machine-readable format." The CRA does not name SPDX or CycloneDX. It requires a format that is both commonly used in the industry and machine-readable. In practice, the two formats that meet this description are SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424). Both have broad tooling support and are widely used across regulated sectors. Manufacturers have discretion, but choosing an obscure proprietary format would not satisfy the "commonly used" criterion. Harmonised standards expected from CEN/CENELEC and ETSI working groups (under M/606) will likely provide further specificity, and BSI's Technical Guideline TR-03183 already pushes toward CycloneDX for German federal systems.

"At the very least the top-level dependencies." This is the legal floor. Direct dependencies — the libraries and components that the manufacturer's own code explicitly references — must be documented. Transitive dependencies (the dependencies of dependencies) are not mandated by the regulation's text. However, "at the very least" is language that anticipates upward movement. Harmonised standards being developed under M/606, accepted by CEN/CENELEC/ETSI in April 2025, have a delivery deadline of 30 August 2026. The vulnerability-handling deliverable that maps to SBOM (produced by WG9) is expected to push toward transitive dependency coverage as a recommended practice even if the regulation's minimum stays at top-level. BSI TR-03183 already recommends transitive coverage for products within the German federal procurement context. Manufacturers building tooling and processes only to the top-level floor risk needing to rebuild when standards shift the expected baseline.

Not required to be public. Recital 77 of the CRA is explicit: manufacturers are not obliged to publish their SBOM. The obligation is to draw up and maintain it, and to make it available to market surveillance authorities on request. This is a significant difference from some US-sector contexts (where FDA guidance for medical devices recommends SBOM disclosure to device purchasers, for example). Under the CRA, the SBOM is a compliance document — maintained internally, available to regulators, and not required to be shared with customers, competitors, or the public. Manufacturers with commercially sensitive dependency information have legitimate reasons to keep SBOMs non-public; the CRA accommodates that.

Maintained, not static. The word "maintain" in the obligation implies ongoing upkeep. A one-time SBOM generated at initial product release does not satisfy the requirement if the product's software components change through updates, patches, or versioning. Manufacturers need processes to regenerate or update the SBOM when software composition changes — and to link SBOM updates to their vulnerability management workflow, since the CRA's Article 14 reporting obligations depend on knowing exactly what components are in the field.

Penalties: The Enforcement Arithmetic

Article 64 of the CRA establishes a three-tier administrative penalty regime.

Tier 1 — Non-compliance with essential requirements (Annex I): The higher of €15,000,000 or 2.5% of total worldwide annual turnover in the preceding financial year. The SBOM obligation in Annex I Part II(1) sits at this tier. So does non-compliance with security requirements in Annex I Part I — things like default secure configurations, authenticated updates, minimisation of attack surface, and cryptographic hygiene.

Tier 2 — Non-compliance with other CRA obligations (conformity assessment, technical documentation, EU Declaration of Conformity, CE marking, product withdrawal): The higher of €10,000,000 or 2% of worldwide annual turnover.

Tier 3 — Providing incorrect, incomplete, or misleading information to notified bodies or market surveillance authorities: The higher of €5,000,000 or 1% of worldwide annual turnover.

Market surveillance authorities in each EU Member State will be responsible for enforcement. The regulation also gives the Commission power to request coordinated enforcement action across Member States for products that present a serious risk across the single market. Penalties apply to the economic operator responsible — manufacturers face the Tier 1 regime for Annex I non-compliance; importers and distributors face graduated penalties depending on what obligation they violated.

For context on scale: a company with €500 million in global annual turnover that fails to maintain an SBOM faces a potential penalty of €12.5 million (2.5%). A company with €5 billion in turnover faces €125 million. These are not rounding errors in a compliance budget.

The CRA also allows Member States to impose additional measures, including market withdrawals, prohibitions on making the product available, and product recalls, where a product presents a significant cybersecurity risk.

Readiness Checklist: What to Do Before 11 September 2026

With the Article 14 reporting deadline eleven weeks away at time of publication, the following work is the minimum needed to be operationally compliant by 11 September 2026, and foundation work for the December 2027 full requirements.

1. Confirm whether the CRA applies to your products

Map your product portfolio against the CRA scope. Products with digital elements intended for the EU market are in scope unless they fall under a specific carve-out. For manufacturers with mixed portfolios — some products EU-facing, some not — this scoping exercise is not optional. Selling a single connected product into an EU Member State brings CRA obligations.

2. Classify products by risk tier

The CRA creates three risk tiers. Most products fall under the default regime (Article 27 — internal control). Important products in Class I and Class II (listed in Annexes III and IV respectively) face stricter conformity assessment requirements, including mandatory third-party assessment for Class II. The classification drives your conformity assessment pathway and timeline. If any of your products are Class II candidates, notified-body engagement must start now — the assessment process takes 6 to 12 months.

3. Stand up Article 14 reporting capability

Before 11 September 2026, manufacturers must be operationally ready to:

• Detect an actively exploited vulnerability in a shipped product within hours of public or private disclosure
• File a 24-hour initial notification with ENISA using the required format
• Follow up with a detailed notification within 72 hours covering the vulnerability, affected versions, and remediation status
• Issue an early warning for severe incidents affecting product security within 24 hours

This requires a documented vulnerability management process, a mechanism to correlate external vulnerability intelligence (CVE feeds, vendor advisories, researcher reports) against your deployed component inventory, and a named owner with authority to trigger the ENISA notification. If you do not have this today, building it is the September 2026 critical path.

4. Begin SBOM generation for each in-scope product

Even though the Annex I SBOM obligation does not apply until December 2027, beginning SBOM generation now serves three purposes. First, you will need component-level visibility for Article 14 vulnerability reporting — you cannot rapidly assess which products contain a newly exploited component if you have no structured dependency inventory. Second, harmonised standards expected by August 2026 may clarify format and depth requirements; having a first-generation SBOM allows you to validate against standards as they publish rather than starting from zero. Third, notified bodies conducting conformity assessments will examine your technical documentation, which must describe vulnerability handling processes — a maintained SBOM is evidence of a functioning process.

Generate SBOMs in SPDX or CycloneDX. Automate generation as part of your build pipeline where possible. Cover top-level dependencies at minimum; begin extending toward transitive coverage, particularly for components in categories with high historical vulnerability rates (logging libraries, networking stacks, XML parsers, cryptographic libraries).

5. Engage your supply chain

The CRA's Annex I Part I requirements include obligations to handle vulnerabilities in components — which means knowing what third-party and open-source components your products contain and being able to act when those components are found to be vulnerable. Suppliers who provide software components should be asked for their own SBOM data and vulnerability disclosure commitments. Contracts entered or renewed after the CRA's entry into force should include provisions for timely vulnerability notification, SBOM provision, and cooperation on regulatory reporting.

6. Prepare technical documentation

Article 31 of the CRA requires manufacturers to draw up and maintain technical documentation that enables conformity assessment. This includes a description of the product's design and manufacturing process, the cybersecurity risk assessment, the essential requirements addressed, the vulnerability handling procedures, and the SBOM. This documentation must be available to market surveillance authorities. It should be treated as a living document, updated when the product changes, when new vulnerabilities are discovered, or when the compliance posture changes.

7. Monitor harmonised standards development

The Standardisation Request M/606 was accepted by CEN/CENELEC/ETSI in April 2025. Working groups across the three organisations are developing 41 standards mapped to CRA requirements. The vulnerability-handling deliverable (WG9, the SBOM-relevant standard) has an adoption deadline of 30 August 2026 — roughly two weeks before Article 14 applies. Once published, compliance with harmonised standards creates a presumption of conformity with the corresponding CRA essential requirements. Following draft standards as they develop — and adjusting your programme to align — is significantly cheaper than retrofitting after final publication.

Cross-References and Further Reading

For the regulatory context, the CRA page in Orizon's Regulatory Intelligence hub covers the full requirement structure, scope guidance, and relationship to NIS2. The CRA and NIS2 interact directly: entities in NIS2's essential and important sectors that manufacture products with digital elements are subject to both regimes simultaneously, with overlapping incident reporting obligations and complementary but distinct security requirements.

For supply-chain security consulting and third-party risk programme design, the Orizon TPRM service addresses the supplier-side of CRA compliance — assessing vendor SBOMs, contractual vulnerability notification requirements, and third-party component risk.

The SBOM Standards Library tracks the primary SBOM-related regulatory instruments, standards, and guidance documents across both the EU and US — with live status indicators for each. The CRA-relevant instruments in the library at time of publication include:

• Cyber Resilience Act — Regulation (EU) 2024/2847

  In forceBinding

  European Union · 2024-12-10

  SBOM mandatory (Annex I Part II(1)). Reporting 11 Sep 2026; full 11 Dec 2027.

  View source ↗Verified 2026-06

• Executive Order 14306 — Sustaining Select Efforts to Strengthen the Nation's Cybersecurity

  FinalVoluntary

  US White House · 2025-06-06

  Struck EO 14144's attestation machinery; retains a NIST SSDF track; no explicit SBOM requirement.

  View source ↗Verified 2026-06

• US federal SBOM requirement (post-M-26-05)

  DiscretionaryVoluntary

  US OMB · 2026-01-23

  After OMB M-26-05 rescinded M-22-18/M-23-16, federal SBOM is agency-discretionary — no government-wide mandate. The EU CRA (binding) contrast is the article thesis.

  View source ↗Verified 2026-06

• OMB M-26-05 — Risk-based Approach to Software and Hardware Security

  FinalVoluntary

  US OMB · 2026-01-23

  Made federal SBOM/attestation discretionary; rescinded M-22-18 + M-23-16.

  View source ↗Verified 2026-06

The regulatory divergence described in the opening of this article is visible directly in that table: binding EU instruments (CRA, force: binding) alongside voluntary and discretionary US instruments (EO 14306, OMB M-26-05, force: voluntary / discretionary). The contrast is not a matter of degree — it is a structural difference in the enforcement architecture.

Sources

1. EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act): Annex I Part II(1) (SBOM obligation), Recital 77 (non-public), Article 14 (reporting obligations), Article 64 (penalties), Article 71 (application dates). https://eur-lex.europa.eu/eli/reg/2024/2847/oj

2. Federal Register — Executive Order 14306 (6 June 2025): "Sustaining Select Efforts to Strengthen the Nation's Cybersecurity" — withdrew EO 14144's enhanced software-attestation machinery. https://www.federalregister.gov/documents/2025/06/11/2025-10804/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694

3. White House OMB — M-26-05 (23 January 2026): "Adopting a Risk-based Approach to Software and Hardware Security" — rescinded M-22-18 and M-23-16, making federal SBOM provision and software attestation agency-discretionary. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf

4. European Commission / CEN-CENELEC / ETSI — Standardisation Request M/606: Commission Implementing Decision C(2025)618, mandating 41 standards for CRA implementation. Accepted by CEN/CENELEC/ETSI on 3 April 2025; WG9 vulnerability-handling deliverable (SBOM-relevant) has an adoption deadline of 30 August 2026. https://digital-strategy.ec.europa.eu/en/news/commission-issues-standardisation-request-support-cyber-resilience-act

5. CISA — The Minimum Elements for a Software Bill of Materials: The 2021 NTIA baseline defined seven data fields (Supplier, Component Name, Version, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, Timestamp). CISA's 2025 update — a pre-decisional draft as of mid-2026 — adds four (component hash, license, tool name, generation context), renames Depth to Coverage (extending the expectation toward transitive dependencies), and drops SWID from its recognised formats. The EU CRA does not specify fields, but the CISA minimum elements provide a practical starting baseline for format design. https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom