Cyber Resilience Act Timeline: Key Dates 2026-2027

As of 24 June 2026, NANDO shows zero CRA-designated notified bodies. No CRA harmonised standard has been published in the Official Journal. The ENISA reporting platform is scheduled to go operational by 11 September 2026. Less than 3 months remain before vulnerability and incident reporting becomes mandatory.

If you manufacture products with digital elements for the EU market, this is the actual situation: what you must build before September, what is currently blocked, and why Important Class I self-assessment is not available yet for many products.

Timeline at a glance

State of play on 24 June 2026, against the two anchor dates that bind manufacturers.

Date reference

Three blockers you cannot work around

No harmonised standards

Important Class I manufacturers have three conformity routes: self-assessment, a third-party assessment using harmonised standards or common specifications, or notified-body assessment. The first two routes depend on standards or specifications that are not available yet. As of 24 June 2026:

• The Commission's harmonised standards page has no entry for Regulation (EU) 2024/2847.
• No common specifications have been adopted for the CRA.
• No delegated act designates any European cybersecurity certification scheme as a CRA presumption-of-conformity route.

Where standards do not exist, the fallback route is Module B+C (EU-type examination) or Module H (full quality assurance). Both require a notified body.

So if you manufacture an Important Class I product, do not plan around self-assessment until the relevant standard route exists. For now, notified-body assessment is the only route available for products that cannot use another presumption-of-conformity route.

CEN-CLC/JTC 13/WG 9 is developing the EN 40000 series:

• prEN 40000-1-1 (Vocabulary): public enquiry complete, not yet at Formal Vote.
• prEN 40000-1-2 (Principles): public enquiry complete, not yet at Formal Vote.
• prEN 40000-1-3 (Vulnerability Handling): public enquiry ran December 2025 to February 2026, currently in comment resolution.
• prEN 40000-1-4 (Generic Security Requirements): still in drafting.
• Type-C verticals (browsers, VPNs, SIEM, and others): mature draft stage, not yet in public enquiry.

Realistic earliest Official Journal citation: Q4 2026. Several vertical standards will likely slip into 2027.

No notified bodies

Chapter IV has applied since 11 June 2026. The Commission's target is sufficient notified-body capacity by 11 December 2026, but that is a best-efforts target, not a guarantee for every product category. As of 24 June 2026, no CRA-designated notified bodies appear in NANDO.

If you need an Important Class I assessment completed before December 2027, plan for:

• Technical file preparation: 3 to 6 months.
• Module B+C assessment: 2 to 4 months per product.
• Notified-body availability: uncertain now that formal designation under Chapter IV has opened.

Contact conformity assessment bodies now. The formal machinery has opened, but CRA capacity is still not listed in NANDO. Waiting for capacity to mature makes completing your assessment before December 2027 less likely.

No ENISA reporting platform

The Single Reporting Platform is not yet operational as of 24 June 2026. ENISA says instructions and training material are being published during June 2026, with the platform scheduled to go operational by 11 September 2026.

What you can do now:

• Draft notification templates for the 24-hour and 72-hour stages, the 14-day vulnerability final report, and the one-month severe-incident final report.
• Identify your member state's designated CSIRT coordinator.
• Define who internally can authorise a 24-hour notification on a weekend or public holiday.

Open the ENISA Single Reporting Platform page.

What must be in place before 11 September 2026

Less than 3 months remain. If these items are not done, you are not behind on paperwork. You are behind on infrastructure, and infrastructure takes months to build.

Product inventory and classification

You need a complete list of every product with digital elements (PDE) you place on the EU market, with CRA classification confirmed for each product:

• Default class: Self-assessment route available.
• Important Class I: notified-body assessment required where the relevant standard route is unavailable.
• Important Class II: notified body required. Module B+C or Module H.
• Critical: Module B+C or full quality assurance. European cybersecurity certification may also apply.

Classification reference: Implementing Regulation (EU) 2025/2392 (OJ 1 December 2025, in force 21 December 2025) provides technical descriptions of Annex III and IV product categories. Use it to resolve edge cases.

SBOM infrastructure

You cannot report an actively exploited vulnerability within 24 hours if you do not know what components your product contains. SBOM generation must be operational before September 2026.

