Praxisorientierte Einordnung zu CRA-Fristen und Übergangsphase: Was 2026 für Hersteller zählt: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Cyber Resilience Act aufbauen.
Für Hersteller ist 2026 das operative Startjahr des Cyber Resilience Act. Die meisten materiellen Produktanforderungen gelten zwar erst ab dem 11. Dezember 2027. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle beginnen jedoch bereits am 11. September 2026. Damit müssen Unternehmen schon jetzt wissen, welche Produkte und Versionen betroffen sind, wie eine aktive Ausnutzung erkannt wird und wer eine fristgerechte Meldung freigibt.
Diese Fristenanalyse gibt den Stand August 2026 wieder und unterscheidet ausdrücklich zwischen Inkrafttreten, einzelnen vorgezogenen Pflichten und vollständiger Anwendung. Sie zeigt außerdem, welche Bestandsprodukte in der Übergangsphase relevant bleiben und welche Entscheidungen Hersteller in den kommenden Monaten treffen sollten.
Die CRA-Zeitleiste in vier Stichtagen
10. Dezember 2024: Der CRA trat in Kraft. Seit diesem Zeitpunkt läuft die Übergangsphase. Das bedeutet nicht, dass alle Produktanforderungen sofort anzuwenden waren, wohl aber, dass Hersteller ihre Umsetzung auf einen verbindlich beschlossenen Rechtsrahmen ausrichten können und müssen.
11. Juni 2026: Die Bestimmungen zur Notifizierung von Konformitätsbewertungsstellen finden Anwendung. Für Hersteller wichtiger und kritischer Produkte ist dies ein relevanter Infrastrukturtermin, weil Verfügbarkeit und Zuständigkeit externer Stellen für spätere Bewertungsverfahren vorbereitet werden.
11. September 2026: Die Meldepflichten nach Artikel 14 werden anwendbar. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Produktauswirkung über die von ENISA bereitgestellte Single Reporting Platform melden.
11. Dezember 2027: Die übrigen wesentlichen Bestimmungen des CRA gelten vollständig. Produkte, die ab diesem Zeitpunkt in den Anwendungsbereich fallen und auf dem Unionsmarkt bereitgestellt werden, müssen den Anforderungen und dem passenden Konformitätsweg entsprechen.
Warum der 11. September 2026 nicht nur ein Meldetool-Termin ist
Ein Zugang zur Single Reporting Platform macht ein Unternehmen noch nicht meldefähig. Bevor eine Meldung erfolgen kann, muss die Organisation erkennen, dass ein Ereignis ein bestimmtes Produkt betrifft, ob eine Schwachstelle aktiv ausgenutzt wird und ob ein Vorfall die Sicherheit des Produkts schwerwiegend beeinflusst. Diese Informationen liegen typischerweise verteilt bei Support, Entwicklung, Cloud-Betrieb, Product Security, Recht und externen Partnern.
Die gesetzliche Logik arbeitet mit frühen und fortgeschriebenen Informationen. Hersteller dürfen daher nicht warten, bis Root Cause, vollständiger Kundenumfang und finaler Fix feststehen. Ein belastbarer Prozess trennt Erstbewertung, frühe Warnung, Folgemeldung und Abschlussbericht. Er dokumentiert zugleich Annahmen und aktualisiert Angaben, sobald neue Erkenntnisse vorliegen.
Besonders kritisch ist die Zeit außerhalb normaler Geschäftszeiten. Eine aktiv ausgenutzte Schwachstelle wird möglicherweise am Freitagabend durch einen Sicherheitsforscher oder Cloud-Alarm bekannt. Deshalb müssen Erreichbarkeit, Stellvertretung, rechtliche Bewertung und Freigabe rund um die relevanten Fristen funktionieren. Ein Postfach, das montags geprüft wird, erfüllt diese operative Anforderung nicht.
Welche Produkte von den Meldepflichten erfasst sein können
Die Meldepflichten sind nicht einfach auf Produkte beschränkt, die nach Dezember 2027 neu auf den Markt kommen. Die offizielle Zusammenfassung der Europäischen Kommission weist darauf hin, dass die Reporting Obligations auch Produkte mit digitalen Elementen betreffen, die bereits vor dem 11. Dezember 2027 auf dem Unionsmarkt bereitgestellt wurden. Hersteller müssen daher den installierten Bestand und unterstützte Altversionen in den Meldeprozess einbeziehen.
Das erfordert ein Produkt- und Versionsregister. Zu jeder Familie sollten Markteinführungsstatus, unterstützte Versionen, Komponenten, Supportkanal und erreichbare Kundengruppen bekannt sein. Ohne diese Basis lässt sich eine neue Schwachstelle nicht schnell genug auf reale Produkte abbilden. Besonders schwierig sind OEM-Varianten, White-Label-Produkte und Software, die über Partner verteilt wurde.
Auch verbundene Backend- oder Cloud-Funktionen müssen im Produktkontext betrachtet werden. Ein Vorfall im zentralen Dienst kann viele Geräte gleichzeitig betreffen. Incident Management des Cloud-Teams und Product Security dürfen daher keine getrennten Eskalationswelten bleiben.
Was bis 11. September 2026 abgeschlossen sein muss
- CRA-Produktregister: Relevante aktive und unterstützte Produktfamilien, Versionen und verantwortliche Gesellschaften sind identifiziert.
- Meldekriterien: Aktiv ausgenutzte Schwachstelle und schwerwiegender Produktsicherheitsvorfall sind in arbeitsfähige Entscheidungskriterien übersetzt.
- Single-Reporting-Zugang: Registrierung, Rollen, Vertreter und technische Bedienung der ENISA-Plattform sind geklärt.
- 24/7-Eskalation: Product Security, Recht und verantwortliche Entscheider können bei Bedarf fristgerecht erreicht werden.
- Datenquellen: Supportfälle, Telemetrie, Schwachstellenmeldungen, Lieferantenhinweise und öffentliche Informationen fließen in eine zentrale Triage.
- Vorlagen: Erstmeldung, technische Bewertung, Kundeninformation und Folgebericht besitzen abgestimmte Mindestinhalte.
- Übung: Mindestens ein realistischer Fall wurde mit Zeitmessung durchgespielt und festgestellte Lücken wurden geschlossen.
Eine schriftliche Richtlinie ohne Übung ist zu schwach. Der Test sollte mit unvollständigen Informationen beginnen, mehrere Produktversionen und einen externen Komponentenlieferanten betreffen und eine Entscheidung außerhalb der Kernarbeitszeit erzwingen.
Was bis Ende 2026 aufgebaut werden sollte
Nach dem Meldestichtag verlagert sich der Schwerpunkt auf skalierbare Produktkonformität. Hersteller sollten bis Jahresende das Portfolio klassifiziert und mindestens eine repräsentative Produktfamilie vollständig durch den künftigen CRA-Prozess geführt haben. Dabei werden Risikobewertung, Security-Anforderungen, Tests, SBOM, technische Dokumentation und Supportnachweise zusammengeführt.
Parallel ist die Standardisierungsentwicklung zu verfolgen. Harmonisierte Standards können später eine Konformitätsvermutung für abgedeckte Anforderungen ermöglichen, sind aber kein Grund, die Umsetzung aufzuschieben. Produktarchitektur, Updatefähigkeit und Vulnerability Handling benötigen Vorlauf und lassen sich nicht durch eine spät veröffentlichte Checkliste nachträglich erzeugen.
Für wichtige oder kritische Produkte sollte der vorgesehene Konformitätsweg validiert werden. Wenn eine externe Stelle nötig wird, sind Kapazität, Prüfzeitpunkt und erwartete Nachweise früh zu planen. Änderungen an Hardwareplattform oder Entwicklungsprozess müssen in die Produkt-Roadmap aufgenommen werden.
Der Arbeitsplan für 2027
Erstes Quartal: Pilotprozess abschließen, offene Designlücken priorisieren und wiederverwendbare Nachweisvorlagen freigeben. Produktteams erhalten Schulungen, die sich auf ihre konkrete Rolle beziehen.
Zweites Quartal: Umsetzung auf alle Produktfamilien ausrollen, Lieferantenanforderungen schließen und technische Prüfungen durchführen. Kritische Bestandskomponenten ohne tragfähigen Support werden ersetzt oder mit genehmigten Maßnahmen behandelt.
Drittes Quartal: Produktakten intern auditieren, externe Bewertungen durchführen und offene Findings bis zur Releasefähigkeit bearbeiten. Marketing, Vertrieb und Support bereiten korrekte Kundeninformationen und Konformitätserklärungen vor.
Viertes Quartal bis 11. Dezember: Freigaben, CE-Kennzeichnung, Aufbewahrung und Marktüberwachungsprozesse finalisieren. Neue oder wesentlich geänderte Produkte dürfen nur über den etablierten CRA-Gate-Prozess freigegeben werden.
Bestandsprodukte und die Frage der wesentlichen Änderung
Die Übergangsregeln dürfen nicht als pauschaler Bestandsschutz verstanden werden. Für Produkte, die vor der vollständigen Anwendung in Verkehr gebracht wurden, ist zu prüfen, ob und wann spätere wesentliche Änderungen neue Anforderungen auslösen. Die 2026 veröffentlichte Kommissionsleitlinie erläutert unter anderem den Begriff der substantial modification und sollte in Change- und Releaseprozesse übersetzt werden.
Hersteller benötigen dafür ein Change Assessment. Es bewertet neue Funktionen, Schnittstellen, Datenflüsse, Plattformwechsel, sicherheitsrelevante Konfigurationen und Veränderungen des vorgesehenen Zwecks. Die Entscheidung wird versioniert und genehmigt. Ein reiner Versionssprung oder Marketingname ist weder Beweis für noch gegen eine wesentliche Änderung.
Unabhängig davon bleiben Vulnerability Handling und die ab September 2026 geltenden Meldepflichten für relevante Produkte im Markt wichtig. Ein Altprodukt ohne aktuelle Komponentenübersicht kann deshalb bereits vor 2027 ein erhebliches Melde- und Reaktionsrisiko erzeugen.
Supportzeitraum jetzt festlegen
Der CRA verlangt, dass Hersteller Schwachstellen während eines Unterstützungszeitraums wirksam behandeln. Die Dauer muss die erwartete Nutzungszeit des Produkts und weitere gesetzliche Kriterien berücksichtigen. Für langlebige industrielle oder infrastrukturelle Produkte kann eine kurze, allein am Vertriebszyklus orientierte Frist unplausibel sein.
Produktmanagement sollte deshalb Absatzdauer, reale Einsatzdauer, Verfügbarkeit von Komponenten, Updatefähigkeit, vertragliche Zusagen und Abkündigungsstrategie gemeinsam bewerten. Die Entscheidung beeinflusst Architektur und Kosten: Langfristige Unterstützung benötigt reproduzierbare Builds, gepflegte Toolchains, Zugriff auf Quellcode, Lieferantenverträge und qualifiziertes Personal.
Die Supportdauer muss für Nutzer verständlich sein. Änderungen oder Verlängerungen werden kontrolliert kommuniziert. Am Ende benötigen Kunden rechtzeitig Informationen über Migration, verfügbare Ersatzprodukte und sichere Außerbetriebnahme.
Häufige Fehlinterpretationen der Übergangsphase
- „CRA gilt erst 2027“: Die Meldepflichten gelten bereits ab 11. September 2026 und benötigen einen funktionsfähigen Prozess.
- „Nur neue Produkte müssen gemeldet werden“: Auch bereits bereitgestellte Produkte können unter die Reporting Obligations fallen.
- „Wir warten auf alle Standards“: Grundlegende Produkt- und Prozessanforderungen sind gesetzlich festgelegt; notwendige Architekturarbeit kann heute beginnen.
- „Eine Meldung ist Sache der Rechtsabteilung“: Recht kann ohne technische Produkt-, Versions- und Ausnutzungsinformationen keine belastbare Meldung erzeugen.
- „Ein PSIRT genügt automatisch“: Bestehende Prozesse müssen auf CRA-Kriterien, kurze Fristen, Single Reporting Platform und betroffene Altprodukte geprüft werden.
- „Altprodukte sind vollständig geschützt“: Änderungen, laufender Support und Meldepflichten erfordern eine differenzierte Bewertung.
Managementfragen für August 2026
- Können wir innerhalb weniger Stunden feststellen, welche Produkte eine gemeldete Komponente enthalten?
- Wer entscheidet außerhalb der Geschäftszeiten, ob eine CRA-Meldung erforderlich ist?
- Ist unser Zugang zur Single Reporting Platform eingerichtet und praktisch getestet?
- Welche unterstützten Altprodukte haben keine belastbare Versions- oder Komponentenübersicht?
- Welche Produktfamilien benötigen voraussichtlich eine externe Konformitätsbewertung?
- Welche Designlücken lassen sich bis Ende 2027 nicht allein dokumentarisch beheben?
- Ist für jedes Produkt ein plausibler Unterstützungszeitraum mit Ressourcen hinterlegt?
- Wie stellen wir sicher, dass wesentliche Änderungen rechtzeitig erkannt und neu bewertet werden?
Wenn mehrere Antworten unklar bleiben, sollte das Thema als Produkt- und Geschäftsrisiko berichtet werden. Die verbleibende Zeit ist für strukturierte Umsetzung ausreichend, aber zu kurz für einen rein sequenziellen Start Ende 2027.
Fazit: 2026 entscheidet über Meldereife und Umsetzungstempo
Die CRA-Übergangsphase ist keine Wartezeit. Bis 11. September 2026 muss die Organisation meldefähig sein; bis Ende des Jahres sollte ein vollständiger Produktpilot zeigen, dass Risiken und Nachweise funktionieren. 2027 dient dann der kontrollierten Skalierung und Konformitätsreife. Hersteller, die Bestandsprodukte, Supportdauer und externe Bewertungswege jetzt einbeziehen, vermeiden Engpässe kurz vor der vollständigen Anwendung.
BlackMount unterstützt Hersteller bei Fristenplanung, Melde-Playbooks und produktbezogenen CRA-Roadmaps. Weitere Informationen finden Sie unter Cyber Resilience Act Beratung.
