What the EU Cyber Resilience Act means for your Kubernetes SBOMs

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) has two dates that matter to software teams. Its reporting obligations have applied since 11 September 2026: if a vulnerability in your product is being actively exploited, you owe ENISA and a national CSIRT an early warning within 24 hours. Everything else, including the requirement to maintain a software bill of materials, applies from 11 December 2027.

If you sell software into the EU that customers run on Kubernetes, both dates are about your container images. If you run an internal platform or sell pure SaaS, most of this probably isn't yours to carry, and the first section explains why.

Does the CRA apply to you?

The CRA regulates products with digital elements: software or hardware, with a data connection to a device or network, made available on the EU market in the course of a commercial activity, "whether in return for payment or free of charge". The obligations fall on the manufacturer, the organisation that puts the product on the market under its own name. For teams that live in Kubernetes, it sorts out roughly like this:

Three details catch people out:

• Where you are based doesn't matter. Like the GDPR, the test is supplying the EU market, not where the vendor is incorporated.
• Open-source components in your product are your responsibility. Non-commercial open-source development is out of scope, and foundations acting as "open-source software stewards" get a lighter regime. But once an open-source component ships inside your commercial product, you have to exercise due diligence over it, and when you find a vulnerability in it you must report it to the maintainer as well as fix it (Article 13(5)–(6)).
• Some Kubernetes-adjacent products carry a heavier class. Annex III lists "hypervisors and container runtime systems" as Class II important products, which need third-party conformity assessment. Most applications and agents fall in the default category, which allows self-assessment.

If you are only a user, the CRA still changes what you get from vendors: they must tell affected users about actively exploited vulnerabilities, "where appropriate in a structured, machine-readable format", and support their products for a declared period of normally at least five years. Non-compliance with the essential requirements or the Article 13 and 14 obligations can draw fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

What has applied since 11 September 2026: reporting

Article 14 is live, and it doesn't wait for December 2027. Under Article 69(3) it applies to every in-scope product, including versions placed on the market years before the regulation existed. Two kinds of event trigger it:

Notifications go through ENISA's single reporting platform, which went live on 11 September 2026 and routes each one to the CSIRT designated as coordinator and to ENISA. At launch it is a web interface with no API, and registration runs on an EU Login account with multi-factor authentication (details). Registering is an afternoon's work; it is not something to discover inside a 24-hour window.

The regulation defines an actively exploited vulnerability as one with "reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". The CISA KEV catalogue is the most widely used public record of exactly that kind of evidence. A KEV-listed CVE in a component of an image you ship isn't automatically a reportable event — the vulnerable code may not be reachable in your product — but it is the trigger to make that call, and quickly.

The SBOM requirement, from 11 December 2027

Annex I, Part II of the regulation lists the vulnerability-handling requirements. The first one is the SBOM clause: manufacturers must "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products".

Unpacking that for a Kubernetes-shaped product:

• "Commonly used and machine-readable format" means CycloneDX or SPDX in practice. A spreadsheet of dependencies doesn't qualify. The regulation names no standard, and the Commission can specify format and fields by implementing act (Article 13(24)); either format carries what regulators ask for, as the CycloneDX vs SPDX comparison shows.
• "At the very least the top-level dependencies" is a floor, not a target. If your product ships as container images, your dependency surface includes the base image's OS packages, where a large share of an image's CVEs usually sit. An SBOM that stops at your package.json clears the floor and still leaves you blind for the other Annex I requirements, which is the part teams miss.
• The SBOM doesn't have to be public. It is part of the technical documentation you hand to a market surveillance authority on a reasoned request; giving it to customers is optional. But that documentation must be kept for 10 years after the product is placed on the market, or for the support period if longer, so the SBOM for every release you still support has to exist and be retrievable.

The SBOM is the easy part

The same Annex I list requires you to address and remediate vulnerabilities without delay, ship security updates, and publish information about fixed vulnerabilities. Combined with the 24-hour reporting clock that already runs, those obligations assume a capability most teams don't have: knowing, at any moment, which shipped versions contain which components, and hearing about it when a new advisory affects one of them.

A one-off SBOM generated in CI on release day can't do that. You need:

1. SBOMs for everything you actually ship — not just the images that went through the happy-path pipeline. Hotfixes, sidecar bumps and base image rebuilds all change the inventory.
2. SBOMs re-matched against a live vulnerability feed — a CVE published today must surface against the SBOM of an image you shipped in March. The 24-hour clock starts when you become aware, so a matcher that only runs at build time doesn't stop the clock; it means you find out late, or from a customer.
3. A record of how each vulnerability was handled — the technical documentation has to describe your vulnerability-handling process, and "we fixed it at some point" won't survive an authority's questions. Keep when it was detected, which versions were affected, and when and by whom it was remediated or the risk accepted.

One caution for manufacturers: what runs in your own clusters is not the same set as what you have shipped. An in-cluster scanner, StackRadar's included, sees the images your clusters are running. Either keep each supported release running somewhere it gets scanned, or scan the released images directly.

Where your SBOM data lives, and for how long

An SBOM is a precise map of your product's attack surface, and under the CRA you'll be keeping one per supported release for years. Two questions are worth asking of any tool that holds them. First, where the data sits: StackRadar stores and processes everything in the EU (details on the security page), which removes one data-transfer conversation with your DPO. Second, how long it stays: StackRadar's history window is 30 days to two years depending on plan, well short of the CRA's 10 years. Archive the SBOM for each release yourself, alongside the rest of your technical documentation, and treat any vendor's copy as a working set rather than the record.

A realistic checklist

The quickest way to see the gap between a top-level SBOM and what an image really contains is to scan one of your released images. The free stackradar scan CLI needs no account and no cluster for a single image:

# every package in the image, OS layer included, matched against OSV and KEV
stackradar scan --image registry.example.com/your-product/api:4.2.0

For how the matching works afterwards, see how StackRadar matches SBOMs against OSV; for what a per-image SBOM of a cluster looks like, see the Kubernetes SBOM guide.