Die CRA-Meldefristen laufen, und die eigentliche Schwierigkeit ist nicht das Formular, sondern der Weg vom externen Signal zu einer belastbaren Produktaussage innerhalb von 24 und 72 Stunden. Zulieferer, die Produktumfang, Kenntnisnahme-Regel und Nachweis-Rückverfolgbarkeit vor dem Vorfall festlegen, melden auf Basis gesicherter Fakten statt Rekonstruktion.
Die Meldefristen des Cyber Resilience Act laufen. Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen, die unter den CRA fallen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Produktsicherheit melden. Die erste Frist kann bereits 24 Stunden nach Kenntnisnahme ablaufen, eine ausführlichere Meldung folgt innerhalb von 72 Stunden. CRA-Meldepflichten für Automobilzulieferer sind damit kein Planungsthema mehr, sondern eine laufende operative Verpflichtung für die Verantwortlichen in PSIRT, Produktsicherheit, Compliance und CSMS eines Tier-1.
Für einen Automobilzulieferer liegt die Schwierigkeit selten darin, ein behördliches Formular zu öffnen. Schwierig ist festzustellen, was passiert ist, welche Produkte betroffen sein können, welche Kunden und Märkte berührt sind und welche Nachweise die erste Position stützen, während die Untersuchung noch läuft.
Die Meldepflicht legt damit eine operative Frage offen: Kann die Organisation vom externen Signal zu einer belastbaren Produktentscheidung kommen, bevor die Frist abläuft? Dieser Leitfaden behandelt die Fristen, die Vorbereitung, die vor jeden Vorfall gehört, die Nachweise hinter jeder Einreichung und ein durchgerechnetes Beispiel, in dem die Uhr läuft, bevor der Betroffenheitsumfang feststeht.
Die CRA-Meldefristen im Überblick
Der CRA sieht eine gestufte Meldefolge vor, keine einzelne Einreichung. Jede Stufe hat einen anderen Zweck und einen anderen Maßstab an Vollständigkeit; sie zu verwechseln ist der erste Weg, Zeit zu verlieren.
| Stufe | Frist | Gilt für | Worauf sie sich stützen sollte |
|---|---|---|---|
| Frühwarnung | Innerhalb von 24 Stunden nach Kenntnisnahme | Aktiv ausgenutzte Schwachstelle oder schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit | Gesicherte Fakten: Auslöser, Zeitstempel der Kenntnisnahme, Produktkandidaten, noch nicht Verifiziertes |
| Meldung | Innerhalb von 72 Stunden nach Kenntnisnahme | Dasselbe Ereignis nach der Erstbewertung | Strukturierte Auswirkungsbewertung: betroffene Produkte und Versionen, Ausnutzungsbedingungen, Gegenmaßnahmen, offene Punkte mit Verantwortlichen |
| Abschlussbericht (Schwachstelle) | Spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme | Aktiv ausgenutzte Schwachstelle | Ursache, Maßnahme, Validierungsnachweise, betroffene Population, Kundenkommunikation |
| Abschlussbericht (Vorfall) | Innerhalb eines Monats nach der 72-Stunden-Meldung | Schwerwiegender Sicherheitsvorfall | Vollständige Vorfallsakte, Korrekturmaßnahmen, Antworten der Lieferanten, Freigaben |
Zwei Merkmale dieser Abfolge prägen alles Weitere. Jede Frist ist am Zeitpunkt der Kenntnisnahme verankert, deshalb ist die organisationsinterne Definition von Kenntnisnahme selbst ein Compliance-Kontrollpunkt. Und die Frühwarnung ist ausdrücklich nicht die abschließende technische Antwort, das Team muss also gesicherte Fakten von Arbeitshypothesen trennen können. Zulieferer, die den EU-CRA-Konformitätsfahrplan für Automobilzulieferer durchgearbeitet haben, erkennen in der Meldung das operative Ende derselben Rückverfolgbarkeit.
Produktumfang vor dem Vorfall klären
Die CRA-Anwendbarkeit erfordert in der Automobilindustrie eine sorgfältige Analyse auf Produktebene. Manche Produkte oder Funktionen können sektorspezifischen Regelwerken unterliegen, während eigenständig vermarktete ECUs, Telematikeinheiten, Diagnosesoftware, Flottenanwendungen, Aftermarket-Geräte und andere digitale Produkte eine separate CRA-Betrachtung erfordern können. Unternehmen sollten nicht davon ausgehen, dass die Typgenehmigung des Fahrzeugs die Frage automatisch für jede Position im Portfolio beantwortet. Das Zusammenspiel beider Regelwerke untersucht EU Cyber Resilience Act vs. UNECE R155.
Die Rechtsabteilung sollte den formalen Anwendungsbereich bestätigen. Produktsicherheit und Entwicklung müssen diesen Anwendungsbereich nutzbar machen, denn ein Rechtsgutachten in einem Memorandum lässt sich an dem Morgen, an dem ein Exploit veröffentlicht wird, nicht abfragen. Das Portfolio-Verzeichnis sollte für jedes Produkt mindestens festhalten:
- Den rechtlichen Hersteller und die Stelle, die das Produkt in Verkehr gebracht hat.
- Die Produktfamilie und die aktuell unterstützten Softwareversionen.
- Die Märkte, in denen jede Version verkauft oder eingesetzt wird.
- Den zuständigen PSIRT-Kontakt und den Eskalationspfad.
- Den Unterstützungszeitraum und das Datum des Support-Endes.
- Den maßgeblichen regulatorischen Pfad: CRA, ein sektorspezifisches Regelwerk, beides oder in rechtlicher Prüfung.
Nehmen Sie einen typischen Tier-1 mit, sagen wir, 40 Produktfamilien: 28 fahrzeugintegrierte Steuergeräte, die in typgenehmigte Programme geliefert werden, 6 Aftermarket-Telematik- und Flottengeräte unter eigenem Namen, 4 Werkstatt-Diagnosewerkzeuge und 2 Flottenanwendungen. Der regulatorische Pfad kann sich zwischen diesen Gruppen unterscheiden, und sogar innerhalb einer Familie, wenn dieselbe Hardware über einen anderen Kanal verkauft wird. Die Entwicklung entscheidet die Rechtsfrage nicht, aber die Antwort muss am Produktdatensatz hinterlegt sein, damit sie ohne Besprechung abrufbar ist.
Diese Arbeit gehört vor dem Vorfall ins Betriebsmodell. Wer rechtliche Produktgrenzen klären will, während das 24-Stunden-Fenster bereits läuft, erzeugt vermeidbare Verzögerung, und die Verzögerung summiert sich: Unklarer Umfang blockiert die Kundenliste, die Kundenliste blockiert die Betroffenheitsbewertung.
Kenntnisnahme definieren, bevor die Uhr es tut
Der Zeitstempel der Kenntnisnahme verankert jede Meldefrist. Die Organisation braucht deshalb eine vereinbarte Regel, wann Kenntnisnahme beginnt, und einen Nachweis, wie die Regel angewendet wurde. Eine Nachricht in einem privaten Posteingang oder einer untriagierten VSOC-Warteschlange darf nicht zum unsichtbaren Startpunkt werden.
Eine praktikable Kenntnisnahme-Regel benennt die Eingangskanäle und für jeden das Erkennungsereignis:
- Eine Meldung aus der Schwachstellenaufklärung, die zu einer Komponente in einem unterstützten Produkt passt.
- Eine OEM-Benachrichtigung nach dem vertraglichen Offenlegungs- oder Eskalationsprotokoll.
- Eine Eskalation aus VSOC oder Flottenüberwachung, die die PSIRT-Warteschlange erreicht.
- Eine Offenlegung durch Forschende oder Koordinatoren über den veröffentlichten Kontakt.
- Ein interner Befund oder die eigene Benachrichtigung eines Lieferanten.
Für jeden Kanal legt die Regel fest, was als Erkennung zählt, wer den Zeitstempel setzt und wo der Nachweis liegt. Zur Veranschaulichung: Ein OEM-Sicherheitskontakt schreibt am Freitag um 17:40 Uhr einer namentlich bekannten Entwicklerin, die die E-Mail am Montag um 08:15 Uhr liest. Ohne Regel hat die Organisation zwei Kandidaten für den Zeitstempel, mehr als zwei Tage auseinander, und für keinen eine dokumentierte Grundlage. Mit einer Regel, die jeden Kanal in eine überwachte PSIRT-Warteschlange leitet, ist die Frage beantwortet, bevor sie gestellt wird.
Eine untriagierte Nachricht ist keine verzögerte Kenntnisnahme. Sie ist eine bereits laufende Frist, die niemand sieht.
Die eigene Meldefrist des OEM kann davon abhängen, wann der Zulieferer ihn informiert. Die Kenntnisnahme-Regel und die vertragliche Zusage im Eskalationsrahmen für Vorfälle zwischen OEM und Zulieferer sollten deshalb gemeinsam entworfen werden.
Die ersten 24 Stunden: eine Frühwarnung auf gesicherten Fakten
Die Europäische Kommission bezeichnet die erste Einreichung als Frühwarnung. Sie muss die abschließende technische Antwort nicht enthalten. Sie sollte sich dennoch auf gesicherte Fakten statt auf Annahmen stützen.
Ein praktikabler Ablauf für den ersten Tag sollte sechs Fragen beantworten:
- Was hat die Kenntnisnahme ausgelöst, und wann wurde sie erfasst?
- Betrifft das Ereignis eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit?
- Welche Produktfamilien und Versionen könnten nach aktueller Beweislage betroffen sein?
- Welche Teams und Lieferanten müssen zur Bewertung beitragen?
- Was ist bekannt, was wird noch untersucht, und welche Aussagen müssen validiert werden?
- Wer ist befugt, die Frühwarnung freizugeben?
Die Fragen lassen sich in eine grobe Abfolge übersetzen. In den ersten zwei Stunden registriert das PSIRT das Signal mit Quelle, Zeitstempel und Produktkandidaten und öffnet die Vorfallsakte, an die jedes spätere Artefakt angehängt wird. Zwischen Stunde zwei und acht arbeitet das Team den Kandidatenumfang ab: SBOM-Abgleich, Architekturabfrage, Kundenkonfigurationsdaten. Zwischen Stunde acht und achtzehn entwirft es die Frühwarnung in drei beschrifteten Blöcken: bestätigt, in Untersuchung, noch nicht bewertet. Die verbleibende Zeit gehört der befugten Freigabeinstanz für Prüfung und Einreichung.
Die beschrifteten Blöcke sind der Kern der Frühwarnung. „Die Komponente ist in drei ausgelieferten Builds enthalten; die Erreichbarkeit in der ausgelieferten Konfiguration wird untersucht; Aftermarket-Varianten sind noch nicht bewertet“ ist belastbarer als eine selbstbewusste Entwarnung oder eine vage Aussage, die Angelegenheit werde geprüft.
Die 72-Stunden-Meldung: vom Signal zur belegten Auswirkungsbewertung
Die nächste Phase macht aus dem frühen Signal eine strukturierte Auswirkungsbewertung. Das Team sollte die Schwachstelle oder den Vorfall mit der betroffenen Produktarchitektur, der Softwarezusammensetzung, den eingesetzten Versionen, den verfügbaren Gegenmaßnahmen und den bekannten Ausnutzungsbedingungen verknüpfen.
Für Automobilzulieferer erfordert das oft Nachweise aus mehreren Quellen, von denen jede eine andere Frage beantwortet.
| Nachweisquelle | Beantwortete Frage | Typisches Versagensmuster |
|---|---|---|
| SBOM je ausgeliefertem Build | Ist die Komponente enthalten, und in welcher Version | SBOM existiert je Release-Branch, nicht je ausgeliefertem Build |
| Softwarearchitektur | Ist die verwundbare Funktion in der ausgelieferten Konfiguration enthalten und erreichbar | Architektur ist eine Folie, kein abfragbares Modell mit Verknüpfung zu den Softwaredatensätzen |
| TARA | Welche Schadens- und Bedrohungsszenarien die Exposition aktiviert | TARA ist älter als die aktuelle Software-Baseline |
| Testergebnisse | Erreichbarkeit nachgewiesen oder widerlegt; kompensierende Maßnahme belegt | Tests sind nicht mit der Maßnahme verknüpft, die sie verifizieren |
| Kundenkonfigurationsdaten | Welche OEM-Programme die betroffene Version erhalten haben, in welchen Märkten | Lieferdaten liegen in einem allgemeinen Ticketsystem ohne Versionsgranularität |
| Antworten der Lieferanten | Status von Unterkomponenten, die der Tier-1 nicht selbst entwickelt hat | Keine Frist für die Antwort, kein Nachweis, was gefragt wurde |
Die SBOM kann einen Komponententreffer liefern, und die Praktiken aus SBOM-Management in der Automobilindustrie entscheiden, ob dieser Treffer je ausgeliefertem Build statt je Release-Branch möglich ist. Jede der übrigen Quellen grenzt den Treffer dann in Richtung einer Antwort auf Produktebene ein.
Die 72-Stunden-Einreichung sollte die zu diesem Zeitpunkt am besten belegte Position wiedergeben. Wo die Untersuchung unvollständig bleibt, sollte der Datensatz das klar sagen und den nächsten Schritt zuweisen. Das Vertrauen wächst, wenn die Entscheidungskette sowohl Nachweise als auch Unsicherheiten bewahrt: Wer mehr Gewissheit behauptet, als die Nachweise tragen, schafft später eine Korrekturpflicht; wer Nachweise weglässt, die das Team bereits besitzt, provoziert die Frage, warum sie nicht genutzt wurden.
Auch Abschlussberichte verlangen Engineering-Disziplin
Der CRA verlangt auch eine Abschlussmeldung. Für eine aktiv ausgenutzte Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme fällig. Für einen schwerwiegenden Sicherheitsvorfall ist er innerhalb eines Monats nach der 72-Stunden-Meldung fällig.
Dieser spätere Bericht lässt sich nicht zuverlässig aus E-Mail-Fragmenten zusammensetzen. Die Organisation braucht Folgendes in einer rückverfolgbaren Vorfallsakte:
- Das ursprüngliche Signal, seine Quelle und den Zeitstempel der Kenntnisnahme.
- Jede Änderung des Umfangs mit dem Nachweis, der sie ausgelöst hat.
- Die technische Analyse und ihre Eingaben: SBOM-Treffer, Architekturabfragen, TARA-Szenarien, Testergebnisse.
- Anfragen an Lieferanten und ihre Antworten, mit Zeitstempeln.
- Die Behandlungsentscheidung und ihre Begründung.
- Validierungsnachweise für die Korrektur- oder Risikominderungsmaßnahme.
- Die Kundenkommunikation und die Liste der betroffenen Programme, an die sie ging.
- Jede behördliche Einreichung und die Freigabe dahinter.
An dieser Stelle stellen viele Teams fest, dass Compliance von der Rückverfolgbarkeit im Engineering abhängt. Der Bericht ist das Ergebnis. Die zugrunde liegende Fähigkeit ist, ein Produktereignis mit genau den Komponenten, Versionen, Programmen, Risiken, Maßnahmen, Tests und Verantwortlichen zu verknüpfen, die beteiligt sind.
Der Abschlussbericht wird nicht an Tag 14 geschrieben. Er entsteht Datensatz für Datensatz ab dem Moment der Kenntnisnahme.
Eine praktikable CRA-Meldekette in fünf Stufen
Ein Automobilzulieferer kann den Ablauf um fünf kontrollierte Stufen organisieren, von denen jede ein Ergebnis erzeugt, das die nächste Stufe weiterverarbeitet.
- Kenntnisnahme erfassen: Signal, Quelle, Zeitstempel und erste Produktzuordnung registrieren.
- Betroffenheit abgrenzen: das Ereignis auf Produktfamilien, Versionen, Kunden, Märkte und eingesetzte Konfigurationen abbilden.
- Auswirkung bewerten: das Problem mit Architektur, SBOM-Datensätzen, Angriffspfaden, TARA-Szenarien und verfügbaren Maßnahmen verknüpfen.
- Entscheiden und melden: Fakten, Unsicherheiten, Freigaben und behördliche Einreichungen je Frist festhalten.
- Validieren und schließen: die Korrekturmaßnahme prüfen, betroffene Datensätze aktualisieren und das abschließende Nachweispaket aufbewahren.
Die Kette ist bewusst produktzentriert: „Produktfamilie“, „ausgelieferte Version“, „OEM-Programm“ und „TARA-Szenario“ müssen abfragbare Datensätze sein, kein Fließtext in einer Ticketbeschreibung. Der nützlichste Reifetest ist eine Übung: Nehmen Sie ein aktuelles Advisory, das ein unterstütztes Produkt betraf, durchlaufen Sie die fünf Stufen gegen die Uhr und halten Sie fest, wo Zeit verloren ging. Zulieferer, die ihre Werkzeuge an dieser Anforderung messen wollen, können mit Ihr aktuelles Setup im Vergleich beginnen.
Für Tier-1-Organisationen lautet die praktische Frage, wie viel der Kette bereits in Engineering-Datensätzen vorliegt und wie viel pro Vorfall rekonstruiert wird; die Übersicht ThreatZ für Tier-1-Zulieferer beschreibt den verknüpften Datensatz in diesem Kontext.
Durchgerechnetes Beispiel: Die Meldefrist läuft, bevor der Umfang feststeht
Ein Tier-1-Zulieferer erfährt um 09:10 Uhr, dass eine Softwarebibliothek in einem Telematikmodul aktiv ausgenutzt wird. Der Zulieferer liefert das Modul an drei OEMs, aber Bibliotheksversion und Build-Konfiguration unterscheiden sich je Programm. In diesem Moment weiß das Team womöglich genug, um die CRA-Bewertung zu beginnen, aber nicht genug für eine abschließende Aussage zur Produktauswirkung.
Die erste kontrollierte Handlung ist, den Zeitstempel der Kenntnisnahme und den Kandidatenumfang zu sichern. Das PSIRT registriert das Signal um 09:25 Uhr nach der Kenntnisnahme-Regel. Bis 11:00 Uhr zeigt der SBOM-Abgleich über die ausgelieferten Builds die Bibliothek in allen drei ausgelieferten Versionen, aber in zwei Bibliotheks-Releases: Die Programme A und B erhielten Release 2.4, Programm C erhielt Release 2.1. Das Advisory nennt 2.4. Programm C wird als „wahrscheinlich nicht betroffen, Bestätigung ausstehend“ markiert statt aus dem Umfang entfernt, denn ein Treffer auf Komponentenebene ist noch keine Antwort auf Funktionsebene.
Am Nachmittag zeigt der Architekturdatensatz, dass die verwundbare Funktion in den 2.4-Builds zum Pfad für die Fernkonfiguration gehört und dass die ausgelieferte Konfiguration von Programm B diesen Pfad zur Build-Zeit deaktiviert. Das Team hält dies als mindernde Bedingung in Untersuchung fest und weist einen Testingenieur zur Bestätigung zu. Eine Anfrage geht an den Upstream-Lieferanten der Bibliothek, mit erfasster Uhrzeit. Die Frühwarnung wird um 17:30 Uhr freigegeben und eingereicht: Komponente in drei ausgelieferten Versionen bestätigt; ausgenutztes Release in zwei davon vorhanden; Erreichbarkeit in einer davon in Untersuchung; Aftermarket-Varianten noch nicht bewertet.
An Tag zwei bestätigt der Erreichbarkeitstest, dass Programm B über den ausgenutzten Pfad nicht erreichbar ist, und die Aftermarket-Variante wird nachweislich mit Release 2.4 und aktiviertem Pfad ausgeliefert. Die TARA enthält bereits ein Bedrohungsszenario für unbefugte Fernkonfiguration, die bestehende Risikoposition wird also angehängt statt neu geschrieben. Die 72-Stunden-Meldung ergänzt die belegte Auswirkungsbewertung, die Behandlungsrichtung und den aktualisierten Produktumfang: Programm A und die Aftermarket-Variante betroffen, Programm B durch Konfiguration mit Testnachweis gemindert, Programm C aufgrund der Version nicht betroffen.
An Tag neun wird ein gepatchtes Bibliotheks-Release verfügbar; das 14-Tage-Fenster für den abschließenden Schwachstellenbericht läuft ab Verfügbarkeit dieser Maßnahme, und weil jeder Schritt an derselben Vorfallsakte hängt, ist der Abschlussbericht ein Export der Kette. Das Beispiel zeigt, warum CRA-Meldefähigkeit von der Produkt-Rückverfolgbarkeit vor dem Vorfall abhängt, nicht vom Ausfüllen von Formularen danach.
Häufig gestellte Fragen
Wann beginnt die 24-Stunden-Meldefrist des CRA?
Die Frist beginnt, wenn der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erlangt, der die Meldebedingungen erfüllt. Weil dieser Zeitstempel jede spätere Frist verankert, sollte die Organisation festlegen, wie Kenntnisnahme über alle Eingangskanäle erkannt, mit Zeitstempel versehen und eskaliert wird, damit eine untriagierte Nachricht in einem privaten Posteingang oder einer Monitoring-Warteschlange keine unsichtbare Frist erzeugt.
Braucht die 72-Stunden-Meldung eine abschließende Ursachenanalyse?
Nein. Sie soll die vom CRA geforderten ausführlicheren Informationen auf Basis der zu diesem Zeitpunkt am besten belegten Position liefern. Wo Umfang, Ursache oder Behandlung noch untersucht werden, sollte die Einreichung gesicherte Fakten von offenen Fragen trennen und die nächsten Schritte mit Verantwortlichen zuweisen. Wer Nachweise und Unsicherheiten gleichermaßen bewahrt, kann die Meldung leichter verteidigen und aktualisieren.
Wie verhält sich die CRA-Meldung zur Typgenehmigung im Fahrzeugbereich?
Die Regelwerke können zusammenwirken, sind aber nicht austauschbar. Automobilunternehmen sollten Produkt für Produkt statt für das Gesamtportfolio bestimmen, welche Produkte mit digitalen Elementen in den CRA-Anwendungsbereich fallen und welche sektorspezifischen Regeln gelten. Die Rechtsberatung sollte die Anwendbarkeit bestätigen; Entwicklung und Produktsicherheit müssen die Produktdatensätze pflegen, mit denen sich die Entscheidung bei einem Signal schnell umsetzen lässt.
Was sollte ein Zulieferer tun, wenn der Produktumfang nach 24 Stunden noch unsicher ist?
Auf Basis der gesicherten Fakten melden und den Rest kennzeichnen. Die Frühwarnung muss die abschließende technische Antwort nicht enthalten; die belastbare Position ist daher ein Kandidatenumfang mit Nachweisgrundlage je Eintrag, eine klare Aussage dazu, was untersucht wird, und benannte Verantwortliche für jede offene Frage. Ein Produkt auf Verdacht zu entfernen oder sicherheitshalber jedes Produkt aufzunehmen, schwächt den Datensatz gleichermaßen.
Welche Aufzeichnungen müssen bis zum Abschlussbericht erhalten bleiben?
Das ursprüngliche Signal und der Zeitstempel der Kenntnisnahme, jede Umfangsänderung mit ihrem Nachweis, die technische Analyse mit ihren SBOM-, Architektur-, TARA- und Testeingaben, Anfragen an Lieferanten und deren Antworten mit Zeitstempeln, die Behandlungsentscheidung, Validierungsnachweise für die Maßnahme, die Kundenkommunikation und jede behördliche Einreichung mit ihrer Freigabe. Von Anfang an an einer Vorfallsakte angehängt, ist der Abschlussbericht ein Export; verstreut über E-Mails und Tickets ist er eine Rekonstruktion.
- Die Uhr läuft: Seit dem 11. September 2026 schulden erfasste Hersteller eine 24-Stunden-Frühwarnung, eine 72-Stunden-Meldung und einen Abschlussbericht innerhalb von 14 Tagen nach einer Maßnahme oder eines Monats nach der Meldung.
- Umfang vor dem Vorfall: Den rechtlichen Pfad je Produkt klären und am Produktdatensatz hinterlegen, damit er am ersten Tag nicht die Kundenliste blockiert.
- Kenntnisnahme explizit definieren: Jeden Eingangskanal, das Erkennungsereignis und den Verantwortlichen für den Zeitstempel benennen und alle Kanäle in eine überwachte Warteschlange leiten.
- Frühwarnung heißt gesicherte Fakten: Drei beschriftete Blöcke – bestätigt, in Untersuchung, noch nicht bewertet –, freigegeben von einer benannten Instanz.
- Die 72-Stunden-Position ist nachweisbasiert: SBOM je ausgeliefertem Build, abfragbare Architektur, aktuelle TARA, verknüpfte Tests und Kundenkonfigurationsdaten beantworten jeweils eine andere Frage.
- Abschlussberichte entstehen schrittweise: Jede Umfangsänderung, Lieferantenantwort, Entscheidung und Freigabe hängt ab dem Moment der Kenntnisnahme an einer Vorfallsakte.
- Die Kette als Übung durchlaufen: Ein echtes Advisory nehmen, die fünf Stufen gegen die Uhr durchlaufen und die Stufe reparieren, an der Zeit verloren ging.
Weiterführende Beiträge auf VxLabs Security
- ThreatZ für Tier-1-Zulieferer
- Ihr aktuelles Setup im Vergleich
- ThreatZ-Plattform
- EU-CRA-Konformitätsfahrplan für Automobilzulieferer
- EU CRA vs. UNECE R155
- Eskalationsrahmen für Vorfälle zwischen OEM und Zulieferer
Maßgebliche Referenzen
- Verordnung (EU) 2024/2847 — Cyber Resilience Act — Europäisches Parlament und Rat, 2024
- Zusammenfassung des Cyber Resilience Act — Europäische Kommission
- Meldepflichten für Hersteller nach dem Cyber Resilience Act — Europäische Kommission
- UNECE-Regelung Nr. 155 — Cybersicherheit und Cybersicherheits-Managementsystem — UNECE
- ISO/SAE 21434:2021 Straßenfahrzeuge — Cybersecurity Engineering — ISO/SAE