CRA Implementation Timeline 2026-2027 — Month-by-Month Developer Compliance Checklist

Post #17 in the sota.io EU Cyber Compliance Series

The Cyber Resilience Act (EU 2024/2847) is not a single deadline — it is a two-phase compliance runway with 18 months of structured preparation required. The first phase lands September 11, 2026, when Articles 14 and 19 activate mandatory vulnerability and incident reporting to ENISA. The second phase arrives December 11, 2027, when the full regulation applies and CE marking becomes mandatory for connected digital products.

Most developer teams and product organizations are focused on the December 2027 date as a distant horizon. The September 2026 date is six months away. It requires reporting infrastructure, documented vulnerability disclosure policies, and tested workflows with ENISA's national single points of contact — none of which can be built in a weekend. This guide maps each calendar month from now to December 2027 with concrete, executable tasks.

The Two Critical Dates — What Each Means

September 11, 2026 — Phase 1: Reporting Obligations Live

Articles 14 and 19 apply from this date. Manufacturers must:

• Report actively exploited vulnerabilities to ENISA (via national CSIRT) within 24 hours of becoming aware
• Submit a preliminary incident notification within 72 hours for any incident with significant impact on the security of the product
• Provide a final report within 14 days of the vulnerability being mitigated or remediated
• Notify affected users "without undue delay" of vulnerabilities and available mitigations

The 24-hour reporting window is the most operationally demanding element. It runs continuously — weekends, public holidays, and outside business hours. Manufacturers without 24/7 incident response capabilities and a tested ENISA submission workflow will fail this deadline not by choice but by practical inability.

December 11, 2027 — Phase 2: Full CRA Applies

Everything else in the CRA becomes mandatory:

• Art.10: Security-by-design requirements, vulnerability handling, and disclosure policies
• Art.13: Manufacturer obligations for the entire product lifecycle
• Art.27: Technical documentation with SBOM and 10-year retention
• Annex I: Essential cybersecurity requirements (no default passwords, network exposure minimized, secure update mechanisms)
• CE marking: Products require conformity assessment and CE marking before market placement
• EU Declaration of Conformity: Formal self-declaration or notified body assessment

Penalties for non-compliance after December 11, 2027: up to €15 million or 2.5% of global annual turnover for essential cybersecurity requirement violations, whichever is higher.

Month-by-Month Checklist: May 2026 → December 2027

May 2026 (Now — 4 Months to Phase 1)

Product Classification

• Enumerate all software products that qualify as "products with digital elements" under CRA Art.3
• Classify each product: Default (self-assessment), Important Class I, Important Class II, or Critical (notified body required)
• Identify which products are "free and open source software" — different obligations apply under Art.24
• Document your classification rationale — MSAs can and will challenge misclassification

SBOM Baseline

• Run a full software composition analysis (SCA) scan across all products
• Select SBOM format: CycloneDX 1.5+ (recommended by ENISA) or SPDX 2.3+
• Identify all third-party components, their licenses, and current CVE status
• Map direct dependencies vs. transitive dependencies — CRA SBOM requirements cover both

Gap Assessment

• Review Art.10 essential security requirements against current product architecture
• Identify: default credentials (must be removed), insecure network services, missing secure update mechanism
• Inventory current vulnerability disclosure process — does one exist? Is it documented?

June 2026 (3 Months to Phase 1)

Vulnerability Disclosure Policy (VDP)

• Draft and publish a Vulnerability Disclosure Policy aligned with Art.10(6) and ENISA guidelines
• Establish a public security contact (security.txt per RFC 9116, security@yourdomain.com)
• Define internal triage SLA: discovery → classification → 24-hour ENISA report (if exploited) → fix → user notification
• Register with national CSIRT/CERT for your EU member state — this is who you report to under Art.14

Reporting Workflow Design

• Map the ENISA notification flow: who submits, what tool/portal, what information is required
• Build internal incident intake form capturing: product name, version, CVE ID, exploitation evidence, affected users
• Identify 24/7 coverage gap — on-call rotation for vulnerability reports
• Define "significant impact" threshold internally (Art.19 uses this term, and it is not yet fully defined — document your interpretation)

Infrastructure Audit

