The Cyber Resilience Act: mapping a new regulatory framework

A market failure, a legislative response

For two decades, the connected electronics market operated without a common baseline for cybersecurity at the design stage. Manufacturers competed on cost and features; security was an optional overhead, rarely weighed in favour of the end user. The outcome is documented: botnets built on millions of poorly secured devices, vulnerabilities left unpatched on products still in service five years after sale, systemically disruptive incidents whose annual economic cost for the European Union was estimated at between €180 and €290 billion in 2020 (European Commission, COM(2022) 454 final).

Regulation (EU) 2024/2847 (the Cyber Resilience Act, CRA) is the EU's legislative response to this structural market failure. Recitals 1 to 7 set out the justification explicitly: fragmentation of national approaches preventing comparability of security levels, the inability of market mechanisms to internalise the negative externalities of insecurity, and the inadequacy of existing obligations under in-force product directives. The regulation entered into force on 10 December 2024, on the legal basis of Articles 114 and 97 of the Treaty on the Functioning of the European Union.

The CRA's architecture follows the New Legislative Framework (NLF) that has structured EU product regulation since 2008: essential requirements, technical file, EU declaration of conformity, CE marking, market surveillance. What changes is the nature of the requirements. Unlike the Radio Equipment Directive, the Low Voltage Directive or the EMC Directive, whose obligations are discharged at the point of placing on the market, the CRA imposes obligations running throughout the product lifecycle.

Scope: what the CRA covers

Article 3(1) defines products with digital elements (PDEs) as software or hardware whose intended or reasonably foreseeable function includes a direct or indirect data connection to a device or network.

The data connection criterion is the key to the scope. The Commission's guidance document (public consultation, March 2026, pursuant to Article 26 CRA) clarifies that a data connection involves the transmission of information in binary form, where binary states are deliberately encoded as information by a source and capable of being decoded at the destination. An electrical signal that triggers or powers a function without transmitting encoded information does not constitute a data connection under the regulation. This distinction excludes simple electrical equipment without digital communication capability.

Three product types fall within scope:

• standalone software:  applications, firmware distributed separately from hardware;
• hardware with embedded software: microcontrollers, embedded systems, connected devices;
• hardware and software designed separately but intended to operate together and supplied as a coherent product.

A point that industrial hardware manufacturers frequently underestimate: software delivered separately (via download, OTA update, or mobile configuration application) forms part of the product if it is necessary for the product to function. The delivery channel does not alter regulatory status.

Exclusions are limited and precise. Article 2 excludes products already covered by sectoral regulations achieving an equivalent level of cybersecurity: medical devices (MDR/IVDR), motor vehicles (type approval), avionics (EASA framework). It also excludes products used exclusively for military or national security purposes, and free and open-source software published outside a commercial activity context.

On the latter, Article 3(48) sets a restrictive definition: software qualifies as FOSS under the CRA only if (i) it is published under a licence granting access, use, modification and redistribution rights, and (ii) its source code is openly shared: publicly accessible, without restriction or condition. Commercially distributed software under a so-called open-source licence whose source code is only accessible to paying customers falls within scope if placed on the EU market in the context of a commercial activity.

Classification: three tiers, three assessment paths

The CRA establishes a three-tier hierarchy that determines the conformity assessment path and, ultimately, whether a notified body (NB) is required.

Default products

Default products are all those not listed in Annex III. According to Commission estimates, they represent approximately 90% of all products with digital elements. For these products, manufacturers may self-certify (Module A): they compile the technical documentation, sign the EU declaration of conformity, and affix the CRA CE marking without third-party involvement.

Module A does not mean an absence of rigour. It means that the manufacturer is not required to engage a notified body. The declaration carries full legal liability and must rest on documented risk assessment and evidence of compliance with the essential requirements of Annex I.

Important products: Class I

Annex III, as detailed by Implementing Regulation (EU) 2025/2392 (published March 2025, setting out the technical descriptions of product categories), lists 35 categories of important products. Among the most significant for connected electronics and security manufacturers:

• Category 3: host-based security software (antivirus, intrusion detection and prevention);
• Category 7: switches and routers intended for small and medium enterprises;
• Category 9: identity and privileged access management systems;
• Category 17: smart home products with security functionalities, connected home security products, including intrusion alarm systems, access control and surveillance cameras.

