Der Countdown läuft bereits
Der EU Cyber Resilience Act (CRA) ist kein regulatorischer Horizont mehr — er ist ein Countdown. Am 11. September 2026 tritt die erste verbindliche Frist des CRA in Kraft: Hersteller und Entwickler von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen an die ENISA und nationale CSIRTs melden. Das sind 77 Tage ab heute.
Wenn Ihr Unternehmen Software entwickelt, vernetzte Hardware vertreibt oder digitale Komponenten Dritter in Produkte integriert, die auf EU-Märkten vertrieben werden, gilt diese Frist für Sie. Der CRA führt Verpflichtungen ein, die Ihre Entwicklungs-Pipeline, Ihre Lieferantenbeziehungen, Ihren Incident-Response-Prozess und Ihre Unternehmensführung betreffen.
Dieser Leitfaden erläutert, was die September-Frist verlangt, wer im Geltungsbereich liegt, welche Sanktionen gelten und welche praktischen Schritte jetzt ergriffen werden sollten — bevor Regulierungsbehörden Fragen stellen.
Was ist der EU Cyber Resilience Act?
Der CRA trat im Dezember 2024 in Kraft, nach Jahren gesetzgeberischer Arbeit, ausgelöst durch eine Serie von Vorfällen — SolarWinds, Log4Shell, MOVEit — die das systemische Risiko unsicherer Software-Lieferketten aufgezeigt haben. Im Gegensatz zur DSGVO (die Daten regelt) oder NIS2 (die den Betrieb regelt) zielt der CRA auf die Produkte selbst: Er legt verbindliche Cybersicherheitsanforderungen für jedes Produkt mit digitalen Elementen (PDE) fest, das auf dem EU-Markt bereitgestellt wird — und deckt den gesamten Produktlebenszyklus von der Entwicklung bis zur Außerbetriebnahme ab.
Das zentrale Prinzip des CRA ist Sicherheit als Standard: Produkte müssen sicher ausgeliefert werden, ohne dass der Kunde die Sicherheit separat konfigurieren muss. Dies verlagert die Verantwortung stromaufwärts — zu Entwicklern und Herstellern.
Wesentlicher Unterschied: Die DSGVO schützt Daten. NIS2 schützt den Betrieb. Der CRA schützt die Software- und Hardware-Produkte selbst — vom Moment ihrer Entwicklung bis zur Außerbetriebnahme.
Die Frist vom 11. September 2026: Was sich ändert
Der CRA wird stufenweise eingeführt. Der 11. September 2026 aktiviert die Schwachstellen-Meldepflichten — die operativ dringendste Anforderung für die meisten Unternehmen heute. Ab diesem Datum löst jede aktiv ausgenutzte Schwachstelle, die Ihr Produkt betrifft, eine strenge Meldekaskade aus.
| Frist |
Verpflichtung |
Empfänger |
| 24 Stunden |
Frühwarnung: Meldung, dass eine aktiv ausgenutzte Schwachstelle identifiziert wurde, mit erster Schweregradbewertung |
ENISA + nationales CSIRT |
| 72 Stunden |
Vollständige technische Meldung: betroffene Versionen, CVE-Referenz, Schweregrad-Score, erste Minderungsmaßnahmen |
ENISA + nationales CSIRT |
| 14 Tage nach dem Patch |
Abschlussbericht: umfassende Remediierungs-Zusammenfassung, Grundursache, Verfügbarkeit des Patches und Empfehlungen für betroffene Nutzer |
ENISA + nationales CSIRT |
Zwei Aspekte dieses Zeitrahmens verdienen besondere Aufmerksamkeit. Erstens beginnt das 24-Stunden-Fenster ab dem Moment, in dem Ihr Unternehmen Kenntnis erlangt von der aktiven Ausnutzung — nicht ab der CVE-Zuweisung oder öffentlichen Offenlegung. Bedrohungserkennung und interne Alarmierung werden damit direkte Compliance-Kontrollen. Erkennungsverzögerungen bedeuten rechtliche Exposition.
Zweitens gilt dies für jede aktiv ausgenutzte Schwachstelle — ohne Schweregradgrenze. Ein niedrigschwerer Bug, der aktiv ausgenutzt wird, muss innerhalb von 24 Stunden gemeldet werden. Eine kritische Schwachstelle, die noch nicht ausgenutzt wird, startet die Uhr nicht. Auslöser ist die Ausnutzung, nicht der Schweregrad.
Wer liegt im Geltungsbereich?
Der Geltungsbereich des CRA ist bewusst weit gefasst. Folgende Kategorien von Unternehmen sind direkt betroffen:
Hersteller
Jedes Unternehmen, das Produkte mit digitalen Elementen entwirft, entwickelt oder herstellt und auf dem EU-Markt bereitstellt. Dazu gehören Unternehmenssoftware, Verbraucheranwendungen, vernetzte Hardware, industrielle Steuerungssysteme, eingebettete Firmware und Netzwerkgeräte.
Software-as-a-Service-Anbieter
Der CRA adressiert explizit digital bereitgestellte Produkte. SaaS-Anbieter fallen in den Geltungsbereich, wenn ihre Dienste Komponenten umfassen, die als Produkte mit digitalen Elementen qualifizieren — insbesondere wenn diese Komponenten auf Kundensystemen heruntergeladen, installiert oder aktualisiert werden können. Desktop-Agents, mobile Anwendungen, On-Premise-Konnektoren oder SDKs fallen unter den CRA-Rahmen.
Importeure und Händler
Unternehmen, die Produkte mit digitalen Elementen in EU-Märkte importieren oder vertreiben, müssen verifizieren, dass die Hersteller CRA-Anforderungen erfüllt haben. Wenn ein Hersteller dies versäumt, tragen Händler und Importeure Restpflichten.
Open-Source-Projekte
Rein gemeinnützige Open-Source-Projekte ohne kommerzielle Aktivitäten sind generell ausgenommen. Wenn Ihr Unternehmen jedoch Open-Source-Software kommerzialisiert — durch Support-Verträge, gehostete Dienste, integrierte Produkte oder auf Open-Source aufbauende SaaS-Angebote — sind Sie nicht ausgenommen.
Praktischer Test: Wenn Ihr Unternehmen mit einem Produkt, das digitale Elemente enthält oder darauf aufgebaut ist, Einnahmen generiert und dieses Produkt EU-Kunden zugänglich ist, gilt der CRA.
Die Anforderungen ab Dezember 2027: Langfristig planen
Der 11. September 2026 ist die erste Welle. Das volle Gewicht der CRA-Verpflichtungen tritt ab dem 11. Dezember 2027 in Kraft. Die 18 Monate zwischen den beiden Fristen sollten für die strukturell komplexeren Anforderungen genutzt werden.
Software-Stückliste (SBOM)
Hersteller müssen eine maschinenlesbare Inventarliste aller Softwarekomponenten, Bibliotheken, Abhängigkeiten und Versionen in ihren Produkten erstellen und bereitstellen. Die SBOM muss über die gesamte unterstützte Lebensdauer des Produkts aktuell gehalten werden.
Sicherheit durch Design
Produkte müssen mit der minimal notwendigen Angriffsfläche, sicheren Standardkonfigurationen, geeigneten Zugangskontrollen, Verschlüsselung von Daten in Transit und im Ruhezustand sowie der Fähigkeit zur Entgegennahme von Sicherheitsupdates konzipiert werden.
Schwachstellen-Management-Programm
Hersteller müssen ein formales Schwachstellen-Management-Programm betreiben: Richtlinien zur Identifizierung, Bewertung und Behebung von Schwachstellen; koordinierte Offenlegungsverfahren; und Aufzeichnungen, die ein kontinuierliches Management über die Produktlebensdauer belegen.
Die Sanktionen: Was auf dem Spiel steht
Die Durchsetzungsmechanismen des CRA sind auf signifikante Wirkung ausgelegt:
- Bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes — bei Nichteinhaltung der wesentlichen Cybersicherheitsanforderungen oder Schwachstellen-Management-Pflichten
- Bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes — bei Versäumnis der Meldepflichten für aktiv ausgenutzte Schwachstellen
- Bis zu 5 Millionen Euro oder 1 % des weltweiten Jahresumsatzes — bei Bereitstellung falscher oder irreführender Informationen gegenüber Marktaufsichtsbehörden
Über finanzielle Sanktionen hinaus können nationale Marktaufsichtsbehörden den Rückzug oder Rückruf nicht konformer Produkte aus EU-Märkten anordnen. Für Unternehmen, deren Umsatz vom EU-Marktzugang abhängt, ist dies ein existenzielles Geschäftskontinuitätsrisiko.
Governance-Implikation: Wie bei NIS2 und DORA können CRA-Verstöße die Prüfung von Führungsentscheidungen auslösen. Vorstände sollten CRA-Compliance als treuhänderische Pflicht behandeln, nicht als technisches Problem.
Der CRA im breiteren regulatorischen Kontext
Der CRA existiert nicht isoliert. Er ist eines von drei großen digitalen EU-Regelwerken, die 2026 in die aktive Durchsetzungsphase eintreten, neben NIS2 (das bereits Verwaltungssanktionen verhängt) und DORA (das seit dem 17. Januar 2025 für den Finanzsektor gilt). Ein einzelner Vorfall kann gleichzeitig Pflichten unter mehreren Rahmenwerken auslösen.
- Dieselben nationalen CSIRTs empfangen sowohl CRA-Schwachstellenmeldungen als auch NIS2-Vorfallsmeldungen. Für Unternehmen im Geltungsbereich beider Rahmenwerke könnte dasselbe Ausnutzungsereignis parallele Meldefristen auslösen.
- Die ICT-Drittanbieter-Risikomanagement-Anforderungen von DORA verpflichten Finanzunternehmen, den CRA-Compliance-Status ihrer Lieferanten zu bewerten. Wenn Sie Software oder Technologiedienstleistungen an Finanzsektor-Kunden liefern, ist Ihre CRA-Reife nun Teil ihrer DORA-Lieferanten-Due-Diligence.
- Die Cybersicherheitsanforderungen des EU-KI-Gesetzes für Hochrisiko-KI-Systeme referenzieren die wesentlichen CRA-Anforderungen. Ein KI-Produkt, das die CRA-Konformität nicht erfüllt, könnte auch die KI-Gesetz-Konformität verfehlen.
Ihre CRA-Bereitschafts-Checkliste in 10 Schritten
- Geltungsbereichserfassung. Kartieren Sie jedes Produkt, das Ihr Unternehmen entwirft, entwickelt, importiert oder vertreibt und das als Produkt mit digitalen Elementen qualifizieren könnte. Schließen Sie vernetzte Hardware, Software, eingebettete Systeme, SDKs und SaaS-Komponenten ein, die auf Kundensystemen installiert werden.
- Bedrohungserkennung und Alarmierung. Implementieren oder stärken Sie die Überwachung zur Erkennung aktiver Ausnutzung bekannter Schwachstellen in Ihren Produkten. Das 24-Stunden-Melde-Fenster beginnt, sobald Sie Kenntnis von der Ausnutzung erlangen — Ihre Erkennungsinfrastruktur ist daher eine Compliance-Kontrolle.
- CSIRT-Registrierung und Kontakte. Identifizieren und dokumentieren Sie formell die nationalen CSIRT- und ENISA-Meldestellen für jede Jurisdiktion, in der Ihre Produkte vermarktet werden. In Luxemburg ist dies das CIRCL (Computer Incident Response Center Luxembourg).
- Aktualisierung des Incident-Response-Plans. Überarbeiten Sie Ihre Incident-Response-Verfahren um CRA-Meldeschritte. Legen Sie fest, wer die 24-Stunden-Frühwarnung auslöst, wer die 72-Stunden-Meldung genehmigt und wer den 14-Tage-Abschlussbericht unterzeichnet.
- Komponenteninventar. Beginnen Sie mit der Katalogisierung aller Softwarekomponenten, Bibliotheken und Abhängigkeiten in Ihren Produkten. Dies ist die Grundlage Ihrer SBOM.
- Überprüfung von Lieferantenverträgen. Überprüfen Sie Verträge mit allen Software- und Technologielieferanten, deren Komponenten in Ihren Produkten erscheinen. Fügen Sie CRA-konforme Klauseln hinzu, die eine zeitnahe Schwachstellenoffenlegung und Verpflichtungen zu Patching-Fristen erfordern.
- Technische Dokumentation aufbauen. Beginnen Sie mit der Zusammenstellung der vom CRA geforderten technischen Dokumentation: Architekturbeschreibungen, Bedrohungsmodelle, Sicherheitstestergebnisse und Schwachstellen-Management-Aufzeichnungen.
- Formalisierung des Schwachstellen-Management-Programms. Etablieren oder formalisieren Sie Ihre Schwachstellen-Management-Richtlinie mit klaren Erkennungsprozessen, Triage, Remediierungsfristen und koordinierten Offenlegungsverfahren.
- SBOM-Tool-Auswahl und Pilotierung. Evaluieren Sie SBOM-Erstellungs- und -Verwaltungstools für Ihren Technologie-Stack. Pilotieren Sie die Integration in die CI/CD-Pipeline mindestens eines Produkts bis Jahresende.
- Schulung von Entwicklern und Führungskräften. Stellen Sie sicher, dass Entwicklungsteams Secure-by-Design-Prinzipien verstehen und dass Führungskräfte den regulatorischen Rahmen und die persönlichen Haftungsdimensionen kennen.
Wie ObsidianCorps helfen kann
Unsere Teams begleiten Unternehmen in Luxemburg und der Großregion bei regulatorischen Compliance-Programmen seit dem Inkrafttreten von NIS2. CRA-Bereitschaft ist eine natürliche Erweiterung dieser Arbeit — und für viele unserer Kunden sind die Grundlagen bereits teilweise vorhanden.
So können wir Ihr Programm vor dem 11. September beschleunigen:
- CRA-Geltungsbereichserfassung und Gap-Analyse. Wir prüfen Ihr Produktportfolio, Ihre Entwicklungspraktiken, Lieferantenbeziehungen und aktuelle Sicherheitsdokumentation gegen CRA-Anforderungen und erstellen einen priorisierten Bereitschaftsbericht.
- Design des Schwachstellen-Management-Programms. Wir helfen Ihnen, die Richtlinien, Prozesse und Tools für Schwachstellenerkennung, Triage, Offenlegung und Meldung aufzubauen oder zu formalisieren — einschließlich Integration mit CSIRT-Melde-Workflows.
- Penetrationstests und Sicherheitsvalidierung. Unabhängige Sicherheitstests Ihrer Produkte liefern sowohl die technischen Nachweise für die Konformitätsdokumentation als auch frühzeitige Einblicke in Schwachstellen.
- SBOM-Implementierung und DevSecOps-Integration. Unsere Software-Entwicklungs- und DevSecOps-Teams helfen, SBOM-Generierung in Ihre CI/CD-Pipeline zu integrieren.
- Technische Dokumentationsvorbereitung. Wir helfen bei der Zusammenstellung der Architekturbeschreibungen, Bedrohungsmodelle und Sicherheitsaufzeichnungen, die für die CRA-Konformitätsbewertung erforderlich sind.
- Entwickler- und Führungskräfteschulung. Wir bieten Schulungsprogramme an, die auf CRA-Pflichten für technische Teams und Führungsebene zugeschnitten sind, einschließlich Tischübungen zur Simulation eines Schwachstellen-Offenlegungs-Szenarios unter CRA-Melde-Fristen.
Wenn Sie unsicher sind, ob Ihre Produkte im Geltungsbereich liegen, oder wenn Sie eine Lücke identifiziert haben und diese vor dem 11. September schließen müssen, bieten wir ein kostenloses Erstgespräch an. 77 Tage reichen für bedeutsamen Fortschritt — aber nicht, um Zeit zu verschwenden.
Kontaktieren Sie ObsidianCorps für Ihre CRA-Bereitschaftsbewertung.
