CRA SBOM Requirements 2026: Software Bill of Materials for EU Compliance

Post #7 in the sota.io EU Cyber Resilience Act Series

The EU Cyber Resilience Act (CRA) introduces mandatory Software Bill of Materials (SBOM) requirements for all products with digital elements sold in the EU market. Under CRA Article 13, manufacturers must maintain a machine-readable SBOM covering all third-party components, and must be able to produce it upon request from market surveillance authorities.

What most EU software teams miss: your SBOM lives on your infrastructure. If that infrastructure is hosted on a US cloud provider, your dependency graph — including known vulnerability windows — falls under US jurisdiction during exactly the moments when attackers are most active.

What CRA Requires for SBOM

Article 13 — SBOM Obligations

CRA Article 13 requires manufacturers of products with digital elements to:

1. Create and maintain an SBOM that includes at minimum:

• Top-level dependencies (direct)
• Transitive dependencies where reasonably practicable
• Component names, versions, and supplier information
• License identifiers (SPDX or CycloneDX format accepted)
• Known vulnerabilities at time of release (CVE references)
• Relationship graph between components

2. Machine-readable format — The CRA specifically requires machine-readable SBOMs. Acceptable formats per ENISA guidance:

• SPDX (ISO/IEC 5962:2021) — Linux Foundation standard
• CycloneDX (OWASP) — security-focused, natively supports VEX (Vulnerability Exploitability eXchange)
• SWID (ISO/IEC 19770-2) — for installed software

3. Availability upon request — Market surveillance authorities can demand your SBOM. Under CRA recital 65, you must be able to provide it within a "reasonable time period" — interpreted as 72 hours in ENISA operational guidance drafts.

4. Update obligation — Your SBOM must be updated each time a new version ships. For continuous deployment pipelines, this means automated SBOM generation is not optional — it is a compliance necessity.

The Scope Question: Are You Covered?

Products with Digital Elements Under CRA

The CRA applies if your software product:

Critical nuance for SaaS companies: CRA Article 2(3) clarifies that cloud services that are not integral to a product's functionality may be excluded — but if your SaaS platform processes user data or provides core functionality (project management, communication, security tooling), you are almost certainly in scope.

The Open Source Exception

CRA Recital 18 created a partial open source carve-out. However, commercial entities that monetize open source software (hosting, support contracts, SaaS wrappers) are explicitly in scope. The European Commission's position: "the act of commercialization removes the open source exception."

SBOM and Supply Chain Transparency

What Your SBOM Reveals

A complete CRA-compliant SBOM is remarkably detailed. For a typical Next.js/Node.js application, it will include:

• Your direct npm dependencies (React, Next.js, Prisma, etc.)
• Their transitive dependencies — often 800-2,000 packages for a mid-size app
• Known CVEs at time of release — including vulnerabilities you haven't patched yet
• License obligations — GPL contamination risks across your dependency tree
• Version pinning — exact versions reveal patch lag

This data is a security researcher's goldmap. It also tells your competitors exactly which infrastructure you rely on. Under normal circumstances, you share this only with auditors and authorities under strict confidentiality.

The CLOUD Act Problem for US-Hosted SBOMs

Here's where hosting jurisdiction becomes a CRA compliance variable.

If your SBOM generation pipeline runs on AWS, Azure, or GCP:

Scenario: Security incident during CRA-active period

1. Your product has a vulnerability window (between CVE publication and your patch)
2. You're legally required to notify ENISA within 24 hours (CRA Art.11)
3. During this window, US law enforcement could theoretically access your SBOM database via CLOUD Act order — revealing your vulnerability window to external parties before you've patched
4. Simultaneously, EU GDPR Art.33 requires breach notification to DPA within 72 hours

The CLOUD Act does not require notification to you before data is disclosed. You could be legally in a position where your SBOM — with its vulnerability documentation — has been accessed by US authorities while you're still in your CRA-mandated 24-hour notification window.

This is not theoretical. The CLOUD Act has been used in active security investigations, and the US DOJ has publicly argued that security incident data (logs, configs, dependency graphs) falls within its scope.

SBOM Generation: Technical Implementation

Recommended Tooling for CRA Compliance

For Node.js/JavaScript:

# CycloneDX (OWASP) — recommended for security focus
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-format JSON --output-file sbom.json

# SPDX (for ISO compliance emphasis)
npx spdx-sbom-generator -p . -o sbom-spdx.json

For Python:

# CycloneDX
pip install cyclonedx-bom
cyclonedx-py requirements requirements.txt > sbom.json

# syft (multi-language, CISA recommended)
syft dir:. -o cyclonedx-json > sbom.json

For containers (most relevant for SaaS):

# Syft — scans container images including OS packages
syft ghcr.io/your-org/your-app:latest -o cyclonedx-json > sbom.json

# Grype — vulnerability scanning on top of syft
grype sbom:sbom.json

For Go:

# OSV-Scanner (Google) — also integrates with VEX
go install github.com/google/osv-scanner/cmd/osv-scanner@v1
osv-scanner --sbom=sbom.json .

Integrating SBOM into CI/CD (GitLab CI Example)

sbom-generation:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.json
    - syft dir:. -o spdx-json > sbom-spdx.json
  artifacts:
    paths:
      - sbom.json
      - sbom-spdx.json
    expire_in: 1 year
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Under CRA, you need this artifact retained for the product's support lifetime (at minimum 5 years for critical products under CRA Annex I).

