CRA Art.11 Actively Exploited Vulnerabilities: The 24-Hour ENISA Notification That Your US-Hosted Stack Cannot Safely Fulfill

Post #5 in the sota.io EU Cyber Resilience Act Compliance Series

In four months, the Cyber Resilience Act's Article 11 mandatory reporting obligations take effect across the EU. Every manufacturer of a product with digital elements — from SaaS platforms to embedded firmware — must notify ENISA within 24 hours of detecting an actively exploited vulnerability.

That clock starts the moment you become aware. Not when you confirm the severity. Not when you complete your initial triage. The moment you have reason to believe exploitation is occurring.

For products hosted on US-headquartered cloud infrastructure, this creates a legal collision that no compliance policy document can resolve: the CLOUD Act empowers US law enforcement to demand disclosure of the same vulnerability data your Art.11 report will contain — and they can do so with a gag order that prevents you from telling anyone, including ENISA, that the request happened.

This post is the fifth in our CRA compliance series. We covered vulnerability database obligations under Art.10, coordinated vulnerability disclosure under Art.14, security by design requirements under Art.13, and the CRA penalty framework. Art.11 sits at the sharp end of all of them: it is where abstract compliance risk becomes an active incident with a running countdown.

What Art.11 Actually Requires

Article 11 of the CRA establishes a three-stage notification obligation for manufacturers. The stages are sequential and cumulative — each subsequent report adds detail to the previous.

Stage 1: Early Warning (24 Hours)

Within 24 hours of becoming aware of an actively exploited vulnerability in your product, you must submit an early warning to ENISA through the national CSIRT (Computer Security Incident Response Team) of the EU member state where you are established, or where most of your users are located.

The early warning must include:

• The fact that exploitation has been detected
• Any information sufficient for ENISA to assess the cross-border impact
• Whether the vulnerability is already known publicly

This is a notification of detection, not a notification of resolution. You cannot wait until you understand the vulnerability fully. The 24-hour clock begins at awareness.

Stage 2: Vulnerability Notification (72 Hours)

Within 72 hours of the same awareness event, you must submit a more detailed notification to ENISA via the national CSIRT. This notification must include:

• Initial assessment of the severity and impact
• Indicators of compromise (IoCs) where available
• Whether the vulnerability was previously known to the manufacturer
• The remediation measures being implemented or planned

The 72-hour window is the same cadence as GDPR Art.33 breach notifications to supervisory authorities — intentionally harmonized so that a security incident involving personal data triggers both reports simultaneously.

Stage 3: Final Report (Within 14 Days, Extended in Complex Cases)

A final detailed report must be submitted to ENISA no later than 14 days after you became aware, or sooner if a patch or mitigation is available. The final report must include:

• Full description of the vulnerability, including the technical root cause
• Complete description of the remediation measures applied
• Any information about similar vulnerabilities in the product class
• Any cross-border or critical infrastructure impact assessment

For critical infrastructure products (Annex I, Class II), ENISA may request additional technical information and can coordinate national CSIRTs across member states to share the data.

Art.11 vs Art.10: The Distinction That Matters

Art.10 covers vulnerability management as an ongoing manufacturing process: maintaining a database, applying patches, keeping documentation current. It is about systematic hygiene across the product lifecycle.

Art.11 is different in kind. It triggers on a specific event: active exploitation. The moment an attacker is using a vulnerability in your product against someone, the Art.11 clock starts, regardless of whether you have a patch, regardless of whether you have notified users, regardless of whether you are still assessing severity.

This has a concrete implication for cloud-hosted products: your ability to detect active exploitation depends entirely on your visibility into your own infrastructure. If your product runs on shared cloud infrastructure where log access, network telemetry, and incident data are intermediated by a platform provider, your detection capability — and therefore your awareness timing — is at the discretion of that provider's tooling and their willingness to surface incidents to you.

EU-native hosting providers operating under EU law are subject to GDPR obligations that create a structural incentive to surface security incidents to customers promptly. US-headquartered providers have a different incentive structure: disclosing an active exploitation event to you might create legal obligations for them under CLOUD Act or other US frameworks.

The CLOUD Act Collision

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. §2713) allows US law enforcement agencies — FBI, DOJ, Secret Service — to compel US-headquartered companies to produce data stored anywhere in the world, including in EU data centers.

When Art.11 applies to your product, the data that CLOUD Act targets is precisely the data you need for your ENISA notification:

• Log data showing the exploitation timeline and attacker behavior
• Network telemetry identifying affected systems and data flows
• Incident records documenting what you knew and when
• Vulnerability details including the technical root cause

A CLOUD Act order can require your cloud provider to produce this data to US authorities. Critically, CLOUD Act orders frequently include gag orders (18 U.S.C. §2705(b)) that prohibit the provider from disclosing the existence of the order to the customer — meaning you — for periods of 90 days or longer.

Under this scenario, the sequence of events is:

