Cyber Resilience Act: Pflichten, Fristen & Anforderungen

Ab dem 11. September 2026 gelten die ersten Meldepflichten des Cyber Resilience Act. Die CRA-Verordnung, offiziell Cyberresilienz-Verordnung (Verordnung (EU) 2024/2847), ist seit dem 10. Dezember 2024 in Kraft. Trotzdem sind laut dem ONEKEY-Report 2025 nur 32 % deutscher Industrieunternehmen mit den Anforderungen vertraut. 38 % haben bislang keine Maßnahmen eingeleitet.

Die Verordnung betrifft alle Hersteller, Importeure und Händler, die Produkte mit digitalen Elementen auf dem EU-Markt anbieten. Vernetzte Industriesteuerungen und Smart-Home-Geräte fallen ebenso darunter wie Softwareprodukte mit lokaler Client-Komponente. Der Geltungsbereich ist breiter, als viele Unternehmen vermuten: Auch Maschinenbauer mit vernetzten SPS-Steuerungen oder Sensorik mit Ethernet-Schnittstelle müssen die Anforderungen des Cyber Resilience Act erfüllen.

Ab Dezember 2027 gelten die vollständigen Herstellerpflichten, einschließlich CE-Kennzeichnung für Cybersicherheit. Die realistische Umsetzungsdauer liegt bei 14 bis 20 Monaten. Wer jetzt nicht startet, riskiert den Marktzugang für seine Produkte.

Was müssen Sie konkret tun, um rechtzeitig CRA-konform zu werden?

Wir zeigen Ihnen, welche Anforderungen der EU CRA an Hersteller stellt, wie die Einstufung in Standard-, wichtige und kritische Produkte funktioniert und welche Fristen bei Meldepflichten gelten. Am Ende finden Sie eine konkrete Checkliste für die strukturierte Umsetzung in Ihrem Unternehmen.

Was ist der Cyber Resilience Act? Definition und Ziele der Cyberresilienz-Verordnung

Der Cyber Resilience Act (kurz EU CRA, im Deutschen auch Cyberresilienz-Verordnung) ist seit dem 10. Dezember 2024 als Verordnung (EU) 2024/2847 in Kraft. Er schafft erstmals verbindliche Cybersicherheitsanforderungen für alle „Produkte mit digitalen Elementen“ auf dem EU-Binnenmarkt. Die Anforderungen gelten horizontal, also branchenübergreifend und unabhängig von der Produktkategorie.

Betroffen sind nicht nur klassische IT- und IoT-Hersteller. Auch Maschinenbauer mit vernetzten SPS-Steuerungen, Anbieter von Desktop-Software mit Update-Funktion und Sensorhersteller mit Fernwartungszugang müssen die CRA-Anforderungen erfüllen.

Verordnung, nicht Richtlinie

Wer nach dem Begriff „CRA Richtlinie“ sucht, liegt rechtlich falsch. Der CRA ist eine Verordnung. Eine EU-Verordnung gilt unmittelbar in allen Mitgliedstaaten und erfordert keine nationale Umsetzung durch ein Bundesgesetz. Der deutsche Gesetzgeber kann die Anforderungen weder abschwächen noch aufschieben. Die Abgrenzung zur NIS-2-Richtlinie, die als Richtlinie tatsächlich in nationales Recht überführt werden muss, behandeln wir im Abschnitt „CRA und NIS-2 im Vergleich“.

Was sind „Produkte mit digitalen Elementen“?

Der CRA definiert seinen Geltungsbereich über den Begriff „Produkte mit digitalen Elementen“. Laut der CRA-Übersicht des BSI umfasst die Definition alle Software- oder Hardwareprodukte und deren Datenfernverarbeitungslösungen, deren bestimmungsgemäßer oder vernünftigerweise vorhersehbarer Gebrauch eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

Diese Definition ist bewusst breit angelegt. Eine Industriesteuerung mit Ethernet-Schnittstelle fällt ebenso darunter wie ein vernetzter Rauchmelder oder ein Smart-Home-Thermostat. Das überrascht viele Hersteller. Gerade Maschinenbauer gehen häufig davon aus, der CRA betreffe sie nicht, weil sie „kein Softwareunternehmen“ seien. Sobald eine Maschine aber vernetzte Steuerungen, Sensoren mit Datenschnittstelle oder einen Fernwartungszugang enthält, fällt das Produkt unter den CRA. Rund 70 % der Unternehmen schätzen den Geltungsbereich bei der ersten Prüfung falsch ein.

Aufgebaut auf dem New Legislative Framework

Die CRA-Verordnung basiert auf dem New Legislative Framework (NLF) der EU. Sie greift auf etablierte Mechanismen der Funkanlagenrichtlinie oder der Maschinenverordnung zurück. Konformitätsbewertung, CE-Kennzeichnung und Marktüberwachung werden nun erstmals auf Cybersicherheit angewendet. Für Hersteller, die bereits CE-konforme Produkte vertreiben, sind die Abläufe vertraut. Neu ist der Gegenstand.

Drei Ziele des CRA

Der Cyber Resilience Act verfolgt drei Kernziele:

1. Cybersicherheit auf dem EU-Binnenmarkt verbessern durch einheitliche Mindestanforderungen für alle vernetzten Produkte
2. Hersteller über den gesamten Produktlebenszyklus verpflichten, von der sicheren Entwicklung bis zur Bereitstellung kostenloser Sicherheitsupdates über mindestens fünf Jahre
3. Transparenz für Käufer schaffen, damit gewerbliche Nutzer und Verbraucher Sicherheitseigenschaften vor dem Kauf bewerten können

CRA-Zeitplan: Alle Fristen und Meilensteine im Überblick

Der Cyber Resilience Act staffelt seine Anforderungen in drei Stufen. Die Verordnung (EU) 2024/2847 ist seit dem 10. Dezember 2024 in Kraft. Zwei Fristen stehen noch bevor. Die nächste greift in weniger als sechs Monaten.

Datum	Was gilt ab diesem Zeitpunkt?
10. Dezember 2024	Die CRA-Verordnung ist in Kraft getreten. Die Übergangsfrist läuft.
11. Juni 2026	Mitgliedstaaten müssen ihre Konformitätsbewertungsstellen benannt haben. Stand März 2026 ist noch keine CRA-spezifische Stelle notifiziert.
11. September 2026	Meldepflichten greifen: Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.
11. Dezember 2027	Vollständige Anwendung: Alle CRA-Anforderungen gelten, darunter Security by Design, Konformitätsbewertung und CE-Kennzeichnung.

September 2026: Weniger als sechs Monate bis zur Meldepflicht

Die Frist am 11. September 2026 unterschätzen viele Hersteller. Ab diesem Datum müssen Sie aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden als Frühwarnung an die zuständige CSIRT und die ENISA melden. Für die vollständige Meldung bleiben 72 Stunden, für den Abschlussbericht 14 Tage. Diese gestaffelten Meldefristen laut BSI gelten für alle Produkte mit digitalen Elementen auf dem EU-Markt, Bestandsprodukte eingeschlossen.

Ein funktionierender Meldeprozess entsteht nicht über Nacht. Sie benötigen Vulnerability-Monitoring, das Ihre Softwarekomponenten automatisiert gegen CVE-Datenbanken abgleicht. Definieren Sie eine Eskalationskette mit klaren Rollen und 24/7-Erreichbarkeit per Rufbereitschaft. Bereiten Sie Melde-Templates vor, damit im Ernstfall keine Stunden mit Formalitäten verloren gehen. Sobald die ENISA Single Reporting Platform verfügbar ist, sollten Sie sich dort registrieren.

Realistisch dauert der Aufbau dieser Strukturen 4 bis 5 Monate, wenn Sie bei null starten. Wer jetzt im März 2026 beginnt, hat noch Puffer. Wer erst im Juni startet, wird die Frist reißen.

