CRA September 2026: The 120-Day Countdown to Mandatory ENISA Vulnerability Reporting

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

September 11, 2026 is 121 days away. On that date, Articles 14, 15, and 22 of the EU Cyber Resilience Act (CRA, Regulation 2024/2847) become directly enforceable across all EU member states. These articles mandate real-time vulnerability and incident notifications to ENISA — and they arrive with a structural conflict for any software team that hosts on a US-based PaaS.

This post maps the exact obligations you face on September 11, what changes on December 11, 2027 (full CRA enforcement), why your hosting jurisdiction is a compliance variable in both phases, and the 120-day action plan to be ready.

The CRA Timeline: Two Deadlines, One Regulation

The Cyber Resilience Act was published in the EU Official Journal on 20 November 2024 (OJ L 2024/2847) and entered into force on 11 December 2024. It does not apply all at once. The Regulation staggers enforcement across three key dates:

The September 2026 phase is commonly underestimated because teams focus on the 2027 "full compliance" date. But the September 2026 obligations are operationally the most demanding: they require a live, tested, jurisdictionally correct reporting pipeline — not just documented policies.

What Articles 14, 15, and 22 Actually Require

Article 14 — Vulnerability and Incident Notification to ENISA

Article 14 requires manufacturers of products with digital elements to notify ENISA:

• Within 24 hours of becoming aware of an actively exploited vulnerability: an early warning notification.
• Within 72 hours of the same awareness event: a notification with initial assessment of severity and impact.
• Within 14 days of remediation or mitigation availability: a final report with root cause, timeline, and fix.

These are not aspirational targets. They are legal obligations with enforcement consequences under Article 52 (fines up to €15 million or 2.5% of global annual turnover for non-compliance, whichever is higher).

The notification goes to ENISA's Single Reporting Platform, which ENISA is currently building in coordination with the European Union Agency for Network and Information Security. ENISA then coordinates with the relevant national Computer Security Incident Response Team (CSIRT) under Article 15.

Article 15 — Notification to Market Surveillance Authorities

In parallel with the ENISA notification, manufacturers must notify the market surveillance authority (MSA) of the member state where they are established. In Germany that is the Bundesnetzagentur; in France the ANSSI; in Ireland the NCSC Ireland. The content mirrors the ENISA notification but goes through a different channel.

Article 22 creates the procedural framework: MSAs coordinate with ENISA; ENISA aggregates reports into the European Vulnerability Database (EUVDB).

The Notification Trigger: "Actively Exploited"

A critical nuance: Articles 14–16 do not require notification for every vulnerability discovered. The 24h/72h clock starts only when the manufacturer becomes aware of an actively exploited vulnerability — one for which there is evidence of exploitation in the wild. The definition aligns with ENISA's guidance on the EUVDB and tracks CVE/CVSS status in context.

This matters operationally: your security team needs a defined process for determining whether a newly discovered vulnerability is actively exploited. "We are investigating" is not a valid reason to delay the 24-hour early warning.

The CLOUD Act Collision: Why Hosting Jurisdiction Is a September 2026 Problem

The 24-hour ENISA reporting window does not pause for legal complexity. But if your production infrastructure runs on AWS, GCP, Azure, Vercel, Railway, Render, Fly.io — any US-headquartered PaaS — that complexity arrives exactly when you need to move fastest.

What the CLOUD Act Enables

The Clarifying Lawful Overseas Use of Data Act (2018, 18 U.S.C. § 2713) grants US law enforcement and intelligence agencies the authority to compel US companies to produce data stored on servers anywhere in the world. It overrides the location of the server. A US Department of Justice order to AWS reaches your Frankfurt-region bucket without EU judicial review.

US PaaS providers are incorporated under Delaware or another US jurisdiction. Their parent companies — Amazon, Google, Microsoft, Cloudflare — are subject to the CLOUD Act regardless of where their servers sit. "EU region" does not mean "outside US jurisdiction."

The September 2026 Collision Scenario

Your product detects an actively exploited vulnerability at 09:00 CET. The Article 14 clock starts. You have until 09:00 CET the next morning for the early warning to ENISA.

Simultaneously, a US law enforcement request arrives at your PaaS provider (authorized under CLOUD Act) requesting access to your production environment logs — the same logs that contain the technical evidence of the exploitation.

