Cyber Resilience Act Fristen: die Termine

Die Cyber Resilience Act Fristen regeln den stufenweisen Beginn der europäischen Produktsicherheitsvorgaben. Die Meldepflicht nach Artikel 14 gilt seit 11. September 2026. Die meisten übrigen Pflichten gelten ab 11. Dezember 2027. Für die Planung brauchen Hersteller deshalb zwei parallele Arbeitsstränge: einen bereits nutzbaren Meldeprozess und die Vorbereitung des Produkts auf die weiteren Anforderungen.

Vier Daten mit unterschiedlicher Wirkung

Die Grundlage ist Artikel 71 der Verordnung (EU) 2024/2847. Die Übergangsphase setzt andere geltende Vorschriften nicht außer Kraft. Für Funkprodukte sind beispielsweise die gesonderten Cybersicherheitsanforderungen der Funkanlagenrichtlinie zu prüfen. Ein CRA-Projekt ersetzt diese Bewertung nicht. Planen Sie zusammengehörige Nachweise gemeinsam, halten Sie die jeweiligen Rechtsgrundlagen aber auseinander.

Die erste Uhr läuft ab Kenntnis

Eine aktiv ausgenutzte Schwachstelle kann eine Meldepflicht auslösen, während Ihr größeres Dokumentationsprojekt noch läuft. Der maßgebliche Zeitpunkt ist die Kenntnis des Herstellers vom relevanten Ereignis. Er verschiebt sich nicht auf die nächste Teambesprechung. Ein funktionierender Prozess erreicht deshalb eine verantwortliche Person und eine Vertretung auch bei Abwesenheit des üblichen Ansprechpartners.

Die Frühwarnung erfolgt unverzüglich, spätestens innerhalb von 24 Stunden ab Kenntnis. Die weitere Meldung erfolgt unverzüglich, spätestens innerhalb von 72 Stunden ab Kenntnis. Für Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme fällig. Bei schwerwiegenden Sicherheitsvorfällen ist es ein Monat nach der Meldung. Die beiden Abschlussfristen haben unterschiedliche Ausgangspunkte. Eine pauschale Frist von 14 Tagen für jeden Vorfall wäre falsch.

Vom Inverkehrbringen rückwärts planen

Der 11. Dezember 2027 ist kein sinnvoller Starttermin für die erste technische Prüfung. Klassifizierung, Wahl des Konformitätsbewertungsverfahrens, verfügbare Prüfkapazitäten und notwendige Änderungen am Produkt beeinflussen den Zeitplan. Klären Sie früh, ob eine Selbstbewertung infrage kommt oder eine dritte Stelle erforderlich ist. Die Seite zu den Produktklassen beschreibt die Unterschiede.

Ordnen Sie jeder Produktfamilie einen konkreten Releaseplan zu. Welche Version kann noch Änderungen am Updateverfahren aufnehmen? Wann werden Architekturentscheidungen festgeschrieben? Wie viel Zeit brauchen Tests und die Aktualisierung der Nutzerinformationen? Ein sicherer Aktualisierungsmechanismus lässt sich häufig nicht durch ein Dokument am Ende des Projekts nachrüsten. Reservieren Sie Entwicklungszeit, bevor Sie einen Termin für die fertige technische Dokumentation vereinbaren.

Ein erster Plan für 90 Tage

In den ersten 30 Tagen erfassen Sie Produkte und unterstützte Versionen. Benennen Sie Produktverantwortliche, Meldekontakt und Vertretung. Prüfen Sie die Produktgrenze, dokumentieren Sie eine vorläufige Klasse und erzeugen Sie eine SBOM aus dem Build. Testen Sie, ob eine externe Sicherheitsmeldung tatsächlich beim zuständigen Team ankommt.

In den folgenden 30 Tagen bewerten Sie Schwachstellen und prüfen die grundlegenden Cybersicherheitsanforderungen aus Anhang I. Halten Sie fest, welche Änderungen Entwicklung benötigen und welche Fragen eine externe Bewertung erfordern. Stimmen Sie den Supportzeitraum mit dem vorgesehenen Verwendungszweck ab. Nutzerinformationen und vorhandene Testergebnisse werden mit einer konkreten Version verknüpft.

In den Tagen 61 bis 90 beginnen die priorisierten Entwicklungsaufgaben. Parallel bauen Sie die Struktur der technischen Dokumentation auf. Eine Meldeübung prüft Zugang zur Single Reporting Platform, Freigaben und Vertretung. Das Ergebnis ist eine Liste überprüfbarer Maßnahmen mit Verantwortlichen und Terminen. Dieser Einstieg ist keine Zusage, dass jedes Produkt innerhalb von 90 Tagen vollständig bewertet werden kann.

Bestehende Produkte gesondert betrachten

Übergangsregeln hängen von den Umständen des Inverkehrbringens und späteren Änderungen ab. Das ursprüngliche Erscheinungsdatum eines Modells sagt nicht automatisch etwas über jede später ausgelieferte Einheit oder Softwareversion aus. Bewahren Sie Vertriebs- und Versionsnachweise auf. Wesentliche Änderungen und gemischte Portfolios benötigen eine konkrete Prüfung. Auch die Anwendbarkeit der Meldepflicht ist gesondert zu prüfen; sie folgt nicht allein aus dem Termin der übrigen Pflichten.

Fortschritt an Nachweisen messen

Eine Aufgabe wie „CRA zu 80 Prozent fertig“ ist schwer zu überprüfen. Aussagekräftiger sind ein validiertes Inventar, ein freigegebener Klassifizierungsvermerk oder das Protokoll einer Meldeübung. Ordnen Sie jedem Ergebnis eine Person und einen Prüftermin zu. Bewahren Sie offene Annahmen neben den bestätigten Fakten auf. So kann das nächste Teammitglied erkennen, worauf eine Entscheidung beruht.

Prüfen Sie bei jedem neuen Release, ob sich Produktgrenze, Abhängigkeiten oder vorgesehene Verwendung verändert haben. Ein einmaliger Projektabschluss ersetzt diese laufende Pflege nicht. Verbinden Sie Ihren Zeitplan mit dem CRA-Leitfaden und dem Meldeablauf nach Artikel 14. Für eine erste Bestandsaufnahme bietet der kostenlose Snapshot einen begrenzten Einstieg.

Häufige Fragen

Quellen

• Verordnung (EU) 2024/2847 – deutsche Fassung auf EUR-Lex
• ENISA: Fragen zur Single Reporting Platform

Allgemeine technische Informationen, geprüft am oben genannten Datum. Produktbezogene Auslegung, aktuelle Normen und das anwendbare Verfahren sind vor einer Konformitätsentscheidung gesondert zu prüfen.