Cyber Resilience Act (CRA): EU baseline for digital

Hugues Orgitello updated 7 Oct 2026 17 min read

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), was signed on 23 October 2024, published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024. It sets cybersecurity requirements for products with digital elements placed on the Union market. Its notified body chapter has applied since 11 June 2026, its reporting obligations since 11 September 2026, and the rest applies on 11 December 2027. This guide follows the text article by article: scope and exclusions, the Annex III and IV categories as described by Implementing Regulation (EU) 2025/2392, the Article 32 conformity routes, the Annex I requirements, the two reporting clocks of Article 14, penalties, and the hand-over from RED 3.3 and the EN 18031 series to the CRA.

Dated milestones

Date	What happens	Basis
23 October 2024	Regulation signed in Strasbourg	Regulation 2024/2847
20 November 2024	Published in the Official Journal (OJ L, 2024/2847)	Regulation 2024/2847
10 December 2024	Entry into force (twentieth day after publication)	Article 71(1)
1 December 2025	Implementing Regulation (EU) 2025/2392 published: technical descriptions of the Annex III and IV categories	Article 7(4)
20 April 2026	Delegated Regulation (EU) 2026/881 published: conditions under which a CSIRT may delay disseminating a notification	Article 14(9)
29 April 2026	Delegated Regulation (EU) 2026/339 published: repeal of the RED cybersecurity act from 11 December 2027	RED Article 3(3)
11 June 2026	Chapter IV (Articles 35 to 51) applies: notifying authorities and notified bodies	Article 71(2)
27 July 2026	Commission guidance C(2026) 5252 published (non-binding)	Article 26
11 September 2026	Article 14 reporting applies; ENISA single reporting platform operational	Article 71(2)
11 December 2026	Member States to strive for a sufficient number of notified bodies	Article 35(2)
11 December 2027	Full application; Delegated Regulation 2022/30 repealed	Article 71(2), Regulation 2026/339
11 June 2028	End of validity of cybersecurity EU type-examination certificates issued under other Union harmonisation legislation (unless they expire earlier or that legislation says otherwise)	Article 69(1)

Scope: products with digital elements

Article 3(1) defines a product with digital elements as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Article 2(1) then limits the Regulation to those products "the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network".

That captures connected hardware (cameras, routers, IoT sensors, connected toys, industrial equipment with a network interface), software placed on the market (operating systems, browsers, applications) and components sold separately for integration. The manufacturer remote data processing solutions are covered as part of the product. Cloud services in their own right (SaaS, PaaS, IaaS) are not: the recitals point them to the NIS2 Directive (EU) 2022/2555.

The Regulation applies to products made available on the market, that is supplied in the course of a commercial activity, whoever and wherever the manufacturer is. A non-EU manufacturer selling into the Union is in scope; its reporting goes to the CSIRT of a Member State chosen by the order set in Article 14(7).

Exclusions, paragraph by paragraph

Article	Excluded	Note
2(2)(a) and (b)	Products to which Regulation (EU) 2017/745 (MDR) or 2017/746 (IVDR) apply	Health wearables outside the MDR/IVDR are in Annex III class I
2(2)(c)	Products to which Regulation (EU) 2019/2144 (vehicle General Safety Regulation) applies	That is how UNECE R155/R156 vehicles stay out; see the ISO 21434 and R155/R156 guide
2(3)	Products certified under Regulation (EU) 2018/1139 (aviation)	Not "civil aviation" as a whole
2(4)	Equipment within the scope of Directive 2014/90/EU (marine equipment)
2(5)	Products covered by other Union rules, where a delegated act limits or excludes the CRA	Only by delegated act
2(6)	Spare parts replacing identical components, made to the same specifications
2(7)	Products developed or modified exclusively for national security or defence, or designed to process classified information

Free and open-source software is not a separate exemption article: it is outside the Regulation when it is not made available in the course of a commercial activity. The recitals give the markers of a commercial activity (charging a price, charging for technical support beyond cost recovery, an intention to monetise). Article 24 creates the open-source software steward, which must keep a documented cybersecurity policy and cooperate with market surveillance authorities, and Article 64(10) excludes administrative fines for any infringement by a steward.

Default, important and critical products

The class is decided by the product core functionality (Article 7(1), Article 8(1)). Integrating an Annex III component does not by itself make the host product important (Article 7(1), second sentence): a thermostat built around a class I microcontroller is not a class I product because of that chip.

Annex III, class I (19 categories)

