EU Cyber Resilience Act: Overview, Requirements, and Timelines

The EU Cyber Resilience Act (CRA), introduced on December 10, 2024, establishes the first horizontal cybersecurity regulation for all products with digital elements placed on the European Union market. Unlike previous sector-specific directives, the CRA applies uniformly to both hardware and software—spanning consumer IoT devices, enterprise applications, container runtimes, and cloud-connected components. Its primary purpose is to close the regulatory gap that left many digital products without mandatory security obligations, such as vulnerability patching, incident disclosure, or software transparency.

The urgency is underscored by Omdia's 2026 software supply chain security report, which found that 77% of organizations experienced a supply chain incident in the preceding year. Prior to the CRA, a manufacturer could ship a product with known vulnerabilities and face no legal requirement to remediate or notify users. The CRA mandates that manufacturers design and develop products with an appropriate level of cybersecurity based on a risk assessment, maintain vulnerability handling throughout the support period, and provide a software bill of materials (SBOM) as part of the technical documentation.

Key CRA obligations for manufacturers include:

• Security-by-design: Products must ship with secure default configurations, minimal attack surface, and mechanisms for secure updates. For container images, this translates to hardened base layers and removal of unnecessary components.
• Vulnerability handling: Manufacturers must establish processes for identifying, documenting, and remediating vulnerabilities, including a coordinated disclosure policy and timely security updates free of charge during the defined support period.
• SBOM requirement: A machine-readable software bill of materials (typically in SPDX or CycloneDX format) must be included in the technical documentation retained for ten years or the support period, whichever is longer. The SBOM is not required to be public but must be provided to market surveillance authorities upon request.
• Incident and vulnerability reporting: Actively exploited vulnerabilities and severe incidents must be reported to the relevant CSIRT and ENISA within strict timelines—24 hours for early warning, 72 hours for a full notification, and a final report within 14 days (or one month for severe incidents).

The CRA also introduces a three-tier product classification system that determines the conformity assessment procedure, ranging from self-declaration to mandatory third-party evaluation. Products classified as Important Class II—such as container runtimes—require assessment by a notified body before receiving CE marking. By establishing these horizontal requirements, the CRA transforms voluntary security practices into legally enforceable duties, directly addressing the supply chain risks that affect a majority of enterprises today.

The CRA assigns obligations based on the entity's role in bringing a product with digital elements to the EU market. Three distinct roles are defined, each with a different burden.

• Manufacturers carry the heaviest obligations. Before placing a product on the market, they must perform a conformity assessment (self-assessment or third-party depending on product classification), affix the CE marking, and issue a declaration of conformity. For container runtimes—typically classified as Important Class II—a notified body assessment is required. Post-market duties include vulnerability handling, reporting actively exploited vulnerabilities (early warning within 24 hours, full notification within 72 hours), and retaining technical documentation—including a machine-readable SBOM in a standard format such as SPDX or CycloneDX—for ten years or the support period, whichever is longer.
• Importers and distributors have lighter but critical verification and documentation duties. They must confirm that the manufacturer has fulfilled its obligations, retain copies of the EU declaration of conformity and technical documentation, and notify authorities if they become aware of a non-conformity or vulnerability affecting the product. Example: a distributor reselling a container image registry in the EU must verify the manufacturer’s conformity documentation before placing the product on the market.
• Open-source software stewards are a new category, primarily for micro-enterprises (fewer than 10 employees and annual turnover ≤ €2M) that systematically support open-source software used in commercial activity. Their obligations are scaled-down: they must implement a cybersecurity policy, handle vulnerabilities, cooperate with market surveillance authorities, and comply with certain reporting duties. They are not required to perform conformity assessment or affix CE marking for the open-source code itself. Example: a micro-enterprise maintaining a widely used open-source library must still provide a vulnerability disclosure policy.

Relationship with NIS2. The CRA and NIS2 target different subjects: CRA governs cybersecurity of products; NIS2 governs resilience of essential and important entities. Recital 12 of the CRA explicitly excludes SaaS, PaaS, and IaaS solutions, leaving them under NIS2. However, the boundary blurs for products that depend on cloud infrastructure. The European Commission’s draft guidance introduced a three-part test to determine when a cloud component falls under CRA scope. The test asks: (1) Does the processing happen remotely? (2) Would the product lose a core function without it? (3) Did the manufacturer design, develop, or control that remote component? If the answer to all three is yes, the cloud component is treated as part of the product for CRA purposes, and GDPR may also apply in parallel if personal data is processed.