For Class I products, Module A remains available, but only where applicable harmonised standards or common specifications cover all relevant essential requirements. Without that normative coverage, a notified body is mandatory (Module B+C or Module H).

This creates a critical normative dependency in 2026. The CRA's harmonised standards are not yet published in the Official Journal. The two horizontal standards developed by CEN/CLC/JTC 13, prEN 40000-1-2 (cyber resilience principles and risk assessment framework) and prEN 40000-1-3 (vulnerability handling), reached mature draft status early 2026. The sector-specific EN 304 632 (ETSI TC CYBER, applicable to Category 17) was submitted for combined public enquiry and vote at the same stage. Until harmonisation through OJ citation, Class I manufacturers cannot rely on these standards to justify Module A, and must either work with common technical specifications or engage a notified body. The NANDO database is the reference for tracking CRA NB designations, expected from June 2026 onwards.

Important products - Class II and critical products

Class II covers products whose criticality requires NB involvement regardless of harmonised standard availability. This includes certain operating systems, industrial gateways and routers, and components of critical network infrastructure. For all Class II products, Module B+C or Module H is mandatory.

Critical products (Annex IV), including connected active implantable medical devices and critical infrastructure equipment, are subject to an even more stringent regime, beyond the scope of this article.

Conformity assessment modules

The following table summarises available options by classification:

Module B is the EU type examination: the NB examines the technical documentation and, where satisfied, issues a type examination certificate. Module C is conformity to type based on internal production control. Module H is the full quality assurance approach, suitable for manufacturers with a quality management system covering design and production.

The cost of NB involvement is material. Based on current practice under the Radio Equipment Directive, a type examination takes between three and six months and costs several tens of thousands of euros per product family. For Class I manufacturers who cannot rely on harmonised standards before mid-2027 and who have not yet initiated their compliance work, the risk of NB diary saturation in 2027 is real. Early contact with NB candidates, likely including bodies currently designated under the RED, is a prudent precaution.

The two-speed timeline

11 September 2026: Article 14 notification obligations

Article 14 of the CRA applies from 11 September 2026. It requires any manufacturer who becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting product security, to:

• submit an early warning to ENISA (and to the national CSIRT, ANSSI in France): within 24 hours of becoming aware;
• submit a full notification: within 72 hours;
• submit a final report: within 14 days of patch availability for exploited vulnerabilities, or within one month of the full notification for severe incidents (Article 14§3).

What makes this milestone distinctive is its retroactive scope. Article 14 applies to all products on the market, regardless of when they were placed there. A manufacturer whose products were commercialised in 2018 but whose units are still installed at customer premises is subject to Article 14 from 11 September 2026. There is no grandfather clause. This retroactivity, frequently underestimated, is one of the most demanding aspects of the regulation for manufacturers with large installed bases of older equipment.

Meeting the 24-hour deadline requires an infrastructure that cannot be assembled at short notice: an up-to-date SBOM enabling rapid correlation of published CVEs against products in service, a designated and operational PSIRT function, an externally accessible reporting channel, and an active registration on ENISA's single reporting platform. Building this chain from scratch takes two to four months at minimum.

11 December 2027: full compliance

The December 2027 deadline marks full entry into application: Annex I Parts I and II (essential requirements: secure design and post-market vulnerability management), Annex II (user documentation), Annex VII (technical documentation including SBOM), completed conformity assessment and CRA CE marking. All products placed on the market after that date must comply. Products placed on the market before that date are not obliged to, formally, but Annex I Part II obligations apply to them from September 2026 if units remain in use.

The two dates are frequently conflated. Some manufacturers have retained only 2027 and have not registered the September 2026 intermediate milestone. For a manufacturer of connected products with a significant installed base, September 2026 is the first operationally binding deadline, and the one with the least room for postponement.

Ongoing obligations: the break with previous directives

The fundamental break the CRA introduces compared with previous product directives is the obligation of cybersecurity throughout the product's useful life. Under the RED, the LVD or the Machinery Regulation, conformity is discharged at the point of placing on the market: the manufacturer assesses the product, compiles the technical file, affixes the CE marking, and subsequent obligations are limited to maintaining the file and reporting accidents. The CRA framework is structurally different.

