Der Cyber Resilience Act: Meldepflicht seit dem 11. September 2026

Die meisten EU-Verordnungen geben Ihnen ein Datum und eine Schonfrist, in der sich alle in Ruhe organisieren. Der Cyber Resilience Act macht etwas anderes. Seine erste harte Pflicht ist eine 24-Stunden-Meldeuhr, und sie läuft seit dem 11. September 2026.

Eine 24-Stunden-Uhr lässt sich nicht schrittweise einführen. Entweder steht der Prozess, wenn eine ausgenutzte Schwachstelle auftaucht, oder Sie verfehlen die Frist.

Was der CRA ist

Die Verordnung (EU) 2024/2847 legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem EU-Markt bereitgestellt werden. Dieser Begriff erfasst weit mehr, als man zunächst annimmt: jedes Software- oder Hardwareprodukt und die zugehörigen Fernverarbeitungslösungen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung einschließt.

Vernetzte Geräte sind erfasst. Ebenso die meiste kommerzielle Software, Betriebssysteme, Browser, mobile Apps, Firmware und die Komponenten in anderen Produkten.

Die Verordnung wurde im November 2024 veröffentlicht und gilt gestaffelt:

• 11. Juni 2026: Pflichten für Konformitätsbewertungsstellen.
• 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.
• 11. Dezember 2027: volle Anwendung, einschließlich wesentlicher Cybersicherheitsanforderungen, CE-Kennzeichnung, technischer Dokumentation und Software-Stückliste.

Das mittlere Datum gilt bereits, und es hängt von Fähigkeiten ab, die Sie möglicherweise nicht haben.

Was seit dem 11. September 2026 gilt

Seit diesem Datum müssen Hersteller melden:

Aktiv ausgenutzte Schwachstellen in ihren Produkten mit digitalen Elementen und

schwerwiegende Sicherheitsvorfälle, die die Sicherheit dieser Produkte betreffen.

Die Meldung läuft über die zentrale CRA-Meldeplattform, betrieben von der ENISA, an das im Mitgliedstaat der Hauptniederlassung des Herstellers benannte CSIRT, das dann an weitere betroffene CSIRTs und die ENISA weitergibt. Die ENISA hat am 11. September 2026, dem Tag, an dem die Pflicht begann, eine erste Version der Plattform in Betrieb genommen und will in den kommenden Monaten weitere Funktionen ergänzen.

Der Zeitplan:

• Innerhalb von 24 Stunden nach Kenntniserlangung: eine Frühwarnung.
• Innerhalb von 72 Stunden: eine vollständige Meldung einschließlich getroffener Korrektur- oder Abhilfemaßnahmen.
• Innerhalb von 14 Tagen, nachdem eine Korrekturmaßnahme verfügbar ist: ein Abschlussbericht für eine aktiv ausgenutzte Schwachstelle.
• Innerhalb eines Monats: ein Abschlussbericht für einen schwerwiegenden Sicherheitsvorfall.

Vierundzwanzig Stunden ab Kenntnis, nicht ab Bestätigung, nicht ab Behebung. Wenn eine Schwachstelle in einer Komponente Ihres Produkts an einem Samstag in freier Wildbahn ausgenutzt wird, läuft die Uhr am Samstag.

Warum das schwerer ist, als es aussieht

Die Meldepflicht selbst ist ein Formular. Die Schwierigkeit liegt in allem, was vorher vorhanden sein muss.

Sie müssen wissen, was in Ihrem Produkt steckt

Um zu melden, dass eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird, müssen Sie wissen, dass die verwundbare Komponente in Ihrem Produkt ist. Für eine moderne Anwendung mit hunderten transitiven Abhängigkeiten kann das kein Mensch aus dem Gedächtnis beantworten.

Deshalb bauen Teams jetzt Pipelines für Software-Stücklisten, mehr als ein Jahr vor der formalen SBOM-Anforderung im Dezember 2027. Die SBOM ist nicht das Ziel. Das Ziel ist, die Frage "Sind wir betroffen?" innerhalb von Stunden beantworten zu können, und die SBOM macht sie beantwortbar.

