Der Cyber Resilience Act (CRA) ist seit dem 10. Dezember 2024 in Kraft - doch für viele Compliance- und Produktteams bleibt er noch abstrakt. Das ändert sich spätestens am 11. September 2026: Ab diesem Datum greifen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Wer dann keinen funktionierenden Prozess hat, riskiert nicht nur Bußgelder, sondern auch Vertriebsverbote für betroffene Produkte.
Dieser Beitrag erklärt die zentralen Herstellerpflichten verständlich - für Compliance-Verantwortliche und Produktteams gleichermaßen. Einen Überblick über den gesamten Anwendungsbereich des CRA finden Sie in unserem [1].
Essential Requirements: Was "Secure-by-Design" konkret bedeutet
Der Kern des CRA ist in Anhang I der Verordnung (EU) 2024/2847 verankert: die sogenannten Essential Requirements. Sie definieren, welche Sicherheitseigenschaften ein Produkt mit digitalen Elementen bereits bei der Entwicklung und Markteinführung aufweisen muss.
Das Leitprinzip lautet Secure-by-Design: Nach diesem Konzeptionsgrundsatz müssen vernetzte Produkte im Hinblick auf Cybersicherheit konzipiert werden - etwa indem sichergestellt wird, dass die mit dem Produkt gespeicherten oder übertragenen Daten verschlüsselt sind und die Angriffsfläche so gering wie möglich ist. Ergänzt wird das durch Secure-by-Default: Die Standardeinstellungen vernetzter Produkte müssen zur Erhöhung der Sicherheit beitragen - zum Beispiel durch das Verbot schwacher Standardpasswörter und die automatische Installation von Sicherheitsupdates.
Praktisch bedeutet das: Ein IoT-Gateway, das ab Werk mit dem Passwort "admin/admin" ausgeliefert wird, ist nach dem CRA nicht mehr zulässig. Ein Industriesteuerungssystem, das keine verschlüsselte Kommunikation unterstützt, ebenfalls nicht. Hersteller müssen die Angriffsfläche durch Designentscheidungen minimieren und Produkte mit sicheren Standardkonfigurationen ausliefern - Least Privilege, keine Standard-Zugangsdaten, Härtung entsprechend dem vorgesehenen Einsatzzweck.
Secure-by-Design ist keine einmalige Aufgabe. Die Essential Requirements gelten über den gesamten Produktlebenszyklus. Wer heute ein Produkt entwickelt, das 2027 auf den Markt kommt, muss die CRA-Anforderungen bereits jetzt in die Architektur einbauen — nachträgliche Anpassungen sind deutlich aufwändiger und teurer.
SBOM: Die Zutatenliste Ihrer Software
Eine der neuartigsten Pflichten des CRA ist die Software Bill of Materials (SBOM) - auf Deutsch: ein maschinenlesbares Verzeichnis aller Softwarekomponenten eines Produkts. Der Begriff klingt technisch, das Prinzip ist intuitiv: Eine SBOM ist ein detailliertes Inventar aller Komponenten, die eine Softwareanwendung ausmachen - einschließlich Bibliotheken, Pakete und Abhängigkeiten. Ähnlich wie eine Zutatenliste bei Lebensmitteln schafft sie Transparenz darüber, was in einem Produkt steckt.
Der CRA führt eine rechtsverbindliche Pflicht für Hersteller ein, eine SBOM für alle Produkte mit digitalen Elementen zu erstellen, zu pflegen und aufzubewahren. Damit wird die SBOM von einer freiwilligen Best Practice zu einem rechtlich geforderten Element der technischen Dokumentation - unverzichtbar für die Konformitätsbewertung, die Sicherheitsgewährleistung und die Reaktion auf Vorfälle über den gesamten Produktlebenszyklus.
Konkret schreibt der CRA vor: Hersteller müssen eine SBOM erstellen und pflegen. Diese muss in einem gängigen, maschinenlesbaren Format vorliegen und mindestens die Top-Level-Abhängigkeiten des Produkts enthalten. Hersteller sind nicht verpflichtet, die SBOM öffentlich zugänglich zu machen, müssen sie aber in die technische Dokumentation aufnehmen und Marktüberwachungsbehörden auf Anfrage vorlegen.
Als De-facto-Standards haben sich SPDX (Software Package Data Exchange) und CycloneDX etabliert. Wichtig: Sicherheitsdokumentation einschließlich SBOMs muss zehn Jahre nach dem Inverkehrbringen des Produkts aufbewahrt werden.
Für das Schwachstellenmanagement ist die SBOM unverzichtbar: Wer nicht weiß, welche Open-Source-Bibliotheken in welcher Version in seinem Produkt stecken, kann bei einer neu entdeckten Sicherheitslücke weder schnell reagieren noch die gesetzlichen Meldefristen einhalten.
Schwachstellenmanagement über den gesamten Lebenszyklus
Der CRA verlangt ein strukturiertes, dauerhaftes Schwachstellenmanagement - nicht nur zum Zeitpunkt der Markteinführung, sondern über die gesamte Supportdauer. Hersteller müssen einen dokumentierten Schwachstellenmanagement-Prozess für die gesamte Supportdauer betreiben. Der CRA erwartet eine koordinierte Schwachstellenoffenlegungsrichtlinie mit einem klaren Ansprechpartner sowie Mechanismen, um von externen Sicherheitsforschern gemeldete Schwachstellen zu empfangen, zu priorisieren und zu beheben.
Das bedeutet in der Praxis: Hersteller brauchen einen öffentlich erreichbaren Sicherheitskontakt (z. B. eine security.txt-Datei auf der Website), einen definierten internen Triage-Prozess und - für den Ernstfall - ein Product Security Incident Response Team (PSIRT) mit klaren Eskalationswegen.
Hersteller müssen bei Drittkomponenten die gebotene Sorgfalt walten lassen, einschließlich der Bewertung bekannter Schwachstellen und der Überwachung von Sicherheitsupdates. Sie bleiben für Schwachstellen in allen integrierten Komponenten verantwortlich - unabhängig von deren Herkunft. Wer also eine Open-Source-Bibliothek eines Drittanbieters in sein Produkt integriert, haftet auch für deren Sicherheit.
Sicherheitsupdates: Kostenlos, zeitnah, für mindestens fünf Jahre
Ein zentraler Paradigmenwechsel des CRA betrifft Sicherheitsupdates: Mit der Cyber-Resilience-Verordnung werden Sicherheitsupdates zu einer klaren Pflicht. Hersteller müssen Schwachstellen unverzüglich und kostenlos beheben, eine transparente Update-Strategie verfolgen und ihre Nutzer während des gesamten Supportzeitraums zuverlässig unterstützen.
Der CRA verankert im Gesetzestext eine Mindestdauer von fünf Jahren, es sei denn, die erwartete Nutzungsdauer ist kürzer. Für Industrieprodukte, die zehn bis fünfzehn Jahre im Feld bleiben, kann die tatsächlich geforderte Supportdauer deutlich darüber liegen.
Für Unternehmen, die bisher Sicherheits- und Funktionsupdates gebündelt haben, ergibt sich eine wichtige Konsequenz: Der CRA schreibt vor, dass Sicherheitsupdates kostenfrei bereitgestellt werden müssen. Wer Feature- und Security-Updates bündelt, kann neue Funktionen nicht mehr separat verkaufen, weil der Sicherheitsteil zwingend kostenlos sein muss. Daraus folgt oft eine technische und organisatorische Trennung: Security-Patches laufen auf einem eigenen Kanal, Feature-Updates auf einem anderen.
Außerdem gilt: Jedes veröffentlichte Sicherheitsupdate muss nach Veröffentlichung mindestens zehn Jahre zum Download bereitstehen. Und der CRA verpflichtet Hersteller, den geplanten Supportzeitraum bereits beim Kauf klar anzugeben, damit Kunden von Anfang an erkennen können, wie lange sie mit Sicherheitsaktualisierungen rechnen können.
Meldepflichten ab 11. September 2026: Der dreistufige Prozess
Dies ist die dringlichste Pflicht für Hersteller: Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die ENISA Single Reporting Platform (SRP) gemeldet werden - in drei gestaffelten Stufen.
Wichtig vorab: Meldepflichtig sind ausschließlich aktiv ausgenutzte Schwachstellen - also Sicherheitslücken, für die bereits belastbare Beweise vorliegen, dass ein Angreifer sie ausnutzt - sowie schwere Vorfälle, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit des Produkts wesentlich beeinträchtigen. Theoretisch ausnutzbare, aber noch nicht angegriffene Schwachstellen lösen die Meldepflicht nicht aus.
Der dreistufige Ablauf im Überblick:
Stufe 1 - Early Warning (24 Stunden): Die erste Stufe ist eine Frühwarnung. Sie ist unverzüglich zu übermitteln, in jedem Fall aber innerhalb von 24 Stunden nach Kenntniserlangung. Diese Frist verlangt zunächst nur knappe Angaben: bei der Schwachstelle die Mitgliedstaaten, in deren Hoheitsgebiet das betroffene Produkt nach Kenntnis des Herstellers bereitgestellt wurde, beim Vorfall zumindest die Angabe, ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht.
Stufe 2 - Vulnerability Notification (72 Stunden): Die zweite Stufe ist eine detaillierte Meldung innerhalb von 72 Stunden nach Kenntniserlangung. Sie enthält allgemeine Informationen über das betroffene Produkt, über die Art der Ausnutzung beziehungsweise des Vorfalls sowie über bereits ergriffene Korrektur- oder Risikominderungsmaßnahmen.
Stufe 3 - Final Report (14 Tage / 1 Monat): Der Final Report hat je nach Art des Vorfalls unterschiedliche Fristen: Bei Schwachstellen muss dieser spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme eingereicht werden, während bei schweren Vorfällen die endgültige Meldung innerhalb eines Monats nach der ersten Benachrichtigung erfolgen muss.
Die Meldung erfolgt über die ENISA Single Reporting Platform (SRP) - ein zentrales elektronisches System für die Meldung aktiv ausgenutzter Schwachstellen und schwerer Vorfälle bei Produkten mit digitalen Elementen im EU-Binnenmarkt. In Deutschland ist das nationale CSIRT das BSI (Bundesamt für Sicherheit in der Informationstechnik).
Parallel zur Behördenmeldung gilt: Die Meldung an Behörden ersetzt nicht die Information der Nutzer. Der Hersteller informiert die betroffenen und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall, sobald er davon Kenntnis erlangt hat. Erforderlichenfalls weist er auf Risikominderungs- und Korrekturmaßnahmen hin, die die Nutzer selbst ergreifen können.
Was das in der Praxis bedeutet: Drei Szenarien
Szenario 1 - SaaS-Anbieter mit IoT-Anbindung: Ein Softwareunternehmen betreibt eine cloudbasierte Plattform, die Daten von vernetzten Industriesensoren verarbeitet. Der CRA gilt für die Sensoren als Produkte mit digitalen Elementen. Der Anbieter muss für die Sensoren eine SBOM führen, Sicherheitsupdates kostenlos bereitstellen und ab September 2026 aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden.
Szenario 2 - Maschinenbauer mit Embedded Software: Ein mittelständischer Maschinenbauer liefert Steuerungseinheiten mit proprietärer Firmware aus. Die Maschinen laufen typischerweise 15 Jahre. Der CRA verlangt einen Supportzeitraum, der sich an dieser Nutzungsdauer orientiert - mit kostenlosen Sicherheitsupdates über die gesamte Laufzeit. Das hat direkte Auswirkungen auf Architekturentscheidungen und Lieferantenverträge.
Szenario 3 - Importeur von Drittanbieter-Hardware: Ein deutsches Unternehmen importiert vernetzte Geräte eines asiatischen Herstellers. Hersteller mit Sitz außerhalb der EU sind in den Anwendungsbereich einbezogen, wenn ihre Produkte den EU-Markt erreichen. Als Importeur trägt das Unternehmen Mitverantwortung für die CRA-Konformität - und muss im Zweifel nachweisen, dass der Hersteller die Anforderungen erfüllt.
Sanktionen: Was auf dem Spiel steht
Bei Verstößen gegen die wesentlichen Anforderungen des CRA drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes - je nachdem, welcher Betrag höher ist. Verstöße gegen die Meldepflichten können mit bis zu 5 Millionen Euro oder 1 % des Jahresumsatzes geahndet werden. Hinzu kommt: Das BSI kann den Vertrieb des betroffenen Produkts einschränken oder untersagen.
Für Geschäftsführer ist das eine unmittelbare Haftungsfrage - nicht nur eine Compliance-Aufgabe für die IT-Abteilung.
Jetzt handeln: Was bis September 2026 zu tun ist
Die Meldepflichten starten in wenigen Monaten. Ein funktionierender Prozess entsteht nicht über Nacht. Folgende Schritte sind prioritär:
- SBOM aufbauen: Inventarisieren Sie alle Softwarekomponenten Ihrer Produkte in einem maschinenlesbaren Format (SPDX oder CycloneDX) und richten Sie ein automatisiertes Monitoring gegen CVE-Datenbanken ein.
- Meldeprozess einrichten: Definieren Sie Rollen, Eskalationswege und Meldetemplates für alle drei Stufen (24h / 72h / 14 Tage). Die 24-Stunden-Frist ist nur einzuhalten, wenn das Incident-Response-Team mit klar definierten Rollen, getesteten Playbooks und gegebenenfalls externer Kapazität einsatzbereit ist - nicht erst im Ernstfall.
- Prozess testen: Führen Sie eine Tabletop Exercise durch und simulieren Sie den vollständigen Meldeprozess gegenüber BSI und ENISA, bevor der Ernstfall eintritt.
- Supportzeitraum festlegen: Bestimmen Sie für jedes Produkt einen begründeten Supportzeitraum und kommunizieren Sie diesen gegenüber Kunden.
- Lieferantenverträge prüfen: Stellen Sie sicher, dass Ihre Zulieferer SBOM-Pflichten, koordinierte Schwachstellenoffenlegung und Incident-Reporting-Protokolle vertraglich übernehmen.
Ob Ihr Produkt unter den CRA fällt und welche Kategorie (Standard, Klasse I oder Klasse II) zutrifft, hängt von den konkreten Produkteigenschaften ab. Eine pauschale Einschätzung ist hier nicht möglich - die Einzelfallprüfung ist entscheidend. Einen strukturierten Einstieg bietet unser [1].
Wir analysieren gemeinsam mit Ihnen, welche CRA-Pflichten für Ihre Produkte gelten — und was bis September 2026 konkret umzusetzen ist.
Herstellerpflichten für Ihr Produkt prüfen lassenGilt der CRA auch für reine Software-Produkte wie SaaS oder mobile Apps?
Ja, grundsätzlich. Der CRA erfasst alle Produkte mit digitalen Elementen — also Hardware mit Softwarekomponenten, aber auch eigenständige Software, die auf dem EU-Markt bereitgestellt wird. Ob eine konkrete SaaS-Lösung oder App in den Anwendungsbereich fällt, hängt von den Produkteigenschaften ab und erfordert eine Einzelfallprüfung.
Müssen Bestandsprodukte, die vor Dezember 2027 auf den Markt gebracht wurden, ebenfalls CRA-konform sein?
Die Meldepflichten (ab 11. September 2026) gelten auch für Bestandsprodukte. Die vollständigen Anforderungen (Secure-by-Design, SBOM, CE-Kennzeichnung) gelten für Bestandsprodukte nur dann, wenn sie nach dem 11. Dezember 2027 eine wesentliche Änderung erfahren.
Was ist der Unterschied zwischen CRA und NIS2?
Der CRA regelt die Cybersicherheit von Produkten mit digitalen Elementen — er richtet sich an Hersteller, Importeure und Händler. NIS2 regelt, wie Unternehmen ihre eigene IT-Infrastruktur schützen — er richtet sich an Betreiber wichtiger Einrichtungen. Beide Regelwerke können gleichzeitig gelten, haben aber unterschiedliche Pflichten, Fristen und Meldewege.
Wer ist in Deutschland die zuständige Behörde für CRA-Meldungen?
In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) das zuständige nationale CSIRT. Meldungen erfolgen über die ENISA Single Reporting Platform (SRP), die als zentraler Single Entry Point für alle EU-Mitgliedstaaten fungiert. Das BSI erhält die Meldungen parallel.
Was passiert, wenn ein Hersteller die 24-Stunden-Frist versäumt?
Verstöße gegen die Meldepflichten können mit Bußgeldern von bis zu 5 Millionen Euro oder 1 % des weltweiten Jahresumsatzes geahndet werden. Darüber hinaus kann das BSI den Vertrieb des betroffenen Produkts einschränken oder untersagen. Die genaue Sanktion hängt vom Einzelfall ab.
