Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026. All other requirements apply from 11 December 2027. 41 harmonised standards are being developed: horizontal ones (the EN 40000-1 series) and vertical ones per product group.

* Reporting came first; the essential requirements and CE marking follow in December 2027. *

Timeline:

• 11 September 2026: reporting obligations for actively exploited vulnerabilities and severe incidents.
• 11 December 2027: all requirements, including the essential requirements and CE marking.

Harmonised standards turn the CRA's general essential requirements into concrete, testable ones. A product that follows them is presumed to conform. That is what lets Important class I products use self-assessment.

• Horizontal (all products, EN 40000-1 series): vocabulary, principles of cyber resilience, vulnerability handling, generic security requirements.
• Vertical (per product group): network components (routers, switches, firewalls, VPNs), software products (browsers, password managers, operating systems, hypervisors), smart-home and consumer products (locks, cameras, wearables, toys), industrial components (microcontrollers, ASICs, FPGAs, smart meter gateways) and security components (HSMs, smartcards, secure elements).

The EU also publishes an official FAQ, guidance for manufacturers and a self-assessment tool.

Go deeper:

• European Commission — CRA implementation FAQ — dates, harmonised standards and transitional rules
• Cyberstand — CRA self-assessment tool — check whether and how the CRA applies to a product

It traces to one specific requirement, gives reproducible steps, and states an exact expected outcome that can clearly pass or fail.

• Good: the requirement is that the Windows Firewall blocks all inbound and outbound connections. The test case verifies that it does so by default. The steps are to open the advanced firewall settings, public profile, and check the defaults. The expected outcome is that both are set to "Block all". Anyone can repeat it and get the same verdict.
• Bad: "Verify system hardening", expected outcome "settings as recommended by standard XYZ". It inherits the vagueness of a bad requirement ("shall be hardened according to XYZ"). The tester has to interpret a whole standard, and two testers will disagree.
• Ugly: "Verify that encryption works", expected "encryption works as expected". It names no algorithm, key length or interface and has no traceable requirement, so it cannot fail.

Most bad test cases start as bad requirements. A test can only be as precise as the requirement it traces to.