Unangenehm daran ist, dass das auch für Produkte gilt, die Sie vor Jahren ausgeliefert haben. Wenn Sie unterstützte Geräte im Feld haben, die Firmware von 2022 aus einem Abhängigkeitsbaum ausführen, den niemand festgehalten hat, ist die Rekonstruktion echte Arbeit.

Sie müssen hinsehen

Kenntnis startet die Uhr, und Kenntnis wird als aktiv statt zufällig erwartet. Das bedeutet, Schwachstellen-Feeds zu beobachten, Advisories für Ihre Komponenten zu abonnieren, Kataloge bekannter ausgenutzter Schwachstellen zu verfolgen und einen Kanal zu haben, über den Sicherheitsforscher Sie erreichen und eine Antwort bekommen.

Sie brauchen einen Entscheidungsweg

Jemand muss zu jeder Stunde entscheiden können, ob ein Vorfall die Schwelle erreicht und ob die Uhr läuft. Ohne benannte Rolle und Eskalationspfad gehen die ersten Stunden dafür drauf, herauszufinden, wer die Entscheidung treffen darf.

End-of-Life-Abhängigkeiten werden zur Haftung

Wenn eine Komponente in Ihrem Produkt keine Sicherheitsupdates mehr erhält, tragen Sie die Meldepflicht bei Ausnutzung trotzdem, und es gibt keinen Upstream-Fix, auf den Sie zeigen können. Eine Prüfung auf End-of-Life-Abhängigkeiten gehört zu den nützlicheren Dingen, die jetzt anstehen, weil die Antwort manchmal eine Migration erzwingt, die selbst Vorlauf braucht.

Was die volle Anwendung im Dezember 2027 bringt

Die Pflichten ab Dezember 2027 sind das größere Programm und müssen lange vorher beginnen.

Sicher durch Design und Voreinstellung. Produkte müssen so entworfen, entwickelt und hergestellt werden, dass ein risikoangemessenes Cybersicherheitsniveau gewährleistet ist. Keine Standardpasswörter. Sichere Konfiguration ab Werk. Minimierung der Angriffsfläche. Schutz von Daten bei der Übertragung und im Ruhezustand.

Umgang mit Schwachstellen. Ein dokumentierter Prozess für Identifikation, Behebung, Test, Verteilung und Offenlegung. Sicherheitsupdates müssen unverzüglich und kostenlos bereitgestellt werden, für einen Unterstützungszeitraum, der die erwartete Produktlebensdauer widerspiegelt, wobei fünf Jahre eine gängige Bezugsgröße sind.

Software-Stückliste. In maschinenlesbarem Format, mindestens die Abhängigkeiten der obersten Ebene abdeckend, und aktuell gehalten.

Technische Dokumentation und Konformitätsbewertung. Die meisten Produkte bewerten sich selbst. Wichtige und kritische Kategorien, darunter etwa Passwortmanager, VPNs, Betriebssysteme und industrielle Steuerungssysteme, erfordern die Einbindung Dritter.

CE-Kennzeichnung. Das digitale Gegenstück zur physischen Kennzeichnung, mit der Sie die Konformität erklären.

Politik zur koordinierten Offenlegung von Schwachstellen. Veröffentlicht, mit einem funktionierenden Kontaktpunkt.

Wer tatsächlich erfasst ist

Ein paar Grenzfälle tauchen ständig auf.

Freie und quelloffene Software, die außerhalb einer kommerziellen Tätigkeit entwickelt wird, liegt weitgehend außerhalb. Die Verordnung führt die Figur des Open-Source-Software-Verwalters mit leichteren Pflichten ein. Wer Open Source aber kommerzialisiert oder in einem verkauften Produkt ausliefert, trägt die Produktpflichten.

Software as a Service liegt in der Regel außerhalb des CRA und fällt stattdessen unter NIS2, wobei Fernverarbeitungslösungen, die integraler Bestandteil eines Produkts mit digitalen Elementen sind, mit hineingezogen werden. Wenn Ihr Gerät zum Funktionieren auf Ihr Cloud-Backend angewiesen ist, reist dieses Backend mit dem Produkt.

Importeure und Händler tragen ebenfalls Pflichten. Wer ein Drittprodukt unter eigenem Namen oder eigener Marke auf den EU-Markt bringt, wird wie ein Hersteller behandelt.