• Format: CycloneDX or SPDX. Both are accepted under CRA. Pick one and standardise across products.
• Scope: Transitive dependencies, not direct dependencies only. Full component visibility is required for the Annex VII risk assessment.
• Storage: Version-controlled, tied to product releases. Each SBOM must map to a specific build.
• Integration: CI/CD pipeline. A one-time export does not satisfy the ongoing obligation.

Vulnerability monitoring

The 24-hour reporting clock starts at awareness: reasonable certainty based on an initial assessment. Forensic confirmation is not required to trigger the clock. You need monitoring capable of producing that initial assessment before the deadline runs.

• Subscribe to NVD, OSV, and relevant vendor advisories for your component stack.
• Automate scanning against your SBOM components.
• Document your internal escalation path and test it end-to-end.
• Draft notification templates now, before the ENISA platform launches.

Pre-September 2026 Checklist

PRODUCT INVENTORY (do this first: classification drives your conformity route):
[ ] Complete list of PDEs sold in EU with CRA classification confirmed per product
[ ] Important Class I products: conformity assessment body engaged now. Formal designation
    has opened, but CRA notified-body capacity is not listed in NANDO yet
[ ] Support period declared based on expected product lifetime

SBOM (start here: feeds monitoring, technical file, and 24-hour reporting):
[ ] SBOM generation integrated in CI/CD pipeline. A one-time export is not enough
[ ] Format standardised: CycloneDX or SPDX
[ ] Transitive dependency coverage verified. Direct dependencies alone are not enough
[ ] SBOMs version-controlled and tied to specific product releases

VULNERABILITY MONITORING (must be live before 11 September):
[ ] Monitoring active for all products: NVD, OSV, vendor advisories
[ ] Automated scanning against SBOM running
[ ] Internal escalation path documented and tested end-to-end
[ ] 24/7 coverage confirmed, including holiday and weekend escalation paths

REPORTING PREPARATION (ENISA platform not live yet: prepare everything else now):
[ ] 24-hour, 72-hour, 14-day vulnerability, and one-month incident templates drafted
[ ] Member state CSIRT coordinator identified
[ ] Person authorised to trigger a 24-hour notification named and reachable around the clock

DOCUMENTATION:
[ ] Technical documentation audited against Annex VII
[ ] Gap analysis complete
[ ] Risk assessment underway

What reporting requires from 11 September 2026

From 11 September 2026, you must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform. The report goes to your member state's designated CSIRT coordinator and is made available to ENISA at the same time, unless exceptional disclosure-delay rules apply.

What "actively exploited" means

The 24-hour clock applies when there is credible evidence that a threat actor has used the vulnerability in a system without the owner's permission. Indicators include:

• Confirmed attacks observed in the wild.
• Exploitation reported in threat intelligence feeds or by security researchers.
• Detection in honeypots with evidence of active deployment.

The Commission's draft guidance (Ares(2026)2319816, 3 March 2026) uses "credible evidence of active exploitation" as the standard, which is lower than forensic confirmation.

September 2026 readiness checklist

REPORTING INFRASTRUCTURE (before 11 September 2026):
[ ] Notification templates prepared: 24-hour, 72-hour, 14-day vulnerability, and one-month incident formats
[ ] Member state CSIRT coordinator identified. This is your primary submission point
    alongside ENISA
[ ] 24/7 escalation path confirmed, including holiday coverage and backup contacts
[ ] Legal review of reporting obligations completed

VULNERABILITY MANAGEMENT:
[ ] Active monitoring operational for all products
[ ] CVE/NVD integration live
[ ] Customer notification templates ready

TEAM READINESS:
[ ] Security team trained on the four-stage reporting timeline
[ ] Management escalation path documented
[ ] Legal team briefed on reporting obligations
[ ] Communications team prepared for public disclosures

Full compliance by 11 December 2027

Essential cybersecurity requirements

Every compliant PDE must meet these requirements:

Security by design

• Security level appropriate to the product's risks (Annex I, Part I, §1).
• Protection against unauthorised access.
• Confidentiality, integrity, and availability of data and essential functions.
• Minimal attack surface, secure defaults, no hardcoded credentials.

Vulnerability Management

• Documented process for identifying and addressing vulnerabilities.
• Timely, free security updates during the support period.
• Coordinated vulnerability disclosure policy.

Update Capability

• Secure, reliable update mechanism.
• Ability to separate security updates from feature updates.

Technical documentation

Support period: two separate obligations

The CRA imposes two distinct obligations on security updates.

