EU Cyber Resilience Act requirements for containers and Kubernetes

Starting in full force on Dec. 10, 2024, the EU Cyber Resilience Act (CRA) is a regulation (EU 2024/2847) that defines mandatory cybersecurity requirements for all products with digital elements sold in EU markets. Reporting obligations will begin on Sept. 11, 2026, with full enforcement kicking in on Dec. 11, 2027. The CRA brings new requirements for teams working with containers and Kubernetes regarding how cloud native applications are built, distributed, and maintained throughout their lifecycle.

CRA scope in cloud native environments

The CRA covers all container images, Kubernetes operators, and Helm charts with commercial support that are available to EU customers, regardless of where the distributing organization is located. The regulation defines its scope as “products with digital elements” available in EU markets, and that includes much of the cloud native stack.

CRA scope items include container images distributed publicly, commercial Kubernetes operators, Helm charts with commercial support, and open source with commercial backing. Open-source projects may also be affected, especially those with commercial backing or support contracts. As part of the regulation, a compliance chain is required throughout the cloud native supply chain.

Important CRA requirements for container teams

The CRA introduces requirements that directly affect how teams build and operate container infrastructure. These categories include:

Security by design and default – Hardened base images, minimal attack surfaces, and secure defaults as regulatory requirements.

Vulnerability management – SBOM data, continuous monitoring, and 24-hour ENISA reporting for exploited vulnerabilities.

Long-term security (5+ Years) – Ongoing security updates, rebuild pipelines, and backward-compatible patching for product lifetime.

This Act requires that base images are hardened with unnecessary components removed and secure configurations applied before products are available on the market. The regulation codifies what many in the cloud native community have long advocated for – minimal attack surfaces and secure defaults have now become regulatory requirements rather than recommendations.

Under the CRA, organizations must maintain Software Bill of Materials (SBOM) data, continuously monitor for vulnerabilities, and remediate within defined timeframes. Under Article 14, actively exploited vulnerabilities require an early warning notification to The European Union Agency for Cybersecurity (maintaining the acronym from the agency’s previous name European Network and Information Security Agency – ENISA) within 24 hours of becoming aware, followed by a full notification within 72 hours. This signals that organizations’ detection and incident response processes need to operate at scale across clusters.

Following CRA Article 13, products require security updates for a minimum of five years from the date of being available on the market, or throughout the expected product lifetime if that period is shorter. For container teams, this means tracking container versions deployed in customer environments, maintaining rebuild pipelines for older images, and ensuring backward compatibility – all while addressing security issues discovered years after release.

The CRA and Kubernetes deployments

Kubernetes environments are affected by the CRA because many production deployments involve numerous container images from different sources, each with varying security practices and update mechanisms. This includes applications, containers, sidecars, monitoring agents, and operators.

In addition, when deploying third-party controllers or operators, teams inherit potential CRA obligations. The regulation’s supply chain requirements define that it is very important to understand the security posture and update mechanisms for dependencies.

Preparing for CRA compliance

It is recommended that teams prepare for CRA compliance by adopting practices in the Cloud Native Computing Foundation (CNCF) ecosystem that align with CRA requirements. The following four areas provide a practical starting point:

Minimal containers – Start from secure base images that do not have inherited vulnerabilities, then harden the application by removing unnecessary software and reducing the overall attack surface.

Software bill of materials complemented with runtime bill of materials – Go beyond static inventory. Integrating automated SBOM and RBOM generation into CI/CD pipelines will help distinguish installed components from those actually executed at runtime.

Image distribution strategies – Review how security updates reach users, which versions are deployed and where, and how registries enforce policies across environments.

Supply chain visibility – Identify who maintains the images you depend on, what their security update cadence looks like, and whether alternative strategies might be needed for critical dependencies.

The CRA and the future of cloud native security

The CRA represents a regulatory shift toward prioritizing software security as a fundamental product requirement rather than a best practice. For the cloud native ecosystem, this creates challenges around operationalizing security practices at scale, but also validates proven approaches the community has developed around minimal containers, supply chain security, and automated vulnerability management.

Organizations distributing containerized products to EU markets have time to adapt, but the architectural and operational patterns required for compliance often take time to implement effectively. Starting the planning now regarding container security posture, SBOM generation, and vulnerability response processes helps teams make informed decisions as they build and evolve their cloud native platforms.