Anderweitig regulierte Produkte, etwa Medizinprodukte, Fahrzeuge und Luftfahrtausrüstung, werden in ihren eigenen Rahmen behandelt.

Die Fragen zum Anwendungsbereich sind wirklich nicht trivial, und hier spart eine Stunde mit Juristen Monate fehlgeleiteter Entwicklung.

Was wir jetzt tun würden

Wenn Sie erfasst sind und jetzt beginnen, ist das die funktionierende Reihenfolge:

Erstens: Produktinventar aufbauen. Was haben Sie tatsächlich auf dem EU-Markt? Einschließlich alter Versionen im Feld, White-Label-Varianten und Produkten, die Sie für jemand anderen vertreiben. Diese Liste ist meist länger, als alle erwarten.

Zweitens: SBOM-Erzeugung in die CI einbauen. Bei jedem Build eine SBOM erzeugen, in CycloneDX oder SPDX, am Release-Artefakt speichern und abfragbar halten. Der Punkt ist, die Frage "Welche unserer ausgelieferten Releases enthalten diese Bibliothek?" in Minuten beantworten zu können.

Drittens: Schwachstellenüberwachung anschließen. Ihre SBOM-Daten in einen Scanner geben, der Advisories und Kataloge bekannter ausgenutzter Schwachstellen beobachtet, und Alarme in einen Kanal leiten, den jemand liest.

Viertens: das Incident-Runbook schreiben. Wer ruft aus, wer bewertet, wer meldet, wer kommuniziert. Benannte Personen, Vertretungen und Kontakte außerhalb der Geschäftszeiten. Dann einmal mit einem fiktiven Advisory üben. In der Übung merken Sie, dass die Person mit den Zugangsdaten für die Meldeplattform im Urlaub ist.

Fünftens: eine Politik zur Offenlegung von Schwachstellen veröffentlichen. Eine security.txt-Datei, eine betreute Adresse und eine genannte Reaktionszeit. Das ist ein Nachmittag Arbeit und der Unterschied dazwischen, ob Sie von einem Forscher oder von einer Journalistin von einem Problem erfahren.

Sechstens: mit der Arbeit für Dezember 2027 beginnen. Sichere Voreinstellungen, Update-Mechanismen, Entscheidungen zum Unterstützungszeitraum und Dokumentation sind Architekturfragen, kein Papierkram. Produkte, die Sie 2026 entwerfen, sind 2028 noch auf dem Markt.

Die Überschneidung, die niemand nutzt

Zwischen dem CRA und anderen Regimen gibt es erhebliche Doppelungen, und die meisten Unternehmen behandeln jedes getrennt, was Verschwendung ist.

Eine für den CRA gebaute SBOM beantwortet die meisten Lieferkettenfragen aus NIS2. Das Incident-Runbook überschneidet sich mit der 24-Stunden-Frühwarnung aus NIS2 und mit der 72-Stunden-Meldung nach der DSGVO. Prozesse zum Umgang mit Schwachstellen fließen direkt in Sicherheitsfragebögen von Kunden und in die Beschaffung von Großunternehmen.

Bauen Sie das einmal als Plattformfähigkeit. Die Alternative sind drei Teams, die drei Versionen desselben Asset-Inventars bauen.

Wo Sie Hilfe bekommen

Wir bauen und betreuen Software für Unternehmen, die in die EU verkaufen, und das heißt zunehmend, die Lieferkettentransparenz und Update-Infrastruktur zu bauen, die der CRA voraussetzt. Wenn Sie klären wollen, ob Sie erfasst sind, oder wenn die Meldepflicht Sie bereits trifft und nichts Ihre Komponenten überwacht, schreiben Sie an office@c9group.dev.

Unsere Wartung von Bestandssystemen ist oft der Ausgangspunkt, weil die Produkte mit der schlechtesten Abhängigkeitstransparenz meist die ältesten sind. Das größere regulatorische Bild steht in unserem Leitfaden zur EU-Digital-Compliance 2026.

Wir sind Ingenieure, keine Juristen. Entscheidungen über Anwendungsbereich und Einstufung gehören zu Ihren Juristen, und wir bauen zu der Antwort, die sie geben.