Cyber Resilience Act (CRA) — Was Hersteller bis 2027 aufbauen müssen
Stellen Sie sich vor: Ihr bester Kunde ruft im Januar 2028 an. Er kann Ihre Steuerungskarten nicht mehr verbauen — weil seit dem 11. Dezember 2027 die vollständige Anwendung des Cyber Resilience Act (CRA) gilt und Ihr Produkt keine CE-Kennzeichnung für Cybersecurity trägt. Sie dürfen nicht mehr in die EU liefern.
Das ist keine Dystopie. Das ist die logische Konsequenz der Verordnung (EU) 2024/2847, die seit dem 10. Dezember 2024 in Kraft ist und den Marktzugang für „Produkte mit digitalen Elementen" neu regelt. Wer Hardware oder Software in die EU bringt, die direkt oder indirekt mit einem Netzwerk kommunizieren kann, muss ab Dezember 2027 nachweislich Secure-by-Design entwickeln, Schwachstellen über den gesamten Lebenszyklus managen und eine CE-Konformitätserklärung vorlegen. Sonst drohen Bußgelder von bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes — und der Ausschluss vom Markt.
Die zwei Stichtage, die Sie kennen müssen
11. September 2026: Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle (24-Stunden-Frist an ENISA).
11. Dezember 2027: Vollständige Anwendung. Ohne CE-Konformität kein Marktzugang.
Sind Sie betroffen? Ein 7-Fragen-Selbsttest
Die meisten Geschäftsführer, mit denen wir sprechen, stellen zuerst die gleiche Frage: „Gilt das wirklich für uns?" Die Antwort lautet meist: Ja. Der CRA greift breiter als viele erwarten — er erfasst alle „Produkte mit digitalen Elementen", also Hardware und Software, die eine direkte oder indirekte Verbindung zu einem Gerät oder Netzwerk herstellen können.
Beantworten Sie folgende Fragen mit Ja oder Nein:
- Stellt Ihr Produkt eine Verbindung zu einem Netzwerk her — auch indirekt? (Ethernet, WLAN, Bluetooth, Mobilfunk, Feldbus, USB an einen Internet-Rechner)
- Enthält Ihr Produkt Software — auch nur Embedded Firmware auf einem Mikrocontroller?
- Bringen Sie das Produkt auf den EU-Markt — als Hersteller, Einführer oder autorisierter Vertreter?
- Handelt es sich um keine der ausdrücklichen Ausnahmen? (Kein Medizinprodukt, kein Fahrzeug mit Typgenehmigung, keine zivile Luftfahrtkomponente, keine Schiffsausrüstung.)
- Verkaufen Sie das Produkt nicht ausschließlich kostenfrei als Open-Source ohne Gewinnerzielungsabsicht?
- Sind Sie in der Lieferkette tätig — auch als Zulieferer von Komponenten für Endprodukte?
- Haben Sie bisher keine systematische Schwachstellen-Dokumentation oder Software Bill of Materials (SBOM)?
🔴 4–7 × Ja
Vollständig im Geltungsbereich. CRA betrifft Ihr Kerngeschäft. Sofortiger Handlungsbedarf.
🟡 2–3 × Ja
Teile Ihres Portfolios sind erfasst. Bis Juni 2026 finale Klassifizierung vornehmen.
🟢 0–1 × Ja
Wahrscheinlich ausgenommen. Oder Sie haben die Vernetzung Ihrer Produkte unterschätzt — Punkte 1 und 2 noch einmal prüfen.
Ein Beispiel aus unserer Praxis: Ein Hersteller industrieller Schaltschränke sagte uns: „Wir sind doch nur Hardware." Bei genauer Betrachtung enthielt jeder Schaltschrank ein IoT-Modul für Fernwartung, die Firmware wurde remote aktualisiert, die Steuerung kommunizierte über Profinet. Ergebnis: Vollständig erfasst. Der CRA macht keine Unterscheidung zwischen „echtem Software-Produkt" und „Hardware mit etwas Steuerung".
Die vier Säulen des CRA — was die Verordnung wirklich verlangt
Der CRA baut auf vier tragenden Säulen auf. Wer diese verinnerlicht, versteht den Geist der Verordnung — und kann die Anforderungen in bestehende Entwicklungs- und QM-Prozesse einpassen.
🛡️ Secure-by-Design
Security darf nicht nachträglich „draufgeschraubt" werden. Sie muss vom ersten Architektur-Entwurf an im Produkt verankert sein.
Konkret: Cybersicherheits-Risikoanalyse vor Markteinführung, keine Standard-Passwörter (einzigartige Credentials pro Gerät), Verschlüsselung wo nötig, Integritätsprüfung (Signed Firmware).
🔄 Vulnerability Management
Der eigentliche Aufwandstreiber. Schwachstellen für die gesamte vorgesehene Lebensdauer managen.
Definierter Prozess zur Behebung, Sicherheits-Updates während transparent kommunizierter Support-Periode, Vulnerability-Disclosure-Kanal, systematische CVE-Überwachung.
✅ CE-Konformitätsbewertung
Die sichtbarste Säule. Ohne CE-Mark kein Marktzugang ab Dezember 2027.
Selbstbewertung (Default-Klasse) oder Drittprüfung durch eine benannte Stelle (Notified Body) für „wichtige" und „kritische" Produkte.
📋 Transparenz
Nutzer-Informationspflichten. Nicht Marketing-Boilerplate, sondern nachprüfbare technische Dokumentation.
Welche Sicherheitseigenschaften? Wie lange Updates? Wo melden? SBOM für Lieferketten-Transparenz.
Die zwei kritischen Stichtage
Der CRA hat einen gestaffelten Anwendungsplan. Zwei Termine sind für Mittelständler existenziell.
| Stichtag | Was tritt in Kraft? | Was Sie tun müssen |
|---|---|---|
| 11. September 2026 | Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an ENISA | Meldeprozess etablieren, 24h-Response-Team benennen, ENISA-Anbindung prüfen, interne Eskalationswege definieren |
| 11. Dezember 2027 | Vollständige Anwendung — ohne Konformität kein Marktzugang | CE-Konformität, technische Dokumentation, SBOM, Schwachstellen-Management dokumentiert, Self-Assessment oder Drittprüfung abgeschlossen |
Dazwischen liegt der 11. Juni 2026: Bis dahin müssen die nationalen Behörden ihre Verfahren zur Notifizierung von Konformitätsbewertungsstellen etabliert haben. Das ist vor allem für Hersteller von „wichtigen" und „kritischen" Produkten relevant. Nach unserer Einschätzung dürfte das Angebot an für CRA-Anforderungen notifizierten Stellen in Deutschland zunächst begrenzt sein — wer auf eine Drittprüfung angewiesen ist, sollte sich frühzeitig um einen Termin bemühen.
Der September 2026 ist der härtere Schnitt. Die 24-Stunden-Frist für Meldungen an ENISA ist unbarmherzig. Wer hier im September noch seine Prozesse definiert, ist zu spät. Der Dezember 2027 ist dann der finale Pflock — aber wer die September-Pflicht nicht erfüllt, steht ohnehin schon mit einem Bein im Bußgeldverfahren.
Wichtige vs. kritische Produkte — die drei Kategorien
Nicht jedes Produkt benötigt eine Drittprüfung. Der CRA unterteilt in drei Klassen — und Ihre Einstufung bestimmt den Aufwand maßgeblich.
| Kategorie | Anteil | Beispiele | Konformitätsweg |
|---|---|---|---|
| Default | ~90 % | Vernetzte Sensoren, Smart-Home-Zwischenstecker, Standard-IoT-Gateways | Selbst-Assessment + CE |
| Wichtig (Annex III) | ~8–9 % | Passwort-Manager, Betriebssysteme, Netzwerk-Routing-Hardware, vernetztes Spielzeug | Drittprüfung durch Notified Body |
| Kritisch (Annex IV) | ~1–2 % | Smartcards, sichere Hardware-Komponenten mit kryptographischen Funktionen | Drittprüfung + ggf. EUCC-Zertifizierung |
Bei Unsicherheit gilt: konservativ einstufen. Eine zu niedrige Einstufung führt im schlimmsten Fall zur Aberkennung der CE-Konformität. Eine zu hohe Einstufung kostet etwas mehr Aufwand — bringt aber Rechtssicherheit.
CRA × NIS-2 × ISO 27001 — wie passt das zusammen?
Ein häufiges Missverständnis: „Wir haben doch ISO 27001, damit sind wir sicher." Oder: „Wir machen sowieso NIS-2, das deckt den CRA mit ab." Beides ist nur halb richtig.
NIS-2 und CRA — komplementär, nicht identisch
Die NIS-2-Richtlinie adressiert Betreiber kritischer Infrastrukturen und wichtige Einrichtungen. Energieversorger, Verkehrsunternehmen, Behörden müssen ein angemessenes Risikomanagement, Meldepflichten und Business-Continuity-Management aufbauen.
Der CRA adressiert Hersteller von Produkten. Er sagt: Wie muss ein Produkt gebaut sein, bevor es auf den Markt kommt?
Die Schnittmenge ist groß, die Rollen sind verschieden. Ein Maschinenbauer, der seine eigene vernetzte Anlage betreibt, fällt unter NIS-2 (als Betreiber) und unter CRA (als Hersteller der Maschinensteuerung). Ein reiner Komponenten-Zulieferer fällt nur unter CRA.
Wer NIS-2 bereits umgesetzt hat — etwa mit einem Informationssicherheitsmanagement nach BSI-Grundschutz oder ISO 27001 — hat einen deutlichen Vorsprung. Schätzungsweise 40 % der organisatorischen CRA-Anforderungen (Dokumentation, Meldeprozesse, Risikomanagement, Management-Verantwortung) sind bereits vorhanden. Aber die produktspezifischen Anforderungen (Secure-by-Design, SBOM, CE-Konformität) fehlen fast vollständig.
ISO 27001 — ein Sprung nach vorn, kein Freifahrtschein
Wer ein ISO-27001-zertifiziertes ISMS betreibt, hat viele Management-Prozesse bereits etabliert: Risikomanagement, Dokumentenkontrolle, interne Audits, kontinuierliche Verbesserung. Das hilft enorm beim CRA, denn der verlangt strukturell Ähnliches.
Was ISO 27001 nicht abdeckt: Produktbezogene Secure-by-Design-Anforderungen (hier ist die IEC 62443 der passende Bezugsrahmen), CE-Kennzeichnung und Konformitätsbewertung nach EU-Produktrecht, die SBOM-Pflicht für Software-Komponenten, die spezifische 24h-Meldepflicht an ENISA.
Die SBOM-Pflicht — der unterschätzte Aufwandstreiber
Eine Software Bill of Materials (SBOM) ist eine detaillierte Stückliste aller Software-Komponenten, aus denen Ihr Produkt besteht — einschließlich Open-Source-Bibliotheken, Treiber, Firmware-Module und Betriebssystem-Komponenten. Der CRA verlangt sie für Lieferketten-Transparenz und schnellere Schwachstellen-Identifikation.
Hier wird es unbequem
Die meisten Mittelständler wissen nicht genau, was in ihrer Firmware wirklich steckt. Ein typisches Embedded-Linux für industrielle Steuerungen enthält schnell 200–500 Pakete. Welche Version? Welche Lizenz? Welche bekannten CVEs? Wer das nicht systematisch erfasst, kann weder die CRA-Anforderungen erfüllen noch im Ernstfall reagieren, wenn eine Zero-Day-Lücke in einer dieser Bibliotheken bekannt wird.
Für die SBOM-Erstellung haben sich Standards etabliert: SPDX (ISO/IEC 5962) für maschinenlesbare Lizenz- und Komponenteninformationen, CycloneDX als leichtgewichtiger Standard für Sicherheitsanwendungen, plus Tools wie Syft, das Container-Images, Dateisysteme und Archive scannt und SBOMs in beiden Formaten generiert.
Der Schlüssel ist die Einbindung in Ihre Build-Pipeline. Eine SBOM darf nicht einmalig manuell erstellt werden — sie muss zu jedem Release automatisch aktualisiert werden. Das ist Prozess-Arbeit, keine einmalige Dokumentation. Maschinenbauer, die ihre Firmware bisher „irgendwo bei einem Dienstleister" entwickeln lassen, müssen den Entwicklungsprozess und die Lieferantenanforderungen neu definieren.
Roadmap — was Sie in den nächsten 6 / 12 / 18 Monaten tun müssen
Der Zeitraum bis Dezember 2027 ist knapp, aber managbar — wenn Sie jetzt starten. Hier ein phasenorientierter Fahrplan mit konkreten Verantwortlichkeiten.
Drei Fallstricke, die teuer werden
„Wir sind doch nur Importeur"
Falsch. Wer ein Produkt aus Nicht-EU-Ländern in die EU bringt, haftet als Einführer mit. Sie müssen die Konformität prüfen und die technische Dokumentation einsehen können. Wenn der Hersteller in China sitzt und keine SBOM liefert, stehen Sie mit dem Rücken zur Wand.
„Open Source ist ausgenommen"
Nur teilweise. Kostenfreie Open-Source ohne Gewinnerzielungsabsicht ist ausgenommen. Sobald Sie diese Software in ein kommerzielles Produkt einbauen, greift der CRA. Die ausgenommene Basissoftware schützt nicht davor, dass Ihr Produkt als Ganzes fällt.
„Wir liefern nur an B2B"
Irrelevant. Der CRA ist B2B-agnostisch. Es spielt keine Rolle, ob Ihr Kunde Endverbraucher oder Industriebetrieb ist. Solange das Produkt auf dem EU-Markt ist, gelten die Anforderungen — gleich, ob Smart-Home-Lautsprecher oder CNC-Steuerungsmodul.
Der unbequeme Satz am Ende
Hier ist die Wahrheit, die niemand gerne hört: Wer im Sommer 2026 noch nicht konkret begonnen hat, seine Produkte, Prozesse und Lieferketten auf den CRA zu trimmen, wird im vierten Quartal 2027 in Panik geraten. Die technische Dokumentation allein braucht Monate, die SBOM-Pipeline will entwickelt und getestet sein, und die wenigen verfügbaren externen Berater und Notified Bodies für Cybersecurity-Produkte werden bis dahin restlos ausgebucht sein.
Der CRA ist kein Papier-Tiger. Er ist ein Marktzugangs-Regulator mit scharfen Zähnen.
Häufige Fragen
Gilt der CRA auch für reine Hardware ohne Software?
Nein — aber die Definition ist sehr weit. Sobald Ihre Hardware eine Steuerung, einen Sensor, ein Kommunikationsmodul oder auch nur einen Bootloader enthält, gilt der CRA. Reine mechanische Bauteile ohne digitale Komponente sind ausgenommen.
Ist Open-Source-Software im CRA ausgenommen?
Kostenfreie Open-Source ohne Gewinnerzielungsabsicht ist ausgenommen. Sobald Sie diese Software jedoch in ein kommerzielles Produkt einbauen oder monetarisieren, unterliegt das Gesamtprodukt dem CRA. Die SBOM muss trotzdem alle enthaltenen Komponenten auflisten.
Was ist der Unterschied zwischen CRA und NIS-2?
NIS-2 richtet sich an Betreiber kritischer Infrastrukturen und verlangt organisatorisches Risikomanagement. Der CRA richtet sich an Hersteller von Produkten mit digitalen Elementen und regelt die Sicherheit des Produkts selbst — vom Design über den Lebenszyklus bis zur CE-Kennzeichnung.
Wann muss die Meldung an ENISA erfolgen?
Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden an ENISA gemeldet werden. Ein schwerwiegender Vorfall kompromittiert die Vertraulichkeit, Integrität oder Verfügbarkeit des Produkts oder der damit verbundenen Daten.
Brauchen alle Produkte eine Drittprüfung durch eine Notified Body?
Nein. Rund 90 % der Produkte fallen in die Default-Klasse, für die ein Hersteller-Selbst-Assessment ausreicht. Nur „wichtige" Produkte (Annex III) und „kritische" Produkte (Annex IV) erfordern zwingend eine Konformitätsbewertung durch eine benannte Stelle.
Was ist eine SBOM und warum wird sie gebraucht?
Eine Software Bill of Materials (SBOM) ist eine detaillierte Stückliste aller Software-Komponenten eines Produkts. Der CRA verlangt sie für Lieferketten-Transparenz und schnellere Schwachstellen-Erkennung. Sie muss in maschinenlesbarem Format (SPDX oder CycloneDX) vorliegen und zu jedem Release aktualisiert werden.
Reicht ISO 27001 für die CRA-Konformität?
ISO 27001 hilft, deckt aber nicht alle CRA-Anforderungen ab. Das ISMS liefert organisatorische Prozesse für Risiko und Dokumentation. Was fehlt: produktspezifische Anforderungen wie Secure-by-Design, CE-Kennzeichnung, SBOM-Pflicht und die spezifische 24h-Meldung an ENISA. Wer ISO 27001 hat, startet aus einer deutlich besseren Position.
Was passiert, wenn ein Produkt ab Dezember 2027 nicht konform ist?
Produkte ohne CE-Kennzeichnung für Cybersecurity dürfen dann nicht mehr auf den EU-Markt gebracht werden. Marktüberwachungsbehörden können sie vom Markt nehmen, Bußgelder verhängen (bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes) und den Verkehr untersagen.
Cyber Resilience Act auf einen Blick
- ✅ Verordnung (EU) 2024/2847 — gilt für alle Produkte mit digitalen Elementen
- ✅ 11.09.2026: 24h-Meldepflicht an ENISA
- ✅ 11.12.2027: Vollständige Anwendung — kein Marktzugang ohne CE
- ✅ Vier Säulen: Secure-by-Design, Vulnerability Management, CE-Konformität, Transparenz
- ✅ SBOM ist Pflicht für Lieferketten-Transparenz
- ✅ Bußgelder bis 15 Mio. € oder 2,5 % weltweiten Jahresumsatzes
- ✅ ~40 % NIS-2-Synergien — wer NIS-2 macht, hat Vorsprung
Wie IQI dabei hilft
Wir beraten seit über 25 Jahren Mittelständler in QM, Arbeitsschutz und regulatorischer Compliance. Die NIS-2-Umsetzung begleiten wir seit zwei Jahren — und der Pfad zur CRA-Konformität ist zu etwa 80 % deckungsgleich mit den Management-Prozessen, die wir dort aufbauen. Wir kennen den Unterschied zwischen einem Audit nach IATF 16949 und einer Konformitätsbewertung nach EU-Verordnung. Wir sprechen die Sprache von Maschinenbauern und Automotive-Zulieferern.
🔍 Gap-Analyse CRA
Wir scannen Ihr Produktportfolio, prüfen die Klassifizierung und zeigen die Lücken — pragmatisch, mit Ampel und Aufwandsschätzung.
⚙️ Prozessaufbau
Wir integrieren Secure-by-Design, SBOM-Management und Schwachstellen-Prozesse in Ihre bestehende QM-Landschaft (ISO 9001, IATF 16949, EN 9100) — statt parallel Silos aufzubauen.
🎯 Begleitung bis CE
Von technischer Dokumentation über Auswahl der Notified Body bis zur Konformitätserklärung — inklusive Vorbereitung auf Marktüberwachungsaudits.
CRA-Vorbereitung mit Substanz statt Panik?
Wir starten mit einem halbtägigen CRA-Check. Kein Boilerplate, keine 200-seitigen Gutachten. Eine klare Handlungsliste.
CRA-Check anfragen