Aktuelle Branchenzahlen verdeutlichen den Handlungsdruck. Nur rund ein Drittel der deutschen Industrieunternehmen ist mit den CRA-Anforderungen vertraut. Fast 40 % haben bislang keine Vorbereitungen getroffen.

Dezember 2027: Volle Konformität gefordert

Am 11. Dezember 2027 endet die letzte Übergangsfrist der CRA-Verordnung. Produkte mit digitalen Elementen dürfen dann nur noch mit CE-Kennzeichnung auf den EU-Markt gebracht werden, die erstmals auch Cybersicherheitsanforderungen abdeckt.

Für ein Unternehmen mit 3 bis 10 Produkten ohne bestehende IEC-62443-Basis bedeutet das 14 bis 20 Monate Vorlaufzeit bis zur vollständigen Konformität. Bei einem Start im Frühjahr 2026 bleibt Puffer. Ab Herbst 2026 wird es eng.

Geltungsbereich: Welche Produkte betrifft der Cyber Resilience Act?

Der CRA erfasst alle Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Laut dem CRA-Verordnungstext umfasst diese Definition Software- und Hardwareprodukte einschließlich ihrer Datenfernverarbeitungslösungen, deren bestimmungsgemäßer Gebrauch eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt. Ob der Hersteller innerhalb oder außerhalb der EU sitzt, ist dabei unerheblich. Entscheidend ist allein die Bereitstellung auf dem europäischen Markt.

Hardware: Vom Smart-Home-Gerät bis zur Industriesteuerung

Die Bandbreite betroffener Hardware ist groß. Konkrete Beispiele:

• IoT-Geräte: Smart-Home-Produkte wie vernetzte Thermostate, Türklingeln mit Kamera, smarte Beleuchtungssysteme und Sprachassistenten
• Netzwerkkomponenten: Router, Switches, Firewalls und Webcams
• Industriehardware: Speicherprogrammierbare Steuerungen (SPS), SCADA-Systeme und industrielle Gateways
• Wearables und Consumer Electronics: Fitness-Tracker, Smartwatches, Smart TVs und vernetztes Spielzeug mit WLAN-Funktion

Selbst ein vernetzter Rauchmelder fällt unter die Verordnung, sobald er eine Datenverbindung herstellt.

Software: Desktop-Apps, Firmware und Cloud-Dienste

Nicht nur physische Produkte sind betroffen. Der CRA gilt ebenso für eigenständige Software:

• Desktop- und Mobile-Anwendungen, die kommerziell vertrieben werden
• Firmware und Betriebssysteme, die in Geräten vorinstalliert oder als Update bereitgestellt werden
• Sicherheitssoftware wie VPN-Clients, Passwortmanager und Antivirenprogramme
• Datenfernverarbeitungslösungen, bei denen die Software Daten extern verarbeitet und das Produkt ohne diese Verbindung nicht vollständig funktioniert

Der EU-Herstellerleitfaden stellt klar: Auch SaaS-Komponenten fallen unter den CRA, sofern sie als Datenfernverarbeitungslösung zu einem Produkt mit digitalen Elementen gehören. Reine Cloud-Dienste ohne zugehöriges Produkt bleiben außen vor.

Welche Branchen sind besonders betroffen?

Die Auswirkungen des Cyber Resilience Act verteilen sich ungleich über verschiedene Sektoren:

IoT-Hersteller trifft es am breitesten. Nahezu jedes vernetzte Gerät fällt in den Geltungsbereich. Wer smarte Sensoren, Aktoren oder Gateways produziert, muss die CRA-Anforderungen vollständig umsetzen.

Software-Unternehmen müssen jede kommerziell vertriebene Anwendung prüfen. Das betrifft auch Unternehmen, die bisher keine physischen Produkte herstellen und sich nicht als „Hersteller“ verstehen. Der CRA ändert diese Perspektive.

Industrieautomation und Maschinenbau stehen vor besonderen Herausforderungen. SPS-Systeme, SCADA-Software und industrielle Gateways fallen häufig in die Kategorie „wichtige Produkte“ oder sogar „kritische Produkte“ und unterliegen damit strengeren Konformitätsverfahren. Rund 90 % der Produkte können zwar über eine Selbstbewertung die Konformität nachweisen, doch gerade im Industrieumfeld greifen oft die höheren Klassen.

Consumer-Electronics-Hersteller müssen vernetzte Endgeräte wie Smart TVs, Spielkonsolen oder WLAN-fähiges Kinderspielzeug CRA-konform gestalten. Für diese Produkte gelten Sicherheitsupdates über mindestens 5 Jahre ab Inverkehrbringen.

Ausnahmen: Was fällt nicht unter den CRA?

Einige Produktkategorien sind explizit ausgenommen, weil sie bereits durch sektorspezifische Regelungen reguliert werden. Dazu zählen unter anderem Medizinprodukte, Fahrzeuge, Luftfahrtsysteme und militärische Ausrüstung. Auch nicht-kommerzielle Open-Source-Software fällt nicht unter die Verordnung. Die Abgrenzung ist allerdings im Detail anspruchsvoll: Sobald Open-Source-Software im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, greift der CRA.

Details zu allen Ausnahmen und Sonderfällen finden Sie im Abschnitt „Ausnahmen vom Cyber Resilience Act“ weiter unten.

Produktklassifizierung: Standard, Wichtig und Kritisch

Nicht jedes Produkt mit digitalen Elementen durchläuft dasselbe Bewertungsverfahren. Der Cyber Resilience Act teilt Produkte in vier Kategorien ein. Diese Einstufung bestimmt, ob Sie die Konformität selbst erklären dürfen oder eine externe Prüfstelle einschalten müssen.

Kategorie	Anteil	Beispiele	Konformitätsbewertung
Standard	ca. 90 %	Allgemeine Software, einfache IoT-Geräte	Selbstbewertung (Modul A)
Wichtig – Klasse I	—	Router, VPN-Software, Passwortmanager, Betriebssysteme (Anhang III)	Harmonisierte Normen ODER Drittbewertung
Wichtig – Klasse II	—	Firewalls, IDS/IPS-Systeme, manipulationssichere Mikroprozessoren (Anhang III)	Drittbewertung zwingend (Modul B+C oder H)
Kritisch	—	Hardware-Sicherheitsmodule, Smart-Meter-Gateways, Smartcards (Anhang IV)	Drittbewertung zwingend, EU-Zertifizierung möglich

Ca. 90 % aller Produkte fallen laut den BSI-Produktanforderungen in die Standardkategorie und kommen mit einer Selbstbewertung aus. Die verbleibenden 10 % verteilen sich auf Klasse I, Klasse II und die kritische Kategorie. Hier steigen die Anforderungen des Cyber Resilience Act an den Konformitätsnachweis deutlich.

So stufen Sie Ihr Produkt richtig ein

Die Klassifizierung folgt drei Stufen.

Stufe 1 – CRA-Relevanz prüfen: Enthält Ihr Produkt Software oder Firmware? Wird es auf dem EU-Markt bereitgestellt? Greift keine sektorspezifische Ausnahme (Medizinprodukte, Kfz, Luftfahrt, Marine)? Falls alle drei Fragen mit Ja beantwortet werden, fällt Ihr Produkt unter die CRA-Verordnung.

Stufe 2 – Kategorie bestimmen: Gleichen Sie die Kernfunktionalität Ihres Produkts mit den Anhängen III und IV ab. Die Durchführungsverordnung (EU) 2025/2392 vom November 2025 definiert für jede Produktkategorie, was als Kernfunktionalität gilt. Ein verbreiteter Fehler: Enthält ein Produkt eine Komponente aus Anhang III (etwa eine VPN-Funktion), bedeutet das nicht automatisch, dass das Gesamtprodukt in Klasse I fällt. Entscheidend ist die Funktion des Gesamtprodukts, nicht einzelner Bestandteile.