1. Active exploitation detected in your product
2. Your US-headquartered cloud provider becomes aware of the same event via their monitoring
3. US law enforcement issues a CLOUD Act order for your incident data, with gag order attached
4. Your cloud provider cannot tell you the order exists
5. You submit your Art.11 early warning to ENISA at T+24h as required
6. Your cloud provider has simultaneously disclosed the same incident data to US authorities, without informing you or ENISA

The CLOUD Act order does not prevent you from submitting your Art.11 notification. But it creates an asymmetry: US authorities have the detailed incident data before — or simultaneously with — your own ENISA submission. The data in your notification can be cross-referenced against what US law enforcement received directly from your provider.

This is not a theoretical risk. The Irish DPC has documented multiple cases of CLOUD Act orders affecting EU data processed by US-headquartered providers on EU-resident data. The Meta Ireland DPC decision (2023) specifically addressed the structural impossibility of providing adequate protection when US parent companies are subject to US surveillance law.

Three Failure Modes for US-Hosted Products Under Art.11

Failure Mode 1: Delayed Awareness

When exploitation occurs on US-hosted infrastructure, your visibility into the incident depends on what the platform provider surfaces to you and when. If the provider detects exploitation before you do — which is common; they have broad network visibility — they may not immediately inform you.

For Art.11, the 24-hour clock starts when you become aware, not when your provider becomes aware. But ENISA can investigate whether a manufacturer should have been aware earlier based on the incident timeline. If your provider had telemetry showing active exploitation at T+0 and you submitted your notification at T+36h because you weren't informed until T+12h, that may be treated as a delayed notification — not as a timely one.

EU-native providers operating under GDPR have a contractual and regulatory obligation to surface security incidents to customers promptly as part of their Data Processing Agreement (DPA) obligations. US-headquartered providers operating under US law do not have an equivalent structural obligation to notify EU customers of exploitation events affecting their data.

Failure Mode 2: Incomplete Notification

Art.11 Stage 2 (72h notification) requires indicators of compromise and an initial impact assessment. If the forensic data you need — network logs, access records, exploitation payloads — is held by your US-headquartered provider and subject to a CLOUD Act order you don't know exists, you may submit a notification that is technically compliant in timing but incomplete in substance.

Market surveillance authorities reviewing your Art.11 notifications post-incident can assess whether they were substantively adequate. A notification that omits available IoCs because the manufacturer did not have access to their own infrastructure data is not a defense to the requirement.

Failure Mode 3: Parallel Disclosure Without Coordination

ENISA coordinates with national CSIRTs, sector regulators (for critical infrastructure), and EU-CERT when processing Art.11 notifications. This coordination is confidential and subject to EU information security frameworks.

If your incident data was already disclosed to US law enforcement via CLOUD Act before or during your Art.11 notification, the confidentiality of the EU coordination process is compromised. The very purpose of the Art.11 notification — enabling ENISA to coordinate a controlled EU-wide response — is undermined if the incident data has already leaked to a non-EU law enforcement authority.

For products affecting critical infrastructure (energy, finance, health, transport — the sectors listed in NIS2 Annex I), this is not just a compliance technicality. It directly undermines the purpose of the CRA's security regime.

The Art.11 Notification Timeline: A Practical Walkthrough

T+0: Detection Your monitoring detects anomalous behavior consistent with active exploitation. Internally, you are "aware" from this moment.

T+24h: Early Warning Required Your national CSIRT submission must be in by this deadline. You need: confirmation that exploitation is occurring (or was occurring), basic product identification, initial cross-border impact estimate.

T+72h: Detailed Notification Required Your CSIRT submission must now include IoCs, initial severity assessment, and remediation status. You need access to forensic data from your infrastructure.

T+14 days (or sooner): Final Report Required Root cause, full remediation, cross-border impact, product class assessment. You need complete access to your incident record.

At every stage, your ability to meet the deadline depends on having unimpeded access to your own infrastructure's data and logs. If that access is mediated by a US-headquartered provider subject to CLOUD Act, you have introduced a structural dependency on a third party whose obligations are to US law, not EU regulation.

Annex I Products and Heightened Obligations

CRA Annex I distinguishes between:

• Class I products: lower risk, self-assessment conformity
• Class II products (Annex I, Part II): higher risk, require third-party conformity assessment

Class II products include:

• Hypervisors and container runtimes used in critical infrastructure
• Firewalls and intrusion detection systems
• Hardware security modules
• Smart meters and EV charging controllers
• Network routers used in industrial environments

If your product falls into Class II, Art.11 obligations are more stringent:

• ENISA may share your notification data with EU member state competent authorities
• Market surveillance authorities can request audit access to your Art.11 records
• Your Art.11 notification history becomes part of the conformity assessment record

For Class II products hosted on US-headquartered cloud, the CLOUD Act collision is especially acute: your conformity assessment record — which will include Art.11 notifications — is subject to US discovery in any litigation involving your cloud provider, regardless of EU classification markings.

What Changes When You Host on EU-Native Infrastructure