Identity management and privileged access management systems (including authentication and access control readers, biometric readers included); standalone and embedded browsers; password managers; software that searches for, removes or quarantines malware; products with a VPN function; network management systems; SIEM systems; boot managers; PKI and digital certificate issuance software; physical and virtual network interfaces; operating systems; routers, modems intended for the connection to the internet, and switches; microprocessors with security-related functionalities; microcontrollers with security-related functionalities; application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities; smart home general purpose virtual assistants; smart home products with security functionalities (smart door locks, security cameras, baby monitoring systems, alarm systems); internet connected toys under Directive 2009/48/EC with social interactive or location tracking features; personal wearables with a health monitoring purpose not covered by the MDR or IVDR, or intended for children.

Annex III, class II (4 categories)

Hypervisors and container runtime systems; firewalls, intrusion detection and prevention systems; tamper-resistant microprocessors; tamper-resistant microcontrollers.

Annex IV, critical (3 categories)

Hardware Devices with Security Boxes; smart meter gateways within smart metering systems (Directive (EU) 2019/944) and other devices for advanced security purposes, including secure cryptographic processing (Annex IV, point 2); smart cards or similar devices, including secure elements.

The silicon ladder in Implementing Regulation 2025/2392

Adopted on 28 November 2025 under Article 7(4), Implementing Regulation (EU) 2025/2392 separates the chip categories by the Common Criteria vulnerability analysis level they are designed for. It is the most useful table for an electronics manufacturer:

Category	CRA class	Technical description (2025/2392)
Microcontroller or microprocessor with security-related functionalities	Important, class I	Provides functions such as encryption, authentication, secure key storage, random number generation or a trusted execution environment that aim to secure other products, networks or services beyond the chip itself
Tamper-resistant microcontroller or microprocessor	Important, class II	The class I chip, with tamper evidence, resistance or response, designed to provide protection of AVA_VAN level 2 or 3
Secure element (smart cards or similar devices)	Critical, Annex IV	Designed to provide protection of at least AVA_VAN.4; includes Trusted Platform Modules (TPM) and embedded UICC
Hardware Devices with Security Boxes	Critical, Annex IV	Multi-component hardware with a physical envelope providing tamper evidence, resistance or response; includes physical payment terminals, hardware security modules (HSM) and tachographs meeting that description

The same act describes routers as products that "establish and control the flow of data between different networks" using routing protocols, wired or wireless, virtual or physical, with or without modem.

Conformity assessment routes (Article 32)

Product	Module A (internal control)	Module B + C	Module H	European cybersecurity certificate
Default	Yes	Yes	Yes	Where available under Article 27(9)
Important, class I	Only if harmonised standards, common specifications or a scheme at level "substantial" are applied in full (Article 32(2))	Yes	Yes	Yes, at least "substantial"
Important, class II	No	Yes	Yes	Yes, at least "substantial" (Article 32(3))
Critical (Annex IV)	No	Yes, while no Article 8(1) delegated act applies	Yes, same condition	Mandatory once an Article 8(1) delegated act requires it (at least "substantial")
Free and open-source product in Annex III	Yes, if the technical documentation is made public (Article 32(5))	Yes	Yes	Yes

On the Commission implementation page (last updated 27 July 2026), the delegated act giving the EUCC scheme (Implementing Regulation (EU) 2024/482) a presumption of conformity under the CRA is listed as planned for the fourth quarter of 2026. No Article 8(1) act making a certificate mandatory for an Annex IV category is listed as adopted, so critical products currently fall back on the class II procedures. For the module mechanics across directives, see self-declaration vs notified body.

Notified bodies

Chapter IV has applied since 11 June 2026 so that Member States can notify bodies before December 2027, and Article 35(2) asks them to strive for a sufficient number by 11 December 2026. A body notified under the RED delegated act must be newly assessed and notified under the CRA (recital 100). The NANDO database listed no notified body under Regulation 2024/2847 on 7 October 2026: see how to choose a notified body in NANDO.

Annex I essential requirements

Part I opens with a general duty, point (1): an appropriate level of cybersecurity based on the risks. Point (2) then lists thirteen properties, applied "on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable".

