CRA September 2026: Vulnerability Reporting Deadline & der CLOUD Act Zielkonflikt

Am 11. September 2026 werden die Vulnerability-Reporting-Anforderungen der EU Cyber Resilience Act (CRA) rechtsverbindlich. Das betrifft jeden Anbieter von Produkten und Diensten in der EU — keine Ausnahmen, auch nicht für kleine Teams oder MVP-Startups.

Aber hier ist das Problem: Wenn deine Applikation auf US-basiertem Cloud-Provider läuft (Fly.io, Render, Railway), gibt es einen Zielkonflikt zwischen europäischen und amerikanischen Gesetzen, den du nicht allein durch besseres Engineering lösen kannst.

Die Fristen: 3 kaskadierte Anforderungen

Die CRA (Regulation EU 2024/2847) definiert gestaffelte Reporting-Fristen für aktiv ausgebeutete Schwachstellen:

Die entscheidende Nuance: Die 24-Stunden-Uhr startet, wenn DU herausfindest, dass eine Schwachstelle aktiv ausgenutzt wird — nicht erst, wenn ein Patch verfügbar ist.

Alle Reports gehen an die ENISA Single Reporting Platform (SRP) und werden an die zuständigen Cybersecurity-Behörden des Mitgliedstaats (CSIRT) weitergeleitet — unabhängig davon, wo deine Server physisch stehen.

Die Jurisdiktion: Wo deine Meldung hingeht

Das ist simpler als gedacht:

• Bist du als Unternehmen in der EU registriert → Meldung an die EU-CSIRT deines Landes
• Verkaufst du als Nicht-EU-Firma in die EU → trotzdem meldepflichtig an die EU, auch ohne lokale Registrierung

Das heißt: Du kannst ein US-Startup sein, auf Fly.io hosten (Delaware), aber sobald deine SaaS EU-Kunden hat, greift die CRA.

Das Problem: Der CLOUD Act Zielkonflikt

Hier wird es kritisch. Der US CLOUD Act (2018, 18 USC § 2705) erlaubt der US-Regierung, direkt auf Daten bei US-Cloud-Providern zuzugreifen — ohne dass der Provider dir oder deinen Kunden Bescheid sagen darf.

Die relevante Bestimmung: Gag Orders. Der FBI/NSA kann eine "stumme Subpoena" erlassen ("Zugriff auf Logs, Sicherheitsmeldungen, Forensik-Daten — aber sag niemandem, dass wir es tun").

Konkrete Szenarien:

Szenario A: Du hostst auf Fly.io, entdeckst eine Schwachstelle

1. 12:00 UTC: Du findest einen aktiven Exploit in deiner Application
2. 12:15 UTC: Du startest Incident-Response, dokumentierst technische Details
3. 12:30 UTC: Du stellst der Öffentlichkeit (deinen Kunden) einen Security-Alert bereit
4. 23:00 UTC: Du reichst einen Incident-Report bei ENISA ein — authentisch, vollständig, gewissenhaft
5. Nächste Woche: Der FBI erteilt eine GovGag-Order an Fly.io — Zugriff auf deine Incident-Logs + Kundendaten, Fly.io darf es dir nicht sagen
6. Resultat: Dein CRA-Report wird faktisch falsch. Du hast der ENISA einen Report eingereicht, der nicht alle relevanten Fakten enthält, die die US-Behörden inzwischen kennen. Das ist Compliance-Bruch, aber du weißt nicht, wie du ihn vermeiden kannst.

Szenario B: Du hostst auf Hetzner (Deutschland)

1-4. Identisch 5. Nächste Woche: Hetzner unterliegt deutschem Datenschutzrecht, nicht dem CLOUD Act. Regierungszugriff verläuft über legale Kanäle (NDB, offene Anordnung). 6. Resultat: Dein CRA-Report ist ehrlich und vollständig.

Das Kernproblem für Compliance-Teams

Standard-Lösungen (Cloud Act Supplements, SCCs, Standard Contractual Clauses) adressieren GDPR-Compliance — Datenschutz, Rechte der Betroffenen. Sie schreiben nicht vor, wie Regierungszugriffe offengelegt werden müssen, und sie übertrumpfen nicht das US-Bundesrecht.

Der CLOUD Act ist älter und superordiniert vs. GDPR-Abkommen.

Drei Strategien für Entwickler

Wenn du diese Risikokaskade ernst nimmst, sind deine Optionen:

1. EU-Native Infrastructure (sicherste Option)

• Hetzner Cloud (Deutschland, privat)
• OVHcloud (Frankreich)
• Scaleway (Frankreich, Iliad-Gruppe)
• Exoscale (Schweiz)
• Rechtsvorteil: Unterliegt EU/EWR-Datenschutz, nicht CLOUD Act

2. Hybrid mit Data Residency (Mittelweg)

• Nutze Railway/Render/Fly.io, aber lagere Kundendaten aus (separate EU-DB, z.B. Supabase mit EU-Hosting)
• CRA-Reports + Incident-Daten → EU-Speicher, nur Application-Logs auf US-Provider
• Funktioniert, kompliziert im Betrieb

3. Transparenz + Planning (für Status quo)

• Dokumentiere explizit in deiner Datenschutzerklärung + Incident-Playbook: "Wir nutzen US-Provider, unterliegen CLOUD Act"
• Definiere einen Eskalationspfad für deinen Legal-Team, falls ein GovGag eintritt
• Keine Lösung für den Zielkonflikt, aber ehrlich

Bottom Line

Der CRA-Deadline (11. September 2026) wird nicht verschoben. Die Fristen sind hart. Und wenn du heute auf US-Providern baust, sollte die Wahl eines EU-Cloud-Anbieters jetzt auf der Roadmap stehen — nicht erst nach einem Incident.

Sota.io läuft auf Hetzner-Infrastruktur (eu.objects.githubusercontent.com, EU-region-locked). Das ist nicht Eigenreklame, sondern eine Design-Entscheidung mit Compliance-Konsequenzen.

Für deine SaaS: Die einfachste Antwort auf die CRA ist, von Anfang an auf EU-native Infrastructure zu setzen.

Quellen

• EUR-Lex Cyber Resilience Act: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• ENISA Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
• EU Digital Strategy / CRA Compliance: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Crowell & Moring: CRA Vulnerability Deadline: https://www.crowell.com/en/insights/client-alerts/eu-cyber-resilience-act-countdown-11-september-2026-incidentvulnerability-reporting-deadline
• Kiteworks: CLOUD Act & EU Data Protection: https://www.kiteworks.com/gdpr-compliance/cloud-act-european-data-protection/
• Synopsys Black Duck: CRA Reporting Requirements: https://www.blackduck.com/solutions/eu-cyber-resilience-act-compliance/cra-vulnerability-reporting-requirements.html