CRA SBOM Compliance Checklist 2026: The Complete Developer Guide — Series Finale

Post #5 in the sota.io EU CRA SBOM Developer Guide Series (2026)

Over the four previous posts in this series, we have covered the regulatory foundation, the format wars, CI/CD automation, and the operational layer of storage and vulnerability reporting. This finale consolidates everything into a single, structured compliance checklist designed to work as a living document for engineering teams navigating the Cyber Resilience Act.

The CRA Notified Bodies become operational on 11 June 2026. Reporting obligations under Art.14 already apply for products placed on the market. The August 2026 application deadline is approaching. If you are shipping software products into the EU market — or running managed infrastructure that EU customers depend on — the time to act is now.

This is not an exhaustive legal analysis. It is a working checklist for engineers, platform teams, and compliance leads who need to translate regulatory text into Jira tickets and pipeline configurations.

Post #1 covered the Art.13 and Annex VII regulatory foundation. Post #2 compared CycloneDX 1.6 and SPDX 2.3 formats. Post #3 covered GitHub Actions and GitLab CI pipeline automation. Post #4 addressed SBOM storage architecture, VEX workflows, and the Art.14 reporting cascade.

Part 1: Regulatory Applicability — Are You In Scope?

Before running through the checklist, confirm your applicability status. The CRA applies to products with digital elements placed on the EU market. This includes:

• Software products sold or distributed to EU customers
• SaaS platforms where the software component is the primary product
• Managed services where you are the manufacturer of the underlying software
• Open source projects that are commercialised (support contracts, hosted versions, integrated products)

Out of scope (CRA Art.2):

• Pure services with no embedded software product (pure hosting, human-only professional services)
• Open source software developed entirely without commercial intent by individuals not acting in the course of a trade
• Products already covered by sector-specific regulation where the CRA explicitly defers (certain medical devices under MDR/IVDR)

Classification check — Art.6 and Annex III:

• Default class (Annex III absent): Self-assessment under Art.13. This covers the majority of general software products.
• Important products (Annex III Class I): Voluntary third-party audit OR application of harmonised standards with self-assessment.
• Critical products (Annex III Class II): Mandatory third-party audit by a Notified Body.

Knowing your class determines whether you need a Notified Body (operational from June 11) and which conformity assessment route applies.

Part 2: SBOM Generation — Mandatory Field Checklist

The Art.13(1) obligation requires manufacturers to identify and document all software components. Annex VII specifies the technical documentation structure. Your SBOM must include, at minimum:

Mandatory Component Fields

For every component in your SBOM:

• Name — exact package or component name as published
• Version — precise version string (not a range, not "latest")
• Supplier / Author — the originating organisation or individual
• License — SPDX license expression (e.g. MIT, Apache-2.0, GPL-2.0-only)
• PURL (Package URL) — machine-readable unique identifier (e.g. pkg:npm/express@4.18.2)
• Hash / Checksum — SHA-256 minimum for each component artifact
• Dependency relationships — directed graph of which component depends on which
• Component scope — whether a dependency is required, optional, or development-only

Document-Level Fields

• Format declaration — CycloneDX 1.6 or SPDX 2.3 (both are accepted; pick one)
• SBOM serial number / document identifier — unique per SBOM document
• Creation timestamp — ISO 8601 datetime of when the SBOM was generated
• Tool provenance — name and version of the tool that generated the SBOM
• Product reference — name, version, and supplier of the product the SBOM describes

Scope Coverage

• Transitive dependencies included — not just direct dependencies
• Container base image components — if you ship containers, the base image must be inventoried
• Infrastructure-as-code dependencies — Terraform providers, Helm charts, Ansible roles
• Build tool chain — compilers, build systems, and significant build-time dependencies
• Runtime environment — language runtime versions (Node.js version, JVM version, Python version)

Part 3: Format Compliance Checklist

Post #2 in this series covered the CycloneDX vs SPDX trade-off in detail. This checklist focuses on the compliance-critical elements regardless of which format you have chosen.

