CRA Art.14 Coordinated Vulnerability Disclosure 2026: The 9-Month CVD Window and Why Your Hosting Jurisdiction Determines Your Risk

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

The EU Cyber Resilience Act (CRA) enters full force on 11 September 2026. While most compliance discussions focus on Article 10's 24-hour ENISA reporting requirements for actively exploited vulnerabilities, Article 14 creates a longer, more nuanced obligation: coordinated vulnerability disclosure (CVD) through ENISA's European vulnerability database (EUVDB).

Here is the problem most EU SaaS developers haven't considered: the CVD coordination window — which can stretch from 90 days to 9 months — is precisely the period when vulnerability data stored on US-owned infrastructure faces maximum CLOUD Act exposure. If you're on AWS, Azure, Google Cloud, or a US-headquartered PaaS, your vulnerability coordination data can be compelled by US law enforcement during the exact window you're trying to keep the information confidential.

What CRA Article 14 Actually Requires

CRA Article 14 establishes the coordinated vulnerability disclosure framework for products with digital elements (PDE) sold in the EU market. The key obligations:

1. Manufacturers must have a published CVD policy Your security policy must describe how security researchers can report vulnerabilities, how you'll acknowledge reports, and your expected timeline to remediation and disclosure.

2. Vulnerabilities must be reported to ENISA's EUVDB after remediation Once you've fixed a vulnerability, you must report it to the European vulnerability database (EUVDB) operated by ENISA. This is separate from the Art.10 24-hour reporting for actively exploited vulnerabilities.

3. The disclosure coordination window Between initial report and public disclosure, you have a coordination period to:

• Verify the vulnerability
• Develop and test a patch
• Coordinate with downstream vendors and component suppliers
• Prepare user notifications
• Submit to EUVDB

This window ranges from 90 days for standard vulnerabilities (aligned with Google Project Zero's responsible disclosure standard) to 9 months for complex supply-chain vulnerabilities where multiple vendors must coordinate.

4. Open-source component obligations If your PDE incorporates open-source components (virtually all SaaS products do), you must coordinate with the relevant open-source security contacts through ENISA's coordinated disclosure mechanism.

The 9-Month CVD Window: Your Most Exposed Period

During the CVD coordination window, the following data sits in your systems:

• The vulnerability report from the security researcher
• Your internal analysis and severity assessment
• Patch development branches and commits (often in draft/private mode)
• Coordination emails with other affected vendors
• ENISA pre-notification drafts
• Internal workaround documentation

This is high-value intelligence — knowledge of an unpatched vulnerability before public disclosure. And if that data lives on US-owned infrastructure, it's governed by the CLOUD Act.

The CLOUD Act Problem During CVD Coordination

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. § 2713) requires US-based cloud providers to produce data in response to US law enforcement orders — regardless of where the data is physically stored.

During a CVD coordination window, the following scenarios create real risk:

Scenario 1: US Law Enforcement Compels Your Vendor

If you're using AWS, Azure, Google Cloud, or a US-headquartered PaaS, US law enforcement can issue a § 2703 order to your cloud provider. Your provider must comply — without being able to notify you in most national security cases.

The result: US law enforcement learns about an unpatched vulnerability in your product, potentially before you've issued a patch or coordinated with affected users. This breaks the CVD coordination chain and may trigger premature public awareness before defenders have time to patch.

Scenario 2: Your Vendor Becomes a Target

If your cloud vendor itself is under investigation and has data compelled, your vulnerability coordination data could become collateral disclosure — reaching parties you never intended to inform during the coordination window.

Scenario 3: The Dual Compliance Burden

Under Art.13 of the CRA (the 24-hour/72-hour reporting regime for actively exploited vulnerabilities), you already face your own reporting obligations to ENISA. If you're on US-owned infrastructure, you simultaneously face:

1. Your CRA Art.13 obligation: Report to ENISA within 24 hours of becoming aware of active exploitation
2. Your vendor's CLOUD Act exposure: Vulnerability data on US servers available to US law enforcement without EU oversight

These two obligations exist in different legal frameworks with different disclosure triggers — creating a compliance gap that EU-native hosting eliminates entirely.

The EUVDB Reporting Process

ENISA operates the European Vulnerability Database (EUVDB) as the central repository for CRA-mandated vulnerability disclosures. The submission process:

Step 1: Pre-notification (optional but recommended) Before patching, notify ENISA's CERT-EU coordination team that you're working on a vulnerability. This establishes your coordination timeline and protects you from allegations of delayed disclosure.

Step 2: Coordinated vendor notification For vulnerabilities affecting multiple products or open-source components, ENISA coordinates notification through established CERT networks. This is where the 9-month window applies for complex supply-chain issues.

Step 3: Patch development and testing Your development team works on the fix. During this period, vulnerability details exist in your issue tracker, code repositories, and internal communication systems.

Step 4: EUVDB submission after patch Once you've released the patch, you submit the full vulnerability disclosure to EUVDB within the statutory timeframe.

Step 5: Public disclosure ENISA publishes the vulnerability to the European vulnerability database, synchronized with your patch release.

The gap between Step 2 and Step 5 is where CLOUD Act exposure is highest. All the coordination data in Steps 2-4 lives in your infrastructure — and if that infrastructure is US-owned, it's governed by US law.

Comparing Hosting Jurisdictions During CVD Windows

The Open-Source Component Amplifier

