Seit dem 11. September 2026 gelten für Hersteller von Produkten mit digitalen Elementen im EU-Binnenmarkt die Meldepflichten des Cyber Resilience Act (CRA). Bestätigt ist: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen gemeldet werden. Das BSI begleitet den Start mit Schritt-für-Schritt-Anleitungen. Für Unternehmen ist das weniger eine zusätzliche Formularaufgabe als eine neue Anforderung an Produktbetrieb, Security und Entscheidungswege.
Was seit dem 11. September 2026 feststeht
Die bestätigte Kernbotschaft ist klar abgegrenzt: Adressiert sind Hersteller von Produkten mit digitalen Elementen auf dem EU-Binnenmarkt. Meldegegenstand sind aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle. Das BSI stellt dafür Umsetzungsanleitungen bereit. Weitergehende Einzelfragen – etwa die genaue Einordnung eines konkreten Produkts oder Vorfalls – sollten Unternehmen anhand der offiziellen Anleitung und bei Bedarf mit qualifizierter Rechtsberatung prüfen.
Die operative Konsequenz lässt sich trotzdem sofort ableiten: Ein Hersteller braucht einen verlässlichen Weg vom ersten Signal bis zur freigegebenen Meldung. Dafür müssen technische Erkenntnisse, Produktbezug, Auswirkungsbewertung und Verantwortlichkeit zusammengeführt werden. Ein isoliertes Ticket im IT-Service-Management genügt nicht, wenn niemand sicher entscheidet, ob der Fall das Produkt, seine Nutzer oder den regulatorischen Meldeprozess betrifft.
Bereitschaftscheck: Ist Ihr Meldeprozess handlungsfähig?
Geschäftsführer und operative Entscheider sollten nicht mit einer abstrakten CRA-Gap-Analyse beginnen, sondern mit einem realistischen Testfall: Heute meldet ein Kunde eine möglicherweise ausgenutzte Schwachstelle. Kann das Unternehmen innerhalb kurzer Zeit Produkt, Version, Verbreitung, beobachtete Ausnutzung und mögliche Auswirkungen zusammenführen? Der folgende Check macht Lücken sichtbar, ohne eine juristische Bewertung vorwegzunehmen.
- Produktinventar: Verantwortliche können jedes digitale Produkt, unterstützte Versionen und technische Ansprechpartner eindeutig zuordnen.
- Eingangskanäle: Support, Security-Postfach, Monitoring und externe Hinweise laufen in einen gemeinsamen Triage-Prozess.
- Beweissicherung: Logs, Zeitpunkte, betroffene Versionen und technische Beobachtungen werden nachvollziehbar und unverändert gesichert.
- Bewertung: Security, Produkt und Betrieb unterscheiden bestätigte Fakten, offene Hypothesen und noch fehlende Nachweise.
- Entscheidung: Eine benannte Rolle darf die regulatorische Prüfung auslösen und die Geschäftsführung bei wesentlichen Fällen eskalieren.
- Freigabe: Inhaltliche, technische und rechtliche Prüfung haben Stellvertretungen; der Prozess hängt nicht an einer einzelnen Person.
- Nachlauf: Korrekturen, Kundenkommunikation und Produktmaßnahmen werden mit der ursprünglichen Meldung verknüpft dokumentiert.
Fehlen mehrere dieser Punkte, ist die wichtigste Investition nicht zwangsläufig ein neues Tool. Meist hilft zuerst eine eindeutige Zuständigkeitsmatrix, ein gemeinsames Fallobjekt und ein fester Eskalationsweg. Automatisierung lohnt sich anschließend dort, wo Daten wiederholt aus Produktinventar, Ticketing, Monitoring und Versionsverwaltung zusammengetragen werden. Die regulatorische Entscheidung selbst sollte nachvollziehbar bei benannten Menschen bleiben.
Vom Warnsignal zur belastbaren CRA-Meldung
Ein praxistauglicher Ablauf trennt Erkennung, technische Prüfung und Meldeentscheidung. Das verhindert zwei typische Fehlsteuerungen: vorschnelles Melden auf Basis ungesicherter Vermutungen und zu spätes Eskalieren, weil Teams erst vollständige Ursachenanalysen abwarten. Für den Start reicht ein schlanker, dokumentierter Workflow.
- Signal erfassen: Quelle, Zeitpunkt, Produkt, Version und beobachtetes Verhalten in einem zentralen Fall dokumentieren.
- Fakten sichern: Technische Indikatoren und Auswirkungen festhalten; Annahmen ausdrücklich als unbestätigt kennzeichnen.
- Produktbezug klären: Verantwortliche aus Produkt, Entwicklung, Betrieb und Security zusammenbringen.
- Meldeprüfung auslösen: Den Fall anhand der offiziellen BSI-Anleitung gegen die CRA-Kriterien prüfen.
- Freigabe und Übermittlung steuern: Zuständigkeit, Vier-Augen-Prüfung und nachvollziehbare Entscheidung dokumentieren.
- Maßnahmen nachhalten: Behebung, weitere Analyse, Kundeninformation und spätere Aktualisierungen im selben Fall verknüpfen.
Dieser Ablauf ist bewusst technologieunabhängig. Ein kleiner Hersteller kann ihn zunächst mit vorhandenem Ticketing und klaren Vorlagen abbilden. Bei größerem Produktportfolio sollte ein Orchestrierungsdienst Daten aus Monitoring, Asset- und Versionssystemen vorbefüllen, Dubletten erkennen und offene Pflichtfelder anzeigen. Entscheidend ist nicht die Anzahl der Integrationen, sondern dass jede Information eine Quelle, einen Status und einen verantwortlichen Eigentümer hat.
Was die Geschäftsführung jetzt entscheiden sollte
Die CRA-Meldepflicht ist seit dem 11. September 2026 keine Zukunftsplanung mehr. Das Management sollte deshalb drei Entscheidungen verbindlich treffen: Wer besitzt den Meldeprozess? Wer entscheidet bei unvollständiger Faktenlage über die Eskalation? Und welche Produktdaten müssen jederzeit verfügbar sein? Diese Fragen verbinden Compliance mit realer Betriebsfähigkeit.
Ein sinnvoller erster Schritt ist eine einstündige Simulation mit einem aktiv ausgenutzten Schwachstellenszenario. Gemessen wird nicht, ob Teams das richtige Formular kennen, sondern ob sie Zuständigkeit, Produktbezug und Evidenz ohne Suchschleifen herstellen. Die gefundenen Brüche ergeben einen priorisierten Maßnahmenplan. So wird aus einer regulatorischen Pflicht ein belastbarer Incident-Prozess, der auch bei echten Angriffen schneller und kontrollierter funktioniert.