EU CRA 2026 Readiness: Deadlines, Decisions, and Do-Nows
Executive Summary
Many teams still treat the EU Cyber Resilience Act (CRA) as a “2027 problem.” That is the wrong planning horizon.
The European Union’s Cyber Resilience Act transitions from legislative theory to operational reality in 2026, marking a decisive shift for manufacturers of products with digital elements (PDEs). While full application lands in December 2027, the year 2026 is the critical “operational readiness” period where key obligations become legally binding.
Most urgently, mandatory reporting obligations for actively exploited vulnerabilities and severe incidents take effect on September 11, 2026. This introduces strict 24-hour early warning and 72-hour notification deadlines that apply to all in-scope products, including legacy devices already on the market. Failure to meet these deadlines or essential cybersecurity requirements can result in fines up to €15 million or 2.5% of global turnover, whichever is higher (Article 64 of Regulation (EU) 2024/2847).
Operational bottlenecks are expected by late 2026. The framework for notifying Conformity Assessment Bodies (CABs) applies from June 11, 2026. Manufacturers of “Important” and “Critical” products will need to secure assessment slots with these bodies before capacity tightens ahead of the December 2026 operational target.
To prepare, organizations should focus on automating Software Bill of Materials (SBOM) generation to meet documentation standards, establishing a Product Security Incident Response Team (PSIRT) capable of meeting the 24-hour reporting window, and updating supplier contracts to ensure upstream visibility.
Why 2026 Matters: From Legal Text to Operational Reality
While the CRA’s core product requirements fully apply from December 11, 2027, two critical building blocks activate in 2026 that carry immediate legal weight.
First, the reporting regime goes live. From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents via a centralized platform managed by ENISA. This obligation applies retrospectively to products already placed on the market, meaning legacy fleets are in scope.
Second, the conformity assessment infrastructure becomes available. The legal framework for notifying conformity assessment bodies applies from June 11, 2026. This allows Member States to designate the “notified bodies” that will audit higher-risk products. With the first notified bodies expected to be operational by December 11, 2026, manufacturers face a narrow window to secure partners before market-wide demand creates bottlenecks.
What actually changes in 2026
Four dates define the sequencing for compliance. Missing these creates immediate regulatory exposure or risks delaying product launches due to certification backlogs.
Key 2026 CRA milestones and required actions
| Date | What Happens | Why It Matters | Action by You |
| Early 2026 | Commission Guidance Published | Clarifies scope and “substantial modification” | Review guidance to finalize product inventory |
| June 11, 2026 | CAB Framework Applicable | Notified bodies can be designated | Monitor NANDO database; pre-qualify auditors |
| Q3 2026 | Harmonized Standards Expected | Presumption of conformity becomes possible | Map Annex I controls to new standards |
| Sept 11, 2026 | Article 14 Reporting Live | Mandatory 24/72-hour reporting begins | PSIRT drills must be active; SRP onboarding complete |
| Dec 11, 2026 | Notified Bodies Operational | Assessment capacity opens | Sign contracts to lock in assessment slots |
Article 14 Reporting Requirements
The CRA establishes a strict, multi-stage reporting timeline that demands automation. Manual triage will likely fail to meet the 24-hour deadline. All reports must be submitted via the ENISA-managed “Single Reporting Platform” (SRP).
Article 14 reporting stages
| Event Type | Stage | Deadline | Core Content |
| Exploited Vulnerability | Early Warning | Within 24 hours | Awareness of event; affected Member States |
| Exploited Vulnerability | Notification | Within 72 hours | General info, initial assessment, corrective measures |
| Exploited Vulnerability | Final Report | 14 days after patch | Description of vulnerability, severity, and fix |
| Severe Incident | Early Warning | Within 24 hours | Suspected malicious cause; affected Member States |
| Severe Incident | Notification | Within 72 hours | Initial assessment of severity and impact |
| Severe Incident | Final Report | Within 1 month | Root cause, severity, and mitigation measures |
Product Classification and Conformity Routes
Misclassification can lead to significant delays. Products are categorized by risk, which dictates whether a manufacturer can self-assess or must engage a third party.
Important products (Class I & II)
Products with critical functions, such as operating systems, firewalls, routers, and industrial control systems, fall into the “Important” category.
Default category
Products not listed in Annex III or IV (e.g., consumer smart speakers) fall into the default category.
SBOM and Supply Chain Visibility
A Software Bill of Materials (SBOM) is a mandatory component of the technical documentation. It is essential for meeting the 24-hour reporting window, as it allows rapid identification of affected products.
SBOM requirements:
- Machine-readable format (CycloneDX or SPDX recommended)
- Coverage of all third-party and open-source components
- Versioning tied to each product release
- Updated with every build that changes dependencies
- Accessible to the response team for rapid queries during incidents
Supplier contract clauses that enable CRA compliance
| Clause | Why It Matters | Practical Target |
| SBOM Delivery | Required for technical file | Machine-readable SBOM for every version |
| Vuln Reporting | Enables 24h CRA compliance | Supplier must notify within 12-18 hours |
| Security Support | Ensures lifecycle compliance | Support provided for product’s support period (min. 5 years) |
| Audit Rights | Verifies conformity | Right to request documentation/audit security |
Technical Documentation and CE Marking
Technical documentation is the comprehensive evidence file required to justify the CE marking. It must be drawn up before the product is placed on the market and continuously updated, and must be retained for at least 10 years or the duration of the support period.
Manufacturers must also provide security updates for the entire support period of the product, with a minimum of 5 years from the date of placing the product on the market (Article 13). This has implications for legacy products: a device sold in 2023 and discontinued in 2025 may still carry support obligations through 2028. Organizations should factor this into product lifecycle planning and communicate support end dates clearly to customers.
A Practical Plan to Reach September 2026 Readiness
Phase 1: Baseline and prioritization
- Build a complete inventory of products, branches, components, and dependencies
- Assess current vulnerability management maturity
- Identify gaps in SBOM coverage, triage SLAs, and reporting readiness
Phase 2: Process build and automation
- Implement or stabilize SBOM generation in CI/CD
- Connect CVE intelligence to actual build artifacts and versions
- Formalize Article 14 playbooks with clear handoffs
Phase 3: Drills and hardening
- Run tabletop and live simulation exercises
- Measure actual response time by step
- Tune escalation paths, templates, and responsibilities
The goal is demonstrated capability, not documentation. Teams should be able to execute the full reporting cycle under realistic conditions.
Final Takeaway
For SaaS providers, CRA readiness in 2026 is fundamentally an operating model challenge. If your team cannot detect, assess, and report under a 24/72-hour cycle, risk materializes before 2027 ever starts.
The best approach is to treat CRA not as a one-time compliance project, but as a permanent product capability that combines secure engineering, vulnerability intelligence, and disciplined execution.
References
