CRA-Meldepflichten ab September 2026
Ist Ihr Schwachstellenprozess schnell genug?
Freitagabend, kurz nach 18 Uhr: Ein Sicherheitsforscher meldet eine Schwachstelle in einer Softwarekomponente. Im Supportpostfach liegt außerdem die Nachricht eines Kunden, der ungewöhnliche Zugriffe beobachtet hat. Noch ist unklar, ob beide Hinweise zusammenhängen und ob Angreifer die Schwachstelle bereits ausnutzen. Der zuständige Entwickler ist nicht mehr erreichbar, die Produktverantwortliche auf dem Heimweg und das Security-Team weiß nicht, wer eine Meldung nach dem Cyber Resilience Act freigeben darf.
Ein solcher Fall lässt sich nicht mit einem zusätzlichen Formular lösen. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei Produkten mit digitalen Elementen über die vorgesehene europäische Plattform melden. Für die erste Warnung bleiben nach Kenntnisnahme grundsätzlich 24 Stunden, für eine ausführlichere Meldung 72 Stunden. Wer erst im Ernstfall Zuständigkeiten, Produktscope und Informationswege klärt, verliert einen großen Teil dieser Zeit.
Die Herausforderung liegt weniger im Absenden als in den Schritten davor. Ein Unternehmen muss relevante Signale empfangen, bewerten, mit betroffenen Produkten verknüpfen und rechtzeitig an eine entscheidungsfähige Stelle eskalieren. Der Prozess muss auch nachts, am Wochenende und während Urlaubszeiten funktionieren. Dazu braucht es keine überladene Sicherheitsorganisation, wohl aber klare Rollen, gepflegte Produktdaten und geübte Abläufe.
Die Meldefrist beginnt nicht erst mit vollständiger Gewissheit
Viele etablierte Schwachstellenprozesse sind auf technische Behebung ausgerichtet. Ein Ticket wird angelegt, priorisiert, einem Sprint zugeordnet und irgendwann geschlossen. Für eine CRA-Meldung reicht dieses Modell nicht. Neben der technischen Arbeit läuft eine regulatorische Uhr, deren Startpunkt an die Kenntnis des Herstellers geknüpft ist.
In der Praxis ist dieser Zeitpunkt nicht immer bequem. Ein Hinweis erreicht vielleicht zuerst den Kundendienst, einen externen Hostingpartner oder einen Entwickler über ein öffentliches Repository. Wenn die Organisation keine Regeln für solche Eingänge festgelegt hat, wandert die Information durch mehrere Postfächer. Später lässt sich kaum sauber rekonstruieren, wann genügend Anhaltspunkte vorlagen und wer davon wusste.
Der Prozess sollte deshalb eine nachvollziehbare Zeitlinie erzeugen. Erfasst werden mindestens Eingang, Quelle, erste Sichtung, Eskalationen, Bewertungsentscheidungen und neue Erkenntnisse. Ein Zeitstempel im Ticketsystem ist hilfreich, ersetzt aber keine Definition dafür, wann ein Sachverhalt als bekannt gilt und welche Rolle diese Bewertung vornimmt.
Für Teams bedeutet das: Unsicherheit ist kein Grund, einen Hinweis liegen zu lassen. Sie ist ein Arbeitszustand, der dokumentiert und innerhalb einer festen Zeit bewertet werden muss. Die erste Warnung nach 24 Stunden verlangt noch nicht dieselbe Detailtiefe wie die nachfolgenden Berichte. Wer bis zur lückenlosen Ursachenanalyse wartet, kann die frühe Frist bereits versäumen.
Nicht jede gefundene Schwachstelle löst eine Meldung aus
Eine neue CVE-Nummer in einer verwendeten Bibliothek ist nicht automatisch ein meldepflichtiger Vorgang. Für die CRA-Meldepflicht ist bei Schwachstellen relevant, ob sie aktiv ausgenutzt wird. Das setzt verlässliche Hinweise voraus, dass ein böswilliger Akteur die Schwachstelle tatsächlich ausgenutzt hat. Ein theoretischer Proof of Concept, eine bloße Vermutung oder die reine öffentliche Bekanntheit sind davon zu unterscheiden.
Diese Unterscheidung darf jedoch nicht zu einer Warteschleife werden. Hinweise auf Exploitation können aus mehreren Quellen stammen: eigene Telemetrie, Kundenmeldungen, Informationen von Sicherheitsforschern, Warnungen von Behörden, Meldungen eines Komponentenherstellers oder Erkenntnisse aus Incident-Response-Arbeiten. Das Triage-Team muss festlegen, welche Belege vorliegen, wie belastbar sie sind und welche offenen Prüfungen sofort erfolgen.
Bei schwerwiegenden Sicherheitsvorfällen ist zu prüfen, ob die Sicherheit eines Produkts mit digitalen Elementen betroffen ist und die gesetzlichen Kriterien erreicht werden. Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit können eine Rolle spielen. Die Bewertung sollte technische Folgen, betroffene Nutzer, Dauer, geografische Verteilung und mögliche Schäden berücksichtigen. Ein gewöhnlicher Betriebsfehler ohne Sicherheitsbezug gehört nicht allein wegen seiner Größe in denselben Meldeweg.
Eine kurze Entscheidungsmatrix hilft im Bereitschaftsdienst. Sie enthält keine scheinbar exakte Formel, sondern Leitfragen, Belegarten und Eskalationsschwellen. Grenzfälle gehen an eine benannte fachliche und organisatorische Instanz. So entscheidet nicht der zufällig erreichbare Entwickler allein über die regulatorische Einordnung.
Der Produktscope muss vor dem Vorfall geklärt sein
Unternehmen sollten vor September erfassen, welche Angebote als Produkte mit digitalen Elementen in den Anwendungsbereich fallen und in welcher Rolle sie handeln. Hersteller, Importeure, Händler und Open-Source-Software-Stewards haben nicht in jeder Konstellation dieselben Pflichten. Auch die Abgrenzung zwischen Produkt, Dienstleistung, eingebetteter Komponente und unterstützender Cloudfunktion kann die Bearbeitung beeinflussen.
Im Sicherheitsfall fehlt die Zeit, Verträge, Architekturbilder und Verantwortungsgrenzen erstmals zusammenzutragen. Ein Produktregister sollte deshalb die verantwortliche Gesellschaft, Produktfamilie, unterstützte Versionen, zentrale Komponenten, Betriebsmodelle und interne Eigentümer enthalten. Bei White-Label-Lösungen und gemeinsam vermarkteten Produkten gehört auch die Rollenverteilung mit Partnern hinein.
Besonders wichtig ist die Verbindung zwischen technischem Asset und vermarktetem Produkt. Ein Alarm nennt möglicherweise einen Paketnamen, einen Container oder einen API-Dienst. Die Meldung und die Kundenkommunikation benötigen dagegen eine verständliche Aussage darüber, welche Produktversionen und Nutzer betroffen sind. Ohne diese Zuordnung beginnt während des Vorfalls eine aufwendige Suche.
Eine gepflegte Software Bill of Materials kann die Analyse beschleunigen. Sie zeigt, in welchen Produkten eine verwundbare Komponente steckt. Sie beantwortet aber nicht automatisch, ob der betroffene Codepfad erreichbar ist, welche Konfigurationen gefährdet sind oder ob eine aktive Ausnutzung stattgefunden hat. Diese technische Bewertung bleibt Aufgabe des Teams.
Ein zentraler Eingang verhindert verlorene Stunden
Sicherheitsinformationen kommen selten über genau einen Kanal. Neben Monitoring und SIEM existieren Supporttickets, E-Mails, Repository-Issues, Meldungen aus Bug-Bounty-Programmen und direkte Kontakte zu Mitarbeitern. Jeder dieser Wege braucht eine erkennbare Weiterleitung in denselben Triage-Prozess.
Für externe Hinweise sollte eine leicht auffindbare Sicherheitsadresse eingerichtet und überwacht werden. Eine aktuelle security.txt-Datei kann Forschern den richtigen Kontakt, unterstützte Sprachen und Regeln zur koordinierten Offenlegung nennen. Das Postfach darf nicht an eine einzelne Person gebunden sein. Vertretung, Spamprüfung und Alarmierung außerhalb der Bürozeiten gehören zum Betrieb.
Interne Teams benötigen ebenfalls eine einfache Meldeoption. Der Kundendienst sollte verdächtige Beobachtungen nicht technisch abschließend bewerten müssen. Er braucht erkennbare Beispiele, einen markierten Eskalationsweg und wenige Pflichtangaben: betroffenes Produkt, Zeitpunkt, Kontakt, beobachtetes Verhalten und vorhandene Belege.
Der zentrale Eingang ist kein einzelnes E-Mail-Postfach, sondern ein organisatorischer Kontrollpunkt. Jeder Hinweis erhält eine Kennung, einen verantwortlichen Bearbeiter und einen Status. Doppelte Meldungen werden zusammengeführt, ohne ursprüngliche Zeitstempel und Quellen zu verlieren. Automatische Benachrichtigungen helfen, doch ein Mensch muss ihre Zustellung und Übernahme kontrollieren.
Die ersten 60 Minuten brauchen einen festen Ablauf
Ein schneller Prozess beginnt mit einer kleinen Zahl klarer Handlungen. Nach Eingang eines relevanten Signals bestätigt der Bereitschaftsdienst den Empfang, sichert die Originalinformationen und eröffnet den Vorgang. Anschließend prüft er, ob das genannte Produkt bekannt ist, ob weitere Meldungen vorliegen und ob ein akutes Risiko für Kunden besteht.
Danach werden Security, Produktverantwortung und gegebenenfalls Incident Response einbezogen. Die Rollen müssen nicht in jeder Firma getrennte Personen sein. Auch ein kleines Softwareunternehmen kann eine primäre und eine stellvertretende Besetzung definieren. Wichtig ist, dass technische Untersuchung, geschäftliche Entscheidung und externe Kommunikation nicht unbemerkt bei einer unerreichbaren Einzelperson hängen bleiben.
Für die erste Stunde ist eine Checkliste sinnvoll. Sie verlangt etwa die Sicherung von Logs, die Erfassung aller Zeitpunkte, die Prüfung erreichbarer Systeme, eine erste Produktzuordnung und die Benennung eines Incident Leads. Außerdem wird festgelegt, wann der nächste Bewertungszeitpunkt stattfindet. Ein Vorgang mit unklarer Exploitation darf nicht kommentarlos bis zum nächsten Arbeitstag ruhen.
Die Checkliste sollte kurz bleiben. Eine Seite, die im Ernstfall gelesen wird, ist wertvoller als ein vierzigseitiges Handbuch im Intranet. Ausführliche Hintergrundinformationen, Kontaktlisten und Berichtsvorlagen können verlinkt werden. Telefonnummern und Vertretungen müssen offline oder über einen unabhängigen Weg verfügbar sein, falls das eigene System betroffen ist.
Die 24-Stunden-Warnung ist ein eigenes Arbeitsergebnis
Die frühe Warnung informiert über eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall. Sie soll schnell erfolgen und kann deshalb auf dem zu diesem Zeitpunkt verfügbaren Wissensstand beruhen. Das Unternehmen sollte trotzdem belastbare Kerndaten liefern und Vermutungen als solche kennzeichnen.
Eine vorbereitete Vorlage spart Zeit. Sie umfasst Identität und Kontakt des Meldenden, betroffenes Produkt oder betroffene Produktgruppe, Art des Vorgangs, Zeitpunkt der Kenntnisnahme, bekannte Auswirkungen sowie verfügbare Hinweise zur Ausnutzung. Bei Vorfällen kann außerdem angegeben werden, ob ein rechtswidriger oder böswilliger Akt vermutet wird und ob grenzüberschreitende Auswirkungen bekannt sind.
Vorlagen dürfen keine Hürde bilden. Wenn einzelne Felder noch nicht geklärt sind, wird der bekannte Stand gemeldet und später ergänzt. Intern sollte klar sein, wer die Angaben technisch prüft, wer die Meldung freigibt und wer sie absendet. Eine Kette aus fünf hierarchischen Genehmigungen ist mit Bereitschaftszeiten und Wochenenden kaum vereinbar.
Das Team dokumentiert die übermittelten Inhalte, Empfangsbestätigungen und Plattformreferenzen im Vorgang. Screenshots allein sind dafür wenig geeignet. Besser ist eine exportierbare oder unveränderbar abgelegte Kopie der Meldung samt Anhängen und Zeitstempeln. So bleibt später erkennbar, auf welchem Informationsstand Entscheidungen beruhten.
Bis zur 72-Stunden-Meldung muss das Bild deutlich schärfer werden
Die ausführlichere Meldung nach spätestens 72 Stunden benötigt zusätzliche Angaben. Bei einer aktiv ausgenutzten Schwachstelle gehören verfügbare Informationen zum betroffenen Produkt, zur Art und Ausnutzung der Schwachstelle sowie zu bereits getroffenen Korrektur- oder Risikominderungsmaßnahmen dazu. Bei einem schwerwiegenden Vorfall werden erste Bewertungen, Schwere und Auswirkungen genauer beschrieben.
Zwischen der frühen Warnung und diesem Bericht darf die Untersuchung nicht nur technisch weiterlaufen. Ein Koordinator sammelt Ergebnisse in einer gemeinsamen Lageübersicht. Betroffene Versionen, Angriffsvektor, beobachtete Indikatoren, Kundenauswirkungen und Gegenmaßnahmen werden mit Quelle und Prüfstatus geführt. Widersprüche bleiben sichtbar, bis sie geklärt sind.
Teams sollten früh zwischen bestätigten Tatsachen, plausiblen Annahmen und offenen Punkten trennen. Diese einfache Kennzeichnung verhindert, dass eine erste Vermutung später versehentlich als gesicherte Ursache gemeldet wird. Änderungen gegenüber der 24-Stunden-Warnung werden erklärt, nicht still überschrieben.
Technische Maßnahmen und Berichterstattung dürfen sich nicht gegenseitig blockieren. Ein kritischer Fix kann parallel entwickelt werden, während ein anderer Bearbeiter die Meldung vorbereitet. Der Incident Lead priorisiert Ressourcen und hält die Zeitfenster im Blick. Eine sichtbare Fristenanzeige im Ticket oder Einsatzkanal reduziert das Risiko, dass alle an der Ursache arbeiten und niemand den Bericht versendet.
Nach 72 Stunden ist der Meldeprozess nicht beendet
Für aktiv ausgenutzte Schwachstellen folgt ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist. Bei schwerwiegenden Vorfällen ist der Abschlussbericht grundsätzlich innerhalb eines Monats nach der ausführlicheren Meldung vorgesehen. Darin werden Ursache, Verlauf, Auswirkungen und ergriffene Maßnahmen nachvollziehbar zusammengeführt.
Diese Phase profitiert von einer sauberen Chronologie. Wer während des Vorfalls Entscheidungen, Versionen und Kommunikationsschritte dokumentiert hat, muss Wochen später keine Erinnerung rekonstruieren. Der Abschlussbericht sollte zu Post-Incident-Review, Patchdokumentation und Kundeninformation passen. Abweichende Zahlen oder Zeitangaben erzeugen unnötige Rückfragen.
Der Vorgang wird erst geschlossen, wenn offene Maßnahmen einen Eigentümer und Termin haben. Dazu können zusätzliche Erkennungsregeln, Architekturänderungen, aktualisierte Abhängigkeiten oder Verbesserungen am Bereitschaftsplan gehören. Auch die Frage, warum ein Signal spät erkannt oder falsch geroutet wurde, gehört in die Nachbereitung.
Ein guter Abschluss verwandelt den Vorfall in eine konkrete Prozessverbesserung. Er misst etwa Zeit bis zur Erkennung, Zeit bis zur internen Eskalation, Zeit bis zur Produktzuordnung und Zeit bis zur Meldung. Diese Werte zeigen präziser als ein allgemeines Sicherheitsgefühl, ob der Ablauf tatsächlich schneller wird.
Die Single Reporting Platform ist nur der letzte Übergabepunkt
Die CRA Single Reporting Platform soll zum 11. September 2026 als zentraler elektronischer Meldeweg bereitstehen. Hersteller übermitteln dort eine Meldung und wählen den koordinierenden CSIRT aus, der sich in der Regel nach der Hauptniederlassung in der Europäischen Union richtet. Die Plattform verteilt die Informationen nach den vorgesehenen Regeln an die zuständigen Stellen und ENISA.
Unternehmen sollten den Zugang nicht am Tag des ersten Vorfalls einrichten. Sobald Testmöglichkeiten und verbindliche Registrierungsinformationen verfügbar sind, gehören Benutzerkonten, Rollen und Mehrfaktorverfahren in den Bereitschaftstest. Mindestens zwei autorisierte Personen sollten eine Meldung absetzen können. Ausscheidende Mitarbeiter müssen aus den Berechtigungen entfernt werden.
Auch ein Ausfall oder Zugriffsproblem braucht einen Plan. Kontaktinformationen des zuständigen CSIRT und interne Eskalationswege werden unabhängig von der Plattform gepflegt. Fehlermeldungen, Versandversuche und Zeitpunkte sollten dokumentiert werden. Der Meldeprozess darf nicht auf der Annahme beruhen, dass jedes externe System jederzeit erreichbar ist.
Die Plattform nimmt dem Hersteller weder die Bewertung noch die Datensammlung ab. Wenn Produktbezeichnungen uneinheitlich, Ansprechpartner unbekannt und Auswirkungen ungeklärt sind, macht ein digitales Formular den Vorgang nicht schneller. Seine Felder sollten früh in die eigenen Berichtsvorlagen und Übungen einfließen.
Bereitschaft außerhalb der Bürozeiten realistisch organisieren
Eine Frist von 24 Stunden umfasst Wochenenden und Feiertage. Ein Hinweis am Freitagabend kann daher nicht bis Montag warten. Unternehmen brauchen eine Bereitschaft, die zu ihrem Risiko und ihrer Größe passt. Das muss nicht automatisch ein rund um die Uhr besetztes Security Operations Center sein.
Kleine Teams können einen rotierenden Rufplan, einen externen Monitoringdienst und klare Eskalationsschwellen kombinieren. Ein Dienstleister darf Signale annehmen und vorbewerten. Verantwortlichkeit, Entscheidungsbefugnis und Zugriff auf Produktwissen müssen trotzdem geregelt bleiben. Verträge sollten Reaktionszeiten, Kontaktwege, Beweissicherung und Unterstützung bei Meldungen konkret beschreiben.
Die erreichbare Person benötigt Zugriff auf die nötigen Systeme, nicht nur eine Telefonnummernliste. VPN, Passwortmanager, Plattformkonto und Notfalldokumentation werden unter realistischen Bedingungen getestet. Wenn für jeden Zugriff zunächst ein Administrator am nächsten Werktag gebraucht wird, existiert faktisch keine Bereitschaft.
Rufbereitschaft braucht außerdem Grenzen. Nicht jede Warnung soll nachts das gesamte Entwicklungsteam alarmieren. Eine abgestufte Triage schützt Ressourcen und sorgt dafür, dass kritische Signale ernst genommen werden. Regelmäßige Auswertung von Fehlalarmen verbessert die Regeln, ohne die Schwelle für echte Vorfälle unkontrolliert anzuheben.
Lieferketten und Open-Source-Komponenten einbeziehen
Viele Schwachstellen entstehen nicht im eigenen Quellcode, sondern in Bibliotheken, Frameworks, Firmware oder zugekauften Modulen. Ein Hersteller bleibt für sein Produkt handlungsfähig, wenn er seine Abhängigkeiten kennt und Sicherheitsinformationen der Lieferanten systematisch empfängt.
Verträge und Beschaffungsprozesse sollten deshalb Sicherheitskontakte, Benachrichtigungsfristen und verfügbare technische Informationen berücksichtigen. Eine allgemeine Zusage zur Zusammenarbeit reicht während einer laufenden 72-Stunden-Frist selten aus. Benötigt werden betroffene Versionen, Ausnutzungsbedingungen, Indikatoren und geplante Korrekturmaßnahmen.
Bei Open Source fehlen oft vertragliche Ansprechpartner. Teams sollten relevante Projekte, Security Advisories, Paketquellen und Maintainer-Hinweise beobachten. Automatische Dependency-Scanner liefern wertvolle Signale, erzeugen aber auch große Mengen nicht erreichbarer oder nicht ausnutzbarer Treffer. Die Ergebnisse brauchen Kontext aus Architektur und Produktbetrieb.
Wenn mehrere Beteiligte denselben Sachverhalt untersuchen, muss intern klar sein, wer für das eigene Produkt meldet. Die Annahme, ein Cloudanbieter oder Bibliothekshersteller werde alle Pflichten stellvertretend erledigen, ist riskant. Rollen, Informationsaustausch und Kundenschnittstellen werden vorab schriftlich festgehalten.
Kundenkommunikation und Behördenmeldung getrennt planen
Eine CRA-Meldung ist nicht identisch mit einer öffentlichen Sicherheitsmitteilung oder einer individuellen Kundenbenachrichtigung. Empfänger, Zweck, Zeitpunkt und Detailgrad unterscheiden sich. Trotzdem müssen alle Kommunikationsstränge auf demselben bestätigten Sachstand beruhen.
Zu frühe technische Details können eine laufende Ausnutzung erleichtern. Zu späte Informationen können Kunden daran hindern, Schutzmaßnahmen umzusetzen. Produkt-, Security- und Kommunikationsteam benötigen deshalb einen abgestimmten Freigabeweg. Vorbereitete Textbausteine helfen bei Struktur und Kontaktdaten, dürfen den konkreten Sachverhalt aber nicht verharmlosen.
Die Lageübersicht sollte festhalten, welche Zielgruppen bereits informiert wurden, welche Version eines Hinweises sie erhalten haben und wann ein Update fällig ist. Statusseiten, E-Mails, Supportskripte und Advisories müssen konsistent bleiben. Für internationale Produkte sind Übersetzung und Zeitzonen einzuplanen.
Eine Person koordiniert die Aussagen, ohne jede technische Formulierung selbst zu schreiben. Das verhindert parallele, widersprüchliche Nachrichten. Zugleich bleibt die technische Behebung handlungsfähig, weil Entwickler nicht jede Kundenanfrage einzeln beantworten müssen.
Beweise sichern, ohne die Behebung auszubremsen
Logs, Speicherabbilder, Konfigurationen und betroffene Artefakte können für Ursachenanalyse und Bericht wichtig sein. Unter Zeitdruck werden Systeme jedoch häufig neu gestartet, Container ersetzt oder Daten überschrieben. Eine kurze Sicherungsanweisung legt fest, welche Belege vor Veränderungen kopiert werden und wer ihre Integrität dokumentiert.
Die Sammlung sollte datensparsam erfolgen. Sicherheitsprotokolle können personenbezogene oder vertrauliche Informationen enthalten. Zugriffsrechte, Aufbewahrung und Weitergabe werden kontrolliert. Für die Meldung werden nur erforderliche Informationen aufbereitet; interne Rohdaten müssen nicht ungeprüft hochgeladen werden.
Werkzeuge helfen bei Zeitlinie, Hashwerten und Zugriffsnachweisen. Ein komplexes Forensiksystem ist aber keine Voraussetzung für einen funktionierenden Grundprozess. Wichtiger sind ein definierter Ablageort, unveränderte Originale und eine verständliche Dokumentation der Erhebung.
Bei laufenden Angriffen hat die Eindämmung Vorrang. Die Sicherung wird so gestaltet, dass sie Schutzmaßnahmen nicht unnötig verzögert. Solche Abwägungen lassen sich besser treffen, wenn sie in Übungen bereits besprochen wurden und ein Incident Lead die Entscheidung dokumentiert.
Ein Tabletop-Test zeigt die echten Lücken
Prozessdokumente wirken am Schreibtisch oft vollständig. Ein zweistündiger Tabletop-Test mit einem realistischen Szenario zeigt, ob Kontakte, Zugänge und Entscheidungen tatsächlich funktionieren. Dafür genügt ein erfundener Hinweis auf eine aktiv ausgenutzte Bibliothek in mehreren Produktversionen.
Das Team spielt den Ablauf mit Zeitdruck durch: Eingang im Support, Triage, Produktzuordnung, Belegprüfung, interne Eskalation, 24-Stunden-Warnung und Vorbereitung der 72-Stunden-Meldung. Der Moderator gibt schrittweise neue Informationen hinzu, etwa einen betroffenen Großkunden, widersprüchliche Logdaten oder einen nicht erreichbaren Lieferanten.
Beobachtet werden Übergaben und Wartezeiten. Die Auswertung hält fest, ob das Team die unterstützten Versionen benennen konnte, eine autorisierte Vertretung erreichbar war und die nötigen Kontaktdaten unabhängig vom normalen Firmennetz zur Verfügung standen. Außerdem zeigt sie, ob sich aus den gesammelten Informationen eine verständliche Meldung erstellen ließ.
Nach der Übung entstehen wenige priorisierte Maßnahmen mit Verantwortlichen und Terminen. Fehlende Rufnummern werden sofort ergänzt, strukturelle Themen wie Produktinventar oder Vertragsänderungen geplant. Eine Wiederholung vor dem 11. September prüft, ob die Verbesserungen greifen.
Typische Prozessfehler vor dem Start beseitigen
Der erste häufige Fehler ist das Warten auf vollständige Gewissheit. Untersuchung braucht Zeit, die frühe Warnung ist jedoch gerade für einen noch unvollständigen Wissensstand vorgesehen. Teams sollten Unsicherheit transparent dokumentieren und Erkenntnisse in den späteren Meldungen aktualisieren.
Der zweite Fehler ist eine rein juristische Eskalationskette. Fachliche Prüfung ist wichtig, doch ohne technische Fakten kann niemand sinnvoll entscheiden. Security, Produkt, Geschäftsverantwortung und zuständige Fachberatung brauchen einen gemeinsamen schnellen Weg mit definierten Stellvertretungen.
Der dritte Fehler ist Vertrauen in ein Tool. Ein Ticketsystem erinnert an Fristen, erkennt aber keine unklaren Produktgrenzen. Ein Scanner findet verwundbare Pakete, bewertet jedoch nicht jede aktive Ausnutzung korrekt. Automatisierung unterstützt einen verantworteten Prozess; sie ersetzt ihn nicht.
Der vierte Fehler sind ungepflegte Stammdaten. Alte Versionslisten, unbekannte Eigentümer und fehlende Lieferantenkontakte kosten im Vorfall Stunden. Diese Grundlagen lassen sich vorab mit überschaubarem Aufwand verbessern und helfen auch außerhalb der CRA-Meldung.
Ein pragmatischer Vorbereitungsplan bis zum 11. September
In der ersten Woche werden Scope und Verantwortung geklärt. Das Unternehmen benennt die betroffenen Produktfamilien, verantwortlichen Gesellschaften, primären Entscheider und Stellvertretungen. Außerdem bestimmt es den zentralen Eingang für Sicherheitshinweise und prüft dessen Überwachung.
In der zweiten Woche entsteht ein schlanker Ablauf. Er enthält Triage-Kriterien, Eskalationsstufen, Zeitmessung, Vorlagen für frühe und ausführliche Meldung sowie die vorgesehenen Freigaben. Kontaktlisten werden vervollständigt und außerhalb des üblichen Systems verfügbar gemacht.
In der dritten Woche werden Produktregister, Komponenteninformationen und Lieferantenkontakte anhand eines Beispiels getestet. Das Team verfolgt eine verwundbare Bibliothek bis zu den betroffenen Produktversionen und formuliert mögliche Minderungsmaßnahmen. Lücken erhalten Eigentümer und Priorität.
Vor dem Stichtag folgt eine Übung über ein Wochenende oder zumindest mit simulierter Nichterreichbarkeit. Die gemessenen Zeiten zeigen, ob 24 und 72 Stunden realistisch eingehalten werden können. Offene Verbesserungen werden nach Risiko priorisiert; der Kernprozess muss einsatzfähig sein, auch wenn noch nicht jedes Komfortmerkmal umgesetzt wurde.
Fazit
Die CRA-Meldepflichten machen Geschwindigkeit zu einer organisatorischen Eigenschaft. Schnelle Entwickler allein genügen nicht. Sicherheitsinformationen müssen zuverlässig ankommen, betroffene Produkte müssen bekannt sein und entscheidungsfähige Personen müssen auch außerhalb der Bürozeiten erreichbar bleiben.
Ein belastbarer Schwachstellenprozess trennt technische Behebung, regulatorische Meldung und Kundenkommunikation, führt sie aber in einer gemeinsamen Lageübersicht zusammen. Er akzeptiert einen zunächst unvollständigen Wissensstand, dokumentiert Entscheidungen und verbessert die Faktenlage von der 24-Stunden-Warnung über die 72-Stunden-Meldung bis zum Abschlussbericht.
Wer jetzt Produktregister, Eingangskanäle, Rollen und Vorlagen prüft, kann die verbleibende Zeit sinnvoll nutzen. Der beste Nachweis ist keine Prozessgrafik, sondern eine Übung, bei der das Team einen realistischen Fall fristgerecht bearbeitet und seine Lücken sichtbar macht.