The EU Cyber Resilience Act (CRA) organizes its essential cybersecurity requirements into two complementary areas defined in Annex I: security-by-design for product properties and vulnerability handling obligations for the product lifecycle. Both areas directly affect how enterprise teams design, build, and maintain containerized software.

Security-by-design requires that products be developed and produced to ensure an appropriate level of cybersecurity based on a risk assessment. In practice, this means shipping with secure default configurations, minimizing the attack surface by removing unnecessary components, protecting the confidentiality and integrity of stored and transmitted data, and providing mechanisms for secure updates. Data minimization is also required: the product must process only personal or other data that is adequate, relevant, and limited to what is necessary for its intended purpose. For container images, these requirements map directly to image hardening practices:

• Use minimal base layers that contain only the libraries and binaries required for the application.
• Remove unnecessary shells, package managers, and debug utilities to reduce the attack surface.
• Apply secure defaults out of the box—for example, non‑root users, read‑only filesystems, and restricted network capabilities.
• Scope generated SBOMs (e.g., in SPDX or CycloneDX format) to package and dependency metadata only, keeping embedded secrets and personal data out of the artifact.

Vulnerability handling obligates manufacturers to maintain documented processes for identifying, documenting, and remediating vulnerabilities throughout the defined support period. This includes implementing a coordinated vulnerability disclosure policy, providing security updates free of charge, and publicly disclosing fixed vulnerabilities with enough technical detail for users to assess impact and apply remediation—while avoiding information that would increase risk or expose personal data. Incident reporting timelines apply to actively exploited vulnerabilities (24‑hour early warning, 72‑hour full notification, 14‑day final report after a corrective measure is available). For container images distributed commercially into the EU, these obligations turn vulnerability scanning, patch management, and disclosure workflows from best practices into legal requirements. Manufacturers must also include a machine‑readable SBOM in technical documentation, retained for ten years after market placement or the support period, whichever is longer.

The EU Cyber Resilience Act (CRA) mandates that manufacturers of products with digital elements include a software bill of materials (SBOM) in the technical documentation for each product. This requirement applies to container runtimes distributed commercially into the EU and takes full effect December 2027, though vulnerability reporting obligations begin September 2026. The SBOM must be in a commonly used, machine-readable format; in practice, this means SPDX or CycloneDX. The regulation does not prescribe a specific format, but these two are the de facto standards for enterprise SBOM tooling.

The SBOM must cover, at minimum, the top-level dependencies of the product. This scope includes direct dependencies declared by the product, but the CRA does not explicitly require recursive transitive dependency enumeration. A practical example: for a container image, the SBOM should list the base image, the runtime libraries installed (e.g., glibc, OpenSSL), and any application-level packages. The artifact must be scoped to package and dependency metadata only. Embedded secrets, credentials, API keys, or personal data must never be included, as exposing such information would violate both the CRA’s security-by-design principles and the GDPR.

Key logistical requirements:

• Retention period: The SBOM must be retained for ten years after the product is placed on the market, or for the duration of the support period, whichever is longer.
• Not publicly required: The CRA does not oblige manufacturers to publish SBOMs publicly. They must be included in technical documentation and provided to market surveillance authorities upon request.
• Confidentiality: The SBOM itself should not contain personal data (e.g., reporter identities, user contact information). Any personal data handled during vulnerability reporting must be processed in line with GDPR.

For enterprise engineering teams, the practical implication is that SBOM generation must be embedded in the CI/CD pipeline. Tools like Syft or Trivy can produce CycloneDX or SPDX output from container images. The generated SBOM should be stored alongside the product’s technical documentation, versioned, and retained for the required period. Avoid including environment variables, configuration secrets, or user identifiers in the SBOM artifact. The CRA’s transparency obligations focus on dependency composition, not operational details.

Under the EU Cyber Resilience Act (CRA), manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents that impact the security of their products. An actively exploited vulnerability is a software flaw for which reliable evidence shows that a malicious actor has exploited it in a system without the owner’s permission. A severe incident is a security event that causes or is capable of causing significant operational disruption, financial loss, or harm to users. These obligations apply separately and follow their own reporting cadences.

