Cyber Resilience Act (CRA): EU cybersecurity baseline for digital products

Author Hugues Orgitello Last updated 26 May 2026

Guide · Cyber Resilience Act

Adopted in October 2024 and in force since 10 December 2024, Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), establishes the first horizontal cybersecurity baseline applicable to every product with digital elements placed on the Union market. Full applicability is set for 11 December 2027, with intermediate reporting duties activated as early as September 2026. This guide sets out the scope of the text, its three product classes, the thirteen essential requirements of annex I, the conformity assessment routes, the transition timetable, and the interaction with RED 3.3 and the EN 18031 series.

Why a horizontal cybersecurity regulation

Before the CRA, cybersecurity of digital products in Europe relied on a sector-by-sector patchwork: RED 3.3 for connected radio equipment, MDR for medical devices, the NIS2 directive for operators of essential entities, EUCC schemes under the Cybersecurity Act. No single text covered non-radio, non-medical products distributed to general users. A wired IP camera, a network attached storage device, an enterprise software package sold on shelves, a firmware embedded in an industrial controller all sat outside the direct scope.

This fragmentation produced two effects documented in the Commission impact assessment: an uneven level of cybersecurity depending on the distribution channel, and an unpredictable regulatory burden for manufacturers asked to cover the same product under several regimes. The CRA responds with a common baseline applicable to any party placing a digital product on the EU market, complemented by a risk-proportionate stratification.

The regulation has an extraterritorial reach: it applies to any manufacturer, importer or distributor placing a product on the EU market, regardless of location. A US software vendor distributing a backup tool to European users enters the scope, just as a Chinese industrial manufacturer exporting IP cameras.

Scope: products with digital elements

The CRA introduces the concept of product with digital elements (PDE). Article 3 defines it as any software or hardware product, together with its remote data processing solutions, the logical or physical connection of which to a device or network is intended.

That definition captures:

• Connected hardware: IP cameras, routers, network attached storage, IoT sensors, industrial equipment with network interfaces, connected toys, connected appliances.
• Standalone software placed on the market: operating systems, browsers, antivirus, office suites, business software sold under licence or as a service when the software component is delivered to the customer.
• Software and hardware components made available separately for integration into a final product, to the extent that they are placed on the market in that capacity.

The regulation specifies several explicit exclusions in article 2, based on the existence of sector-specific cybersecurity legislation:

Excluded category	Applicable text
Medical devices	Regulation (EU) 2017/745 (MDR) and 2017/746 (IVDR)
Motor vehicles	Regulation (EU) 2019/2144, UNECE R155/R156
Civil aviation	Regulation (EU) 2018/1139
Marine equipment	Directive 2014/90/EU
Products exclusively intended for defence or national security	Outside Internal Market competence

The regulation also carves out an exemption for free and open source software distributed outside a commercial activity. A volunteer community project stays out of scope. As soon as a publisher derives direct or indirect revenue from the distribution (paid support, enterprise edition, integration in a commercial offering), it falls within scope. The text further introduces the figure of open source software steward, subject to lighter obligations focused on security policy and cooperation with authorities.

Three product classes, three assessment routes

The CRA stratifies products by cybersecurity risk level, determined by intended use and by the potential to compromise other components of the information system.

Default class

This is the residual class, covering the majority of digital products not listed in annex III or IV. For this class the manufacturer proceeds with self-assessment (module A) on the basis of European harmonised standards where available, and issues the EU declaration of conformity itself. Annex I must be fully met, but no third party is required.

Important class (annex III)

Annex III lists the important products for the cybersecurity of the European digital market. It is split into two sub-classes:

• Class I: identity managers, password managers, standalone web browsers, antivirus, VPNs, network management systems, SCADA controllers (second tier), residential routing equipment. Self-assessment remains possible if all relevant harmonised standards are fully applied. Otherwise, a notified body examination becomes necessary (module B+C or H).
• Class II: hypervisors, container runtimes, enterprise-grade firewalls, intrusion detection systems, secure microprocessors, microcontrollers with security elements, smart card readers. Third-party evaluation is mandatory (module B+C or H), even when harmonised standards are fully applied.

Critical class (annex IV)

Annex IV groups the critical products whose compromise would carry systemic consequences: hardware security modules (HSM), secure smart meter gateways, secure smart cards. For these products, the regulation allows the Commission to require, through a delegated act, a European cybersecurity certification scheme (EUCC) under Regulation (EU) 2019/881. Absent such an act, evaluation follows the important class II route.

Summary table

Class	Examples	Assessment route	Third party required
Default	IoT sensor, consumer IP camera, office application	Module A (internal)	No
Important I (annex III)	Antivirus, VPN, browser, home router	Module A if harmonised standards fully applied, otherwise B+C or H	Conditional
Important II (annex III)	Hypervisor, enterprise firewall, secure microcontroller	Module B+C or H	Yes (notified body)
Critical (annex IV)	HSM, smart meter gateway, secure smart card	European cybersecurity certification scheme or module B+C/H	Yes (certification or NB)