If You Use CycloneDX 1.6

• Schema version declaration: "specVersion": "1.6"
• BOM format: "bomFormat": "CycloneDX"
• Serial number: "serialNumber": "urn:uuid:<uuid4>"
• VEX support enabled: component vulnerabilities declared in the vulnerabilities array
• PURL present for every component in the components array
• License expression in licenses[].license.id (SPDX expression)
• Dependency graph in the dependencies array with dependsOn relationships

If You Use SPDX 2.3

• Header: SPDXVersion: SPDX-2.3 and DataLicense: CC0-1.0
• Document namespace: unique URI per SBOM document
• Relationship type DESCRIBES connecting the document to the product package
• PackageVersion filled for every package — not omitted
• PackageChecksum: SHA256: for every package
• SPDXID unique within the document
• PackageDownloadLocation — NOASSERTION acceptable if unknown, but prefer the exact registry URL

Machine-Readability Validation

• Format parses with zero errors against the official schema
• JSON output preferred (both formats) for automated processing
• Schema validation integrated into CI pipeline (fails build on invalid SBOM)

Part 4: CI/CD Pipeline Integration Checklist

Post #3 covered GitHub Actions and GitLab CI automation in depth. This checklist summarises the mandatory pipeline controls.

Generation

• SBOM generated automatically on every production release build — not manually
• SBOM generation tool pinned to an exact version (no floating @latest)
• Generation step fails the build if it cannot reach the dependency manifest
• Transitive dependency flag enabled on the generation tool

Validation

• Schema validation step runs after generation (CycloneDX CLI validate or ntia-checker)
• NTIA minimum elements check passes (if you use ntia-checker)
• License policy check integrated — fails on prohibited licenses (GPL-3.0 in proprietary products, etc.)
• Build fails if SBOM contains components with no license declaration

Vulnerability Scanning

• Vulnerability scan runs against the generated SBOM on every build
• Grype, OSV-Scanner, or equivalent tool integrated against OSV.dev or NVD feed
• Scan results attached to the build artifact (not just printed to console)
• Critical severity findings fail the build (configurable threshold)
• VEX document checked during scan to suppress known-and-managed findings

Artifact Publishing

• SBOM published to the SBOM store as a build artifact with build metadata
• SBOM stored alongside the release artifact (not in a separate unlinked location)
• SBOM file name follows a consistent convention: <product>-<version>-sbom.cdx.json
• SBOM signing configured (Sigstore cosign or GPG) for artifact integrity

Part 5: Storage and Retention Checklist

Post #4 covered the Art.31 retention requirements in depth. The key obligation: SBOM documents must be retained for the greater of ten years after market placement or the duration of the product's supported lifecycle.

Storage Architecture

• Immutable storage — stored SBOMs cannot be modified or deleted before retention period expires
• Version history preserved — every SBOM update stored, not just the latest version
• Build correlation — every stored SBOM links to the build that produced it (commit hash, build ID)
• Product version mapping — given a product version string, you can retrieve the corresponding SBOM
• Release correlation — every release artifact maps to exactly one canonical SBOM

Access and Retrieval

• SBOM retrievable in under 5 minutes without manual intervention (audit requirement)
• Access control: read access for compliance/legal, write access restricted to CI pipeline service accounts
• API or CLI retrieval available (not just UI-based download)
• SBOM export in both machine-readable and human-readable forms available

Jurisdiction — CLOUD Act Exposure

This is the checklist item that surprises most teams. If your SBOM store runs on AWS S3, Azure Blob Storage, or Google Cloud Storage — and those accounts are operated by US entities — the stored documents are reachable by US law enforcement via the CLOUD Act without the need for an EU mutual legal assistance treaty request.

For SBOM compliance evidence, this creates a specific risk: a regulator investigating a CRA compliance failure could argue that your compliance documentation itself is accessible to a foreign government outside EU legal channels.