Reporting must be submitted to the relevant national Computer Security Incident Response Team (CSIRT) and to the European Union Agency for Cybersecurity (ENISA) through a single reporting platform. The timeline for each notification stage is defined relative to the moment the manufacturer becomes aware of the event:

• 24 hours – Early warning notification: A preliminary alert stating that an actively exploited vulnerability or severe incident has been identified. This notification should include an initial assessment of the nature and potential impact, but does not need full technical detail.
• 72 hours – Full notification: A comprehensive report containing technical details about the vulnerability or incident, including the root cause, affected components, and any indicators of compromise. This submission must be complete enough for authorities to triage the event.
• 14 days (for actively exploited vulnerabilities) – Final report: Submitted after a corrective measure (e.g., a security patch or workaround) is available. The report describes the fix, its validation, and guidance for users.
• 1 month (for severe incidents) – Final report: Submitted one month after the 72-hour notification. It summarises the incident, the actions taken, and any lessons learned that could inform broader defensive measures.

Privacy must be minimised in all reports. While the notifications may legitimately contain personal data (such as the reporter’s identity or details of affected users), manufacturers must limit each submission to only the technical information that the CSIRT and ENISA need for their analysis. Any personal data must be handled in accordance with the General Data Protection Regulation (GDPR). Additionally, notifications must avoid disclosing information that would increase risk to users, such as exploit details that have not yet been mitigated.

These mandatory reporting timelines take effect on September 11, 2026. Manufacturers should already have internal processes capable of generating an alert within 24 hours of discovery and a full forensic report within 72 hours. For example, when a vulnerability in a container runtime is discovered to be under active exploitation, the manufacturer must notify the CSIRT and ENISA within one day, provide a detailed technical breakdown within three days, and deliver a final remediation report within two weeks of the patch release.

The EU Cyber Resilience Act (CRA) mandates a conformity assessment before any product with digital elements can be placed on the European market. This assessment verifies adherence to the essential cybersecurity requirements defined in Annex I of the regulation. The specific procedure depends on the product’s risk classification, which the CRA divides into three tiers: default (general software and hardware), Important Class I (e.g., identity management systems, firewalls), and Important Class II (e.g., container runtimes, operating systems, hardware security modules). Default-tier products typically undergo a self-assessment by the manufacturer. Important Class I products may also be self-assessed if harmonized standards exist; otherwise, third-party involvement is required. Important Class II products always require a third-party conformity assessment by a notified body.

Container runtimes distributed commercially into the EU fall under the Important Class II tier. Consequently, a manufacturer of such a runtime must engage an independent, EU-designated notified body to audit the product’s design, development, and vulnerability handling processes. This third-party assessment verifies that security-by-design principles—such as minimal base layers, removal of unnecessary shells and package managers, and secure default configurations—are implemented and documented. In practice, this means the manufacturer must provide technical documentation that includes a machine-readable software bill of materials (SBOM) and evidence of secure update mechanisms. Upon successful completion, the manufacturer may affix the CE marking and issue an EU declaration of conformity, which is required before the product can be sold in the EU market.

Key compliance deadlines drive the timeline for conformity activities:

• Mandatory vulnerability and incident reporting takes effect on September 11, 2026. From this date, actively exploited vulnerabilities and severe incidents must be reported to the relevant CSIRT or ENISA within 24 hours (early warning), 72 hours (full notification), and 14 days (final report). Manufacturers must have their vulnerability handling processes in place before this deadline.
• Full regulation effect on December 11, 2027. By this date, all products with digital elements placed on the EU market must have completed their conformity assessment and bear the CE marking.

For enterprise teams building container runtimes, the practical sequence begins with a risk classification analysis to confirm the Important Class II tier. The manufacturer should then select a notified body early—ideally by early 2027—to allow time for the assessment. The third-party audit will examine the SBOM format (typically SPDX or CycloneDX), vulnerability disclosure policies, and secure development lifecycle documentation. Only after successful assessment can the CE marking be applied, granting legal market access. No statistics or specific vendor case studies are required; the regulation itself mandates these steps for all applicable products.