The structural solution to the Art.11 CLOUD Act collision is not a policy workaround or a contractual clause. Standard Contractual Clauses (SCCs) specifically do not override CLOUD Act obligations — the CJEU has confirmed this repeatedly, most recently in Schrems III discussions. The only structural solution is to eliminate the US-law dependency entirely.

When your infrastructure runs exclusively on EU-headquartered providers without US parent companies or US-domiciled subsidiaries in the ownership chain, CLOUD Act does not apply. A law enforcement order targeting your incident data must go through EU law — mutual legal assistance treaties (MLATs), EU court orders, or the new EU-US Data Privacy Framework for specific cases — rather than US unilateral authority.

This means:

• Your Art.11 early warning is the first notification of your incident, not a parallel disclosure
• ENISA's coordination is genuinely confidential because there is no parallel US channel
• Your forensic data is accessible to you in its complete form at the time you need it for Stage 2 and Stage 3 notifications
• Your Art.11 notification record cannot be accessed via US discovery without EU legal process

EU-native hosting does not eliminate all Art.11 compliance risk. You still need technical capability to detect exploitation, internal processes to trigger the notification workflow within 24 hours, and documented procedures for your CSIRT communications. But it eliminates the category of risk that is structurally irresolvable — the category where complying with EU law and complying with US law become mutually exclusive.

Art.11 Compliance Checklist for September 2026

With four months to the CRA's main obligations taking effect, here is a practical readiness checklist:

Detection and Awareness

• Active exploitation monitoring deployed and generating alerts with timestamps
• Defined criteria for what constitutes "active exploitation" (not just vulnerability discovery)
• Designated security contact with authority to initiate Art.11 notification workflow
• Escalation path from monitoring alert to Art.11 trigger decision: under 2 hours

Notification Process

• National CSIRT identified and contact established (varies by member state — check ENISA CSIRT network)
• Art.11 Stage 1 template prepared (early warning format per ENISA guidance)
• Art.11 Stage 2 template prepared (72h notification with IoC placeholder)
• Art.11 Stage 3 template prepared (final report structure)
• Secure channel for CSIRT communication established

Infrastructure and Access

• Verified that all incident data (logs, telemetry, forensic records) is accessible to you without provider intermediation
• Confirmed no US-headquartered entities in your cloud provider's ownership chain
• Data Processing Agreement reviewed for incident notification obligations — DPA must include provider's obligation to notify you of exploitation events within 4 hours
• Business continuity plan for Art.11 notifications if primary contact is unavailable

Legal and Documentation

• Legal counsel reviewed CLOUD Act exposure in current infrastructure setup
• Gag order scenario documented in incident response plan
• Art.11 notification log system in place (ENISA may audit notification history)
• For Class II products: conformity assessment body informed of Art.11 process

Connection to Art.10, Art.13, and Art.14

CRA's vulnerability management obligations form an interlocking system. Understanding how Art.11 connects to the other articles clarifies why hosting jurisdiction is a cross-cutting concern, not an isolated risk:

Art.10 (covered in our previous post) establishes the ongoing obligation to monitor for vulnerabilities and maintain a database. Art.10 is your proactive vulnerability management process — running continuously.

Art.11 triggers when Art.10 monitoring discovers active exploitation. It is the incident activation of your Art.10 system. The quality of your Art.10 vulnerability database directly affects your Art.11 response time: if you maintain accurate product component records (SBOM, dependency tree), you can assess impact and generate IoCs faster.

Art.13 (covered in our security by design post) requires products to be designed so that vulnerabilities can be addressed by design. Products with good Art.13 compliance have well-documented component architecture, which makes the Art.11 root cause analysis significantly faster.

Art.14 (covered in our CVD post) covers non-exploited vulnerabilities reported externally. Art.14 is your CVD process — handling bug bounty and researcher reports. Art.11 and Art.14 can trigger simultaneously if a researcher-reported vulnerability is also being actively exploited in the wild.

The September 2026 Deadline

The main CRA obligations — including Art.11 — apply from 11 September 2026. The Articles 14 and 10 obligations on vulnerability handling apply from 11 June 2026, giving them a three-month head start.

This sequence is deliberate: ENISA and the Commission expect manufacturers to first establish their CVD policies (Art.14, Art.10) and then test them under the more demanding active exploitation scenario (Art.11).

For EU software manufacturers, the practical readiness question is: if an attacker begins exploiting a vulnerability in your product at 9am on 11 September 2026, can your team submit an accurate early warning to your national CSIRT before 9am on 12 September 2026?

If the answer depends on your US-headquartered cloud provider surfacing the incident to you, providing complete forensic data without legal impediment, and not being subject to a parallel disclosure obligation to US law enforcement — then the answer is not reliably yes.

Further Reading in This Series

• CRA Art.10: Vulnerability Reporting Database and Hosting Jurisdiction
• CRA Art.13: Security by Design and the CLOUD Act Architecture Gap
• CRA Art.14: Coordinated Vulnerability Disclosure and EU Jurisdiction
• CRA Penalty Framework: Fines Up to €15 Million for Manufacturers