EU Cyber Resilience Act: Implementation Timeline 2024-2027

As of April 2026, zero Notified Bodies are designated under the CRA. No harmonized standard has been published in the Official Journal. The ENISA reporting platform does not exist yet. Five months remain before Article 14 enforcement begins on 11 September 2026.

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 does not work today.

Three Blockers You Cannot Work Around

Three things that CRA conformity requires do not exist yet. Know these before finalizing your timeline.

No Harmonized Standards

Article 32(2) gives Important Class I manufacturers three conformity routes: self-assessment, a third-party assessment using harmonized standards or common specifications, or Notified Body assessment. The middle route requires CRA harmonized standards. But no CRA harmonized standard has been published in the Official Journal. As of April 2026:

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

Where standards do not exist, Article 32(2) requires 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, self-assessment does not work today. Notified Body assessment is the only compliant path.

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 activates on 11 June 2026. The Commission's target is sufficient NB capacity by 11 December 2026 (Article 35(2), best-efforts language). As of April 2026, no CRA-designated Notified Bodies appear in the Single Market Compliance Space.

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.
• NB availability: uncertain until formal designation opens after June 2026.

Contact conformity assessment bodies now. The formal machinery does not open until mid-2026. Waiting until then makes completing your assessment before December 2027 unlikely.

No ENISA Reporting Platform

The Article 16 Single Reporting Platform is not available as of April 2026. ENISA has contracted a vendor. The platform is scheduled to open before 11 September 2026. No registration URL and no manufacturer-facing guidance have been published.

What you can do now:

• Draft notification templates against the Article 14(2) format requirements (24-hour, 72-hour, 14-day, 30-day).
• Identify your member state's designated CSIRT coordinator.
• Define who internally can authorize a 24-hour notification on a weekend or public holiday.

ENISA SRP page: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

What Must Be in Place Before 11 September 2026

Five months remain. If these items are not done, you are not behind on tasks. 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 today (see above).
• 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 standardize 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 — NB designation
    does not open until June 2026; waiting until then puts you past December 2027
[ ] Support period declared per expected product lifetime (Art. 13(8))

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 standardized: 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, and 30-day notification templates drafted against Art. 14(2)
[ ] Member state CSIRT coordinator identified
[ ] Person authorized 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

Article 14: What Reporting Requires from 11 September 2026

From 11 September 2026, you must report actively exploited vulnerabilities and severe incidents to two destinations simultaneously: your member state's designated CSIRT coordinator and ENISA via the Single Reporting Platform (Article 16).

SME carve-out: Article 64(10)(a) exempts microenterprises and small enterprises from fines for missing the timing requirements in Article 14(2)(a) and 14(4)(a). The exemption covers timing only. The reporting obligation itself still applies.

What "Actively Exploited" Means

Article 14(2)(a) 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.

Phase 2 Readiness Checklist

REPORTING INFRASTRUCTURE (before 11 September 2026):
[ ] Notification templates prepared: 24-hour, 72-hour, 14-day, 30-day 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 Art. 14 obligations completed

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

TEAM READINESS:
[ ] Security team trained on Article 14 obligations and the four-tier 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 (Annex I)

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 unauthorized 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 (Art. 13(6)).

Update Capability

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

Technical Documentation (Annex VII)

Support Period: Two Separate Obligations

The CRA imposes two distinct obligations on security updates.

Article 13(8): You must issue security updates for a minimum of five years from the date of placing the product on the market, or 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.

Article 13(9): Each security update you issue must remain available for download for a minimum of 10 years from the issuance date, or 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 violate Article 13(9) 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: NB process finished for Important Class I and Class II
[ ] CE marking applied
[ ] EU Declaration of Conformity prepared per Art. 28

TECHNICAL FILE (Annex VII):
[ ] Risk assessment complete and documented
[ ] SBOM current and validated
[ ] Conformity evidence organized and accessible
[ ] Support period declared per Art. 13(8) expected product lifetime

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

ONGOING:
[ ] Art. 13(8): security update process active for the full support period duration
[ ] Art. 13(9): 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 31 March 2026. The document is not finalized. Final language versions are pending. 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.

Official announcement: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act

Penalties

Article 64(2) of Regulation (EU) 2024/2847 sets the top-tier penalty at €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for:

• Non-compliance with the essential cybersecurity requirements in Annex I and Article 13 obligations.
• Failure to meet Article 14 obligations (vulnerability and incident reporting).

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

Article 64(3) (€10 million or 2%) covers a separate set of obligations: Articles 18-23, 28, 30-33, 39, 41, 47, 49, 53. These are primarily importer, distributor, and Notified Body obligations. Article 14 is not in this list.

SME carve-out: Article 64(10)(a) exempts microenterprises and small enterprises from fines for missing the specific timing requirements in Article 14(2)(a) and 14(4)(a). The exemption covers timing, not the substance of the reporting obligation.

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 (Article 13(9)). 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

Long product lifecycles (10 to 20 years) interact directly with both the five-year minimum support floor (Article 13(8)) and the 10-year update availability requirement per issuance (Article 13(9)). A product with a 20-year expected lifetime may need a 20-year support commitment.

Industrial products frequently fall into Important Class I or Class II, which currently means Notified Body assessment. Contact conformity assessment bodies now. The formal NB designation process opens after June 2026, and capacity will be constrained through at least December 2026.

IoT Devices

Default credential elimination is a hard requirement (Annex I, Part I, §2(e)). 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.

How CRA Evidence Helps

The hardest parts of CRA compliance are not knowing what to do. They are operational: tracking component changes across multiple product versions, getting a 24-hour notification out at 11 PM on a Friday, keeping update archives reachable for 10 years.

CRA Evidence is built around these operational problems:

• SBOM management: Upload CycloneDX or SPDX files, run TR-03183 quality checks, track coverage gaps across product versions.
• Vulnerability monitoring: Automated scanning against your SBOM, with alerts keyed to the Article 14 timeline: 24-hour, 72-hour, and 14-day thresholds.
• Technical file export: Generate Annex VII documentation bundles directly from your compliance data.
• Portfolio dashboard: Track Article 14 readiness across every product in one view.
• Audit trail: Full traceability linking vulnerability responses to specific product versions and builds.

Classification: Determine your product category with our product classification guide.

SBOM: Build your SBOM infrastructure with our SBOM requirements guide.

Reporting: Learn the 24-hour rule in our ENISA vulnerability reporting guide.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult qualified legal counsel.