Cyber Resilience Act — the 2027 timeline

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the most underrated regulation in the EU’s 2024–2027 wave. It applies to virtually every product with digital elements sold in the EU and brings product-security obligations comparable to those long established for safety (CE marking, conformity assessment, post-market monitoring). It comes into full force on 11 December 2027. This guide is the timeline and the practical scope.

What the CRA covers — products with digital elements

The CRA regulates products with digital elements placed on the EU market. The definition is sweeping. It covers:

• Software products distributed commercially (operating systems, applications, libraries)
• Hardware products with software components (IoT devices, smartphones, network equipment, industrial control systems)
• Remote data-processing solutions where the data processing is integral to the product

If your product runs code that ends up in the EU, the CRA likely applies to it.

What’s excluded

The CRA carves out products already regulated by sector-specific cybersecurity rules:

• Medical devices (regulated under MDR/IVDR — Regulations 2017/745 and 2017/746)
• Civil aviation (Regulation 2018/1139)
• Motor vehicles (UN R155/156 already covers them)
• Marine equipment (Directive 2014/90)
• Products regulated under specific national security exemptions
• Free and open-source software distributed outside commercial activity (with nuances — see Recital 18 and Article 13)

The open-source carve-out is narrower than commonly believed. Maintainers monetising through services or warranties on open-source projects can still be in scope.

The timeline

The CRA was published on 20 November 2024 and entered into force on 10 December 2024. Its substantive provisions phase in:

Date	What applies
10 Dec 2024	Regulation in force
11 Jun 2026	Notified body designation provisions apply
11 Sep 2026	Incident and vulnerability reporting obligations for manufacturers apply (Art. 14)
11 Dec 2027	Full application — essential requirements (Annex I), conformity assessment, CE marking, all obligations binding

The September 2026 date for reporting is the one most teams miss. Vulnerability and active-exploitation reporting are enforceable well before the full conformity-assessment regime kicks in.

If you want to know where you stand against that September date specifically, the free CRA readiness scan walks the same obligations as a twelve-question check and tells you which of them you can already meet.

What the essential requirements look like (Annex I)

Products with digital elements must be designed to:

Part I — Security properties

• Be made available on the market without known exploitable vulnerabilities
• Be delivered with a secure-by-default configuration
• Ensure protection from unauthorised access
• Ensure protection of the confidentiality, integrity, and availability of data
• Process only data adequate, relevant, and limited to the intended purpose
• Be designed with the principle of minimal attack surface
• Be designed with the principle of reduced impact of incidents
• Provide security-related information by recording and monitoring relevant internal activity
• Provide the possibility for users to securely and easily remove all data and settings

Part II — Vulnerability handling

• Identify and document vulnerabilities and components contained in the product (SBOM)
• Address and remediate vulnerabilities without delay
• Apply effective and regular tests and reviews of the security
• Once a security update has been made available, share information on the patched vulnerability
• Enforce a coordinated vulnerability disclosure policy
• Provide for mechanisms to securely distribute updates

Reporting obligations (Article 14)

From 11 September 2026, manufacturers must:

• Notify ENISA and the relevant CSIRT of any actively exploited vulnerability contained in the product, within 24 hours of becoming aware
• Notify any severe incident having an impact on the security of the product, within 24 hours for early warning, and a fuller report within 72 hours
• Final detailed report within 14 days for vulnerabilities, one month for incidents

The 24/72-hour pattern echoes NIS2 and GDPR. If you’re already running an incident-response programme for NIS2 or GDPR, the CRA bolts on rather than duplicates.

Product categories — what affects conformity assessment

This is the part most summaries get wrong, so it is worth being precise: two separate annexes carry the lists, not one.

Annex III — important products with digital elements, split into two classes:

• Class I — identity management and privileged access management, browsers, password managers, malware detection and removal, VPNs, network management systems, SIEM, boot managers, PKI and certificate issuance software, physical and virtual network interfaces, operating systems, routers, and microprocessors or microcontrollers with security-related functionality.
• Class II — hypervisors and container runtimes, firewalls and intrusion detection/prevention systems, and tamper-resistant microprocessors and microcontrollers.

Annex IV — critical products with digital elements, a separate and much shorter list: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes, and smartcards or similar devices including secure elements.

Two traps worth naming. Operating systems are Class I, not Class II — they sit alongside browsers, not alongside hypervisors. And microprocessors and microcontrollers appear in both classes: the plain security-functionality ones in Class I, the tamper-resistant ones in Class II.

Most software lands outside all three lists. That default tier is where internal control is available as a conformity route.

CE marking and conformity assessment

When the CRA fully applies on 11 December 2027, every product with digital elements placed on the EU market needs:

• A CE marking
• A signed declaration of conformity
• Technical documentation per Annex VII
• A conformity assessment matching the product’s importance category

This is exactly the same architectural shape as CE marking for safety — it just adds a cybersecurity dimension. If your engineering team is used to CE marking for product safety, the CRA will feel familiar. If you’re a SaaS team that’s never produced CE technical documentation, expect 2–3 months of work for the first product.

Fines (Article 64)

The CRA’s fine regime aligns with NIS2:

• Non-compliance with the essential requirements: up to €15 million or 2.5% of global annual turnover
• Other obligations: up to €10 million or 2%
• Supplying incorrect information: up to €5 million or 1%

What to do now

Given the CRA’s December 2027 full-application date but September 2026 reporting kick-in, the rational backwards-plan is:

• Q3 2026: incident-and-vulnerability reporting playbook live, ENISA/CSIRT contacts confirmed, SBOM tooling in place
• Q1 2027: gap analysis against Annex I essential requirements
• Q2 2027: documentation drafted, internal conformity assessment process designed
• Q3 2027: external pen-test or third-party assessment if applicable
• Q4 2027: declaration of conformity, CE marking, technical documentation finalised before 11 December

The interaction with NIS2 and the AI Act

The CRA covers products. NIS2 covers services and operators. The AI Act covers AI systems specifically. A medium-sized SaaS company can easily be in scope of all three.

In practice, your security programme answers all three:

Control area	CRA	NIS2	AI Act
Secure-by-default config	✓	✓ (Art. 21)	—
Vulnerability disclosure	✓	✓ (Art. 21)	—
Encryption in transit / at rest	✓	✓	✓ (Art. 15 for high-risk)
Logging and monitoring	✓	✓ (Art. 21)	✓ (Art. 12)
Incident reporting	✓ (Art. 14)	✓ (Art. 23)	✓ (Art. 73 serious incidents)
SBOM	✓	—	—

Build one security programme; satisfy three regulations.