For EU-jurisdiction clean storage:

• SBOM store hosted on EU-native infrastructure (Hetzner, Scaleway, OVHcloud, IONOS) OR on sota.io managed PaaS (Hetzner Germany, no US parent)
• Storage operator has no US parent company subject to CLOUD Act jurisdiction
• Data processing agreement (DPA) with the storage provider specifies EU-only data residency
• SBOM store access logs stored in the same EU-jurisdiction environment

Part 6: Vulnerability Tracking Checklist

The CRA requirement is not just to produce an SBOM once — it is to keep it current throughout the product lifecycle, and to act when vulnerabilities are discovered.

Continuous Monitoring

• Automated feed polling: OSV.dev, NVD (NIST), GHSA (GitHub Advisory) checked daily
• Alert configured: any new CVE matching a component in your current SBOM triggers a notification
• Alert routing to the security engineering team (not just dumped into a low-priority queue)
• SBOM updated when a component is patched, added, or removed — not just on major releases

VEX Document Management

• VEX (Vulnerability Exploitability eXchange) process defined and documented
• VEX statements produced for every CVE that affects your SBOM and is assessed as not exploitable
• VEX status vocabulary used consistently: not_affected, affected, fixed, under_investigation
• VEX documents stored alongside the SBOM they reference (not in a separate system)
• VEX justification populated for not_affected statements (vulnerable_code_not_present, code_not_reachable, requires_environment_to_be_present, etc.)
• VEX documents updated when the vulnerability status changes

SBOM Freshness

• SBOM regenerated and republished within 24 hours of any dependency update (patch, minor, or major)
• Outdated SBOM detection: alert if the SBOM for a deployed version is more than 30 days old without a regeneration event
• SBOM completeness audit: quarterly review that all deployed versions have a current SBOM

Part 7: Art.14 Vulnerability Reporting Checklist

Art.14 of the CRA establishes the reporting obligations when an actively exploited vulnerability is discovered in your product. This is the most operationally complex part of CRA SBOM compliance.

The reporting cascade has three tiers:

Tier 1 — Initial report to ENISA (24 hours from discovery) The initial notification to ENISA (via the Single Reporting Platform once operational) must reach them within 24 hours of the manufacturer becoming aware that the vulnerability is being actively exploited in the wild. This is not a full analysis — it is an early warning that a vulnerability exists and is being exploited.

Tier 2 — Detailed technical report (72 hours) Within 72 hours of the initial notification, a more detailed technical report covering the vulnerability, the affected product versions, the SBOM components involved, and the current remediation status must be submitted.

Tier 3 — Final report (14 days) The complete incident report, including remediation timeline, patch availability, and any coordinated disclosure timeline agreed with the security researcher who reported the issue.

Process Checklist

• Art.14 reporting procedure documented in the security incident response runbook
• Responsible person designated for ENISA reporting (PSIRT lead or equivalent)
• ENISA Single Reporting Platform account created and access tested
• Internal escalation path defined: who is notified internally before the 24-hour clock expires
• Template for the Tier 1 initial notification prepared in advance
• Template for the Tier 2 detailed technical report prepared in advance
• SBOM query tool available: given a CVE ID, retrieve all affected product versions within 5 minutes
• Coordinated disclosure policy published (for externally reported vulnerabilities)

When Art.14 Does Not Apply

Art.14 reporting obligations apply specifically when the vulnerability is actively exploited in the wild. A CVE disclosure alone does not trigger the 24-hour clock — it starts only when the manufacturer has evidence of active exploitation. However, discovered but not-yet-exploited vulnerabilities must still be handled under the Art.13 vulnerability handling requirements (Annex I Part II).

Part 8: Audit Readiness Checklist

CRA enforcement is conducted by Market Surveillance Authorities (MSAs) in each EU member state. Notified Bodies (operational from 11 June 2026) conduct conformity assessment. When a regulatory inquiry arrives, you need to produce:

Documentation Package

• Technical documentation per Annex VII: SBOM, security architecture, risk assessment, vulnerability handling process, conformity assessment records
• EU Declaration of Conformity (DoC) signed by an authorised representative
• Conformity assessment records showing which route was followed (self-assessment, Class I voluntary NB, Class II mandatory NB)
• SBOM for every currently supported product version — retrievable on request
• SBOM for product versions placed on market in the last 10 years — retrievable from archive
• Vulnerability handling log — every CVE that affected your product, with status and remediation dates
• Art.14 reporting log — every instance where ENISA reporting was triggered, with timestamps

Process Evidence

• CI/CD pipeline logs showing SBOM was generated as part of each release build
• Vulnerability scan results from each release (not just current state)
• VEX document history showing when vulnerability statuses were assessed and updated
• Evidence that a security lifecycle management process exists and is followed (not just described)

Response Time Targets

• MSA documentation request responded to within 5 business days (prepare retrieval workflows in advance)
• SBOM for any product version retrievable in under 1 hour from archive
• Art.14 reporting timeline evidenced by timestamped logs in an immutable audit log

Part 9: Jurisdiction Summary — The EU-Native Decision

Across all five posts in this series, the jurisdiction question has appeared repeatedly. Here is the summary:

The compliance risk of US-hosted SBOM infrastructure is not theoretical. If your SBOM store, vulnerability tracking system, or Art.14 reporting records are hosted on AWS, Azure, or Google Cloud — operated by US parent entities — those records are reachable by US government demand under the CLOUD Act without EU-side legal process.

This does not mean you are automatically non-compliant. But it does mean that:

1. Your compliance evidence can be examined by a foreign government without your knowledge
2. In a cross-border regulatory dispute, the evidence chain integrity is weakened
3. A future EU regulation (Data Act, Digital Sovereignty Package) may explicitly require EU-jurisdiction infrastructure for compliance documentation

The EU-native stack for CRA SBOM compliance:

Part 10: 30-Day Sprint to Compliance

If you are reading this five-post series for the first time and need to get to CRA SBOM compliance quickly, here is a prioritised 30-day sprint:

Week 1 — Baseline

1. Confirm your CRA applicability and product classification
2. Run a dependency audit on your most critical product — count direct + transitive dependencies
3. Generate a first SBOM using Syft or cdxgen — even an imperfect one gives you a starting baseline
4. Identify which format (CycloneDX or SPDX) your toolchain supports best

Week 2 — Pipeline

1. Add SBOM generation to your release CI pipeline
2. Add schema validation to fail the build on invalid SBOM
3. Add Grype or OSV-Scanner for vulnerability scanning
4. Set up a minimal SBOM artifact store (even an S3-compatible bucket with versioning is a start)

Week 3 — Operations

1. Set up daily vulnerability feed polling against your SBOM
2. Define your Art.14 reporting procedure in the incident runbook
3. Create ENISA Single Reporting Platform account
4. Draft Tier 1 and Tier 2 notification templates

Week 4 — Audit Readiness

1. Produce your EU Declaration of Conformity draft
2. Review your Annex VII technical documentation package for gaps
3. Run an internal mock retrieval drill: retrieve the SBOM for your last three releases within 1 hour
4. Evaluate your infrastructure jurisdiction and plan migration to EU-native if needed

Series Summary

This five-post series has covered the complete CRA SBOM compliance picture:

The CRA is not a box-ticking exercise. It establishes ongoing obligations that require a security lifecycle process, continuous monitoring, and the operational infrastructure to report and remediate within tight timeframes. The good news: for most software teams, the tooling exists and is free. The primary investment is process design and infrastructure selection — and choosing EU-native infrastructure from the start avoids re-platforming costs when jurisdiction requirements tighten further.

This post is part of the sota.io EU CRA SBOM Developer Guide 2026 series. sota.io is an EU-native managed PaaS — no US parent, no CLOUD Act exposure, Hetzner Germany. Explore sota.io →