Security1 publisher2 min readPublished
EU's Cyber Resilience Act puts Helm chart and Kubernetes operator vendors on a 24-hour exploit clock
EU Cyber Resilience Act rules have required 24-hour ENISA warnings on exploited flaws in commercial container images since Sept. 11, 2026. Vendors of supported Kubernetes operators and Helm charts are on the same clock, well before the rest of the law is enforced in December 2027.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Under Article 14, the 24-hour early warning to ENISA must be followed by a full notification within 72 hours.
- Article 13 requires security updates for at least five years from the date a product reaches the market, or for its expected lifetime if that is shorter.
- Vendors must keep SBOM data, monitor continuously for vulnerabilities and remediate within defined timeframes.
- Base images must be hardened, with unnecessary components removed and secure configurations applied, before a product goes on the market.
- Open-source projects may fall in scope, especially those with commercial backing or support contracts.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Vendors need exploit detection and triage that work across customer clusters today, because the 24-hour window counts from the moment they become aware.
- cost Each supported image commits its vendor to years of version tracking in customer environments, rebuild pipelines for older images and backward-compatible patches.
- exposure Vendors headquartered outside the EU are in scope for any supported image, operator or chart that EU customers can obtain.
- decision Picking a third-party Kubernetes operator now means vetting its supplier's update practices, since the team that deploys it inherits potential CRA obligations.
The 15 months between Sept. 11, 2026 and Dec. 11, 2027 [1] give vendors time to meet the build and lifecycle rules. Reporting has applied since Sept. 11 [1]. A vendor that learns this week of active exploitation in an image it ships owes ENISA an early warning within 24 hours of becoming aware [5].
Article 13 is where the cost sits. A container image first made available on Dec. 11, 2027 would need security updates until Dec. 11, 2032, unless its expected lifetime is shorter [2]. The article's examples include security issues discovered years after release [11].
Kubernetes adds suppliers. Many production deployments run images from several sources, each with its own security practices and update mechanisms, across applications, sidecars, monitoring agents and operators [15]. The regulation requires a compliance chain through the whole cloud native supply chain [12].
For teams already shipping minimal images, the build rules change little. Help Net Security describes hardened base images and secure defaults as practices the cloud native community has long advocated, now written into law as requirements [17]. Its preparation advice follows CNCF ecosystem practice. It starts with minimal containers built on secure base images and with SBOMs paired with a runtime bill of materials [16].
Regulation (EU) 2024/2847 has been in force since Dec. 10, 2024 and applies to products with digital elements sold in EU markets [3]. For cloud-native software, whether a product is covered depends on commercial support [4]. The article does not say where a community chart with no backing falls, what penalties apply, or how ENISA will process the warnings.
What to watch
- ENISA or European Commission guidance on whether community-maintained Helm charts and images without commercial support fall inside CRA scope.
- The first public figures on Article 14 early warnings filed by software vendors since Sept. 11, 2026.
- Vendors publishing defined support periods for container images and operators ahead of Dec. 11, 2027.