• Review where your product data and incident logs are stored
• If using US-headquartered cloud: document National Security Letter (NSL) risk for Art.14 reporting — see section below on jurisdiction gap
• Evaluate whether your cloud provider can confirm real-time access to all incident data during a reporting window

July 2026 (2 Months to Phase 1)

Reporting Dry Run

• Conduct a tabletop exercise simulating an actively exploited vulnerability discovery at 11 PM on a Friday
• Trace: who receives the alert, who classifies it, who submits the 24-hour ENISA report, who notifies affected users
• Test the national CSIRT submission portal (most member states use ENISA's MISP-based system or national equivalents)
• Document gaps found in the dry run — these are your September blockers

Documentation Infrastructure

• Establish version-controlled technical documentation repository (Art.27 requires 10-year retention)
• Configure automated SBOM generation in CI/CD pipeline — manual SBOMs become stale within weeks
• Implement immutable audit logging for vulnerability discoveries, classification decisions, and remediation actions
• Test documentation retrieval — can you produce any historical document within 24 hours of an MSA request?

Security Testing Baseline

• Commission penetration test for Class I/II products (results become part of Art.27 technical documentation)
• Run DAST/SAST tools and integrate results into CI pipeline
• Document all test results — including failures — in technical documentation repository

August 2026 (1 Month to Phase 1)

Final Pre-Compliance Verification

• VDP published and tested — security.txt verified, contact works
• ENISA/CSIRT relationship confirmed — submission credentials tested
• On-call rotation documented and staffed for September 11 go-live
• Legal review of "actively exploited" vs. "discovered but not exploited" distinction — different reporting timelines apply
• Internal communication: all product teams briefed on September 11 obligations

Art.14 Reporting Template

Prepare ready-to-send notification template containing:

• Product name and version
• CVE ID or internal reference
• Description of vulnerability and exploitation vector
• Evidence of active exploitation (if applicable)
• Affected user scope estimate
• Current mitigation status
• Timeline to patch

Having this template pre-approved by legal saves hours during a live incident.

User Notification Draft

• Draft user notification template (Art.19) — what information must be disclosed, what can be withheld during active investigation
• Identify notification channels: email, product dashboard, changelog, security advisory page
• Test notification delivery at scale

September 11, 2026 — Phase 1 Live

Go-Live Checklist

On September 11, 2026, your organization must be able to:

• Receive a vulnerability report at any hour and classify it within 4 hours
• Submit Art.14 notification to national CSIRT within 24 hours of confirming active exploitation
• Submit preliminary Art.19 incident notification within 72 hours of a significant impact incident
• Notify affected users "without undue delay" per Art.19(4)
• Produce final report within 14 days of remediation

October–December 2026 (Phase 1 Operating, Phase 2 Preparation Begins)

Conformity Assessment Planning

• For Important Class I products: identify which conformity assessment route applies (self-assessment vs. harmonized standard)
• For Important Class II and Critical products: identify notified body for third-party assessment
• Review EN 18045 (CRA-specific standard, expected 2026) and relevant ETSI/ISO standards
• Begin EU Declaration of Conformity draft

Technical Documentation Completion (Art.27)

• Complete all seven Annex VII documentation categories for each product
• Verify SBOM currency — automated generation pipeline must produce updated SBOM on each release
• Ensure risk assessment (Annex I Part 2) is complete and documented
• Verify 10-year retention mechanism is operational

Essential Security Requirements Gap Close (Art.10)

• Default passwords: removed or forced-change on first use
• Network attack surface: document all exposed services, close unnecessary ones
• Secure update mechanism: cryptographically signed updates, rollback capability
• Data minimization: only collect what the product needs
• Confidentiality protections: data at rest and in transit encrypted

January–June 2027

Conformity Assessment Execution

• Submit to notified body (Class II/Critical) or complete harmonized standard self-assessment (Class I)
• Address all findings from conformity assessment
• Prepare CE marking technical file

Market Surveillance Readiness

• Establish single point of contact for MSA inquiries in each member state where product is placed on market
• Prepare market surveillance response playbook: who responds, what documents to provide, what timeline
• Verify Art.27 documentation can be produced in English (lingua franca for cross-border MSA cooperation)

Supply Chain Documentation

• Document all third-party software component suppliers
• Obtain security attestations from critical suppliers
• Add CRA conformity clauses to new supplier contracts

July–November 2027

Final Verification Sprint

• Third-party penetration test for all CE-marked products (ideally two months before deadline)
• Final SBOM audit: verify all components, versions, and CVE status current
• Legal review of EU Declaration of Conformity — entity signing it assumes full legal liability
• Label and packaging review: CE marking placement and accompanying documentation

Importer/Distributor Obligations (Art.16/17)

If your organization places products on the EU market without manufacturing them:

• Verify manufacturer's CRA compliance before distribution
• Obtain and retain copy of EU Declaration of Conformity
• Add Art.4(3) clause to supply agreements

December 11, 2027 — Full CRA Applies

Products placed on the EU market from this date must have CE marking and meet all CRA requirements. Products already on the market receive a grace period based on support lifecycle — but "already on market" means shipped to customers before December 11, 2027, not released or announced.

The Jurisdiction Problem That Breaks Your Reporting Timeline

The 24-hour ENISA reporting window is operationally difficult. It becomes legally impossible under one specific circumstance: if your cloud provider is US-headquartered and receives a National Security Letter (NSL) with a gag order during or before the incident window.

An NSL gag order prohibits the cloud provider from disclosing to you — their customer — that:

• Your infrastructure was accessed by US law enforcement or intelligence
• Your log data was copied or reviewed
• A security event affecting your system occurred under the order

Under this scenario, you cannot meet Art.14's requirement to report "actively exploited vulnerabilities" to ENISA within 24 hours, because your cloud provider cannot tell you the exploitation occurred. The gag order creates a legal silence between the incident and your obligation to disclose it.

This is not a theoretical risk. The US DOJ issued approximately 23,000 NSLs in 2022 alone. FISA §702 and CLOUD Act provisions have been served to all major US cloud providers. No US-headquartered provider has been able to fully disclose the scope of government access orders.

The EU-native alternative: A cloud provider incorporated and operating under EU jurisdiction (Germany, France, Netherlands, etc.) with no US parent company is not subject to NSL or CLOUD Act jurisdiction. The provider can tell you everything. Your incident timeline remains intact. Your 24-hour ENISA window is actually achievable.

This is why cloud provider jurisdiction has moved from a compliance nice-to-have to a CRA prerequisite for any organization that takes the Art.14 reporting obligation seriously.

Which Products Are In Scope

The CRA defines "products with digital elements" broadly:

In scope:

• Software products sold or provided commercially (including SaaS via subscription)
• Hardware products with network connectivity
• Components supplied to manufacturers for integration

Out of scope:

• Medical devices (covered by MDR)
• Motor vehicles (covered by separate type-approval)
• Aviation, maritime, civil aviation equipment
• Military and national security products
• Software as a service where users do not receive a copy (this exclusion is narrower than it sounds — most SaaS is in scope via the "remote data processing" carve-in)
• Free and open source software not placed on the market in the course of commercial activity (Art.24)

The "commercial activity" threshold for open source is not a revenue test — it is a market placement test. If your organization controls the commercial distribution of software built on open source components, you are likely the manufacturer under Art.3(13), not the open source project.

Summary: The 18-Month Sprint

The CRA compliance runway from today (May 2026) to December 2027 is 19 months. The Phase 1 reporting window (Art.14/19) opens in 117 days. Organizations that have not yet:

1. Classified their products under the CRA risk tiers
2. Established a VDP and CSIRT relationship
3. Built 24/7 incident response capacity for Art.14's 24-hour window
4. Assessed their cloud provider's jurisdiction for the reporting gap

...are not on track for September 11, 2026.

The technical documentation and conformity assessment work for December 2027 is substantial — but it has 19 months. The operational readiness work for September 2026 has four months, and most of it cannot be parallelized.

The month-by-month structure matters: each month's tasks depend on the previous month's completion. The August dry run is meaningless if the June VDP is not published. The July documentation infrastructure is useless if the May SBOM baseline is incomplete.

Start with classification. Everything else flows from knowing which tier your products occupy.

sota.io is EU-native managed PaaS — incorporated and operating in Germany, no US parent company, not subject to CLOUD Act or NSL jurisdiction. For teams building CRA-compliant connected products, this means your incident timeline stays intact regardless of what happens in a US court. Learn more about CRA-compliant infrastructure →