Stufe 3 – Bewertungsverfahren ableiten: Standardprodukte nutzen Modul A (Selbstbewertung). Klasse-I-Produkte dürfen Modul A nur anwenden, wenn sie harmonisierte Normen, gemeinsame Spezifikationen oder ein EU-Cybersecurity-Zertifizierungsschema vollständig einhalten. Klasse-II- und kritische Produkte müssen eine Drittbewertung durchlaufen.

Grenzfälle bei der Einstufung

• Router mit VPN-Funktion: VPN-Produkte gehören zu Klasse I. Bei einem dedizierten VPN-Router ist die Einstufung eindeutig. Bei einem Industrierouter, der VPN als Zusatzfunktion bietet, hängt die Klassifizierung vom Hauptzweck und der Vermarktung ab.
• Industriesteuerung mit Webserver: Dient der Webserver nur der Konfiguration, während die Kernfunktionalität in der Prozesssteuerung liegt, fällt das Produkt nicht automatisch in die Kategorie „Netzwerkmanagement-System“.
• Smart-Home-Geräte: Ein vernetzter Thermostat ohne Sicherheitsfunktion gehört zur Standardkategorie. Sobald er Sicherheitsaufgaben übernimmt (z. B. Einbrucherkennung über Temperaturanomalien), rückt er in Klasse I.

Viele Unternehmen stufen sich vorschnell als Standardprodukt ein und stellen zu spät fest, dass eine Drittbewertung nötig ist. Das Problem verschärft sich aktuell: Stand März 2026 existieren noch keine harmonisierten CRA-Normen. Eine ENISA/JRC-Analyse hat die Normungslücken identifiziert, CEN/CENELEC und ETSI arbeiten an deren Schließung. Bis die Normen vorliegen, können Klasse-I-Hersteller die Selbstbewertung nach Modul A nicht nutzen und müssen mit einer Drittbewertung planen.

Cyber Resilience Act: Anforderungen an Hersteller im Detail

Die Anforderungen des Cyber Resilience Act erfassen den gesamten Produktlebenszyklus. Cyberresilienz beginnt bei der ersten Designentscheidung und endet erst mit dem Auslaufen des Supports. Vier Kernpflichten bestimmen, was das für Ihre Entwicklungs- und Geschäftsprozesse konkret bedeutet.

Security by Design und Secure by Default

Cybersicherheit darf kein nachgelagertes Testing kurz vor dem Release sein. Laut EU-Herstellerleitfaden müssen Sicherheitsanforderungen von der Konzeption bis zur Wartung kontinuierlich einfließen.

**Produkte mit digitalen Elementen dürfen nur in Verkehr gebracht werden, wenn sie keine dem Hersteller bekannten, ausnutzbaren Schwachstellen aufweisen. Jede ausnutzbare Schwachstelle in der Codebasis blockiert den EU-Marktzugang.

Das Fraunhofer-Whitepaper konkretisiert als Praxisleitfaden für die Umsetzung, welche technischen Maßnahmen Anhang I verlangt:

• Secure-by-Default-Konfiguration: Keine offenen Ports, keine Standardpasswörter, verschlüsselte Kommunikation ab Werk
• Schutz vor unautorisiertem Zugriff durch Authentifizierungs- und Autorisierungsmechanismen
• Integritätsschutz gespeicherter und übertragener Daten, Befehle und Konfigurationen
• Minimierung der Angriffsfläche, einschließlich externer Schnittstellen
• Sicherer Update-Mechanismus mit Verfügbarkeitsprüfung, Authentizitätsverifikation und Rollback-Fähigkeit

Die größte Herausforderung ist dabei kulturell, nicht technisch. Entwickler müssen Sicherheit als Produkteigenschaft verstehen, gleichwertig mit Funktionalität und Performance.

Software Bill of Materials (SBOM)

Eine Software Bill of Materials (SBOM) ist ein Inventar aller Softwarekomponenten, die in Ihrem Produkt verbaut sind. Der CRA verpflichtet Hersteller, eine solche maschinenlesbare Stückliste zu erstellen und zu pflegen. Laut EU-Herstellerleitfaden muss sie mindestens die Top-Level-Abhängigkeiten dokumentieren. Für ein typisches IoT-Gerät mit Embedded Linux und mehreren Bibliotheken umfasst eine SBOM schnell 200 bis 500 Einträge. Ohne dieses Inventar ist kein systematisches Schwachstellen-Monitoring möglich.

Für die technische Umsetzung hat das BSI mit der Technischen Richtlinie TR-03183 Empfehlungen veröffentlicht. Als Formate empfiehlt die Richtlinie CycloneDX oder SPDX. Beide sind maschinenlesbar und ermöglichen den automatisierten Abgleich gegen Schwachstellendatenbanken wie die NVD. Der CRA fordert zwar nur die Dokumentation der Top-Level-Abhängigkeiten, doch die BSI-Empfehlung in TR-03183-2 geht weiter und rät zur Erfassung bis zur ersten externen Komponente. Wer nur Top-Level dokumentiert, übersieht bei der Schwachstellenerkennung kritische Abhängigkeiten.

Schwachstellenmanagement und Coordinated Vulnerability Disclosure

Für den Umgang mit entdeckten Schwachstellen schreibt der CRA eine koordinierte Schwachstellenoffenlegung (Coordinated Vulnerability Disclosure, CVD) vor. Laut Fraunhofer-Whitepaper umfasst das zwei Anforderungen: eine öffentlich zugängliche Kontaktadresse für Vulnerability Reports und einen strukturierten Meldeprozess für externe Sicherheitsforscher.

Das geht über eine einfache E-Mail-Adresse hinaus. Der CVD-Prozess muss Reaktionszeiten und Verantwortlichkeiten definieren. Externe Sicherheitsforscher brauchen klare Informationen, an wen sie sich wenden können und welche Rückmeldung sie erwarten dürfen. Eine veröffentlichte Security-Policy (z. B. als security.txt nach RFC 9116) schafft die nötige Transparenz.

Neben dem CVD-Prozess fordert der CRA ein dauerhaftes Vulnerability-Monitoring über den gesamten Supportzeitraum. SBOM-Einträge müssen kontinuierlich gegen Schwachstellendatenbanken (NVD/CVE, CISA KEV) abgeglichen werden. Tools wie OWASP Dependency-Track oder Trivy automatisieren diesen Abgleich. Systematisches Schwachstellenmanagement ist ein laufender Betriebsprozess mit Personalkosten, Tooling und definierten Eskalationswegen.

Die konkreten Meldefristen bei aktiv ausgenutzten Schwachstellen werden im Abschnitt „Meldepflichten“ behandelt.

Supportzeitraum und Sicherheitsupdates

Laut EU-Herstellerleitfaden müssen Hersteller Sicherheitsupdates für mindestens 5 Jahre ab Inverkehrbringen bereitstellen. Falls die erwartete Produktlebensdauer kürzer ist, gilt dieser kürzere Zeitraum. Updates müssen kostenlos und ohne unnötige Verzögerung verfügbar sein.

Jedes veröffentlichte Sicherheitsupdate muss nach Veröffentlichung mindestens zehn Jahre zum Download bereitstehen. Wer 2028 ein Produkt auf den Markt bringt, muss bis mindestens 2033 Patches liefern und diese bis 2043 vorhalten.

Diese Pflicht verändert die Produktkalkulation. Bei einem Produkt mit 500.000 € Entwicklungskosten sollten Sie 10 bis 20 % des Entwicklungsbudgets pro Jahr für Security-Maintenance einplanen. Über fünf Jahre summiert sich das auf 250.000 bis 500.000 € zusätzlich. Wer diese Kosten nicht in den Verkaufspreis einrechnet, verkauft unter Selbstkosten.

