What the EU Cyber Resilience Act means for your Kubernetes SBOMs

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024, and its first hard deadline is close: from 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products within 24 hours. The full set of obligations — including maintaining a software bill of materials — applies from 11 December 2027. If you ship software that runs in Kubernetes and is sold in the EU, this regulation is about your container images, whether or not anyone in your org has read it yet.

Who the CRA applies to

The CRA covers products with digital elements — software or hardware with a remote data connection, sold on the EU market. That includes plain commercial software: a SaaS-adjacent agent your customers install, an on-prem product delivered as Helm charts and container images, a desktop app. Two details surprise people:

• It applies regardless of where you are based. Like the GDPR, what matters is selling into the EU market, not where the vendor is incorporated.
• Open-source software has a carve-out, commercial use of it doesn't. Non-commercial OSS development is out of scope (with a light-touch regime for foundations acting as "stewards"), but the moment open-source components ship inside your commercial product, they are your responsibility under the CRA.

Non-compliance with the essential requirements can draw fines up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

The SBOM requirement, specifically

Annex I, Part II of the regulation lists 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.
• "At the very least the top-level dependencies" is a floor, not a target. If your product ships as container images, your real dependency surface includes the base image's OS packages — the layer where most exploitable CVEs actually live. An SBOM that stops at your package.json won't help you meet the other Annex I requirements, which is the part teams miss.
• The SBOM is not required to be public. You provide it to market surveillance authorities on request. But "on request" means it has to exist, be current, and be retrievable — for every version you still support.

The SBOM is the easy part

The same Annex I list requires you to address and remediate vulnerabilities without delay, provide security updates, and — from September 2026 — report actively exploited vulnerabilities to your CSIRT and ENISA on a 24-hour early-warning clock. Those obligations quietly assume a capability most teams don't have: knowing, at any moment, which shipped versions contain which components, and being alerted when a new advisory affects one of them.

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

1. Continuous SBOM generation — every image that actually runs, not just the ones that went through the happy-path pipeline. Hotfixes, sidecar bumps, and base image rebuilds all change the inventory.
2. SBOMs matched against a live vulnerability feed — a CVE published today must surface against the SBOM of an image you shipped in March. Matching against a stale database, or only at scan time, means your 24-hour clock starts before you know it's ticking.
3. An audit trail — when the authority asks how you handled a vulnerability, "we fixed it at some point" is not an answer. When was it detected, what was affected, when was it remediated or the risk accepted, by whom.

Where your SBOM data lives matters too

An SBOM is a precise map of your product's attack surface. Under the CRA you'll be maintaining these documents for years, per supported version, and producing them to EU authorities. It is worth asking where that data sits: most vulnerability-management vendors in this space are US-based and store SBOM data in US regions. StackRadar stores all SBOM and vulnerability data in the EU — one less data-transfer conversation with your DPO, and consistent with the posture the CRA itself is pushing European buyers toward.

A realistic checklist for platform teams

If you want to see what your inventory actually looks like today, the fastest experiment is to point a scanner at a real cluster — how StackRadar matches SBOMs against OSV explains what happens to the data afterwards.