CRA September 2026: Vulnerability Reporting Obligations and the CLOUD Act Jurisdiction Problem

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

The Cyber Resilience Act (Regulation 2024/2847) does not fully apply until December 2027. But two provisions arrive much earlier: Articles 14 and 16 take mandatory effect on 11 September 2026 — exactly 21 months after the CRA entered into force on 11 December 2024.

Article 14 is the vulnerability reporting obligation. Every manufacturer of a product with digital elements must notify ENISA of actively exploited vulnerabilities within 24 hours of becoming aware. Article 16 adds incident reporting obligations on a parallel track.

For most developers and SaaS companies, the September 2026 deadline sits in the middle distance — visible but not yet urgent. That framing is wrong. Infrastructure decisions made today determine whether you can legally comply with CRA Article 14 in September.

If your product runs on AWS, Azure, Google Cloud, or any infrastructure operated by a US-incorporated entity — regardless of where the servers are physically located — you face a structural compliance conflict that cannot be solved by a DPA, SCCs, or a technical measure. It can only be solved by moving your infrastructure outside US jurisdiction before 11 September 2026.

What CRA Articles 14 and 16 Actually Require

Article 14: Vulnerability Reporting to ENISA

CRA Article 14 establishes a three-stage notification process triggered by discovery of an actively exploited vulnerability in a product you manufacture:

Stage 1 — Early Warning (24 hours)

"Without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability, manufacturers shall submit an early warning to ENISA."

The early warning must include:

• Product identification
• General description of the vulnerability
• The fact that active exploitation has been observed
• Whether the vulnerability has been publicly disclosed

The 24-hour clock starts when you become aware — not when a patch exists, not when exploitation is confirmed beyond doubt.

Stage 2 — Detailed Notification (72 hours)

Within 72 hours of becoming aware, manufacturers must submit a detailed notification including:

• Severity and impact assessment
• Affected product versions and configurations
• Any available mitigations or workarounds
• Whether the vulnerability was discovered internally or reported externally
• Details on exploitation activity observed

Stage 3 — Final Report (14 days after resolution, or 1 month if unresolved)

A final report covering the full vulnerability lifecycle, root cause analysis, remediation steps taken, and coordination with downstream users.

Article 16: Security Incidents

Article 16 runs in parallel to Article 14. Manufacturers must notify their CSIRT (Computer Security Incident Response Team) of security incidents that have a significant impact on the security of their product. The reporting timeline is the same three-stage structure as Article 14.

Who Is a "Manufacturer"?

CRA Article 3(13) defines manufacturer as any legal person who develops or manufactures products with digital elements, or has such products designed, developed, or manufactured and markets them under their name or trademark.

SaaS companies providing software as a service are covered. If your SaaS product processes data, provides security functions, or could be exploited to compromise user systems, you are a manufacturer of a product with digital elements under the CRA.

The September 2026 Timeline

Most CRA commentary focuses on the December 2027 full application date. The September 2026 early-application date for reporting obligations gets less attention — and that is a problem, because the reporting obligations are the ones with the most direct regulatory conflict with US infrastructure law.

The CLOUD Act Conflict

How the CLOUD Act Works

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. §2523) authorises US law enforcement to compel US-incorporated cloud service providers to produce data stored anywhere in the world, including EU data centres.

The statute applies to any provider that is "a person or entity that provides an electronic communication service or a remote computing service." AWS (Amazon Web Services Inc., Delaware), Microsoft Azure (Microsoft Corporation, Washington), and Google Cloud (Google LLC, Delaware) are all US-incorporated providers subject to CLOUD Act compelled production.

CLOUD Act §2523 also prohibits providers from notifying customers of such demands unless the government opts not to impose a gag order. Under 18 U.S.C. §2705(b), a court may prohibit a provider from notifying any person of the existence of a request for communications records "for such period as the court deems appropriate."

The Non-Disclosure Order Mechanism

When US law enforcement opens an investigation related to a security vulnerability — whether investigating the threat actor, the criminal use of the exploit, or a national security concern — they can obtain:

• A National Security Letter (NSL) under 18 U.S.C. §2709, which comes with a default non-disclosure requirement
• A court order under 18 U.S.C. §2703(d) requiring production and prohibiting disclosure
• A CLOUD Act warrant under 18 U.S.C. §2703 for email, stored data, and transaction records

Any of these instruments can arrive at your US cloud provider prohibiting disclosure of the underlying security matter — including prohibiting the provider from telling you about the order, and by extension prohibiting you from disclosing the vulnerability it relates to.

The Direct CRA Conflict