Besonders betroffen sind Hersteller mit kurzen Produktzyklen. Wer alle 18 Monate ein Nachfolgemodell einführt, muss für drei Produktgenerationen gleichzeitig Patches entwickeln, testen und ausliefern. Umgekehrt stehen Industrieausrüster mit Lebenszyklen von 15 bis 20 Jahren vor der Frage, ob fünf Jahre Support reichen, wenn Kunden längere Zeiträume erwarten.

Konformitätsbewertung und CE-Kennzeichnung nach dem CRA

Die etablierte CE-Kennzeichnung deckt zudem künftig laut den BSI-Produktanforderungen erstmals auch die Ebene der Cybersicherheit ab. Produkte mit digitalen Elementen dürfen nur mit CE-Zeichen auf dem EU-Markt bereitgestellt werden. Das Zeichen bestätigt dann nicht mehr nur elektromagnetische Verträglichkeit oder physische Sicherheit, sondern auch die Einhaltung der Cyber Resilience Act Anforderungen.

Drei Module im Überblick

Welches Konformitätsbewertungsverfahren Ihr Produkt durchlaufen muss, hängt von der Produktklassifizierung ab.

Modul	Bezeichnung	Geeignet für	Dritte Stelle nötig?
A	Interne Fertigungskontrolle (Selbstbewertung)	Standardprodukte, Klasse I (mit harmonisierter Norm)	Nein
B + C	EU-Baumusterprüfung + Konformität mit Baumuster	Klasse I (ohne harmonisierte Norm), Klasse II, Kritisch	Ja
H	Umfassende Qualitätssicherung	Klasse I (ohne harmonisierte Norm), Klasse II, Kritisch	Ja

Die meisten regulären Produkte decken Modul A unkompliziert über eine interne Dokumentation ab. Für Klasse-I-Produkte greift Modul A nur, wenn Sie harmonisierte Normen, gemeinsame Spezifikationen oder ein EU-Cybersecurity-Zertifizierungsschema vollständig anwenden. Fehlt diese Voraussetzung, wird eine Drittbewertung über Modul B+C oder H verpflichtend. Klasse-II- und kritische Produkte erfordern immer eine Drittbewertung.

Modul B+C oder Modul H? Entscheidungsfaktoren

Die Wahl zwischen den beiden Drittbewertungsverfahren hat direkte Auswirkungen auf Kosten und Zeitaufwand.

Modul B+C eignet sich für Hersteller mit wenigen Produkttypen. Die benannte Stelle prüft ein Muster, der Hersteller stellt anschließend die Serienkonformität sicher. Die geschätzten Kosten liegen bei 20.000 bis 60.000 € pro Produkttyp, vergleichbar mit Verfahren unter der Funkanlagenrichtlinie und IEC 62443. Nach Einreichung vollständiger Dokumentation dauert das Verfahren 3 bis 6 Monate.

Modul H lohnt sich bei breiten Portfolios oder häufigen Produktvarianten. Statt jedes einzelne Produkt zu prüfen, überwacht die benannte Stelle Ihr Qualitätsmanagementsystem. Die Einstiegskosten sind höher, doch pro Produkt sinken die Kosten deutlich. Wer bereits ein QMS nach ISO 9001 betreibt, vermeidet doppelte Audit-Strukturen und senkt den Aufwand pro Produktvariante.

Faustregel für den typischen Mittelständler: Bei 1 bis 3 Produkten in Klasse I oder II ist Modul B+C die pragmatische Wahl. Ab 5 oder mehr Produktvarianten mit bestehendem QMS sollten Sie Modul H prüfen.

Harmonisierte Normen: Der aktuelle Stand

CEN, CENELEC und ETSI haben den Normungsauftrag M/606 im April 2025 angenommen und arbeiten an 41 harmonisierten Normen. Die Zeitplanung ist ambitioniert. Typ-A- und Typ-B-Normen (Framework, Vulnerability Handling) sollen bis August 2026 als Entwürfe vorliegen. Die Typ-B-Horizontalnorm für technische Anforderungen ist erst für Oktober 2027 terminiert, einen Monat vor Geltung der vollständigen CRA-Anforderungen. Das lässt wenig Spielraum.

Bis zur Veröffentlichung können Hersteller auf bestehende Standards zurückgreifen, um die Konformitätsvermutung auszulösen. ETSI EN 303 645 (Consumer IoT) und IEC 62443 (Industrieautomation) decken einen Großteil der Anforderungen ab. Das ENISA-Standards-Mapping ordnet die CRA-Anforderungen aus Anhang I diesen bestehenden Normen zu und identifiziert Lücken, in denen neue Normen entwickelt werden müssen.

Für Hersteller im Industrieumfeld ist die Überlappung mit IEC 62443 besonders relevant. IEC 62443-4-2 deckt etwa 70 bis 80 % der produktbezogenen CRA-Anforderungen ab. Die verbleibenden Lücken betreffen fünf Bereiche: maschinenlesbare SBOMs, die 24-Stunden-Meldepflicht, den Mindest-Supportzeitraum von fünf Jahren, die CE-Kennzeichnung und die kostenlose Update-Pflicht. Wer IEC 62443-4-1 und -4-2 bereits implementiert hat, kann die Gap-Analyse in 3 bis 6 Monaten abschließen statt in 12 bis 18 Monaten ohne diese Basis.

Falls die harmonisierten Normen nicht rechtzeitig kommen, kann die EU-Kommission gemeinsame Spezifikationen nach Artikel 27 erlassen. Das Instrument umgeht den Normungsprozess und wird in der Industrie kontrovers diskutiert.

Benannte Stellen: Der Engpass ab 2026

Stand März 2026 ist keine einzige CRA-spezifische benannte Stelle notifiziert. Der Rahmen greift ab dem 11. Juni 2026. Die Akkreditierungspipeline läuft an, am 30. März 2026 findet ein EA-Workshop statt. Erste notifizierte Stellen sind realistisch ab Q3/Q4 2026 zu erwarten. TÜV-Gruppen, SGS/Brightsight und Bureau Veritas gehören zu den wahrscheinlichsten Kandidaten.

Wer Modul B+C oder H benötigt, sollte jetzt Vorgespräche mit diesen Stellen führen. Die Vorlaufzeit für eine Drittstellenbewertung beträgt 3 bis 6 Monate nach Einreichung. Wer erst kurz vor Dezember 2027 mit der Dokumentation beginnt, wird diesen Stichtag verpassen.

Meldepflichten: Fristen bei Schwachstellen und Sicherheitsvorfällen

Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle melden. Wer bis dahin keinen funktionierenden Meldeprozess etabliert, riskiert im Ernstfall unmittelbar den Vertrieb seiner Produkte.

Drei Fristen, drei Eskalationsstufen

Die Meldepflichten der Cyberresilienz-Verordnung folgen laut den BSI-Produktanforderungen einem dreistufigen Schema:

• Innerhalb von 24 Stunden gibt der Hersteller eine Frühwarnung an die zuständige nationale CSIRT und an die ENISA ab. Diese Meldung erfordert keine vollständige Analyse. Sie enthält das betroffene Produkt, die Mitgliedstaaten, in denen es vertrieben wird, und eine erste Einschätzung zur aktiven Ausnutzung.
• Innerhalb von 72 Stunden folgt die vollständige Schwachstellenmeldung: Art der Schwachstelle, Auswirkung auf das Produkt, verfügbare Gegenmaßnahmen und geplante Korrekturschritte.
• Innerhalb von 14 Tagen nach Bereitstellung der Korrekturmaßnahme reicht der Hersteller einen Abschlussbericht ein, der die Schwachstelle detailliert beschreibt, Patch-Informationen dokumentiert und Lessons Learned festhält.