Under the CLOUD Act, your provider must respond to that request without necessarily notifying you first. Under the CRA, you must notify ENISA within 24 hours with an initial assessment of what happened.

You now face a concurrent obligation and a potential evidence-access constraint in the same 24-hour window. You cannot accurately assess "severity and impact" for the ENISA notification if a US subpoena has constrained your access to logs, or if your provider cannot confirm whether logs have been accessed by a third party.

This is not a theoretical edge case. It is a foreseeable operational scenario for any team hosting security-relevant production workloads on a US PaaS provider.

The EU-Native PaaS Structural Advantage

Hosting on an EU-native PaaS — incorporated in the EU, with no US parent, operating under EU/EEA law exclusively — removes the CLOUD Act variable from the September 2026 equation.

The 120-Day Action Plan

You have 121 days from today (May 13, 2026) to September 11, 2026. Here is the sequence that matters.

Days 1–30: Scope Assessment

Determine which of your products qualify as products with digital elements under CRA Art. 3(1). The definition is broad: software with remote data connections (including SaaS, firmware, IoT software) that is made available on the EU market. Free and open-source software not in a commercial activity is excluded; if your project is commercially supported, it is in scope.

For each in-scope product, identify the manufacturer under Article 3(14): the entity that places the product on the EU market, or the natural or legal person who imports or distributes it if the manufacturer is outside the EU.

Deliverable: A list of in-scope products and the legal entity responsible for CRA Article 14 notifications for each.

Days 31–60: Reporting Pipeline Setup

Build the technical and procedural pipeline for Article 14 notifications before you need it:

1. Identify your ENISA reporting endpoint. ENISA's Single Reporting Platform will be operational before September 11, 2026. Monitor enisa.europa.eu for the final endpoint and required data format (expected: CSAF 2.0 or equivalent structured format).

2. Identify your MSA. Find the market surveillance authority in your establishment member state. In Germany: Bundesnetzagentur (bundesnetzagentur.de). In France: ANSSI (ssi.gouv.fr). In Ireland: NCSC Ireland (ncsc.gov.ie). In the Netherlands: RDI (rdi.nl). The full list is in Annex I of Regulation (EU) 2019/1020 as amended.

3. Build internal escalation triggers. Define what constitutes "becoming aware" of an actively exploited vulnerability in your team's workflow. This is typically: a credible external report, internal detection with exploit indicators, or CVE assignment with exploit flag. The trigger determines when the 24-hour clock starts.

4. Draft notification templates. Prepare CRA-compliant templates for: early warning (24h), notification (72h), and final report (14 days post-remediation). Templates should include: product identifier, vulnerability description, affected versions, severity assessment, exploitation evidence, initial mitigation steps, and affected jurisdictions.

Deliverable: Documented reporting pipeline with named owners, SLAs, and draft templates approved by legal.

Days 61–90: Hosting Jurisdiction Audit

Audit your production infrastructure for CLOUD Act exposure:

1. Map your PaaS and IaaS providers. List every service that stores or processes data related to your in-scope products.
2. Identify US-headquartered providers. Check parent company incorporation, not server location.
3. Assess CLOUD Act risk for each. A US company is a "covered US person" under 18 U.S.C. § 2523(b)(3) if incorporated in the US, organized under US law, or resident in the US. Delaware C-corps qualify regardless of where their servers run.
4. Evaluate migration timeline. If you identify critical production workloads on CLOUD Act-exposed providers, determine the lead time for migration to EU-native alternatives. Allow 8–12 weeks for a PaaS migration including testing.

Deliverable: Hosting jurisdiction audit report with risk ratings and migration plan for any critical workloads.

Days 91–120: Dry Run and Legal Review

Conduct a tabletop exercise simulating a September 11, 2026 day-one scenario:

• An actively exploited vulnerability is confirmed at T+0.
• Walk through the 24h early warning notification to ENISA.
• Walk through the simultaneous MSA notification.
• Identify gaps in log access, evidence preservation, and template completeness.
• Legal review of notification content for completeness under Article 14(2).

Fix identified gaps before September 11.

Deliverable: Dry run report with gap findings and remediation status.