The split echoes, in spirit, the way RED article 3.3 modulates assessment based on the selected assurance level (basic, substantial, high), with finer granularity for software.

The thirteen essential requirements of annex I

Annex I lists the technical requirements every PDE must meet. Part I addresses product properties (cybersecurity by design and by default). Part II frames vulnerability handling across the lifecycle.

Part I, product properties (13 requirements)

1. The product is delivered without known exploitable vulnerabilities.
2. The product is delivered with a secure-by-default configuration, which can be modified by the user.
3. Vulnerabilities can be addressed through security updates, automatic where appropriate.
4. The product ensures protection against unauthorised access through appropriate authentication, identity management or access control mechanisms.
5. The product protects the confidentiality of stored, processed or transmitted data (encryption at rest and in transit, key management).
6. The product protects the integrity of data, commands and internal parameters against unauthorised modification or manipulation.
7. The product processes only the data necessary for its intended use (minimisation).
8. The product protects the availability of essential functions, including resilience to denial-of-service attacks.
9. The product limits its negative impact on the availability of services provided by other devices or networks.
10. The product is designed, developed and produced to limit attack surfaces, including external interfaces.
11. The product is designed to reduce the impact of an incident through mitigation techniques and mechanisms.
12. The product provides security-related information (logs, internal events) accessible to the user or to a monitoring agent.
13. The product allows users to securely delete or transfer their data and configurations.

Part II, vulnerability handling

The manufacturer must identify and document the vulnerabilities and components of the product, including by producing a software bill of materials (SBOM) structured and machine-readable. It must address vulnerabilities without delay through free security updates, separated from feature updates. It must publish a coordinated vulnerability disclosure policy, provide a reporting address, and document the patches released. The minimum security support period is left to the manufacturer but cannot be shorter than the expected period of use of the product, and is typically not shorter than five years.

Conformity assessment routes

The regulation reuses the modules defined in Decision No 768/2008/EC. The selection grid is simpler than under the RED because the CRA excludes certain modules.

Module	Description	CRA use case
A	Internal production control	Default class; important class I with harmonised standards fully applied
B + C	EU-type examination (by NB) + conformity to type	Important class I without complete harmonised standards, important class II
H	Full quality assurance	Important class I and II, high-volume manufacturers with mature QMS
European certification	EUCC scheme under Regulation 2019/881	Critical class (annex IV) where the Commission requires it

For a comparison with other electronic directives, the self-declaration vs notified body guide details the module mechanics.

ENISA reporting duties

Article 14 establishes a tiered reporting mechanism, modelled on NIS2 but specific to digital products. Reports flow through a single platform managed by ENISA, connected to the national CSIRTs.

Deadline	Expected content	Recipient
24 hours after awareness	Early warning indicating that an actively exploited vulnerability or a severe incident is suspected	National CSIRT + ENISA
72 hours	Vulnerability notification with initial assessment (severity, exploitation, intended corrective measures)	National CSIRT + ENISA
Without undue delay	Information to affected users on corrective measures and required actions	Product users
14 days after a patch is available	Updated report including the patch	National CSIRT + ENISA
Final report within one month	Detailed description, root cause, permanent mitigation measures	National CSIRT + ENISA

The dual dimension of the reporting is worth noting. ENISA and the national CSIRT receive the technical information; users receive in parallel an operational notice enabling them to apply available patches or take mitigation measures. The manufacturer cannot patch silently.

Transition timetable

The regulation entered into force on 10 December 2024, twenty days after publication in the Official Journal. Article 71 organises a staged application across thirty-six months.

Date	Step	Activated scope
10 December 2024	Entry into force	Text legally binding, transitional provisions
11 June 2026	+18 months	Obligations applicable to notified bodies (designation, accreditation)
11 September 2026	+21 months	Reporting duties for actively exploited vulnerabilities and severe incidents to ENISA
11 December 2027	+36 months, full applicability	All other obligations: annex I essential requirements, conformity assessment, CE marking under the CRA, EU declaration of conformity, penalties

The intermediate window of September 2026 deserves attention. A manufacturer that has not yet built its vulnerability monitoring capability, its user notification channel and its working relationship with ENISA will be exposed to a breach from that date, even though the technical requirements of annex I are not yet enforceable. The sequencing is deliberate: the Commission considered that early reporting was needed to calibrate the future assessment schemes.

Interaction with the CE marking and other directives

The CRA belongs to the CE marking family. Compliance is evidenced by affixing the CE marking on the product and by issuing an EU declaration of conformity. For a product already covered by other acts (RED, EMC, low voltage), a single declaration cites all applicable texts. The transversal rules of the CE marking are detailed in the CE marking guide and the CE procedure.

Overlap with RED 3.3

For radio products connected to the Internet, two regimes coexist from 2027 onward: RED 3.3 (Delegated Regulation 2022/30, activated since 1 August 2025) and the CRA. RED 3.3 covers three targeted essential requirements (network protection, protection of personal data and privacy, fraud protection) and applies to equipment falling under Directive 2014/53/EU. The CRA introduces a wider horizontal baseline (thirteen requirements, vulnerability handling, reporting) covering all digital products.

On the common perimeter (radio products connected to the Internet), both texts apply in parallel. Article 12 of the CRA establishes a cross presumption of conformity: a product compliant with the cybersecurity requirements of other Union acts may be presumed compliant with corresponding CRA requirements. Regulatory consolidation is expected by 2028, with details still to be defined.

The EN 18031-1/-2/-3 harmonised standards published in the OJEU in August 2024 serve as a common technical foundation for both regimes. They presume conformity to RED 3.3 today, and their ongoing revision integrates CRA requirements to play the same role in the future framework.

For RED-side mapping, see the RED directive, RED harmonised standards and RED tests pages, together with the RED checklist which already integrates article 3.3.

Penalties and market surveillance

Article 64 sets out the administrative penalty regime:

• Breach of annex I essential requirements and of manufacturer obligations: up to EUR 15 million or 2.5 percent of total worldwide annual turnover (whichever is higher).
• Failure to comply with reporting and cooperation duties: up to EUR 10 million or 2 percent of worldwide turnover.
• Incorrect, incomplete or misleading information provided to authorities: up to EUR 5 million or 1 percent of worldwide turnover.

Market surveillance is carried out by national authorities designated under Regulation (EU) 2019/1020, which can order withdrawal, recall or prohibition of a non-compliant product. ENISA maintains a public registry of reported vulnerabilities (with filtering of sensitive information) and coordinates cross-border actions.

Preparing a CRA-ready product

For a manufacturer placing a digital product on the EU market today, the compliance trajectory runs through several milestones.

1. Classification: determine the product class (default, important I/II, critical) based on annexes III and IV. Document the decision.
2. Requirement mapping: for each requirement of parts I and II of annex I, identify the technical controls in place, the gaps, and the corrective actions.
3. SBOM: produce an operable SBOM (CycloneDX, SPDX formats) covering all software components, including third-party libraries and embedded module firmwares.
4. Disclosure policy: publish a coordinated disclosure policy, a reporting address (security.txt, dedicated contact), a response SLA.
5. Vulnerability watch: subscribe critical components to CVE, NVD, GitHub Advisory feeds; automate SBOM/CVE correlation.
6. Update process: ensure cryptographic signing, secure channel, anti-rollback, version history.
7. Assessment route: for important class II and certain important class I products, preselect a notified body (the NANDO list will be consolidated from June 2026).
8. Technical documentation: prepare the technical file according to annex VII (product description, design, risk assessment, test reports, SBOM).
9. EU declaration of conformity: annex V template, combining where applicable CRA, RED, EMC, low voltage.

Manufacturers already running a RED 3.3 programme have a reusable foundation: cybersecurity risk analysis, firmware signing mechanisms, secret management, signed OTA. Transposing to the CRA remains an additional effort, mainly concentrated on SBOM, formalised vulnerability handling and the ENISA reporting setup.

The spilma glossary lists key terms (PDE, SBOM, EUCC, coordinated disclosure) with their reference definitions.

Need help?

A 30-minute audit with AESTECHNO engineers.

AESTECHNO is the electronics design house that edits spilma. We help product teams scope their certification effort and avoid the common mistakes.

Book a free audit

Watch points

Risk	Consequence	Action
Conflating RED 3.3 and CRA	Scope underestimated for non-radio products	Map the two regimes separately
Overlooking the open source exemption	Non-compliance for a publisher monetising a project	Document the business model and status
Underestimating SBOM	Inability to qualify a reported vulnerability	Industrialise from design stage
Postponing the reporting setup to 2027	Breach as early as September 2026	Activate vulnerability watch and user channel before end 2025
Confusing security support with feature support	Security updates not free or tied to a contract	Separate them in the commercial policy
Missing the unified declaration of conformity	Incomplete DoC, exposure to withdrawal	Integrate the CRA into the DoC template from 2026

Working on CRA scoping and gap analysis for a digital product for a real product? AESTECHNO can audit your design and certification plan. Get in touch →

Sources & references

1. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements , EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
2. European Commission, Cyber Resilience Act policy page , European Commission digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
3. ENISA, Cyber Resilience Act dossier , ENISA www.enisa.europa.eu/topics/cyber-resilience-act
4. Delegated Regulation (EU) 2022/30, activating RED article 3.3 , EUR-Lex eur-lex.europa.eu/eli/reg_del/2022/30/oj
5. CENELEC, European harmonised standards portal , CENELEC www.cenelec.eu/