Die Fristen beginnen, sobald der Hersteller Kenntnis von der aktiv ausgenutzten Schwachstelle erlangt. Konkret bedeutet das: Ein CVE, das Freitagabend veröffentlicht wird und Samstagmorgen einen Alert auslöst, startet die 24-Stunden-Frist ab dem Moment, in dem eine verantwortliche Person den Alarm zur Kenntnis nimmt. Rufbereitschaft ist deshalb Pflicht.

Die ENISA-Meldeplattform als zentrale Anlaufstelle

Hersteller müssen Meldungen nicht einzeln an jede nationale Behörde senden. Die ENISA richtet eine einheitliche europäische Single Reporting Platform ein. Über diese Plattform geben Hersteller Schwachstellen- und Vorfallmeldungen zentral ab. Die Weiterleitung an die zuständigen nationalen CSIRTs erfolgt automatisiert. Das ENISA-Standards-Mapping dokumentiert die Anforderungen an diese Plattform und ordnet sie bestehenden Normen zu.

Registrieren Sie sich für die Plattform, sobald diese verfügbar ist. Die Registrierung gehört zu den fünf Maßnahmen, die vor September 2026 abgeschlossen sein müssen.

So bauen Sie Ihren 24-Stunden-Meldeprozess auf

Die 24-Stunden-Frist klingt knapp. Sie ist es auch. Die Frühwarnung verlangt aber keine fertige Analyse, sondern eine erste Einschätzung. Ein häufiger Fehler: Unternehmen verzögern die Meldung, weil sie erst „alles klären“ wollen. Genau das führt zur Fristüberschreitung. Drei Bausteine machen den Prozess handhabbar.

Klare Rollen definieren. Benennen Sie einen Vulnerability Coordinator als Hauptverantwortlichen für Triage und Meldeentscheidung. Diese Person braucht Rufbereitschaft mit einer Reaktionszeit von maximal vier Stunden außerhalb der Geschäftszeiten. Ein Eskalationsentscheider aus der Geschäftsführung muss telefonisch erreichbar sein, um die finale Meldeentscheidung zu treffen. Ein technischer Ansprechpartner aus der Entwicklung bewertet die betroffene Komponente. Ein 24/7-SOC ist für mittelständische Hersteller nicht nötig. SMS- oder Push-Alerts an den Coordinator in Rufbereitschaft reichen.

Vorbereitete Templates nutzen. Erstellen Sie drei Melde-Templates: Frühwarnung (24h), Schwachstellenmeldung (72h) und Abschlussbericht (14 Tage). Jedes Template enthält alle Pflichtfelder vorausgefüllt mit statischen Produktdaten. Mit einem solchen Template lässt sich die Frühwarnung in rund 30 Minuten ausfüllen und absenden.

Trockenübung vor dem Ernstfall durchführen. Spielen Sie den Ablauf vom CVE-Alert über die Triage bis zur Meldung an einem fiktiven Szenario durch. Ohne diese Übung verlieren Sie im Ernstfall die 24-Stunden-Frist garantiert.

Zeitplan: Was bis September 2026 stehen muss

Für ein Unternehmen mit 3–10 Produkten, das heute bei Null startet, sieht ein realistischer Zeitrahmen so aus:

Phase	Zeitraum	Aktivität
Scope & Inventar	Woche 1–3	Produktliste erstellen, vorläufige CRA-Klassifizierung durchführen
SBOM-Aufbau	Woche 3–10	Tool-Auswahl, CI/CD-Integration, SBOMs für Kernprodukte generieren
Vulnerability Monitoring	Woche 6–12	Dependency-Track oder Trivy einrichten, CVE-Feed anbinden, Triage-Kriterien festlegen
Meldeprozess	Woche 8–14	Rollen definieren, Eskalationskette aufbauen, Templates erstellen, Rufbereitschaft einrichten
Trockenübung	Woche 14–16	Fiktives Szenario simulieren, Prozess anpassen
SRP-Registrierung	Woche 16–20	Bei ENISA Single Reporting Platform registrieren

Gesamtdauer: 4–5 Monate. Starten Sie idealerweise zeitnah im Frühjahr, um die Frist zuverlässig einzuhalten.

Pflichten für Importeure und Händler

Der EU CRA adressiert nicht nur Hersteller. Auch Importeure und Händler unterliegen konkreten Pflichten. Importeure müssen vor dem Inverkehrbringen verifizieren, dass der Hersteller die Konformitätsbewertung durchgeführt, die technische Dokumentation erstellt und die CE-Kennzeichnung angebracht hat. Gebrauchsanweisungen in der jeweiligen Landessprache müssen beiliegen, der Supportzeitraum muss deklariert sein. Eine Kopie der EU-Konformitätserklärung ist mindestens zehn Jahre aufzubewahren. Händler prüfen vor der Marktbereitstellung, ob CE-Kennzeichnung und EU-Konformitätserklärung vorliegen. Die Anforderungen an alle Wirtschaftsakteure erläutert die ATHENE-Rechtsanalyse im Detail.

Artikel 21 der CRA-Verordnung definiert zwei Fälle, in denen ein Importeur oder Händler selbst als Hersteller gilt: wenn das Produkt unter eigenem Namen oder eigener Marke vertrieben wird (White-Labelling) oder wenn eine Änderung vorgenommen wird, die das Risikoniveau verändert. In beiden Fällen gelten alle Herstellerpflichten, von der Konformitätsbewertung über die technische Dokumentation bis zu Meldepflichten und Supportverpflichtung. Das betrifft eine große Zahl von Distributoren in Deutschland, die elektronische Produkte aus China, Taiwan oder den USA unter Eigenmarke anbieten. Viele dieser Unternehmen haben ihre CRA-Pflichten noch nicht auf dem Schirm. Der erste Schritt: Senden Sie einen CRA-Fragebogen an Ihre Lieferanten, der Konformitätsbewertungsverfahren, SBOM-Verfügbarkeit, Supportzeitraum und CVD-Prozess abfragt. Verifizieren Sie die Ergebnisse eigenständig, bevor Sie das Produkt auf dem EU-Markt bereitstellen.

Ausnahmen vom Cyber Resilience Act

Nicht jedes Produkt mit digitalen Elementen fällt unter den Cyber Resilience Act. Die Verordnung definiert drei Ausnahmebereiche: nicht-kommerzielle Open-Source-Software, eine neue Kategorie für Open-Source-Organisationen und Produkte mit bestehender Sektorregulierung. Diese Abgrenzung genau zu kennen schützt vor unnötigem Compliance-Aufwand, aber auch vor falscher Sicherheit.

Nicht-kommerzielle Open-Source-Software

Freie und quelloffene Software fällt laut BSI-Übersicht zum CRA grundsätzlich nicht unter die Verordnung. Die Ausnahme greift, solange die Software außerhalb einer kommerziellen Tätigkeit auf dem Markt bereitgestellt wird.

Der Preis allein entscheidet nicht. Ausschlaggebend ist der wirtschaftliche Kontext. Ein Entwickler, der eine JavaScript-Bibliothek ehrenamtlich pflegt und auf GitHub veröffentlicht, gilt nicht als Hersteller im Sinne des EU CRA. Bietet ein Unternehmen dagegen dieselbe Software gezielt an, um Kunden in ein kostenpflichtiges Ökosystem zu führen, liegt eine kommerzielle Tätigkeit vor. Dann greift die Verordnung.

Der Gesetzgeber wollte mit dieser Regelung verhindern, dass ehrenamtliche Entwickler und gemeinnützige Projekte denselben Pflichten unterliegen wie kommerzielle Softwarehersteller. Ohne diese Abgrenzung wäre ein Großteil der Open-Source-Infrastruktur gefährdet, auf der die europäische Digitalwirtschaft aufbaut.

