Cyber Resilience Act

Cyber Resilience Act: cybersecurity as a condition of market access

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires products with digital elements to be securely built, maintained and supplied with vulnerability handling across their whole lifecycle, making cybersecurity a condition of market access for which the manufacturer is answerable.

Until now, there were no horizontal, EU-wide cybersecurity duties for products with digital elements as a condition of market access. The Cyber Resilience Act (CRA) creates exactly those: it treats cybersecurity like any other product property a product is measured against in the EU. This page describes what the CRA asks of manufacturers, how it ties market access to security, and what manufacturer responsibility for software security involves.

What the CRA governs

The CRA addresses products with digital elements, that is hardware and software whose intended use involves a direct or indirect data connection to a device or network. That spans connected sensors, operating systems and application software alike. The obligations fall mainly on the manufacturer who places such a product on the market under its own name, and in a graded form on importers and distributors. Three blocks of requirements sit at the core:

• Secure by design. The product must be designed, developed and produced to provide a level of cybersecurity appropriate to the risk. Security is not a downstream option but part of the construction.
• Vulnerability handling. The manufacturer must identify, document and remediate vulnerabilities through the support period by means of security updates. Updates for security-relevant flaws are meant to be available free of charge.
• Conformity and marking. Before being placed on the market, the product undergoes a conformity assessment and then carries the CE marking, which shows that it meets the requirements.

The essential cybersecurity requirements and the vulnerability-handling provisions are set out in the annexes to the regulation. Effective vulnerability handling presupposes that a manufacturer knows its own components; that inventory is exactly what a Software Bill of Materials (SBOM) provides, which the CRA addresses as an element of the technical documentation.

Manufacturer responsibility for software security

The CRA's real lever is not a single obligation but the shift of responsibility. So far the risk of an insecure application sat with the user who deployed it. The CRA places it where it originates: with the manufacturer who builds the product and puts it on the market. Security thus becomes a condition of market access, comparable to the electrical safety of a device. Whoever places a product with digital elements on the EU market without appropriate cybersecurity risks having it withdrawn, and is subject to oversight by national market surveillance authorities.

This logic changes the build side. Security is no longer a maturity level a team reaches eventually, but a property that must be demonstrable from the design stage on. Methodically this is only sustainable if security and conformity evidence is anchored as an auditable rule in the delivery process, as Compliance as Code describes, rather than as a one-off audit shortly before launch. The organisational frame for that, from risk assessment to evidence, is covered by the security strategy; the recognised bracket for a security management system is provided by ISO 27001.

The path to conformity

A product's path from design to CE marking follows a recurring sequence. It turns the three requirement blocks into a traceable flow:

flowchart TD
    A["Product with digital elements<br/>check scope"] --> B["Classify<br/>default, important, critical"]
    B --> C["Secure by design<br/>risk assessment, secure construction"]
    C --> D["Technical documentation<br/>incl. SBOM"]
    D --> E["Conformity assessment<br/>self-assessment or third party"]
    E --> F["CE marking<br/>place on market"]
    F --> G["Vulnerability handling<br/>updates, reports across the lifecycle"]
    G --> C

The decisive point is that the loop does not end at the sale. Vulnerability handling continues across the entire support period and feeds new findings back into construction and documentation. How deep the conformity assessment goes depends on the product's classification: for the bulk of products a self-assessment by the manufacturer is foreseen, while for products of particular cybersecurity relevance an assessment by a notified body may be required.

Reporting obligations

Beyond the build requirements, the CRA introduces reporting obligations. Manufacturers must report actively exploited vulnerabilities and severe security incidents to the competent bodies; the EU cybersecurity agency ENISA and the national computer emergency response teams (CSIRTs) are part of that reporting path. The regulation sets tight deadlines for this, with an early notification shortly after becoming aware. The expectation thus shifts from quietly handling a vulnerability internally toward an active, deadline-bound report.

Timeline

The regulation does not apply all at once but in stages:

• In force since 10 December 2024. This starts the transition period in which manufacturers prepare.
• Reporting obligations from 11 September 2026. The duties to report actively exploited vulnerabilities and severe incidents apply first.
• Main application from 11 December 2027. From this date the remaining obligations, including secure by design, conformity assessment and CE marking, apply in full.

What the scope means for an organisation

Whether the CRA reaches an organisation is decided not by its seat but by whether a product with digital elements is made available on the EU market. For the build side that means: anyone placing hardware or software on the EU market must reckon with the obligations, regardless of where that organisation is established. This market-based reach resembles the extraterritorial logic of the EU AI Act. A Swiss manufacturer or supplier placing products on the EU market may meet the trigger accordingly; whether that holds in a given case depends on the specific constellation, this page only reports the mechanism.

An organisation building for several markets also meets regimes running side by side. Switzerland has had its own reporting obligation for cyberattacks on critical infrastructure since 2025 under the Information Security Act, which applies independently of the CRA; anyone building products for both markets therefore meets two reporting regimes at once. At EU level the CRA also sits alongside the Network and Information Security Directive (NIS2), which addresses not products but operators of essential services; in practice the two are often considered together.

Where implementation breaks

• Vulnerability handling without an inventory. Without knowing the product's own components and their dependencies, vulnerabilities cannot be remediated systematically. Without an SBOM the obligation stays a declaration of intent.
• Security only at the end. Conformity retrofitted shortly before launch contradicts the secure-by-design idea and costs more than an end-to-end process.
• Reporting paths unclear. Without a prepared process for the deadline-bound report to ENISA and CSIRTs, the first serious incident becomes a crisis rather than a routine.
• Scope misjudged. Assuming that being established outside the EU shields an organisation from the CRA misses the market-access trigger.

References

• European Commission Cyber Resilience Act, official policy page. Explains scope, obligations, CE marking and the staggered application dates. (03.12.2025). digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• ENISA European Union Agency for Cybersecurity. Receives manufacturer reports and supports CRA implementation, for example on SBOM practice. (living doc). www.enisa.europa.eu/
• Federal Office for Cybersecurity (BACS) Reporting obligation for cyberattacks on critical infrastructure. Switzerland's reporting duty under the Information Security Act, which applies in parallel to the CRA. (living doc). www.ncsc.admin.ch/ncsc/en/home/meldepflicht.html
• Regulation (EU) 2024/2847 (EUR-Lex) Full text of the Cyber Resilience Act, the authoritative legal text. Contains the essential requirements, vulnerability handling and the application dates. (20.11.2024). EUR-Lex CELEX 32024R2847

---

Related topics

• SBOM, the bill of materials without which vulnerability handling does not hold.
• Security strategy, the organisational frame for security and evidence.
• EU AI Act, the parallel EU regulation with similar extraterritorial reach.
• ISO 27001, the recognised bracket for a security management system.
• Compliance as Code, the methodical lever for auditable conformity.