The conflict is not theoretical. Here is the sequence of events that creates it:

1. You discover, on 15 September 2026, that your SaaS product has an actively exploited vulnerability. Your infrastructure runs on AWS Frankfurt (eu-central-1).

2. Your 24-hour CRA Article 14 clock starts: you must notify ENISA by 16 September 2026.

3. Simultaneously, US law enforcement is investigating the threat actor exploiting your vulnerability — potentially a nation-state actor or criminal group of interest to FBI/CIA.

4. US law enforcement serves Amazon Web Services Inc. (Delaware) with a CLOUD Act warrant and a §2705(b) non-disclosure order covering the vulnerability and any related investigation.

5. AWS cannot tell you about the order. You cannot tell ENISA about the vulnerability — the US order covers the same subject matter as your CRA notification.

6. Result: You are in breach of CRA Article 14 if you comply with the US non-disclosure order. You are in breach of US law if you notify ENISA.

There is no way to comply with both simultaneously.

Why SCCs and DPAs Do Not Help

Organisations running on US cloud providers often address data sovereignty concerns with Standard Contractual Clauses (SCCs), Data Processing Agreements (DPAs), or supplementary technical measures.

None of these instruments resolves the CLOUD Act conflict for CRA Article 14:

SCCs are a GDPR mechanism for international data transfers. They do not bind US law enforcement and do not limit the scope of CLOUD Act warrants. A US court issuing a CLOUD Act order is not bound by the contractual commitments in your SCCs.

DPAs are contractual agreements with your processor. They cannot override statutory obligations imposed on the processor by US law. AWS's DPA with EU customers does not limit what AWS must do when served with a US federal court order.

Encryption is sometimes proposed as a technical measure that makes CLOUD Act production meaningless. This argument has merit for static data — if AWS cannot decrypt your data, the production of encrypted ciphertext is not useful to law enforcement. But the CRA Article 14 conflict is not about data extraction. It is about a non-disclosure order preventing you from making a mandatory regulatory notification. Encryption of your data does not prevent the non-disclosure order from binding your ability to communicate with ENISA.

Jurisdictional Scope Is Determined by Incorporation, Not Server Location

The most common misunderstanding about CLOUD Act jurisdiction is the belief that data stored in EU data centres is outside US jurisdiction. This is incorrect.

CLOUD Act jurisdiction is determined by the incorporation and control of the service provider, not the physical location of the servers. AWS Frankfurt is operated by Amazon Web Services EMEA SARL (Luxembourg, EU), but the contractual relationship for business customers routes through Amazon Web Services Inc. (Delaware). The Delaware entity is subject to CLOUD Act compelled production regardless of where the servers are.

The same analysis applies to Microsoft Azure (Microsoft Ireland Operations Ltd routes through Microsoft Corporation, Redmond, Washington) and Google Cloud (Google Ireland Ltd routes through Google LLC, Mountain View, California).

How EU-Sovereign Infrastructure Solves the Conflict

The CLOUD Act conflict is a structural problem that cannot be solved at the contractual or technical layer. It is solved by removing the US nexus from your infrastructure stack entirely.

What "EU-Sovereign" Means for CRA Article 14 Purposes

For CRA Article 14 compliance purposes, EU-sovereign infrastructure means:

• Operated by an EU-incorporated legal entity with no US parent company
• No contractual relationship with a US entity that could be subject to CLOUD Act compelled production
• No US persons or entities in the ownership or control chain that would create personal jurisdiction in US courts

An EU-sovereign infrastructure provider meeting these criteria cannot be compelled to produce data under the CLOUD Act, and cannot receive valid non-disclosure orders from US law enforcement. You can notify ENISA within the CRA Article 14 timeline without risk of conflicting US legal obligations.

Infrastructure Categories and CRA Article 14 Risk

The Application Layer Problem

Many developers understand the infrastructure jurisdiction issue but believe they can resolve it by running the application on EU servers while keeping the application code, build pipeline, or management plane on US-controlled systems.

This does not work for CRA Article 14.

The CLOUD Act order can be directed at any US-incorporated entity that has access to or control over the relevant systems. If your CI/CD pipeline runs on GitHub Actions (GitHub Inc., San Francisco), your deployment tooling connects to a US-controlled API, or your monitoring sends data to a US SaaS tool, there are additional CLOUD Act vectors that may be covered by the same non-disclosure order.

CRA Article 14 compliance requires that the entire path from vulnerability discovery to ENISA notification is free of entities subject to CLOUD Act non-disclosure orders.

Your CRA Article 14 Compliance Checklist