Verwalter quelloffener Software: Die Steward-Kategorie

Zwischen Hobby-Entwicklung und kommerziellem Hersteller hat der CRA eine dritte Rolle geschaffen. Der „Verwalter quelloffener Software“ (Open-Source Steward) bezeichnet laut ATHENE-Rechtsanalyse Organisationen, die systematisch die Entwicklung von Open-Source-Software unterstützen, welche für kommerzielle Aktivitäten bestimmt ist. Typische Vertreter sind Stiftungen wie die Eclipse Foundation oder die Apache Software Foundation. Sie koordinieren Open-Source-Projekte, deren Code in tausenden kommerziellen Produkten steckt.

Diese Organisationen sind keine Hersteller. Aber sie beeinflussen die Sicherheit kommerziell genutzter Software direkt. Deshalb gelten für sie abgemilderte Pflichten:

• Einführung einer dokumentierten Sicherheitsrichtlinie für die betreute Software
• Zusammenarbeit mit Marktüberwachungsbehörden bei Sicherheitsvorfällen
• Einrichtung eines Prozesses zur koordinierten Schwachstellenoffenlegung (CVD)

Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation nach Anhang VII gelten für Stewards ausdrücklich nicht. Sie tragen keine Herstellerpflichten. Diese Differenzierung ist bewusst gewählt, denn eine volle Regulierung würde viele Stiftungen dazu zwingen, die kommerzielle Nutzung ihrer Software zu untersagen oder ihre Arbeit einzustellen.

Sektorspezifisch regulierte Produkte

Produkte, die bereits durch eigene EU-Vorschriften für Cybersicherheit reguliert sind, fallen nicht unter den CRA. Der Gesetzgeber will damit Doppelregulierung vermeiden. Für jede ausgenommene Produktgruppe existiert ein alternatives Regelwerk mit vergleichbaren oder strengeren Anforderungen.

Medizinprodukte unterliegen der Medical Device Regulation (MDR, Verordnung 2017/745) und der In-vitro-Diagnostika-Verordnung (IVDR, Verordnung 2017/746). Beide enthalten eigene Cybersicherheitsanforderungen für vernetzte Geräte und Software über den gesamten Produktlebenszyklus. Ein vernetztes Infusionssystem oder eine diagnostische KI-Anwendung wird über MDR/IVDR reguliert, nicht über den CRA.

Für Fahrzeuge gelten die UNECE-Regelungen R155 (Cybersecurity Management System) und R156 (Software Update Management System). Sie verpflichten Fahrzeughersteller zu einem zertifizierten Cybersicherheits-Managementsystem und regeln Software-Updates über die gesamte Fahrzeuglebensdauer. Aber Vorsicht: Die Ausnahme gilt nur für das Fahrzeug als Ganzes. Einzelne Automotive-Komponenten wie ECUs, Aftermarket-Geräte oder separat vertriebene Sensoren fallen unter den CRA, sobald sie eigenständig auf dem EU-Markt bereitgestellt werden.

Luftfahrtprodukte reguliert die European Union Aviation Safety Agency (EASA) über die Verordnung (EU) 2018/1139. Avionik-Systeme und Bordnetzwerke durchlaufen das EASA-Zertifizierungssystem, das zu den strengsten Prüfverfahren weltweit gehört. Die dort geltenden Anforderungen an Cybersicherheit gehen in vielen Bereichen über den CRA hinaus.

Sanktionen: Welche Bußgelder drohen bei Verstößen gegen den CRA?

Der Cyber Resilience Act sieht ein abgestuftes Sanktionsmodell vor. Die höchste Bußgeldstufe greift bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen aus Anhang I und gegen die Herstellerpflichten der CRA-Verordnung: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Das geht aus der BSI-Übersicht zum CRA hervor. Für andere Verpflichtungen aus der Verordnung gelten niedrigere Obergrenzen. Fehlerhafte oder unvollständige Angaben gegenüber Behörden werden ebenfalls sanktioniert, mit reduzierten Höchstbeträgen.

Der Bußgeldrahmen orientiert sich am NIS-2-Modell. Unternehmen mit NIS-2-Erfahrung kennen die Größenordnung.

Das eigentliche Risiko: Marktzugangsblockade

Die Maximalstrafen von 15 Mio. EUR dominieren die Schlagzeilen. Doch für die meisten Hersteller ist ein anderes Szenario bedrohlicher. In Deutschland wird das BSI als nationale Marktüberwachungsbehörde für den Cyber Resilience Act fungieren. Seine Befugnisse gehen über Geldbußen hinaus. Das BSI kann nicht-konforme Produkte vom Markt nehmen, Rückrufe anordnen und den Vertrieb untersagen.

Ein Verkaufsstopp trifft härter als jede Geldstrafe. Wenn das BSI ein Produkt vom Markt nimmt, das 30 oder 40 % Ihres Umsatzes ausmacht, stoppt der Cashflow sofort. Das Kundenvertrauen erholt sich nur langsam. Die Geldbuße kommt obendrauf, doch der wirtschaftliche Schaden durch die Vertriebsuntersagung übersteigt sie in aller Regel.

Beachten Sie den Zeitrahmen. Die Meldepflichten greifen ab dem 11. September 2026, die vollständigen Anforderungen ab dem 11. Dezember 2027. Ab diesen Stichtagen können Verstöße sanktioniert werden.

CRA und NIS-2 im Vergleich: Abgrenzung und Zusammenspiel

Cyber Resilience Act und NIS-2-Richtlinie verfolgen dasselbe Ziel: mehr Cyberresilienz in der EU. Der Weg dorthin unterscheidet sich grundlegend.

Kriterium	CRA	NIS-2
Regelungsgegenstand	Produkte mit digitalen Elementen	Betreiber kritischer Infrastrukturen und wichtiger Einrichtungen
Adressaten	Hersteller, Importeure, Händler	Unternehmen als Betreiber und Nutzer
Rechtsform	EU-Verordnung (unmittelbar gültig)	EU-Richtlinie (nationale Umsetzung nötig)
Schwerpunkt	Produktsicherheit (Security by Design)	Organisatorische Cybersicherheit (Risikomanagement)
Konformitätsnachweis	CE-Kennzeichnung, technische Dokumentation	Nachweis gegenüber nationaler Aufsichtsbehörde
Meldepflichten	24 h / 72 h / 14 Tage an CSIRT und ENISA	24 h / 72 h an nationale Behörde

Verordnung vs. Richtlinie: Warum der Unterschied zählt

Häufig taucht der Begriff „CRA Richtlinie“ auf, obwohl der CRA eine EU-Verordnung ist. Dieser Unterschied entscheidet über die Umsetzung: Wie die ATHENE-Rechtsanalyse festhält, gilt der EU CRA unmittelbar in allen Mitgliedstaaten. Kein nationales Parlament muss ein Umsetzungsgesetz verabschieden. Die Regeln stehen fest und gelten überall gleich.

Bei NIS-2 sieht das anders aus. Jeder Mitgliedstaat überträgt die Vorgaben in eigenes Recht. Deutschland arbeitet nach wie vor an der vollständigen Umsetzung. Das führt zu unterschiedlichen Zeitplänen je nach Standort und teils abweichenden Anforderungen.

Produktsicherheit trifft auf organisatorische Sicherheit

Die CRA-Verordnung definiert die Sicherheitseigenschaften, die ein Produkt vor dem Verkauf auf dem EU-Markt erfüllen muss. Secure-by-Default-Konfiguration, SBOM-Dokumentation und kostenlose Sicherheitsupdates für mindestens fünf Jahre sind produktbezogene Pflichten des Herstellers.