Article 14 vs. GDPR Art. 33: Two Parallel Notification Obligations

A common question: does an Article 14 CRA notification overlap with GDPR Article 33 breach notification?

Yes, they can coexist. GDPR Art. 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. CRA Art. 14 requires notification to ENISA within 24/72 hours of an actively exploited vulnerability — which may or may not involve personal data.

When a CRA-reportable incident also constitutes a personal data breach, both clocks run simultaneously. Plan for concurrent notifications to different regulators, potentially with different content requirements.

What Does Not Change Until December 2027

The September 2026 phase triggers notification obligations only. The broader CRA obligations — the Annex I essential requirements (the 13-point security checklist we covered in Post #1028), SBOM requirements, CE marking, conformity assessment, declarations of conformity — these apply from December 11, 2027.

That means you have until 2027 for:

• Implementing all 13 Annex I essential security requirements in your product.
• Preparing the technical documentation under Article 31.
• Conducting the appropriate conformity assessment (self-assessment for most standard products; notified body review for Class I critical products under Annex III).
• Affixing CE marking.
• Registering Class II critical products in the European product database.

The 2027 requirements demand more fundamental product architecture changes. But the 2026 notification obligations demand operational readiness — processes, pipelines, and jurisdictional clarity — starting in 121 days.

The September 2026 Readiness Checklist

Use this checklist to assess where your team stands today:

Scope and Ownership

• Identified all in-scope products with digital elements under CRA Art. 3(1)
• Named the legal manufacturer for each product (the Art. 3(14) responsible entity)
• Confirmed establishment member state for MSA identification

Reporting Pipeline

• Identified ENISA Single Reporting Platform endpoint (monitor enisa.europa.eu)
• Identified the relevant national MSA contact
• Drafted 24h early warning template
• Drafted 72h notification template
• Drafted 14-day final report template
• Named incident owner responsible for CRA reporting (different from GDPR DPO?)

Triggering Criteria

• Defined "becoming aware" criteria for actively exploited vulnerabilities
• Integrated with existing CVE/vulnerability management workflow
• Established internal escalation path (security → legal → executive) within 24h

Hosting Jurisdiction

• Audited all PaaS/IaaS providers for US-headquartered parent companies
• Assessed CLOUD Act exposure for each critical production workload
• Migration plan in place for any CLOUD Act-exposed critical workloads

Legal and Process

• Legal review of notification templates for Art. 14(2) completeness
• Tabletop exercise scheduled before September 11, 2026
• Coordination with GDPR Art. 33 notification process documented

Why September 2026 Is Harder Than December 2027

The 2027 full-compliance deadline is further away but more tractable: it maps to concrete technical deliverables (implement Annex I requirements, get CE marking, produce SBOM). Engineering teams understand those as feature work.

The September 2026 deadline demands something different: operational readiness under time pressure, with legal and jurisdictional dimensions that engineering alone cannot resolve. A product that has perfect CE marking in 2027 but missed a 24-hour ENISA notification in October 2026 is still exposed to Article 52 penalties for the missed notification.

Start with the reporting pipeline. Audit your hosting jurisdiction. Run the tabletop exercise before September 11. The 120 days are sufficient — if you start now.

sota.io and the September 2026 CRA Obligation

For sota.io customers: deploying your products on sota.io means your production workloads run on infrastructure incorporated and operated entirely within the EU. There is no US parent company. There is no entity subject to the CLOUD Act. Your logs, your runtime data, and your security evidence remain in a single EU jurisdiction.

When the September 2026 notification window opens, you are reporting a vulnerability while maintaining full control of the technical evidence — without the CLOUD Act variable that complicates the same process for teams on US-headquartered PaaS providers.

This does not replace your internal CRA compliance programme. You must still build the reporting pipeline, identify your MSA, and run the tabletop exercise regardless of where you host. But jurisdiction removes one foreseeable failure mode from the September 2026 scenario.

About this series: The sota.io EU Cyber Compliance Series covers the intersection of EU digital regulations and hosting jurisdiction. Previous posts in this series: CRA Annex I Essential Requirements Checklist · CRA Art.7 Vulnerability Handling · CRA Art.14 Coordinated Vulnerability Disclosure · CRA Art.11 ENISA 24h Notification.