Before 11 September 2026

Infrastructure audit:

• Map every infrastructure provider in your stack to its legal incorporation
• Identify any US-incorporated entities in the ownership chain of each provider
• Flag all US-incorporated providers as CRA Article 14 risk

Reporting process design:

• Designate a CRA Article 14 responsible person with authority to notify ENISA
• Set up ENISA reporting account (ENISA Single Reporting Platform, launching Q3 2026)
• Establish internal escalation procedure: detection → assessment → notification decision within 12 hours
• Define what constitutes "actively exploited" for your product (ENISA guidance: any evidence of exploitation in the wild, including reports from customers or security researchers)

Documentation:

• Vulnerability tracking system with timestamps from "first awareness"
• Template for ENISA early warning (24h) and detailed notification (72h)
• Legal review: confirm your infrastructure stack has no US-jurisdiction conflict for notification obligations

Infrastructure Migration Decisions

If your audit identifies US-incorporated infrastructure providers in your critical path:

Option 1 — Full migration to EU-sovereign infrastructure

Move your application, data, and management plane to EU-incorporated providers with no US parent. This eliminates the conflict entirely. Timeline for a typical SaaS: 6-10 weeks for planning, testing, and cutover. Starting now (May 2026) gives you 4 months before the September deadline.

Option 2 — Hybrid architecture with EU-sovereign critical path

Keep US infrastructure for non-sensitive workloads while migrating the systems that store vulnerability-related data (security logs, incident tracking, deployment system) to EU-sovereign infrastructure. The CLOUD Act conflict applies to the entity that has access to the relevant information — so even a hybrid approach can reduce risk if the security-critical path is entirely EU-sovereign.

Option 3 — Do nothing and document the conflict

Some organisations will choose not to migrate infrastructure and instead document the known regulatory conflict in their compliance posture. This approach accepts the risk that a CRA Article 14 violation may occur if a conflicting US non-disclosure order arrives. ENISA guidance on this scenario is not yet published; NCA enforcement priorities will clarify how this conflict is handled in practice.

For most SaaS companies, Option 1 or 2 is the correct approach, and the cost of migration is lower than the cost of a CRA Article 14 violation (up to €15 million or 2.5% of global annual turnover under CRA Article 64).

CRA Article 14 Penalties

CRA Article 64 sets out the penalty structure for non-compliance with reporting obligations:

Market surveillance authorities in each member state have enforcement jurisdiction. The CLOUD Act conflict does not constitute a valid defence for non-notification — the regulatory obligation exists regardless of conflicting US law.

The Broader CRA Picture: What Else Is Coming

While Articles 14 and 16 are the September 2026 urgent items, developers should be aware of the broader CRA obligations timeline:

From 11 June 2027:

• Security requirements for products with digital elements (Annex I, Part I)
• Vulnerability handling requirements (Annex I, Part II)
• Conformity assessment obligations for high-criticality products (Annex III)

From 11 December 2027 (full application):

• CE marking requirement for products with digital elements
• EU Declaration of Conformity
• Market surveillance compliance

The September 2026 reporting obligations are effectively a preview deployment of the CRA's security requirements. Organisations that build compliant vulnerability management processes now — including resolving the infrastructure jurisdiction question — will be in a significantly stronger position for the 2027 full application.

Conclusion: Infrastructure Jurisdiction Is a Compliance Decision

CRA Article 14's 24-hour vulnerability reporting requirement is not primarily a technical problem. The technical challenge of detecting and triaging an actively exploited vulnerability within 24 hours is real — but it is solvable with good security tooling and incident response processes.

The harder problem is legal: ensuring that the regulatory notification you are required to make is not blocked by a conflicting obligation imposed on your infrastructure provider by a foreign government.

US cloud providers — regardless of their EU data centres, SCCs, and DPAs — cannot guarantee that they will not receive CLOUD Act compelled non-disclosure orders. They cannot make that guarantee because the orders are issued by US courts, not negotiated between contracting parties.

EU-sovereign infrastructure removes this conflict at the root. An infrastructure provider incorporated and operated entirely within EU jurisdiction, with no US parent company, cannot receive CLOUD Act orders. Your CRA Article 14 notification path is clear.

The September 2026 deadline is 4 months away. Infrastructure migration decisions that take 6-10 weeks to implement need to begin now.

sota.io runs on infrastructure incorporated and operated in the EU — no US parent company, no CLOUD Act exposure. If you are evaluating EU-sovereign hosting for CRA Article 14 compliance, see how sota.io compares to AWS Frankfurt for compliance-sensitive workloads.