Annex I Part II sets out the ongoing obligations. The principal ones are:

• identify and remediate vulnerabilities within a timeframe proportionate to their severity, independently of planned product revisions;
• deliver security patches through a secure update mechanism, separately from functional updates, with user notification;
• allow users to defer or disable automatic updates, provided they are informed of the associated risks;
• maintain and make available, on request from market surveillance authorities, an SBOM compliant with Annex VII;
• publish and respect a Coordinated Vulnerability Disclosure (CVD) policy enabling third parties to report vulnerabilities.

The support period is not left to the manufacturer's unrestricted discretion. Article 13(8) requires that it should not be shorter than the expected useful life of the product, and sets a minimum of five years unless a documented justification for a shorter useful life is provided. This duration must appear explicitly in the user documentation (Annex II, point 2k).

These obligations create a permanent responsibility of a kind manufacturers had not encountered under previous directives. They structurally transform the relationship between manufacturer and product after delivery. For certain product categories, those with long development cycles and service lives of ten to twenty years (industrial systems, building security equipment), the support obligation over the full useful life is the most structurally demanding constraint in the regulation, well ahead of the CE marking question.

How an inspector reads a CRA file: what early compliance attempts reveal

Understanding the CRA's regulatory structure is necessary. Understanding how a market surveillance authority will read a manufacturer's file is equally important, and the answer differs significantly from what a reading of the texts alone suggests.

An inspector's method follows a funnel: scan many products quickly, then pull the thread wherever a non-conformity signal appears. This initial filter targets what is visible at distribution: the presence and correctness of the CE marking, the manufacturer's address on the product, a batch or lot number, and a user manual in the required language containing the required statements. These checks take a few minutes at a retailer or on receipt of a product. A deficient marking or a missing address is not merely a formality: it is an indicator. If labelling is deficient, it is reasonable to infer that the technical file behind it is too. The inspection deepens accordingly.

Once at the manufacturer's premises, the inspector's first assessment targets the company's maturity on the regulation, before examining any document. Does the company know the regulation's key obligations? Can it answer straightforward questions about its scope? Does it have the essential documents available? None of this is written into any regulatory text, but it shapes the entire inspection. A company that is completely lost on the regulation sends a dual signal: on one hand, a warning about the risks it may be posing to consumers; on the other, for a recently enacted regulation like the CRA, a pedagogical reflex in the inspector: guidance rather than immediate sanction, with sequenced injunctions to support the compliance path. This is not a guarantee of leniency: consumer safety takes precedence, and both responses coexist.

As for what the first CRA compliance attempts observed in the industry already reveal, two patterns are predictable from what is systematically produced in the first years of any new regulation. The first is the absent file: a company that has not started, with no scope analysis, no documentation. The second is the generic file: a risk assessment produced from a standard company-level template, not tailored to the specific product, filed as evidence of Annex I conformity. Annex I Part I of the CRA requires a product-specific risk assessment — covering its functionalities, operational environment, attack surface, and components. A generic template without this tailoring will be identified as such at the first inspection.

What this means for a manufacturer starting today

A manufacturer whose products fall within CRA scope and who begins compliance work in 2026 has nineteen months to full conformity and only a few months to the first operational milestone. This timeline demands a clear prioritisation:

1. Classify products first: identify Class I products (Annex III via Regulation 2025/2392). This decision determines whether a notified body will be required, which in turn conditions the entire budget and schedule;
2. Map the Article 14 perimeter: all products on the market, including older generations still installed at customer premises, and assess their current SBOM coverage;
3. Establish the PSIRT function and CVD policy: before any other documentation workstream. The CVD is a hard-dated compliance obligation;
4. Launch product risk assessments per the prEN 40000-1-2 methodology, to identify technical gaps requiring remediation;
5. Compile technical documentation per Annex VII for products to be maintained in compliance from December 2027.

The temptation is to treat the CRA as a documentation project. It is partly that. But the essential requirements of Annex I Part I impose design decisions (secure by default configuration §1b, secure update mechanism §1c, attack surface minimisation §1d, secure credential management §1e, secure data deletion §1m) that require development time and cannot be substituted by after-the-fact documentation. Manufacturers who document before identifying their technical gaps risk significant rework mid-project. The logical sequence holds: risk assessment first, then design decisions, then compliance documentation.