The EU-Native SBOM Architecture Advantage

When your SBOM pipeline, storage, and access controls are on EU-sovereign infrastructure:

ENISA's Position on SBOM Confidentiality

ENISA's 2025 guidance on CRA implementation (ENISA-REPORT-2025-SBOM) explicitly recommends that organizations classify SBOM data as "confidential security information" and apply appropriate access controls. The guidance notes that SBOM data "should be treated with equivalent security controls to vulnerability disclosure information."

This directly implies that SBOM storage on infrastructure subject to foreign legal orders creates a compliance risk gap.

VEX: The CRA Vulnerability Context Layer

What is VEX?

VEX (Vulnerability Exploitability eXchange) is CISA's mechanism for communicating vulnerability status in SBOM context. CRA-compliant SBOMs increasingly require VEX statements alongside the base component inventory.

VEX status values:

• not_affected — CVE exists in component but your usage pattern is not exploitable
• affected — CVE applies and you are working on a fix
• fixed — patch applied, version pinned
• under_investigation — assessing impact

Under CRA Article 14 (CVD, Coordinated Vulnerability Disclosure), your VEX statements are the machine-readable complement to your human-readable CVD policy. If you've published a CycloneDX SBOM with VEX, your CVD process and ENISA notification timeline become auditable.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "vulnerabilities": [
    {
      "id": "CVE-2024-XXXXX",
      "affects": [{"ref": "your-component-bom-ref"}],
      "analysis": {
        "state": "under_investigation",
        "justification": "requires_configuration",
        "detail": "Assessing attack surface — ENISA notification deadline: 2026-05-14T10:00:00Z"
      }
    }
  ]
}

Including your ENISA notification deadline in your VEX detail field creates an auditable timestamp that satisfies CRA Art.11's documentation requirements.

Practical Compliance Roadmap

Phase 1: Inventory (Weeks 1-2)

1. Enumerate all products with digital elements you ship to EU market
2. Identify SBOM generation gap (manual vs automated)
3. Choose format: CycloneDX preferred for security-heavy use cases; SPDX for license compliance emphasis
4. Audit current CI/CD pipelines for SBOM generation steps

Phase 2: Implementation (Weeks 3-6)

1. Integrate syft or CycloneDX CLI into build pipeline
2. Store SBOMs as build artifacts (minimum 5-year retention for critical products)
3. Set up Grype or OSV-Scanner for vulnerability correlation
4. Draft VEX policy: who approves VEX status changes, what is the SLA?
5. Link SBOM generation to your CVD policy timeline

Phase 3: Infrastructure Review (Weeks 7-8)

1. Assess where SBOM data is stored and processed
2. If US-hosted: document CLOUD Act exposure in your risk register
3. Consider migrating SBOM storage to EU-sovereign infrastructure
4. Verify your PaaS/IaaS provider can provide SBOM for their components (supply chain depth)

Phase 4: Market Surveillance Readiness (Week 9+)

1. Create the "authority request package" — how you'll produce your SBOM within 72h
2. Define escalation path: who is your CRA technical contact for authority requests?
3. Annual SBOM accuracy audit against deployed artifact inventory

Key Deadlines

The 18-month window before the first CRA obligations kick in sounds generous. For organizations that need to retrofit SBOM generation into existing CI/CD pipelines, negotiate with vendors for SBOM delivery, and implement VEX workflows — the timeline is tight.

What This Means for Your Hosting Choice

The CRA's SBOM requirements add a new dimension to infrastructure decisions:

Your SBOM pipeline runs on your PaaS. If that PaaS is:

• AWS/Azure/GCP: Your SBOM database, VEX statements, and vulnerability timelines fall under US CLOUD Act jurisdiction. During a security incident, US authorities could access your SBOM before you've completed your CRA Art.11 ENISA notification.

• EU-native PaaS (e.g., sota.io): Your SBOM data stays under EU GDPR jurisdiction. Any authority access requires following GDPR Art.86 procedures — with notification to you. Your CRA Art.11 24-hour notification window is not vulnerable to parallel foreign legal process.

This is a subtle but legally significant distinction. CRA Recital 64 specifically notes that manufacturers should ensure their vulnerability management processes — which includes SBOM maintenance — are protected from unauthorized access.

Summary

The CRA's SBOM requirements (Article 13) create a mandatory software supply chain transparency obligation for EU market participants. Key implementation decisions:

1. Choose CycloneDX or SPDX and integrate into CI/CD from day one
2. Automate generation — manual SBOM processes fail CRA's update obligations
3. Implement VEX — machine-readable vulnerability status is the CRA Art.14 complement
4. Assess your SBOM storage jurisdiction — US-hosted SBOM = CLOUD Act exposure during incidents
5. Plan for 72-hour authority delivery — build the "authority package" before you need it

The August 2027 date for CRA vulnerability notification obligations is 14 months away. Organizations that start SBOM implementation now will have compliance infrastructure in place. Those that wait until 2027 will be building under regulatory pressure.

sota.io provides EU-sovereign PaaS for companies building CRA-compliant software. Your SBOM pipeline, VEX data, and vulnerability management infrastructure under German jurisdiction — not US CLOUD Act reach. Start free.