NIS-2 dagegen regelt, wie Unternehmen ihre eigene IT-Infrastruktur schützen. Risikomanagement, Incident Response und Lieferkettensicherheit stehen im Fokus. Es geht um die Organisation als Betreiber, nicht um das Produkt als Handelsobjekt.

Beide Regelwerke können gleichzeitig greifen. Ein Hersteller von Netzwerkkomponenten etwa muss seine Produkte CRA-konform gestalten und parallel als Betreiber wichtiger Einrichtungen die NIS-2-Pflichten erfüllen. Das bedeutet zwei getrennte Compliance-Stränge mit eigenen Fristen, Meldewegen und Dokumentationsanforderungen.

Vier Regelwerke, ein Unternehmen: Die Überlappungsproblematik

Die Bitkom-Stellungnahme warnt an dieser Schnittstelle vor Doppelprüfungen und widersprüchlichen Anforderungen. CRA, NIS-2, DORA, AI Act und Maschinenverordnung sind parallel anwendbar, ohne dass klare Abgrenzungsregeln existieren.

Ein Hersteller vernetzter Medizinprodukte muss beispielsweise potenziell den CRA, die MDR (Medical Device Regulation) und bei KI-Komponenten den AI Act beachten. Betreibt er gleichzeitig kritische Infrastruktur, kommt NIS-2 hinzu. Jedes Regelwerk bringt eigene Konformitätsbewertungen und Meldepflichten mit. Welche Dokumentation sich mehrfach nutzen lässt, ist bisher nur teilweise geklärt. Bitkom fordert deshalb verbindliche Abgrenzungsregeln auf EU-Ebene.

Was folgt daraus für Ihre Vorbereitung?

Prüfen Sie frühzeitig, welche Regelwerke auf Ihre Produkte und Ihre Organisation zutreffen. Wer bereits ein ISMS nach ISO 27001 betreibt, deckt etwa 60–70 % der CRA-Anforderungen auf Governance-Ebene ab. Die produktspezifischen Pflichten fehlen trotzdem. CE-Kennzeichnung, maschinenlesbare SBOM und die 24-Stunden-Meldepflicht an CSIRT und ENISA lassen sich nicht aus einem bestehenden Managementsystem ableiten. Eine Gap-Analyse macht sichtbar, wo NIS-2-Maßnahmen bereits CRA-Anforderungen abdecken. So vermeiden Sie Doppelarbeit und identifizieren offene Pflichten frühzeitig.

Checkliste: So bereiten Sie Ihr Unternehmen auf den CRA vor

Die Meldepflichten der Cyberresilienz-Verordnung greifen ab dem 11. September 2026. Sämtliche Anforderungen des Cyber Resilience Act gelten ab dem 11. Dezember 2027. Wer ohne Vorarbeiten beginnt, benötigt für die Umsetzung realistisch 14 bis 20 Monate. Jetzt, im März 2026, haben Sie noch Puffer. Ab Juni wird es eng.

Der VhU-Leitfaden empfiehlt Unternehmen, frühzeitig eine Bestandsaufnahme ihrer Produkte mit digitalen Elementen durchzuführen und drei Kernthemen zu priorisieren: SBOM-Prozesse, Schwachstellenmanagement und Updatefähigkeit. Unsere Checkliste führt Sie in sieben strukturierten Schritten zur Konformität.

Schritt 1: Bestandsaufnahme durchführen

Erstellen Sie ein Inventar aller Produkte mit digitalen Elementen, die Sie auf dem EU-Markt bereitstellen. Klassifizieren Sie jedes Produkt als Standard, Wichtig (Klasse I oder II) oder Kritisch (→ Abschnitt Produktklassifizierung).

Gerade bei Maschinenbauern steckt Software in Komponenten, die intern niemand als „digitales Produkt“ betrachtet. Ein häufiger Fehler: Hersteller stufen sich vorschnell als „Standard-Produkt“ ein und stellen Monate später fest, dass eine Drittbewertung nötig ist. Vernetzte Thermostate mit Sicherheitsfunktionen fallen beispielsweise unter Anhang III, Klasse I, nicht in die Standard-Kategorie.

Schritt 2: Gap-Analyse gegen CRA-Anforderungen

Vergleichen Sie Ihren Entwicklungsprozess mit den Anforderungen des Cyber Resilience Act (Anhang I). Das Fraunhofer-Whitepaper übersetzt diese Vorgaben in technische Maßnahmen und eignet sich als Implementierungshilfe für Hersteller.

Vier Fragen zeigen Ihren Reifegrad:

• Pflegen Sie für eines Ihrer Produkte eine SBOM? Falls nein, starten Sie bei Null. Die SBOM-Frage ist der zuverlässigste Indikator für den aktuellen Stand. Falls ja, gibt es einen Anknüpfungspunkt für die September-2026-Readiness.
• Was passiert heute bei einer bekannten Sicherheitslücke in einer Produktkomponente? Wer beschreiben kann, wie CVEs überwacht, bewertet und behoben werden, hat eine Basis. Wer sagt „Das leitet der Entwickler weiter, der gerade Zeit hat“, hat keinen Prozess.
• Setzen Sie IEC 62443, ISO 27001 oder ISO 9001 ein? IEC 62443 liefert den besten Ausgangspunkt für die technischen Anforderungen. Ein QMS nach ISO 9001 gibt Struktur für die Dokumentationspflichten. Ohne beides beginnen Sie bei der Grundstruktur.
• Wann planen Sie Ihr nächstes Produkt-Release? Die Antwort bestimmt, welche Produkte Sie zuerst CRA-konform machen müssen.

Unternehmen mit bestehender IEC-62443-Basis können mit 50–60 % des Gesamtaufwands rechnen.

Schritt 3: SBOM-Prozess aufsetzen

Instrumentieren Sie Ihr Build-System so, dass bei jedem Release automatisch eine SBOM generiert wird. Empfohlenes Format ist CycloneDX 1.6+ (bietet native VEX-Integration für den Security-Kontext) oder SPDX 3.0.1+.

Für die meisten Szenarien bewährt sich ein zweigleisiger Ansatz. Syft (Open Source, von Anchore) analysiert Container-Images, Dateisysteme und Archive und lässt sich per CLI oder GitHub Actions in die CI/CD-Pipeline integrieren. Für Embedded-Systeme ohne Build-Transparenz, etwa bei zugekaufter Firmware, ergänzen Tools wie ONEKEY die SBOM durch Binary-Analyse. Besonders relevant ist das für Importeure, die SBOMs ihrer Lieferanten verifizieren müssen.

Eine IoT-Firmware mit Embedded Linux enthält schnell 200–500 SBOM-Einträge. Der CRA fordert „mindestens Top-Level-Abhängigkeiten.“ Das reicht für eine systematische Schwachstellenerkennung nicht aus. Das BSI empfiehlt in der TR-03183-2 die Erfassung bis zur ersten externen Komponente, denn wer nur Top-Level dokumentiert, bleibt bei der Schwachstellenerkennung blind. Erfassen Sie so tief, wie Ihre Tools es automatisiert hergeben.

Gleichen Sie die generierte SBOM automatisiert gegen Schwachstellendatenbanken ab. OWASP Dependency-Track ist die Open-Source-Referenz dafür. Für kleinere Teams reicht ein Trivy-Scan mit JSON-Output.

Schritt 4: Meldeprozesse einrichten

Deadline: 11. September 2026. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden als Frühwarnung an die zuständige CSIRT und die ENISA melden (→ Abschnitt Meldepflichten).

Drei Bausteine sind dafür nötig.

Vulnerability-Monitoring: Richten Sie einen Prozess ein, der kontinuierlich CVE-Datenbanken und CISA KEV gegen Ihre SBOM-Einträge abgleicht. Dependency-Track oder Trivy automatisieren das. Definieren Sie Triage-Kriterien: Wann gilt eine Schwachstelle als „aktiv ausgenutzt“?

