Am 11. September 2026 begann die erste operative Phase des EU-Cyber-Resilienz-Acts (CRA). Hersteller von Produkten mit digitalen Elementen müssen, sofern ihre Produkte in den Anwendungsbereich der Verordnung fallen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die übrigen Kernpflichten, darunter grundlegende Cybersicherheitsanforderungen, Konformitätsbewertung und CE-Kennzeichnung, gelten ab Dezember 2027. Laut Niko Boeker, Director Business Development DACH bei QNX, rücken für Hersteller drei Aufgaben jetzt besonders in den Mittelpunkt.
1. Klare Melde- und Eskalationswege etablieren
Ab dem Stichtag verlangt der CRA in meldepflichtigen Fällen eine Frühwarnung innerhalb von 24 Stunden sowie eine ausführlichere Meldung innerhalb von 72 Stunden nach Bekanntwerden. Hinzu kommt ein Abschlussbericht: bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Korrekturmaßnahme verfügbar ist, und bei schwerwiegenden Sicherheitsvorfällen innerhalb eines Monats. Die Meldung erfolgt über die zentrale CRA-Meldeplattform und wird an das zuständige Computer Security Incident Response Team (CSIRT) sowie grundsätzlich an die Agentur der Europäischen Union für Cybersicherheit (ENISA) weitergegeben.
Entscheidend ist deshalb nicht, ob eine Vorlage für den Bericht existiert. Hersteller müssen einen Vorfall erkennen, seine Relevanz für konkrete Produkte bewerten und die nötigen Informationen in kürzester Zeit zwischen Product Security, Entwicklung, Recht, Compliance und Management zusammenführen. Zuständigkeiten und Eskalationswege sollten vorab feststehen und in realistischen Übungen getestet werden. Wie hoch der Druck bereits ist, zeigt der „Under the Hood: SDV Developer Report“ von QNX: 47 Prozent der befragten Entwickler bezeichneten Cybersicherheitsvorschriften als die schwierigste Compliance-Kategorie und ein Drittel berichtete von Verzögerungen durch neue regulatorische Anforderungen.
2. Softwarekomponenten und Abhängigkeiten lückenlos nachvollziehen
Moderne Embedded-Produkte bestehen aus Betriebssystemen, Open-Source-Paketen, Bibliotheken und Komponenten zahlreicher Zulieferer. Wenn in einem dieser Bausteine eine Schwachstelle bekannt wird, muss der Hersteller des Endprodukts nachvollziehen können, welche Produktlinien, Versionen und Konfigurationen betroffen sind. Außerdem muss er prüfen, ob die verwundbare Funktion im konkreten System überhaupt erreichbar oder ausnutzbar ist. Diese Verantwortung lässt sich nicht vollständig an einen einzelnen Lieferanten delegieren.
Eine Software Bill of Materials (SBOM) ist dafür eine wichtige Grundlage, allerdings nur, wenn sie aktuell gepflegt wird. Ihr Nutzen entsteht erst, wenn die Komponentendaten mit Schwachstellenhinweisen, Produktinventaren, Supportständen und klaren Ansprechpartnern verknüpft werden. Eine statische Liste, die erst im Ernstfall ausgewertet wird, ist für die 24- und 72-Stunden-Fenster zu langsam. Dass dies nicht nur ein theoretisches Problem ist, zeigen zwei Entwicklerstudien aus sicherheitskritischen Branchen: Im SDV-Report nannten 44 Prozent der Befragten Cybersicherheitslücken als größtes Risiko für die Einführung softwaredefinierter Fahrzeuge. Im QNX-Report „Inside the Robot“ stuften 51 Prozent der Robotikentwickler Cybersicherheitsvorgaben als die am schwierigsten einzuhaltende regulatorische Kategorie ein.
3. Sicherheitsupdates ermöglichen, ohne das Gesamtsystem zu gefährden
Bei langlebigen Embedded- und missionskritischen Systemen ist ein Update kein routinemäßiger Mausklick. In Robotik, Industrieautomation, Schienenverkehr oder Energieinfrastruktur kann eine Änderung das Echtzeitverhalten beeinflussen, die Verfügbarkeit beeinträchtigen oder eine erneute Validierung sicherheitsrelevanter Funktionen erfordern. Besonders eng gekoppelte Architekturen erschweren gezielte Korrekturen, denn eine Änderung an einer Komponente kann umfangreiche Regressionstests im gesamten System auslösen.
Damit wird Cyberresilienz mehr zu einer Architektur- und Lebenszyklusfrage. Klar getrennte Komponenten, minimale Berechtigungen, Modularität und eine kleine vertrauenswürdige Systembasis können begrenzen, welche Bereiche eine kompromittierte Komponente erreicht, und Änderungen besser isolierbar machen. Das allein ist jedoch kein Compliance-Nachweis. Hersteller benötigen weiterhin eine produktspezifische Risikobewertung, belastbare technische Dokumentation, sichere Update-Mechanismen, festgelegte Supportzeiträume und Prozesse für den Umgang mit Schwachstellen – auch dann, wenn einzelne Softwarekomponenten das Ende ihres regulären Supports erreichen.
Der erste CRA-Stichtag prüft mehr als die Meldeprozesse
Die neuen Meldepflichten treten mehr als ein Jahr vor der vollständigen Anwendung des CRA in Kraft. Unternehmen sollten den Stichtag deshalb nutzen, um ihre gesamte Reaktionskette zu prüfen. Können sie einen Vorfall schnell erkennen, betroffene Produkte eindeutig bestimmen, eine regulatorische Entscheidung treffen, fristgerecht melden und anschließend sicher nachbessern?
Wer diese Abläufe erst nach dem ersten meldepflichtigen Ereignis aufbaut, verliert wertvolle Zeit. Wer sie hingegen bereits heute mit Softwaretransparenz, klarer Verantwortung und beherrschbaren Update-Prozessen verbindet, schafft zugleich eine belastbare Grundlage für die umfassenden Anforderungen ab Dezember 2027. Der eigentliche Maßstab ist dabei nicht die Menge der erzeugten Dokumente, sondern die Frage, ob Produkte über ihren gesamten Lebenszyklus hinweg nachvollziehbar, aktualisierbar und widerstandsfähig bleiben.