Point	Requirement (Annex I, Part I(2))
(a)	No known exploitable vulnerabilities when made available
(b)	Secure by default configuration, including the possibility to reset to the original state (unless agreed otherwise with a business user for a tailor-made product)
(c)	Vulnerabilities addressable through security updates, with automatic updates on by default where applicable, a clear opt-out, user notification and the option to postpone
(d)	Protection from unauthorised access (authentication, identity or access management) and reporting of possible unauthorised access
(e)	Confidentiality of stored, transmitted or processed data, for example encryption at rest or in transit by state of the art mechanisms
(f)	Integrity of data, commands, programs and configuration against unauthorised manipulation, and reporting of corruptions
(g)	Data minimisation
(h)	Availability of essential and basic functions, also after an incident, including resilience against denial-of-service attacks
(i)	Minimise negative impact on the availability of services provided by other devices or networks
(j)	Limit attack surfaces, including external interfaces
(k)	Reduce the impact of an incident using exploitation mitigation mechanisms
(l)	Record and monitor relevant internal activity, with a user opt-out
(m)	Let users securely and easily remove all data and settings permanently, and transfer data securely where it can be transferred

Part II, vulnerability handling

Eight duties: (1) identify and document vulnerabilities and components, including a software bill of materials (SBOM) in a commonly used, machine-readable format covering at the very least the top-level dependencies; (2) remediate without delay, with security updates separate from functionality updates where technically feasible; (3) regular security tests and reviews; (4) publicly disclose fixed vulnerabilities once an update is available; (5) a coordinated vulnerability disclosure policy; (6) a contact address for reporting vulnerabilities; (7) secure update distribution; (8) security updates disseminated without delay and free of charge (unless agreed otherwise with a business user for a tailor-made product).

Article 13 adds the time dimensions that the old summaries usually get wrong:

Obligation	Duration	Article
Support period	At least five years, or the expected use time if the product is expected to be in use for less	13(8)
Each security update stays available	At least 10 years after issue, or the rest of the support period if longer	13(9)
Technical documentation and EU declaration kept	At least 10 years after placing on the market, or the support period if longer	13(13)
End date of support shown at purchase	At least month and year	13(19)

Reporting obligations (Article 14)

Article 14 has applied since 11 September 2026, and Article 69(3) makes it apply to every in-scope product, including products placed on the market before 11 December 2027. Notifications go through the ENISA single reporting platform to the CSIRT designated as coordinator of the Member State of main establishment, and are simultaneously accessible to ENISA (Article 14(7)). There are two clocks, and their final reports differ:

Step	Actively exploited vulnerability (14(2))	Severe incident (14(4))
Early warning	Within 24 hours of becoming aware, with the Member States where the product is available	Within 24 hours, stating whether unlawful or malicious acts are suspected
Notification	Within 72 hours: product, nature of exploit and vulnerability, measures taken and measures users can take	Within 72 hours: nature of the incident, initial assessment, measures
Final report	No later than 14 days after a corrective or mitigating measure is available	Within one month after the incident notification
Users	Inform impacted users, where appropriate all users, and of mitigation measures (14(8))	Same

An incident is severe when it affects or can affect the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led or can lead to malicious code being introduced or executed (Article 14(5)). The coordinating CSIRT may ask for an intermediate report (Article 14(6)). Delegated Regulation (EU) 2026/881 sets the conditions under which a CSIRT may delay dissemination of a notification to the other coordinating CSIRT teams.

The platform became operational on 11 September 2026 at what ENISA calls initial operating capability. According to the ENISA FAQ, no API is provided at the initial release, the voluntary reporting of Article 15 is not yet implemented, representatives need an EU Login account with multi-factor authentication, there can be only one Primary Assigned Representative per manufacturer and up to 20 secondary ones invited by it, and the platform is in English only at launch. See the reporting platform is live, but not finished and Article 14 reporting has started.

Harmonised standards and presumption of conformity

Under Article 27(1), the presumption of conformity comes from harmonised standards whose references are published in the OJ under this Regulation. The Commission standardisation request M/606 (C(2025) 618) covers 41 standards, horizontal and product-specific. Until references are cited, the Commission may adopt common specifications only under the conditions of Article 27(2), and an EU certificate or statement of conformity under a scheme specified by delegated act gives presumption for the requirements it covers (Article 27(8) and (9)). The ETSI product-specific drafts went to public enquiry in August 2026: see 17 ETSI CRA drafts in public enquiry.

The hand-over from RED 3.3

Delegated Regulation 2022/30 has applied RED Article 3(3)(d)(e)(f) to certain radio equipment since 1 August 2025, with EN 18031-1, EN 18031-2 and EN 18031-3 (CEN-CENELEC, published in August 2024) cited with restrictions in the OJEU in January 2025. Recital 30 of the CRA states that Annex I includes all the elements of those RED requirements. Delegated Regulation (EU) 2026/339 therefore repeals Regulation 2022/30 with effect from 11 December 2027, to prevent radio equipment from being subject to both. Its recital 5 keeps RED market surveillance for radio equipment placed on the market between 1 August 2025 and 10 December 2027.