Eskalationskette mit Rollen: Benennen Sie einen Vulnerability Coordinator mit Rufbereitschaft (Reaktionszeit ≤ 4 Stunden) und einen Eskalationsentscheider aus der Geschäftsleitung für die finale Meldeentscheidung. 24/7-Besetzung ist nicht nötig. Rufbereitschaft am Wochenende per SMS/Push-Notification reicht aus.

Melde-Templates vorbereiten: Erstellen Sie drei vorausgefüllte Templates für Frühwarnung (24 h), Schwachstellenmeldung (72 h) und Abschlussbericht (14 Tage). Hinterlegen Sie zudem Ihre Kontaktdaten auf der kommenden EU-Meldeplattform.

Die Frühwarnung erfordert keine vollständige Analyse und lässt sich mit einem vorbereiteten Template zügig absenden. Üben Sie den gesamten Ablauf mit einem simulierten Szenario, bevor die Frist greift.

Schritt 5: CVD-Kontakt einrichten

Veröffentlichen Sie eine Security-Kontaktadresse und erstellen Sie eine Vulnerability Disclosure Policy (VDP). Der CRA schreibt eine koordinierte Schwachstellenoffenlegung vor, über die Sicherheitsforscher Schwachstellen melden können.

security.txt nach RFC 9116: Platzieren Sie eine maschinenlesbare Datei unter /.well-known/security.txt auf Ihrer Website mit Kontakt-E-Mail, Link zur VDP, PGP-Key und Gültigkeitsdatum. Viele Sicherheitsforscher prüfen diese Adresse als Erstes.

Vulnerability Disclosure Policy: Beschreiben Sie, wie Meldungen eingehen sollen. Mindestinhalt: Scope (welche Produkte), Kontaktweg (idealerweise security@firma.de), Antwortzeit (Erstreaktion innerhalb 72 Stunden), Safe-Harbor-Klausel und Disclosure-Timeline (üblicherweise 90 Tage).

Planen Sie den Worst Case ein: Veröffentlicht ein Sicherheitsforscher eine Schwachstelle, bevor Sie reagieren konnten, greift die 24-Stunden-Meldepflicht. Wer keinen Prozess hat, verliert diese Frist garantiert.

Schritt 6: Konformitätsbewertung planen

Die Art der Bewertung hängt von Ihrer Produktklassifizierung ab. Standardprodukte weisen die Konformität über eine Selbstbewertung nach, während Klasse-II- und kritische Produkte zwingend eine externe Prüfstelle erfordern (→ Abschnitt Konformitätsbewertung).

Für Klasse-I-Produkte gilt eine Besonderheit: Die Selbstbewertung nach Modul A ist nur zulässig, wenn harmonisierte Normen, gemeinsame Spezifikationen oder EU-Cybersecurity-Zertifizierungsschemata vollständig angewendet werden. Stand März 2026 liegen keine dieser Referenzen vor. Sie müssen deshalb mit einer Drittbewertung (Modul B+C oder H) planen.

CRA-spezifische benannte Stellen sind bisher nicht notifiziert. Die Notifizierung läuft voraussichtlich ab Q3/Q4 2026 an. Rechnen Sie mit 3–6 Monaten Vorlaufzeit für eine Drittbewertung und nehmen Sie frühzeitig Kontakt zu potenziellen Stellen auf (TÜV, SGS/Brightsight, Bureau Veritas). Wer erst Ende 2027 mit der Dokumentation beginnt, wird die Dezember-Deadline nicht halten.

Schritt 7: Technische Dokumentation vorbereiten

Erstellen Sie die technische Dokumentation nach Anhang VII und die EU-Konformitätserklärung. Gefordert sind Produktbeschreibung, Risikoanalyse, Beschreibung der Sicherheitsmaßnahmen, aktuelle SBOM, Prüfberichte und die Konformitätserklärung.

Wer die Schritte 1–6 abgearbeitet hat, verfügt bereits über die meisten Inhalte. Die Dokumentation fasst die Ergebnisse zusammen und bringt sie in die geforderte Form. Planen Sie dennoch ausreichend Zeit ein: Für ein Unternehmen mit 5 Produkten sind 4–6 Monate Dokumentationsarbeit realistisch.

Zeitplan und Ressourcen

Für ein Unternehmen mit 50–500 Mitarbeitern und 3–10 Produkten, das von Null startet:

Phase 1 – Meldepflicht-Readiness (bis September 2026): Schritte 1–5 laufen teilweise parallel. Realistischer Zeitbedarf: 4–5 Monate. Wer jetzt im März 2026 startet, schafft das mit Puffer. Wer im Juni anfängt, wird es kaum halten.

Phase 2 – Vollständige Konformität (bis Dezember 2027): Schritte 6–7 plus Security-by-Design-Integration in den Entwicklungsprozess, CRA-konforme Lieferantenverträge und CE-Kennzeichnung. Weitere 10–14 Monate Zeitbedarf.

Personaleinsatz: 0,5–1 FTE dediziert für CRA-Compliance, plus Zuarbeit aus Entwicklung, QM und Einkauf.

Kostenschätzung: Für 5 Produkte ohne bestehende IEC-62443-Basis: 150.000–400.000 €, verteilt auf 18 Monate. Darin enthalten: externe Beratung, Tooling (SBOM-Generierung, Vulnerability-Monitoring, ggf. Drittbewertung) und interner Personalaufwand als größter Einzelposten.

Wir erstellen Ihre Gap-Analyse, begleiten die Meldeprozess-Einrichtung und schulen Ihr Entwicklungsteam. Sprechen Sie uns an, wenn Sie Unterstützung bei der CRA-Vorbereitung brauchen.

Fazit: Cyber Resilience Act: Jetzt handeln statt abwarten

Der Cyber Resilience Act ist seit dem 10. Dezember 2024 geltendes EU-Recht. Die Übergangsfristen laufen. Was Sie jetzt mitnehmen sollten:

1. Die erste Frist kommt im September 2026. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an CSIRT und ENISA melden. Planen Sie für den Aufbau der Abläufe intern genügend Vorlauf ein, um zum Stichtag auskunftsfähig zu sein.

2. Der Geltungsbereich ist breit. Die CRA-Verordnung betrifft nahezu alle Hersteller von Produkten mit digitalen Elementen, also Hardware und Software. Je nach Klassifizierung reicht eine Selbstbewertung aus, während für wichtige oder kritische Systeme Drittstellenprüfungen verpflichtend greifen.

3. Frühzeitig starten spart Geld. Bei Verstößen gegen die Anforderungen des Cyber Resilience Act drohen Bußgelder bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes (Details im Abschnitt „Sanktionen“). Die Kosten für CRA-Konformität liegen bei 150 000 bis 400 000 € für ein mittelständisches Unternehmen mit 5 Produkten, verteilt auf 18 Monate. Ein Bruchteil möglicher Sanktionen.

Ihr erster Schritt: Erstellen Sie eine SBOM für Ihr umsatzstärkstes Produkt und richten Sie einen automatisierten CVE-Abgleich ein. Tools wie Syft oder Trivy machen das innerhalb einer Woche möglich. Oft fördert der erste Durchlauf dutzende bekannter Schwachstellen zutage. Das schafft intern die Grundlage für Budget und Ressourcen schneller als jede Präsentation über Bußgeldhöhen.

Wir erstellen Ihre CRA-Gap-Analyse, unterstützen beim Aufbau Ihres SBOM-Prozesses und bereiten Ihre Konformitätsdokumentation vor. Buchen Sie jetzt ein unverbindliches Erstgespräch.

FAQ: Häufige Fragen zum Cyber Resilience Act