Most EU SaaS products include significant open-source dependencies. CRA Art.14 extends disclosure obligations to these components through the "open-source software steward" concept.

Under the CRA framework:

• If you distribute a PDE that incorporates a vulnerability in an open-source component, you must coordinate disclosure with the open-source project's security team
• ENISA coordinates this through established CVD channels
• The coordination window for supply-chain vulnerabilities affecting multiple downstream products is where the 9-month maximum applies

The US-PaaS problem amplifies here: if your development environment, build pipelines, and issue trackers are on US-owned platforms, your coordination with open-source security teams — emails, draft patches, vulnerability descriptions — all passes through US-governed infrastructure during the coordination window.

For a typical modern SaaS product with 200+ npm or PyPI dependencies, this isn't a theoretical risk. It's the daily reality of open-source security maintenance.

The Penalty Framework Context

CRA non-compliance carries penalties up to €15 million or 2.5% of global annual turnover, whichever is higher (CRA Art.64). The penalty framework specifically identifies:

• Failure to implement a CVD policy (Art.14)
• Failure to report to EUVDB after remediation
• Failure to coordinate with ENISA for multi-vendor vulnerabilities

Regulators will also examine structural compliance — whether your infrastructure enables compliance or creates systematic gaps. Running your CVD coordination on US-owned infrastructure when a CLOUD Act compulsion could break your coordination window is a structural gap that EU data protection authorities will scrutinize.

CRA Art.14 CVD Compliance Checklist

Immediate Actions (Before 11 September 2026)

• Publish a CVD policy: Define how researchers report vulnerabilities, response SLAs, and disclosure timeline
• Register with EUVDB: Create your manufacturer profile in ENISA's European vulnerability database
• Map your PDE perimeter: Which of your products qualify as "products with digital elements" under CRA?
• Inventory your open-source dependencies: Which components would require multi-vendor coordination?
• Assess your infrastructure jurisdiction: Where does CVD coordination data live during the disclosure window?

Infrastructure Review

• Issue tracker jurisdiction: Is your bug tracker (GitHub Issues, Jira, Linear) on US-owned infrastructure?
• Code repository: Is your private patch development happening in a US-governed repo?
• Internal communications: Does your CVD coordination use US-governed email/messaging (Gmail, Microsoft 365, Slack)?
• CI/CD pipeline: Does your build system that compiles and tests patches run on US-owned infrastructure?

EU-Native Migration Priority for CVD

If migrating all infrastructure to EU jurisdiction isn't immediately feasible, prioritize:

1. Issue tracker for security bugs: Move to EU-governed instance (GitLab EU-hosted, self-hosted on EU infrastructure)
2. Private patch repositories: Development branches for unpatched vulnerabilities should be EU-governed
3. Application hosting platform: Eliminate the US-parent PaaS nexus for production systems
4. Coordination communications: Avoid US-governed email for ENISA/CERT coordination

Why EU-Native PaaS Matters Specifically

A managed PaaS platform is where your application runs — and typically where your development CI/CD pipeline executes, your logs are generated, and your environment variables (including security tooling credentials) live.

For CRA Art.14 compliance, your PaaS platform's jurisdiction affects:

Source code exposure: If your PaaS provides Git integration or deployment from private repositories, and those repositories contain unpatched vulnerability fixes in development branches, the PaaS platform's CLOUD Act status affects whether US law enforcement can access those branches during the coordination window.

Log retention during vulnerability investigation: When analyzing a reported vulnerability, your application logs are critical. If those logs sit on a US-owned PaaS, they're governed by the CLOUD Act.

Environment configuration: Your security tooling credentials, ENISA API keys, and EUVDB authentication tokens — if stored as environment variables on a US-owned PaaS — are compellable.

Deployment pipeline: The CI/CD pipeline that tests your patch before release runs on your PaaS. The test results that confirm the fix is working without regression are part of your CVD evidence trail.

EU-native PaaS means this entire chain — source, build, test, deploy, log — stays under EU jurisdiction throughout the coordination window.

Series Navigation

This is Part 2 of the sota.io EU Cyber Resilience Act Compliance Series:

• Part 1: CRA Art.10 Vulnerability Reporting 2026: Why Your Hosting Jurisdiction Determines Your Compliance Burden
• Part 2: CRA Art.14 Coordinated Vulnerability Disclosure: The 9-Month CVD Window ← You are here
• Part 3: Coming soon — CRA Art.64 Penalty Framework: How Regulators Will Assess Structural Compliance

Conclusion: Jurisdiction Is CVD Infrastructure

CRA Art.14's coordinated vulnerability disclosure framework creates a 3-to-9-month window during which your most sensitive security data — unpatched vulnerability details, patch development branches, coordination emails — requires maximum confidentiality.

US-owned PaaS infrastructure creates a structural contradiction: you're trying to maintain CVD confidentiality under EU legal frameworks, while your data sits in systems governed by a US law that allows compulsion without EU court oversight.

EU-native hosting doesn't just help you check a compliance box. It eliminates the structural gap between your CRA Art.14 obligations and your infrastructure's legal jurisdiction — so your CVD coordination stays EU-governed from report intake through EUVDB publication.

CRA enters full force 11 September 2026. If you're evaluating EU-native PaaS alternatives before that deadline, sota.io runs entirely on Hetzner Germany — no US parent, no CLOUD Act exposure, single EU jurisdiction for your entire application stack.