CRA-Fristen 11.09.2026 und 11.12.2027 — was bis wann belegbar sein muss
Zwei Daten strukturieren den Cyber Resilience Act. Welche Pflicht wann greift, was für bereits ausgelieferte Produkte gilt und woran die Rückwärtsplanung hängt.
Der Cyber Resilience Act ist seit Ende 2024 in Kraft, seine Pflichten greifen aber gestaffelt. Für die Planung in der Produktentwicklung sind zwei Daten entscheidend — und das erste ist näher, als es in den meisten Roadmaps aussieht.
Die Zeitachse
| Datum | Was greift |
|---|---|
| 11.09.2026 | Meldepflichten: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind an ENISA und das zuständige nationale CSIRT zu melden |
| 11.12.2027 | Vollständige Anwendung: grundlegende Anforderungen aus Annex I, Konformitätsbewertung, technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung |
Betroffen sind Produkte mit digitalen Elementen, deren Datenverbindung zu einem Gerät oder Netz vorgesehen ist — Hardware wie Software. Der CRA unterscheidet dabei zwei Kritikalitätsklassen mit strengeren Konformitätsbewertungswegen; einzelne Produktbereiche mit eigener EU-Regulierung, etwa Medizinprodukte, zivile Luftfahrt und Schiffsausrüstung, sind ausgenommen. Für typische Industriefeldgeräte lautet die Frage also selten ob, sondern in welcher Klasse.
Warum das erste Datum das unterschätzte ist
Die Meldepflichten sind kein Entwicklungsthema, sondern ein Betriebsthema — und sie treffen auch Produkte, die längst im Markt sind. Wer ab September 2026 von einer aktiv ausgenutzten Schwachstelle in einem seiner Geräte erfährt, muss innerhalb kurzer Fristen melden können. Das setzt Dinge voraus, die sich nicht in einer Woche aufbauen lassen:
- eine erreichbare Meldestelle beim Hersteller, die Hinweise von außen annimmt und bearbeitet — auch außerhalb der Bürozeiten des Produktmanagements,
- Wissen darüber, was ausgeliefert wurde: welche Firmware-Stände bei welchen Kunden laufen und welche Komponenten darin stecken,
- einen entscheidungsfähigen Ablauf, der eine Meldung auslöst, statt sie zu eskalieren,
- und die Fähigkeit, zu reagieren — ein Update bereitzustellen, das der Kunde auch einspielen kann.
Wer für eine gemeldete Schwachstelle nicht sagen kann, welche Produktstände betroffen sind, hat kein Meldeproblem, sondern ein Nachweisproblem. Hier zahlt sich eine SBOM, die aus dem Build entsteht, unmittelbar aus.
Was zum zweiten Datum stehen muss
Zum 11. Dezember 2027 wird aus dem Thema eine Marktzugangsfrage. Ohne erfüllte grundlegende Anforderungen, durchgeführte Konformitätsbewertung, technische Dokumentation, Konformitätserklärung und CE-Kennzeichnung darf ein Produkt mit digitalen Elementen nicht in Verkehr gebracht werden.
Für bereits in Verkehr gebrachte Produkte gilt eine Übergangslogik: Sie werden von den Anforderungen grundsätzlich erst dann erfasst, wenn sie nach diesem Datum wesentlich verändert werden. Die Meldepflichten gelten davon unabhängig.
Ebenfalls zum zweiten Datum relevant, weil es die Produktplanung direkt betrifft: Der Hersteller legt einen Unterstützungszeitraum fest, in dem Schwachstellen behandelt werden. Er orientiert sich an der erwarteten Nutzungsdauer; für langlebige Industriegeräte ist das eine Zusage mit spürbaren Konsequenzen für Architektur, Toolchain und Lieferantenverträge.
Rückwärts gerechnet
Für ein Gerät, das im Jahr 2028 in Serie gehen soll, sieht die Planung nüchtern so aus:
- Konformitätsbewertung braucht einen Vorlauf — je nach Produktkategorie mit Beteiligung einer benannten Stelle, deren Kapazität 2027 nicht beliebig verfügbar sein wird.
- Technische Dokumentation entsteht nicht am Ende, sondern ist das Nebenprodukt eines Prozesses, der sie erzeugt. Nachträglich zusammengetragene Dokumentation ist genau die Arbeit, die niemand eingeplant hat.
- Die Risikobewertung muss dabei bereits vorliegen, denn die Anforderungen aus Annex I sind auf sie zurückzuführen. Sie steht nicht am Schluss der Kette, sondern am Anfang.
- Der Meldeprozess muss ein Jahr früher laufen, also 2026 — nicht als Dokument, sondern als geübter Ablauf.
Das verschiebt die eigentliche Frist nach vorn: Nicht Dezember 2027 ist der relevante Zeitpunkt für die Entwicklung, sondern der Beginn des letzten Vorhabens, das bis dahin abgeschlossen sein muss.
Was sich daraus ableiten lässt
Der CRA erzwingt keine neue Methodik — er erzwingt, dass eine vorhandene bis zum Nachweis durchgehalten wird. Ein nach IEC 62443-4-1 gelebter Entwicklungsprozess liefert den Großteil dessen, was die technische Dokumentation verlangt. Die Einordnung dazu steht im Übersichtsartikel zum sicheren Entwicklungsprozess.
Dieser Artikel ist eine fachliche Einordnung und kein Rechtsrat. Für die verbindliche Auslegung im Einzelfall ziehen Sie bitte den Rechtstext und juristische Beratung heran.
Teil A des Reifecheck: Prozessreife über acht Practices.
Der TRA-Reifecheck zeigt in wenigen Minuten, wo Ihr Nachweis heute steht — Prozessreife, Umsetzungsabdeckung und die Lücke dazwischen.