CRA Art.10 Vulnerability Reporting 2026: Why Your Hosting Jurisdiction Determines Your Compliance Burden

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

The EU Cyber Resilience Act (CRA, Regulation 2024/2847) introduced a requirement that many software teams are only now absorbing: mandatory vulnerability disclosure to ENISA within 24 hours of discovering that a vulnerability in your product is actively being exploited. This obligation, codified in Article 10, becomes enforceable on 11 September 2026 — roughly 15 months after this post.

The compliance logic sounds straightforward until you look at where your software runs. If you deploy on a US-headquartered PaaS — Vercel, Heroku, Render, Railway, or similar — you inherit a second compliance layer that EU-native hosting avoids entirely. This post walks through exactly what Art.10 requires, who it covers, and how hosting jurisdiction shapes your incident-response and reporting burden.

What CRA Article 10 Actually Requires

CRA Art.10(1) obliges manufacturers of products with digital elements (PDE) to:

1. Report actively exploited vulnerabilities — to ENISA's EUVDB (European Union Vulnerability Database) within 24 hours of becoming aware that the vulnerability is being actively exploited in the wild.
2. Submit an Early Warning — an initial notification that must include: product identification, a description of the vulnerability, the nature of exploitation, and any available mitigation guidance.
3. Provide a final report within 72 hours — a detailed technical assessment, the root cause where known, and any patches or workarounds.
4. Notify affected users — downstream customers must receive information "without undue delay."

Art.10 applies on top of, not instead of, any existing NIS2 obligations your organisation has as an essential or important entity. For SaaS companies deploying on third-party infrastructure, you may trigger both regimes simultaneously.

Who Qualifies as a "Manufacturer" Under CRA?

The CRA defines a manufacturer as any natural or legal person who places a PDE on the EU market. This is intentionally broad. If you:

• Sell a SaaS product to EU customers
• Publish an open-source library used in EU production systems
• Operate a developer tool, API, or cloud service accessed by EU users

…you are likely a CRA manufacturer. The "commercial activity" exception excludes purely private-use software and most FOSS projects where no significant commercial benefit is derived — but if you charge for support, host a paid tier, or the software forms part of a commercial offering, CRA applies.

The 24-Hour Clock Starts at Awareness, Not Discovery

This distinction matters operationally. Art.10 does not give you 24 hours from when you patch the vulnerability — it gives you 24 hours from when you become aware that it is being actively exploited. Your monitoring stack, your SOC alerts, and your on-call rotation all contribute to that timestamp.

Practically, this means:

• A CVE being published does not start the clock (that's Art.13, coordinated disclosure with ENISA at 9 months).
• A threat intelligence feed flagging active exploitation in the wild does start the clock.
• An incident responder finding exploitation evidence in logs also starts the clock — and it starts at the time the evidence was created, not when your engineer reviewed it.

ENISA's reporting portal will be the single submission point. Reports not submitted within the 24-hour window expose manufacturers to administrative fines up to €15 million or 2.5% of global annual turnover under CRA Art.64.

The US-PaaS Double Burden

Here is where hosting jurisdiction becomes material.

If your product runs on a US-owned PaaS — and most do, even when the compute sits in a Frankfurt or Dublin data centre — you face two simultaneous compliance pressures when a vulnerability is actively exploited:

Layer 1: Your Own Art.10 Obligation

You must report to ENISA within 24 hours. This requires your incident response team to:

• Pull logs from the PaaS platform (API, dashboard, or SIEM integration)
• Correlate exploitation evidence across your application and the underlying infrastructure
• Confirm scope and attribution under severe time pressure
• Draft and submit a technically accurate ENISA Early Warning

This is demanding but manageable if your tooling cooperates.

Layer 2: Your Vendor's Parallel Obligation (and CLOUD Act Exposure)

US-owned PaaS providers — Vercel (Delaware C-Corp), Heroku/Salesforce (Delaware C-Corp), Render (Delaware C-Corp), Railway (Delaware C-Corp) — are themselves PDE manufacturers under CRA if they operate in the EU market. They have their own Art.10 obligations for vulnerabilities in their platform.

But the deeper problem is the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2523). During an active security incident, US federal law enforcement can compel a US company to produce customer data stored on its servers — anywhere in the world — within 7 days, without requiring an EU court order. For your Art.10 incident:

• Your security incident evidence (access logs, telemetry, memory dumps) lives on the vendor's infrastructure.
• The US DOJ or FBI can access that evidence under a CLOUD Act production order faster than your ENISA report is due.
• The vendor may not be permitted to notify you that production has occurred.
• You may file an Art.10 report with ENISA while simultaneously having your incident data reviewed by US federal agencies — creating a jurisdiction conflict you cannot resolve.

Why This Matters for Art.10 Specifically

ENISA's Early Warning reports contain sensitive technical information: specific CVE identifiers, exploitation vectors, affected customer data categories, system architecture details. This is precisely the category of data that would be compelled under a CLOUD Act order in a major incident — think state-sponsored attacks, critical infrastructure targeting, or supply-chain compromises.

The January 2025 Vercel OAuth supply-chain incident (a third-party Context.ai token exposure affecting Vercel's management plane) illustrated this: GDPR Art.33 notification obligations, CRA Art.10-class vulnerability disclosure, and potential CLOUD Act exposure all overlapped in a 72-hour window. No EU manufacturer hosting on Vercel could have been certain that their incident data remained solely within EU regulatory reach during that window.

The EU-Native Hosting Advantage

When your production infrastructure runs on a provider with no US parent company and no US legal entities, the CLOUD Act simply does not apply. There is no parent subject to US jurisdiction, no subsidiary that can receive a production order, and no legal mechanism by which US federal law enforcement can compel disclosure without going through the EU Mutual Legal Assistance Treaty (MLAT) process — which typically takes 6–12 months, not 7 days.

For CRA Art.10 compliance, this means:

EU-native PaaS providers — those incorporated and operating exclusively under EU law, with no US parent, subsidiary, or legal entity — eliminate the CLOUD Act layer entirely. Your vulnerability report goes to ENISA. Your incident data stays within the reach of EU courts and EU data protection authorities. Your on-call team knows exactly which framework applies.

Practical CRA Art.10 Preparation Checklist

Regardless of hosting provider, these steps reduce Art.10 risk:

1. Map your PDE perimeter now Identify every product or component you place on the EU market. Each is a separate Art.10 obligation source. Include: SaaS tiers, APIs, SDKs, libraries, CLI tools, and firmware.

2. Integrate ENISA's EUVDB reporter into your incident runbook ENISA will publish the submission endpoint before September 2026. Pre-register your organisation. Many vulnerability notification systems (Snyk, GitHub Security Advisories, OSV) will add EUVDB integration — follow their release notes.

3. Set your 24-hour clock trigger Define exactly what constitutes "awareness of active exploitation" in your incident classification system. Document it. Train your SOC. The timestamp must be defensible to a regulator.

4. Prepare your Early Warning template Art.10 reports need: product name + version, CVE ID or internal reference, description of exploitation, affected systems, mitigation status, and contact information. Pre-populate the static fields.

5. Audit your vendor's CRA posture Ask your PaaS provider: (a) Are they registering as a manufacturer under CRA? (b) What is their Art.10 notification SLA? (c) Do they have a CLOUD Act response policy that triggers notification to customers? The answers reveal your actual risk profile.

6. Consider EU-native infrastructure for the highest-sensitivity workloads Critical components — authentication systems, payment processors, health data handlers — generate the highest-consequence Art.10 reports. Removing the CLOUD Act variable from these workloads is the lowest-effort, highest-certainty risk reduction available.

CRA Timeline Reference

The 11 September 2026 date is firm. It cannot be extended by individual member states, and it applies to all products placed on the EU market by that date — there is no grace period for existing products already in use.

What sota.io Does Differently

sota.io is incorporated under German law, operates exclusively on Hetzner Germany infrastructure (GDPR-compliant EU data centre, no US parent), and has no US subsidiaries or legal entities. Under CRA's jurisdictional framework, data processed through sota.io's management plane is subject to EU law exclusively.

For SaaS teams building products that will face Art.10 obligations, this means:

• Your deployment infrastructure contributes zero CLOUD Act surface area to your incident response
• Log data, container images, and runtime telemetry for CRA-covered products stay in EU judicial reach
• No parallel US federal production order risk during the 24-hour ENISA reporting window

If you're evaluating your CRA Art.10 preparation and infrastructure stack is on the list — try sota.io free for 14 days and see how EU-native managed PaaS simplifies your compliance architecture.

Further Reading

• EU Cyber Resilience Act full text (Regulation 2024/2847)
• ENISA CRA guidance and EUVDB information
• NIS2 Directive Art.23 — reporting timelines for significant incidents
• CRA Art.13 — coordinated vulnerability disclosure (9-month process)
• sota.io: GDPR Art.32 security measures for EU-hosted deployments