Ab dem 11. September 2026 beginnt beim Cyber Resilience Act eine besonders praktische Phase: Hersteller bestimmter Hard- und Softwareprodukte müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die umfassenden Produktanforderungen des CRA greifen zwar erst später, doch die Reporting-Pflichten starten bereits jetzt.
Für Unternehmen in Deutschland ist das mehr als ein juristisches Detail. Wer vernetzte Geräte, Apps, Softwarekomponenten oder andere Produkte mit digitalen Elementen unter eigenem Namen in der EU anbietet, sollte wissen, wann eine Meldung nötig wird, welche Fristen laufen und wie sich technische Teams, Produktmanagement und Compliance darauf vorbereiten können.
Der Cyber Resilience Act, offiziell Verordnung (EU) 2024/2847, ist seit dem 10. Dezember 2024 in Kraft. Die meisten materiellen Verpflichtungen gelten ab dem 11. Dezember 2027. Die Meldepflichten nach dem CRA werden jedoch bereits ab dem 11. September 2026 angewendet. Genau diese zeitliche Staffelung macht den September 2026 für Hersteller so relevant.
Was ändert sich ab dem 11. September 2026?
Die Europäische Kommission fasst die neue Lage klar zusammen: Hersteller müssen aktiv ausgenutzte Schwachstellen sowie schwerwiegende Vorfälle melden, wenn diese die Sicherheit eines Produkts mit digitalen Elementen betreffen.
Die Fristen sind gestaffelt. Zunächst muss innerhalb von 24 Stunden nach Bekanntwerden eine Frühwarnung erfolgen. Danach folgt innerhalb von 72 Stunden eine vollständige Meldung. Für aktiv ausgenutzte Schwachstellen ist außerdem spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme ein Abschlussbericht vorgesehen. Bei schwerwiegenden Sicherheitsvorfällen muss der Abschlussbericht innerhalb eines Monats eingereicht werden.
| Schritt | Frist | Zweck |
|---|---|---|
| Frühwarnung | innerhalb von 24 Stunden | Schnelle Information über eine aktiv ausgenutzte Schwachstelle oder einen schweren Sicherheitsvorfall |
| Vollständige Meldung | innerhalb von 72 Stunden | Ergänzende technische und organisatorische Informationen zum Fall |
| Abschlussbericht bei Schwachstelle | spätestens 14 Tage nach Verfügbarkeit einer Korrektur | Dokumentation der Abhilfemaßnahmen |
| Abschlussbericht bei schwerem Vorfall | innerhalb eines Monats | Zusammenfassung von Auswirkungen, Ursachen und Gegenmaßnahmen |
Die Meldung soll über die von ENISA eingerichtete CRA Single Reporting Platform erfolgen. Nach Angaben der Kommission soll sie mit Beginn der Meldepflichten am 11. September 2026 betriebsbereit sein.
Welche Produkte betrifft der Cyber Resilience Act?
Der CRA ist bewusst breit angelegt. Er gilt grundsätzlich für Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Dazu gehören sowohl fertige Produkte als auch Komponenten, die separat verkauft oder bereitgestellt werden.
Typische Beispiele können vernetzte Haushaltsgeräte, Router, Smart-Home-Komponenten, Apps, Desktop-Software, Betriebssysteme, industrielle Steuerungskomponenten oder Softwarebibliotheken sein, sofern sie unter die rechtliche Definition und den kommerziellen Anwendungsbereich fallen.
Die Verordnung richtet ihre zentralen Pflichten vor allem an Hersteller, also an natürliche oder juristische Personen, die ein Produkt unter ihrem eigenen Namen oder ihrer eigenen Marke auf den Markt bringen. Je nach Rolle kommen daneben auch Pflichten für Importeure, Händler und andere Wirtschaftsakteure hinzu.
Die Kommission hat im Juli 2026 zusätzliche Leitlinien veröffentlicht, die unter anderem erklären, welche Produkte erfasst werden, wie mit wesentlichen Änderungen umzugehen ist und wie Support-Zeiträume verstanden werden sollen.
Nicht jede Schwachstelle löst automatisch eine 24-Stunden-Meldung aus
Für die Praxis ist diese Unterscheidung wichtig. Der CRA verlangt nicht, dass jede intern gefundene Sicherheitslücke sofort über die Plattform gemeldet wird. Im Mittelpunkt der ab September geltenden Meldepflicht stehen insbesondere aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle.
Damit wird die Fähigkeit zur schnellen Bewertung entscheidend. Ein Unternehmen muss innerhalb kurzer Zeit einschätzen können, ob tatsächlich eine aktive Ausnutzung vorliegt, welche Produkte und Versionen betroffen sind und ob das Ereignis die Schwelle zu einem schwerwiegenden Vorfall erreicht.
Diese Bewertung lässt sich kaum erst dann aufbauen, wenn ein Alarm bereits eingegangen ist. Sinnvoll ist deshalb ein vorbereiteter Prozess, in dem technische Analyse, Product Security, Incident Response und rechtliche Bewertung ineinandergreifen.
Warum die 24-Stunden-Frist organisatorisch anspruchsvoll ist
Eine Frist von 24 Stunden klingt zunächst nach einem reinen Meldeproblem. Tatsächlich zwingt sie Unternehmen vor allem dazu, ihre Informationswege zu überprüfen.
Stellen wir uns einen Hersteller eines vernetzten Geräts vor. Ein externer Security Researcher meldet eine Schwachstelle. Gleichzeitig beobachtet das Security-Team verdächtige Zugriffe, die zu dieser Lücke passen könnten. Wenn nun erst geklärt werden muss, wer intern zuständig ist, welches Produktteam betroffen ist und wer eine Meldung freigeben darf, geht wertvolle Zeit verloren.
Ein robuster Prozess beantwortet deshalb schon vorher fünf Fragen:
- Wer nimmt externe Vulnerability-Meldungen entgegen?
- Wer entscheidet, ob Anzeichen für aktive Ausnutzung vorliegen?
- Wer prüft die rechtlichen Meldekriterien?
- Wer darf die Meldung über die Reporting-Plattform absenden?
- Wie werden technische Updates und Abschlussberichte nachverfolgt?
Gerade kleinere Unternehmen müssen dafür kein großes Security Operations Center aufbauen. Aber Rollen, Eskalationswege und Kontaktdaten sollten dokumentiert sein.
Was Unternehmen jetzt konkret vorbereiten können
1. Produktportfolio klassifizieren
Der erste Schritt ist eine belastbare Übersicht darüber, welche Produkte überhaupt als Produkte mit digitalen Elementen in Betracht kommen. Dabei sollten nicht nur fertige Geräte betrachtet werden, sondern auch Software, eigenständig vertriebene Komponenten und cloud- oder remote-bezogene Funktionen, soweit sie für das Produkt relevant sind.
2. Vulnerability-Management dokumentieren
Unternehmen sollten nachvollziehbar beschreiben können, wie Sicherheitslücken gemeldet, bewertet, priorisiert und geschlossen werden. Dazu gehört auch die Frage, wie Hinweise externer Forscher oder Kunden verarbeitet werden.
Ein solcher Prozess ergänzt klassische Schutzmaßnahmen gegen Angriffe. Wer sich tiefer mit heutigen Angriffsmustern beschäftigen möchte, findet auf Röschel auch den Beitrag Ransomware-Evolution: Doppel-Erpressungstaktiken und Prävention.
3. Kriterien für aktive Ausnutzung definieren
Security-Teams brauchen eine gemeinsame Sprache dafür, welche Signale als belastbarer Hinweis auf aktive Ausnutzung gelten. Das können beispielsweise bestätigte Angriffsspuren, reproduzierbare Indicators of Compromise, Erkenntnisse aus Telemetrie oder glaubwürdige externe Meldungen sein.
Automatisierte Erkennung und KI können dabei unterstützen, ersetzen aber nicht die fachliche Bewertung. Welche neuen Risiken durch maschinelles Lernen selbst entstehen können, beleuchtet unser Hintergrundartikel AI-gestützte Cyberangriffe: Neue Bedrohungen durch maschinelles Lernen.
4. Einen 24/72-Stunden-Workflow testen
Ein kurzer Tabletop-Test kann viel sichtbar machen. Das Team simuliert einen realistischen Vorfall und prüft, ob innerhalb von 24 Stunden eine erste Einschätzung und innerhalb von 72 Stunden eine vollständige Meldung möglich wäre.
Dabei geht es nicht darum, perfekte Informationen zu haben. Gerade die Staffelung der Fristen zeigt, dass die erste Meldung früh erfolgen soll und später ergänzt werden kann. Entscheidend ist, dass Zuständigkeiten, Datenquellen und Freigaben funktionieren.
5. Technische Produktinformationen zentral verfügbar machen
Wenn eine Schwachstelle gemeldet werden muss, sollte schnell klar sein, welche Produktversionen betroffen sind, welche Komponenten verbaut oder integriert wurden und welche Nutzergruppen potenziell betroffen sind. Eine gepflegte Software Bill of Materials kann hier je nach Produkt einen wichtigen Baustein bilden.
Was ist mit Open Source?
Der CRA behandelt freie und quelloffene Software differenziert. Nach Angaben der Kommission fällt freie und quelloffene Software grundsätzlich dann in den Anwendungsbereich, wenn sie auf dem Markt bereitgestellt und im Rahmen einer kommerziellen Tätigkeit angeboten wird. Nicht monetarisierte Open-Source-Beiträge und Entwickler, die lediglich Code zu Projekten beitragen, für die sie nicht verantwortlich sind, werden anders behandelt.
Das ist besonders relevant für Unternehmen, die Open-Source-Komponenten nicht nur intern verwenden, sondern selbst paketieren, vertreiben oder kommerziell verantworten. Die genaue Rolle im Software-Ökosystem kann daher entscheidend sein.
Reporting ab 2026, Produktanforderungen ab 2027: der Zeitplan
Ein häufiges Missverständnis rund um den CRA betrifft den Starttermin. Der Rechtsakt ist bereits in Kraft, doch nicht alle Pflichten beginnen gleichzeitig.
| Datum | Bedeutung |
|---|---|
| 10. Dezember 2024 | Cyber Resilience Act tritt in Kraft |
| 11. September 2026 | Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle beginnen |
| 11. Dezember 2027 | Die meisten übrigen CRA-Verpflichtungen werden anwendbar |
Für Unternehmen bedeutet das: September 2026 ist kein allgemeiner Stichtag, an dem jedes Produkt bereits sämtliche künftigen CRA-Anforderungen erfüllen muss. Er ist aber ein konkreter operativer Stichtag für das Reporting.
Warum der CRA auch eine Chance für bessere Produktentwicklung ist
Regulatorische Anforderungen werden leicht als zusätzliche Dokumentationsarbeit wahrgenommen. Beim CRA steckt jedoch ein technischer Gedanke dahinter, der unabhängig von Compliance sinnvoll ist: Sicherheit soll nicht erst nach dem Verkauf eines Produkts beginnen.
Wenn Schwachstellenmanagement, Update-Prozesse, Risikobewertung und Support bereits in die Produktentwicklung eingebaut werden, entsteht ein klareres Bild über den gesamten Lebenszyklus eines digitalen Produkts. Das kann nicht nur regulatorische Risiken reduzieren, sondern auch Support, Qualitätssicherung und technische Wartung verbessern.
Die Herausforderung besteht darin, den CRA nicht als isoliertes Rechtsprojekt zu behandeln. Sobald ausschließlich die Rechtsabteilung verantwortlich ist, fehlt möglicherweise der technische Kontext. Wird er ausschließlich als Security-Thema betrachtet, fehlen wiederum Produktverantwortung und Compliance-Perspektive.
Eine praktische Checkliste für September 2026
| Frage | Sollte jetzt geklärt sein |
|---|---|
| Welche unserer Produkte könnten unter den CRA fallen? | Produktliste mit verantwortlichen Teams |
| Wer erkennt und bewertet Schwachstellen? | Definierter Product-Security- oder Incident-Prozess |
| Wer entscheidet über eine CRA-Meldung? | Klare technische und rechtliche Zuständigkeit |
| Können wir in 24 Stunden reagieren? | Getesteter Eskalationsweg |
| Können wir innerhalb von 72 Stunden belastbare Zusatzinformationen liefern? | Zugriff auf Produkt-, Versions- und Incident-Daten |
| Wer verfolgt Korrekturmaßnahmen und Abschlussberichte? | Verantwortliche Person und dokumentierter Workflow |
Wann beginnt die Meldefrist wirklich?
Für die Praxis ist nicht nur wichtig, was gemeldet werden muss, sondern auch, wann die Uhr zu laufen beginnt. Die 24- und 72-Stunden-Fristen knüpfen an den Zeitpunkt an, zu dem der Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem meldepflichtigen schweren Sicherheitsvorfall Kenntnis erlangt. Das ist organisatorisch anspruchsvoller, als es auf den ersten Blick klingt.
In größeren Unternehmen entstehen Sicherheitsinformationen an vielen Stellen gleichzeitig: im SOC, beim technischen Support, im Product-Security-Team, über externe Sicherheitsforscher, in Fehlertelemetrie, bei Cloud-Providern oder über einen Zulieferer. Wenn diese Informationen getrennt bleiben, kann die Organisation zwar technisch über ein Problem verfügen, ohne dass die verantwortliche Stelle schnell genug erkennt, dass eine CRA-relevante Meldesituation entstanden ist.
Deshalb sollte die interne Definition von „Kenntnis“ nicht auf eine einzelne Person zugeschnitten werden. Sinnvoller ist ein Prozess, der festlegt, welche Signale eine Eskalation auslösen. Dazu können bestätigte Exploit-Spuren, glaubwürdige Meldungen über Angriffe auf reale Systeme, eine belastbare Korrelation zwischen Telemetrie und bekannter Schwachstelle oder Informationen eines vertrauenswürdigen Zulieferers gehören.
Ebenso wichtig ist die Gegenrichtung: Ein theoretischer Proof of Concept, ein automatisierter Scannerfund oder eine Schwachstelle ohne Hinweise auf reale Ausnutzung ist nicht automatisch dasselbe wie eine aktiv ausgenutzte Schwachstelle. Gerade unter Zeitdruck braucht das Team Kriterien, mit denen es zwischen technischem Verdacht, bestätigter Ausnutzung und einer gewöhnlichen Schwachstellenmeldung unterscheiden kann.
Aktiv ausgenutzte Schwachstelle oder schwerer Sicherheitsvorfall?
Der CRA unterscheidet zwei Meldeanlässe, die sich in der Praxis überschneiden können, aber nicht identisch sind. Eine aktiv ausgenutzte Schwachstelle ist eine konkrete Schwäche im Produkt, für die belastbare Hinweise vorliegen, dass ein Angreifer sie ohne Erlaubnis tatsächlich ausnutzt. Ein schwerer Sicherheitsvorfall beschreibt dagegen ein Ereignis mit erheblicher Auswirkung auf die Sicherheit des Produkts.
Bei der Bewertung eines Vorfalls spielen klassische Schutzziele eine zentrale Rolle: Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit. Ein Ereignis kann beispielsweise relevant werden, wenn es sensible Funktionen manipuliert, wichtige Daten offenlegt, Schadcode in ein Produkt einführt oder die Sicherheitsfunktion eines Produkts substanziell beeinträchtigt.
| Beobachtung | Mögliche Einordnung | Was intern geklärt werden muss |
|---|---|---|
| Neue Schwachstelle, aber keine Hinweise auf reale Angriffe | Vulnerability-Management, nicht automatisch CRA-Sofortmeldung | Ist aktive Ausnutzung nachweisbar oder glaubwürdig belegt? |
| Angreifer nutzt eine konkrete Produktlücke in realen Systemen | Aktiv ausgenutzte Schwachstelle | Betroffene Produkte, Versionen, Reichweite und Gegenmaßnahmen |
| Schadcode verändert sicherheitsrelevante Produktfunktionen | Möglicher schwerer Sicherheitsvorfall | Auswirkung auf Integrität, Verfügbarkeit und Nutzer |
| Ein externer Dienst fällt kurzzeitig aus, ohne Sicherheitswirkung auf das Produkt | Nicht automatisch CRA-relevant | Besteht tatsächlich eine Auswirkung auf die Produktsicherheit? |
Diese Beispiele ersetzen keine rechtliche Einzelfallprüfung. Sie zeigen aber, warum eine rein technische Schweregradskala nicht ausreicht. Ein CVSS-Wert kann ein wichtiges Signal sein, beantwortet jedoch nicht allein die regulatorische Frage, ob eine reale Ausnutzung vorliegt oder ein Ereignis die für den CRA relevante Sicherheitswirkung erreicht.
Wie die Single Reporting Platform den Prozess verändert
Die Single Reporting Platform von ENISA soll vermeiden, dass Hersteller denselben Fall parallel an mehrere Stellen in verschiedenen Mitgliedstaaten melden müssen. Der Hersteller reicht die Meldung zentral ein und ordnet sie dem zuständigen koordinierenden CSIRT zu. Maßgeblich ist grundsätzlich der Hauptsitz beziehungsweise die Hauptniederlassung des Herstellers.
Für den praktischen Zugang ist ein EU-Login mit Mehrfaktor-Authentifizierung vorgesehen. Die meldende Person arbeitet als autorisierte Vertretung des Herstellers. Die Validierung dieser Vertretungsbefugnis ist in den Ablauf eingebaut; sie soll die Abgabe einer zeitkritischen Meldung nicht unnötig blockieren.
Zum Start der Plattform liegt der Schwerpunkt auf den verpflichtenden Meldungen nach Artikel 14. Für Unternehmen bedeutet das: Der interne Prozess sollte nicht davon ausgehen, dass die Plattform ein vollständiges Incident-Management-System ersetzt. Sie ist die externe Meldeschnittstelle. Untersuchung, Beweissicherung, technische Analyse, Patch-Entwicklung, Kommunikation und Managemententscheidungen bleiben Aufgaben des Unternehmens.
Auch eine vollständige Automatisierung ist zum Start nur begrenzt möglich. Unternehmen können ihre internen Datenflüsse automatisieren und Informationen strukturiert vorbereiten. Für die Plattform selbst steht jedoch zunächst kein allgemeiner API-basierter Massenprozess im Vordergrund. Das spricht dafür, intern einen sauberen Datensatz zu erzeugen, der anschließend zuverlässig in die erforderlichen Felder übertragen werden kann.
Welche Informationen sollten intern sofort verfügbar sein?
Schon die erste Meldestufe benötigt eine eindeutige Identifikation von Hersteller und Produkt. In späteren Stufen werden mehr technische Informationen relevant. Je besser diese Daten bereits in Produkt- und Security-Systemen gepflegt sind, desto weniger muss ein Team während eines laufenden Vorfalls zusammensuchen.
- Produktname, Produktfamilie und betroffene Versionen
- verantwortliche interne Produkt- und Security-Teams
- Art der Schwachstelle oder des Vorfalls
- Zeitpunkt der ersten belastbaren Kenntnis
- vorhandene CVE- oder EUVD-Kennungen, sofern verfügbar
- erste Einschätzung zu Auswirkung und Reichweite
- bereits umgesetzte oder geplante Minderungsmaßnahmen
- Hinweise für Nutzer, falls diese selbst Schutzmaßnahmen ergreifen können
- Status eines Patches, Updates oder Workarounds
Ein Unternehmen, das diese Informationen in mehreren voneinander getrennten Tabellen, Ticketsystemen und E-Mail-Postfächern pflegt, verliert unter Umständen genau die Zeit, die der gestaffelte Meldeprozess einsparen soll.
Warum Drittanbieter-Komponenten zu einem zentralen Thema werden
Moderne Software entsteht fast nie vollständig aus eigenem Code. Betriebssysteme, Bibliotheken, Container-Images, SDKs, Firmware-Komponenten und Open-Source-Pakete bilden komplexe Lieferketten. Der CRA betrachtet diese Realität ausdrücklich mit: Hersteller müssen bei integrierten Drittanbieter-Komponenten angemessene Sorgfalt walten lassen, damit diese die Cybersicherheit des eigenen Produkts nicht untergraben.
Für das Reporting ergibt sich daraus eine praktische Konsequenz. Wenn eine weit verbreitete Bibliothek aktiv ausgenutzt wird, reicht es nicht, nur die Meldung des ursprünglichen Komponentenherstellers zu beobachten. Der Hersteller des Endprodukts muss beurteilen, ob die betroffene Komponente tatsächlich in seinem Produkt enthalten ist, welche Version eingesetzt wird, ob die verwundbare Funktion erreichbar ist und welche Auswirkungen sich für die eigene Produktumgebung ergeben.
Genau hier gewinnt eine gepflegte Software Bill of Materials an Wert. Eine SBOM verhindert keine Schwachstelle, sie verkürzt aber die Suchzeit. Ohne Komponentenübersicht kann die scheinbar einfache Frage „Sind wir betroffen?“ Stunden oder Tage kosten. Mit einer belastbaren Zuordnung von Komponenten zu Produktversionen lässt sich die Untersuchung wesentlich gezielter starten.
Das gilt auch für Firmware und eingebettete Systeme. Bei einem vernetzten Gerät kann eine Schwachstelle in einem Netzwerk-Stack, einer Kryptobibliothek oder einem Update-Modul stecken, obwohl die sichtbare Benutzeroberfläche vollständig vom Hersteller selbst stammt. Produktsicherheit ist deshalb zunehmend Lieferkettenmanagement.
Ein realistischer 24/72-Stunden-Prozess
Ein guter CRA-Prozess ist kein einzelnes Formular, sondern eine kurze Kette klarer Entscheidungen. Ein mögliches Modell besteht aus fünf Phasen.
Phase 1: Signal aufnehmen
Eine Warnung trifft über Telemetrie, Support, einen Forscher oder einen Zulieferer ein. Das Signal bekommt sofort einen verantwortlichen Owner und eine Zeitmarke. Schon hier sollte dokumentiert werden, welche Informationen bestätigt und welche lediglich vermutet sind.
Phase 2: Technisch triagieren
Das Security-Team prüft betroffene Versionen, Reproduzierbarkeit, Angriffsspuren und mögliche Auswirkungen. Ziel ist nicht, innerhalb weniger Stunden eine vollständige Root-Cause-Analyse abzuschließen. Ziel ist eine belastbare erste Einordnung: Ist das Produkt betroffen, gibt es Hinweise auf aktive Ausnutzung und wie groß könnte der Sicherheitsimpact sein?
Phase 3: Meldeentscheidung treffen
Technische und rechtliche Verantwortliche bewerten gemeinsam, ob die Kriterien des CRA erfüllt sind. Dabei sollte eine dokumentierte Entscheidungslogik helfen. Ein Unternehmen, das diese Frage erst in jedem Vorfall neu diskutiert, riskiert unnötige Verzögerungen.
Phase 4: 24-Stunden-Meldung und 72-Stunden-Update
Die Frühwarnung enthält das, was zu diesem Zeitpunkt belastbar bekannt ist. Innerhalb der nächsten Stunden läuft die Untersuchung weiter. Die 72-Stunden-Meldung ergänzt insbesondere technische Einzelheiten, erste Bewertung, zeitlichen Verlauf und Maßnahmen. Wichtig ist, dass beide Meldestufen aus derselben internen Fallakte gespeist werden, damit widersprüchliche Angaben vermieden werden.
Phase 5: Abhilfe und Abschlussbericht
Der Prozess endet nicht mit dem Absenden des Formulars. Patch, Workaround, Kommunikation an Nutzer, Verteilung des Updates und Monitoring bleiben entscheidend. Der Abschlussbericht dokumentiert schließlich Ursachen, Auswirkungen und Korrekturmaßnahmen. Für die Produktentwicklung ist diese Phase besonders wertvoll, weil aus einem einzelnen Sicherheitsfall systematische Verbesserungen entstehen können.
Beispiel: Eine vernetzte Kamera mit verwundbarer Komponente
Nehmen wir einen fiktiven deutschen Hersteller von smarten Sicherheitskameras. In der Firmware steckt eine Open-Source-Netzwerkbibliothek. Am Vormittag erhält der Hersteller von einem Partner Hinweise, dass Angreifer eine Schwachstelle dieser Bibliothek gegen reale Geräte ausnutzen.
Das Product-Security-Team prüft zunächst, ob die verwundbare Version tatsächlich in den eigenen Kameramodellen vorhanden ist. Die SBOM zeigt, dass zwei Produktgenerationen betroffen sein könnten. Telemetriedaten enthalten außerdem Verbindungsversuche, die zum beschriebenen Exploit-Muster passen.
Jetzt sind mehrere Arbeiten parallel notwendig. Entwickler versuchen, die Ausnutzung in einer isolierten Testumgebung zu reproduzieren. Das Incident-Team untersucht Logdaten. Das Produktteam identifiziert betroffene Firmware-Versionen und Nutzergruppen. Gleichzeitig bereitet die verantwortliche Person die Frühwarnung vor.
Bis zur 72-Stunden-Stufe liegt eine genauere Bewertung vor: Der Angriff funktioniert nur bei einer bestimmten Konfiguration, ein Firmware-Update befindet sich im Test und Nutzer können vorübergehend eine konkrete Netzwerkfunktion deaktivieren. Diese Informationen fließen in die nächste Meldestufe und in die Kundenkommunikation ein.
Das Beispiel zeigt den eigentlichen Sinn eines vorbereiteten Prozesses. Niemand kann im Voraus wissen, welche Schwachstelle auftreten wird. Man kann aber im Voraus festlegen, wo Komponenteninformationen liegen, wer technische Entscheidungen trifft, wer Nutzerhinweise formuliert und wer eine regulatorische Meldung absendet.
Was sich für ältere Produkte ändert
Ein weiterer wichtiger Punkt betrifft Produkte, die schon vor der vollständigen Anwendung des CRA im Dezember 2027 auf dem Markt sind. Für die allgemeinen Produktanforderungen gibt es Übergangsregeln. Die Reporting-Pflichten ab September 2026 sind jedoch bewusst früher angesetzt und können auch Produkte betreffen, die bereits zuvor auf dem EU-Markt bereitgestellt wurden.
Das bedeutet praktisch: Ein Hersteller sollte sein Reporting-Inventar nicht nur auf neue Produktlinien beschränken. Auch ältere, weiterhin relevante Produkte müssen in der Lage sein, einem Security-Fall eindeutig zugeordnet zu werden. Gerade Legacy-Produkte haben häufig schlechtere Dokumentation, ältere Build-Systeme und weniger klar definierte Verantwortlichkeiten. Dadurch können sie organisatorisch schwieriger zu behandeln sein als neue Entwicklungen.
Unternehmen sollten deshalb prüfen, für welche älteren Produkte noch Sicherheitsinformationen, Kontaktpersonen, Komponentenlisten und Updatewege vorhanden sind. Wenn ein Produkt technisch nicht mehr aktiv weiterentwickelt wird, verschwindet ein aktuelles Sicherheitsereignis dadurch nicht automatisch.
Was Open-Source-Projekte jetzt beachten sollten
Beim Open-Source-Bereich lohnt sich eine präzise Trennung. Ein Entwickler, der freiwillig Code zu einem nicht von ihm verantworteten Projekt beiträgt, befindet sich in einer anderen Rolle als ein Unternehmen, das freie Software unter eigenem Namen kommerziell auf dem Markt bereitstellt.
Außerdem gibt es die besondere Rolle des Open-Source-Software-Stewards. Diese Kategorie richtet sich an juristische Personen, die die Entwicklung bestimmter Open-Source-Produkte dauerhaft und systematisch unterstützen, ohne selbst zwingend als klassischer Hersteller aufzutreten. Für diese Akteure sieht der CRA ein angepasstes Regime vor.
Wichtig für September 2026: Die neuen Art.-14-Meldepflichten starten jetzt für Hersteller. Die spezifischen Reporting-Pflichten der Open-Source-Software-Stewards greifen nach dem vorgesehenen CRA-Zeitplan später. Unternehmen sollten daher ihre tatsächliche Rolle bestimmen, statt sämtliche Open-Source-Aktivitäten pauschal gleich zu behandeln.
Wie kleine und mittlere Unternehmen den Aufwand begrenzen können
Ein mittelständischer Softwareanbieter braucht nicht dieselbe Organisationsstruktur wie ein globaler Hardwarekonzern. Der Kernprozess kann erstaunlich kompakt sein, wenn Verantwortlichkeiten eindeutig sind.
Für ein kleineres Unternehmen kann eine praktikable Minimalstruktur aus einem zentralen Security-Kontakt, einem technischen Stellvertreter, einer rechtlich oder compliance-seitig verantwortlichen Person und einer freigegebenen Incident-Vorlage bestehen. Wichtig ist weniger die Anzahl der Rollen als die Frage, ob im Ernstfall jemand erreichbar ist und Entscheidungen treffen darf.
Ein quartalsweiser Tabletop-Test kann genügen, um grundlegende Schwächen sichtbar zu machen. Dabei wird beispielsweise simuliert, dass am Freitagnachmittag eine aktiv ausgenutzte Schwachstelle bekannt wird. Das Team prüft dann: Wer nimmt die Meldung entgegen? Wer findet am Wochenende die betroffenen Versionen? Wer kann auf die notwendigen Systeme zugreifen? Wer ist berechtigt, eine externe Meldung abzusenden?
Solche Übungen sind oft wertvoller als ein umfangreiches Compliance-Handbuch, das im konkreten Vorfall niemand schnell anwenden kann.
Vom Reporting zur besseren Produktarchitektur
Langfristig ist der interessanteste Effekt des CRA möglicherweise nicht das Formular, sondern der Druck, Produktsicherheit messbarer zu organisieren. Wer innerhalb von 24 Stunden belastbar berichten möchte, braucht nachvollziehbare Produktversionen, gepflegte Abhängigkeiten, technische Telemetrie und definierte Ownership.
Diese Grundlagen verbessern auch andere Bereiche. Ein sauberes Komponenteninventar beschleunigt Patch-Management. Klare Support-Zeiträume helfen Produktmanagement und Kundenservice. Zentralisierte Security-Kontakte erleichtern die Zusammenarbeit mit Forschern. Reproduzierbare Build- und Release-Prozesse machen es einfacher, eine Korrektur gezielt auszuliefern.
Der CRA kann deshalb als Anlass dienen, Product Security nicht länger als nachgelagerten Kontrollpunkt zu behandeln. Im besten Fall entsteht ein Kreislauf: Risiken werden während der Entwicklung bewertet, Komponenten dokumentiert, Schwachstellen strukturiert bearbeitet, Updates kontrolliert verteilt und Erfahrungen aus Vorfällen wieder in die nächste Produktgeneration zurückgeführt.
Fazit: Der 11. September ist vor allem ein Prozess-Stichtag
Der Cyber Resilience Act verändert Produktsicherheit in Europa schrittweise. Am 11. September 2026 beginnt nicht die vollständige Anwendung aller Anforderungen, sondern zunächst ein besonders zeitkritischer Teil: das Melden aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle.
Unternehmen müssen deshalb nicht innerhalb weniger Tage ihre gesamte Produktentwicklung neu bauen. Sie sollten aber sicherstellen, dass ein relevanter Sicherheitsfall erkannt, intern bewertet und fristgerecht gemeldet werden kann.
Die wichtigste Vorbereitung ist überraschend unspektakulär: Verantwortlichkeiten kennen, technische Informationen verfügbar halten und den Ablauf einmal realistisch testen. Genau diese Grundlagen helfen nicht nur bei der CRA-Compliance, sondern machen digitale Produkte auch unabhängig von Regulierung robuster.
