EU Cyber Resilience Act Compliance for DevOps: Your September 2026 SBOM Deadline Checklist

The EU Cyber Resilience Act's first deadline is 11 September 2026, days away, and most engineering organizations are not ready for it. Datadog's State of DevSecOps 2026 report found that 87% of organizations have at least one known exploitable vulnerability in production, and that the median dependency is now 278 days behind its latest major version. From 11 September, you have 24 hours to send an early warning to EU authorities when you learn that a vulnerability in your product is being actively exploited. If you cannot say which components are in your products, you cannot meet that clock. Here is the checklist we are working through with clients.

What the EU Cyber Resilience Act means for your engineering org

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) entered into force on 10 December 2024. It applies to almost every organization that manufactures, imports, or distributes "products with digital elements" in the EU: SaaS platforms with a software component, IoT devices, developer tooling, and everything in between.

The scope is broader than most teams assume. If your software is sold to EU customers, you are almost certainly in scope. The clear exemption is non-commercial open-source software. Commercial open source, including projects backed by a company that sells support or a hosted version, is not exempt.

The CRA sets four core engineering obligations:

1. Secure by design. Products must ship with a secure default configuration and a minimized attack surface.
2. A software bill of materials (SBOM). A machine-readable inventory of the components in your product, covering at least the top-level dependencies.
3. Vulnerability handling and reporting. Documented processes for detection, triage, patching, and coordinated disclosure.
4. Technical documentation. Design specs, risk assessments, the SBOM, test results, and patch history, kept for at least 10 years after the product is placed on the market or for the whole support period, whichever is longer.

The penalties are not symbolic. Breaching the essential requirements or the manufacturer obligations in Articles 13 and 14 carries fines of up to 15 million euros or 2.5% of worldwide annual turnover, whichever is higher. Market surveillance authorities can also order products withdrawn or recalled.

The September 2026 deadline: who is affected and what changes

The CRA has two enforcement milestones, and the first one is this month:

| Milestone | Date | What is required | |-----------|------|-----------------| | Vulnerability and incident reporting (Article 14) | 11 September 2026 | 24-hour early warning, 72-hour notification, 14-day final report for actively exploited vulnerabilities | | Full application | 11 December 2027 | CE marking, conformity assessment, complete technical documentation including the SBOM, secure-by-design validation |

September 2026 is not "just" a reporting deadline. It is an implicit SBOM deadline. You cannot file a meaningful vulnerability report in 24 hours if you do not know which components are in your products. The clock starts when you become aware that a vulnerability in your product is being actively exploited, and that includes a vulnerability in a transitive dependency three layers down the tree.

Without an SBOM, your incident response workflow looks like this: "We think we might use that library somewhere, let someone check." Under the CRA that workflow ends in a regulatory fine.

Reports go through the single reporting platform run by ENISA (the EU Agency for Cybersecurity) and land with ENISA and the national CSIRT designated as coordinator for your country. The reporting is staged:

• Within 24 hours: an early warning that you have an actively exploited vulnerability.
• Within 72 hours: a full notification with severity, impact, affected products, and any corrective or mitigating measures taken so far.
• Within 14 days of a fix being available: a final report describing the vulnerability, the root cause, and the remediation.

Why SBOM generation is the foundation of CRA compliance

An SBOM is a machine-readable inventory of every software component in your product: direct dependencies, transitive dependencies, build tools, and embedded libraries. Think of it as a nutrition label for software.

What the regulation actually requires of the SBOM is narrower than most vendor marketing suggests. It has to be in a commonly used, machine-readable format (a PDF or a spreadsheet does not count), it has to cover at least the top-level dependencies, and it forms part of the technical documentation you keep for 10 years and hand to market surveillance authorities on request.

Our advice is to go well past that floor. Generate the SBOM on every build, not once per release, and resolve the full dependency graph, not just the top level. The regulation's minimum will not get you through a 24-hour reporting window when the exploited package is a transitive dependency.

For teams already running software composition analysis in their CI/CD pipeline, SBOM generation is a small extension. You are already scanning dependencies. You just need to formalize and store the output. For teams that have not invested in SCA, the CRA forces the issue.