The practical consequence: until 10 December 2027 a connected radio product follows RED 3.3 and EN 18031 (plus Article 14 reporting, which already applies); from 11 December 2027 its cybersecurity is assessed under the CRA, and EN 18031 gives no CRA presumption unless cited under Regulation 2024/2847. See the RED repeal news, the RED directive, RED harmonised standards, RED tests and the RED checklist.

CE marking and declaration

The CRA is Union harmonisation legislation with CE marking (Articles 29 and 30). The EU declaration of conformity follows Annex V; a simplified declaration (Annex VI) with the internet address of the full one may accompany the product instead (Article 13(20)). Where other acts such as the RED, the EMC Directive or the LVD also require a declaration, a single declaration covers all of them (Article 28(3)). Technical documentation follows Annex VII and must include the cybersecurity risk assessment (Article 13(4)). See the CE marking guide and the CE procedure.

Penalties (Article 64)

Tier	Infringements	Maximum fine
Article 64(2)	Annex I essential requirements; manufacturer obligations of Articles 13 and 14	EUR 15 million or 2.5 percent of total worldwide annual turnover, whichever is higher
Article 64(3)	Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3), 33(5), 39, 41, 47, 49 and 53	EUR 10 million or 2 percent
Article 64(4)	Incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request	EUR 5 million or 1 percent

Member States lay down the penalty rules (Article 64(1)). Article 64(10) excludes these administrative fines for microenterprises and small enterprises that miss the 24-hour early warning deadline, and for open-source software stewards. Market surveillance runs under Regulation (EU) 2019/1020. After a fix is available, ENISA adds the publicly known vulnerability, in agreement with the manufacturer, to the European vulnerability database set up under NIS2 (Article 17(5)).

Products already on the market

Article 69(2): products placed on the market before 11 December 2027 are subject to the CRA only if they undergo a substantial modification from that date. Article 69(3) is the exception: Article 14 reporting applies to them all. Article 22 makes anyone who substantially modifies a product and makes it available a manufacturer, for the affected part or for the whole product if its cybersecurity as a whole is affected.

Claims the texts contradict

Common claim (including earlier versions of this page)	What the text says
The final report is due one month after the early warning, for every report	For an exploited vulnerability, 14 days after a corrective or mitigating measure is available (14(2)(c)); one month after the incident notification applies only to severe incidents (14(4)(c))
Reporting failures carry the EUR 10 million tier	Article 14 is in the EUR 15 million or 2.5 percent tier (64(2))
The support period is left to the manufacturer, "typically" five years	At least five years unless the product is expected to be in use for less (13(8))
Article 12 creates a cross presumption with other Union acts	Article 12 is about high-risk AI systems; presumption comes from cited harmonised standards, common specifications or EU certification (Article 27)
Civil aviation is excluded	Only products certified under Regulation 2018/1139 (2(3))
UNECE R155/R156 are the exclusion basis for vehicles	The exclusion is Regulation (EU) 2019/2144 (2(2)(c)), which itself makes R155/R156 mandatory for type-approval
Microcontrollers with security elements and smart card readers are class II	Microcontrollers with security-related functionalities are class I; class II is tamper-resistant microcontrollers (AVA_VAN 2 or 3); secure elements (at least AVA_VAN.4) are critical
"HSM" is an Annex IV category by name	Annex IV lists Hardware Devices with Security Boxes; 2025/2392 includes hardware security modules, payment terminals and tachographs in that description
RED 3.3 and the CRA run in parallel after 2027, with consolidation by 2028	Regulation 2026/339 repeals the RED act on 11 December 2027, the day the CRA applies in full
EN 18031 will give presumption under the CRA	Presumption under the CRA requires references cited under Regulation 2024/2847 (27(1))
An SBOM must list every component	The minimum is the top-level dependencies (Annex I, Part II(1))
ENISA keeps a public registry of every reported vulnerability	ENISA adds publicly known vulnerabilities to the European vulnerability database after a fix, in agreement with the manufacturer (17(5))
The CRA does not touch products sold before December 2027	Article 14 reporting applies to them (69(3)), and a substantial modification brings them fully in (69(2))

Preparing a CRA-ready product