Support duration: You must issue security updates for a minimum of five years from the date of placing the product on the market, or for the expected product lifetime if shorter. Five years is the floor, not the default. A product with a 10-year expected lifetime needs a 10-year support commitment.

Update availability: Each security update you issue must remain available for download for a minimum of 10 years from the issuance date, or for the remainder of the support period, whichever is longer.

These are independent obligations. An update issued in year four of a five-year support period must remain downloadable until year 14 from issuance. If you delete old update packages or let distribution infrastructure lapse, you can breach the update-availability rule even while issuing new updates on schedule. Plan your storage and distribution infrastructure for the long haul before you issue your first update under the CRA.

December 2027 Checklist

PRODUCT COMPLIANCE:
[ ] All products meet Annex I requirements: security by design, vulnerability management,
    and update capability
[ ] Conformity assessments complete: notified-body process finished for Important Class I and Class II
[ ] CE marking applied
[ ] EU declaration of conformity prepared

TECHNICAL FILE (Annex VII):
[ ] Risk assessment complete and documented
[ ] SBOM current and validated
[ ] Conformity evidence organised and accessible
[ ] Support period declared based on expected product lifetime

MARKET CHAIN:
[ ] Importers and distributors informed of their CRA obligations
[ ] Customer-facing documentation updated

ONGOING:
[ ] Security update process active for the full support period duration
[ ] Update availability infrastructure in place. 10 years from each issuance date
[ ] Vulnerability monitoring active and tested
[ ] Incident response exercised at least quarterly

Commission guidance: March 2026 draft

The Commission published a draft Communication (Ares(2026)2319816) on 3 March 2026, approximately 70 pages. Stakeholder consultation closed on 31 March 2026. The document is not finalised. For a full breakdown, see our CRA Commission guidance guide.

Key rulings relevant to your timeline:

RDPS test for SaaS scope: Remote data processing software is in CRA scope only if it passes three conditions. The software performs remote data processing. The remote processing is necessary for the product's core function. And the manufacturer controls the remote processing. SaaS that fails this test is out of scope.

Legacy products: No historical documentation reconstruction is required. You need a present-day risk assessment. Product families may be grouped for risk assessment purposes.

Software updates: An update does not constitute a "substantial modification" that triggers a new conformity assessment unless it introduces new threat vectors or changes the product's intended purpose. The guidance provides a four-question test.

24-hour clock: Starts at awareness. Reasonable certainty based on an initial assessment is enough. Forensic confirmation is not required.

Support period floor: Five years is a minimum, not a default. The support period must reflect the product's expected lifetime.

Open source: Publishing source code does not constitute placing a product on the market. Contributors who do not control the release of a finished product are not manufacturers under the CRA.

Read the Commission announcement.

Penalties

The top CRA penalty tier is €15 million or 2.5% of total worldwide annual turnover, whichever is higher. It applies to:

• Non-compliance with essential cybersecurity requirements and manufacturer obligations.
• Failure to meet vulnerability and incident reporting obligations.

Both categories sit in the same penalty tier. There is no general lower tier for reporting failures.

For the complete fine-tier structure and the market-surveillance measures that can sit alongside fines, see CRA penalties and enforcement.

Industry-specific notes

Consumer electronics

SBOM automation is the highest-value early investment. It feeds directly into vulnerability monitoring and technical file generation. Consumer products typically have complex supply chains with multiple component vendors.

Managing firmware updates across large device populations requires OTA infrastructure. An update issued in year three of a product's life must remain downloadable for 10 years from that issuance date. Plan your distribution infrastructure now, not at the point of issuance.

Software publishers

Vulnerability reporting is the most operationally demanding obligation for software products. Discovery rates are higher, and tracking dependencies at transitive depth in modern stacks is not simple. Integrate SBOM generation into your existing CI/CD pipelines. It feeds directly into monitoring and the response workflow.

Industrial equipment

Industrial products frequently fall into Important Class I or Class II, which currently means notified-body assessment. Contact conformity assessment bodies now. The formal designation process has opened under Chapter IV, and capacity will be constrained through at least December 2026.

IoT devices

Default credential elimination follows from the secure-by-default requirement in Annex I, Part I. Address it first. It is a clear Annex I violation and relatively contained to fix compared to architectural changes. Secure update mechanisms for resource-constrained devices require more work. Start with credentials, then tackle updates.