Choosing between CycloneDX and SPDX formats

The CRA does not name a format. It says "commonly used and machine-readable", and the Commission can specify format and elements later through implementing acts. In practice there are two candidates, CycloneDX and SPDX, and every serious SBOM tool emits both. They serve different needs:

| Dimension | CycloneDX 1.5 | SPDX 2.3 | |-----------|---------------|-----------| | Primary focus | Security and supply chain risk | License compliance and provenance | | Vulnerability correlation | Native VEX (Vulnerability Exploitability eXchange) support | Separate VEX document | | CI/CD tooling | Syft, Trivy, cdxgen, CycloneDX CLI | Syft, Trivy, SPDX Tools, FOSSology | | Ecosystem adoption | Dominant in DevSecOps tooling | Dominant in legal, compliance, and automotive | | Dependency graph | Full transitive dependency tree by default | Supported, but relationships must be declared explicitly | | File size | Typically smaller for equivalent content | More verbose because of relationship metadata |

We recommend CycloneDX 1.5 for CRA work. The native VEX integration means the SBOM can carry your exploitability assessments, which is exactly what the 24-hour workflow needs. When a new CVE lands, your tooling can cross-reference the SBOM with VEX data and tell you whether you are affected and whether the vulnerability is reachable in your deployment.

If you also have SPDX requirements (common in automotive, defense, and organizations with heavy open-source license compliance needs), generate both formats from the same scan. Syft and Trivy both support dual output.

Building CRA-compliant SBOM generation into your CI/CD pipeline

Here is a GitHub Actions workflow that generates a CycloneDX SBOM on every build, validates it, scans it, and stores it as an artifact:

# .github/workflows/sbom-cra-compliance.yml
name: CRA SBOM Compliance
on:
  push:
    branches: [main, release/*]
  pull_request:
    branches: [main]

jobs:
  generate-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Install Syft
        uses: anchore/sbom-action/download-syft@f325610c9f50a54015d37c8d16cb3b0e2c8f4de0 # v0.18.0

      - name: Generate CycloneDX SBOM
        run: |
          syft dir:. -o cyclonedx-json@1.5 > sbom-cyclonedx.json
          echo "Components found: $(jq '.components | length' sbom-cyclonedx.json)"

      - name: Validate SBOM completeness
        run: |
          # Fail the build if the SBOM is missing the metadata the CRA record needs
          jq -e '.metadata.component.name' sbom-cyclonedx.json
          jq -e '.metadata.component.version' sbom-cyclonedx.json
          jq -e '.metadata.timestamp' sbom-cyclonedx.json
          COMP_COUNT=$(jq '.components | length' sbom-cyclonedx.json)
          if [ "$COMP_COUNT" -lt 1 ]; then
            echo "ERROR: SBOM has no components, check the scan configuration"
            exit 1
          fi

      - name: Scan SBOM for known vulnerabilities
        uses: anchore/scan-action@869c549e657a088dc0441b08ce4fc0ecdac2bb65 # v5.3.0
        with:
          sbom: sbom-cyclonedx.json
          fail-build: false  # Do not block builds; feed results into monitoring
          output-format: json

      - name: Archive SBOM
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: sbom-${{ github.sha }}
          path: sbom-cyclonedx.json
          # GitHub caps artifact retention at 90 days (400 on private repos).
          # This is a working copy only; the 10-year CRA record lives in
          # object storage (see below).
          retention-days: 90

Two details in that workflow matter more than they look.

First, the actions are pinned to commit SHAs, not version tags. Datadog's 2026 report found that only 4% of organizations pin the hash for all of their marketplace actions, and 71% never pin any. A mutable @v1 tag means whoever controls that repository controls what runs in your build. That is a bad property for any pipeline and a ridiculous one for the pipeline that produces your security evidence.

Second, GitHub Actions artifacts cannot hold your 10-year record. The platform caps retention at 90 days for public repositories and 400 days for private ones. Add a step that copies each SBOM to versioned object storage (S3 with Object Lock, or the GCS and Azure equivalents) keyed by commit SHA and product version. That bucket, not the Actions artifact, is what you show a market surveillance authority.

For teams on GitLab CI, the equivalent job runs syft directly:

generate-sbom:
  stage: security
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json@1.5 > sbom-cyclonedx.json
    - syft dir:. -o spdx-json@2.3 > sbom-spdx.json  # Dual format if needed
  artifacts:
    paths:
      - sbom-cyclonedx.json
      - sbom-spdx.json
    expire_in: 10 years  # subject to your instance's artifact limits; mirror to object storage

Continuous vulnerability monitoring and 24-hour reporting

Generating SBOMs on every build is necessary but not sufficient. The 24-hour obligation means you need something that continuously checks your deployed SBOMs against new vulnerability disclosures, every day the product is in production, not only at build time.

The monitoring stack we recommend:

1. SBOM storage. Dependency-Track (open source) or Anchore Enterprise. Ingest every SBOM your pipeline produces. Dependency-Track consumes CycloneDX and gives you a searchable inventory of every component across every product version. If a partner sends you SPDX, convert it with syft convert before ingesting.
2. Vulnerability feeds. NVD, the GitHub Advisory Database, and OSV (Open Source Vulnerabilities). Dependency-Track polls these on its own and correlates new CVEs against the SBOMs it holds.
3. Alerting. Alert on any vulnerability in the CISA KEV catalog or with an EPSS score above 0.5. Those are your candidates for CRA-reportable events. Note that the legal clock starts when you become aware of active exploitation, so the alert is the trigger for triage, and the triage outcome decides whether a report is due.
4. VEX generation. When a CVE hits a component you ship but the vulnerable code path is not reachable in your deployment, record that assessment as a VEX statement attached to the SBOM. That document is your evidence that the vulnerability was triaged responsibly.

The response-time math is unforgiving. Your team has to go from "new CVE published" to "early warning filed" inside 24 hours. Feed polling latency eats 4 to 6 hours. On-call triage takes another 8 to 12 hours. The compliance person filing the report gets whatever is left. Manual SBOM processes cannot hit that timeline at any real scale.

Common CRA compliance mistakes that will cost you

We have worked with teams across financial services, healthtech, and SaaS who are preparing for the CRA. These are the mistakes we see most often.

Treating the SBOM as a one-off. A team generates an SBOM for the latest release, ticks the box, and moves on. Three months later a critical vulnerability is disclosed in a transitive dependency they cannot locate, because nobody regenerated the SBOM after 47 subsequent deployments. An SBOM that describes last quarter's release is useless when the question is what is running today.

Stopping at top-level dependencies. Your application declares 30 direct dependencies and pulls in 400 transitive ones. The regulation's floor is the top level, but the 24-hour clock does not care about the floor. If your SBOM tool only reads package.json or requirements.txt entries, you are blind to most of your attack surface. Configure the generator to resolve the full graph. Syft does this by default when it finds lockfiles.

Assuming December 2027 is the real deadline. The reporting obligation that starts in September 2026 needs the same component visibility that the full-application date formalizes in December 2027. You cannot report what you cannot see. Teams that wait for the "real" deadline will be exposed for 15 months.

No named owner for reporting. The CRA requires a single point of contact for vulnerability reporting. "The security team" is not a contact. Name a person and a backup with the authority and the process to file through the ENISA platform, and put that in the incident response runbook.

Forgetting the infrastructure supply chain. Terraform providers, Helm charts, and container base images are components of your product too. If you generate SBOMs for application code but not for your infrastructure-as-code supply chain, you have a blind spot the CRA does not forgive.

When to Get Help

If your team is looking at the September deadline without SBOM generation in the pipeline, without vulnerability monitoring, and without a documented reporting workflow, you are not alone. You are, however, out of runway.

We help engineering organizations build CRA-ready DevSecOps pipelines: SBOM generation and storage, vulnerability monitoring, VEX workflows, incident response playbooks, and the regulatory reporting path. A typical engagement takes a team from nothing to a working pipeline in 4 to 6 weeks.

Talk to us about CRA compliance

The deadline is a forcing function. The underlying capability, knowing exactly what is in your software and being able to respond to a vulnerability in hours rather than weeks, is something every engineering organization should have regardless of regulation. The CRA just puts a price on not having it: up to 15 million euros.