1. Classification: compare the product core functionality with Annex III and IV as described in Implementing Regulation 2025/2392. Document the decision.
2. Risk assessment: carry out and document the Article 13(2) cybersecurity risk assessment; it decides which Annex I, Part I(2) points apply and how.
3. Requirement mapping: for each Annex I point, record the control, the evidence and the justification where a point does not apply (Article 13(4)).
4. SBOM: produce a machine-readable SBOM covering at least top-level dependencies; CycloneDX and SPDX are commonly used formats (the Regulation names no format; Article 13(24) allows the Commission to specify one).
5. Disclosure and contact: publish a coordinated vulnerability disclosure policy and a single point of contact (Article 13(17)).
6. Reporting: register the Primary Assigned Representative on the ENISA platform and rehearse the 24-hour, 72-hour and final-report steps; this already applies.
7. Updates: secure distribution, security updates separate from feature updates where feasible, free of charge, each kept available for at least 10 years.
8. Support period: set it (at least five years unless shorter expected use), record the reasoning in the technical documentation and show the end date at purchase.
9. Assessment route: for class I without fully applied standards, class II and critical products, plan for a notified body (NB) or certification; none was notified under the CRA on 7 October 2026.
10. Documentation and declaration: technical file per Annex VII, declaration per Annex V, single declaration with RED, EMC and LVD where applicable.

Manufacturers already running a RED 3.3 programme have a reusable foundation: cybersecurity risk analysis, firmware signing, secret management, signed OTA. The added effort sits in the SBOM, formal vulnerability handling, support period commitments and reporting.

For the engineering practice behind these controls, secure boot, firmware signing, SBOM generation and coordinated vulnerability disclosure on real devices, see the AESTECHNO guide to CRA compliance for IoT products.

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

See also

• Product cybersecurity: obligation, evaluation, label
• DO-326A and ED-202A: avionics cybersecurity airworthiness
• PSA Certified: Arm-led IoT security baseline
• SESIP: IoT platform security evaluation methodology
• IEC 62443 (ISA-99), industrial control cybersecurity
• ETSI EN 303 645: cybersecurity for consumer IoT
• NISTIR 8425 and the US Cyber Trust Mark: consumer-IoT label
• NIST SP 800-213 and 8259A: US baseline for IoT cybersecurity
• ISO/SAE 21434 and UNECE R155/R156: automotive cybersecurity
• How to choose a notified body in NANDO
• CRA timeline

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
Treating reporting as a 2027 topic	Article 14 has applied since 11 September 2026, also to products already on the market	Register on the ENISA platform and set the internal 24-hour process now
Classifying by component instead of core functionality	Over- or under-estimating the assessment route	Apply Article 7(1) and the 2025/2392 descriptions
Assuming EN 18031 covers the CRA	No CRA presumption after 11 December 2027	Track standards cited under Regulation 2024/2847
Counting on a notified body late	None notified on 7 October 2026	Plan class II and critical assessments early
Confusing security support with feature support	Paid or bundled security updates breach Part II(8)	Separate them in the commercial policy
Forgetting the single declaration	Incomplete DoC	One Annex V declaration citing every applicable act

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 (Cyber Resilience Act), Articles 2, 7, 8, 13, 14, 27, 32, 35, 64, 69, 71 and Annexes I, III, IV, EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Implementing Regulation (EU) 2025/2392, technical description of important and critical product categories, EUR-Lex eur-lex.europa.eu/eli/reg_impl/2025/2392/oj
3. Delegated Regulation (EU) 2026/881, delaying the dissemination of notifications, EUR-Lex eur-lex.europa.eu/eli/reg_del/2026/881/oj
4. Delegated Regulation (EU) 2026/339, repealing Delegated Regulation 2022/30 from 11 December 2027, EUR-Lex eur-lex.europa.eu/eli/reg_del/2026/339/oj
5. Delegated Regulation (EU) 2022/30, activating RED Article 3(3)(d)(e)(f), EUR-Lex eur-lex.europa.eu/eli/reg_del/2022/30/oj
6. European Commission, Cyber Resilience Act policy page, European Commission digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
7. European Commission, Cyber Resilience Act implementation (acts adopted and planned), European Commission digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
8. European Commission, CRA standardisation (request M/606, C(2025) 618), European Commission digital-strategy.ec.europa.eu/en/policies/cra-standardisation
9. European Commission, guidance on the application of the CRA, C(2026) 5252 (27 July 2026), European Commission digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
10. ENISA, Single Reporting Platform frequently asked questions, ENISA www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions