CRA — Cyber Resilience Act erklärt
Der Cyber Resilience Act (EU 2024/2847) verpflichtet Hersteller digitaler Produkte zu Cybersecurity-Anforderungen über den gesamten Lebenszyklus. Der CRA schafft damit erstmals ein einheitliches EU-Regelwerk für Security by Design, Schwachstellenmanagement, CE-Kennzeichnung und dokumentierte Produktkonformität bei Produkten mit digitalen Elementen.
Was ist der CRA (EU-VO 2024/2847)?
Der CRA ist die EU-Verordnung 2024/2847 über Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Gemeint sind nicht nur IoT-Geräte, sondern auch Software, vernetzte Industrieprodukte, eingebettete Systeme und digitale Komponenten, die mit anderen Geräten oder Netzen verbunden werden können. Für Unternehmen ist der Kernpunkt einfach: Sicherheit wird nicht mehr nur als freiwillige Produktqualität behandelt, sondern als regulatorische Marktanforderung.
Wichtig ist die Logik des Gesetzes. Der CRA verlangt, dass Hersteller Sicherheitsrisiken bereits in Entwicklung, Design und Auslieferung berücksichtigen und danach über den Support-Zeitraum weiter adressieren. Dazu gehören sichere Voreinstellungen, dokumentierte Risikoanalysen, der Umgang mit Drittkomponenten und Prozesse für Sicherheitsupdates. Einen vertiefenden Überblick finden Sie auf unserer Seite zum Cyber Resilience Act.
Wen betrifft der CRA — Hersteller, Importeure, Händler
Der CRA betrifft primär Hersteller, außerdem Importeure und Händler. Hersteller tragen die Hauptverantwortung, weil sie Produkte entwickeln, herstellen oder unter eigenem Namen in Verkehr bringen. Das gilt auch dann, wenn einzelne Komponenten oder die Produktion ausgelagert sind. Importeure müssen prüfen, ob ein außereuropäischer Hersteller die grundlegenden CRA-Anforderungen erfüllt. Händler haben geringere Pflichten, dürfen aber erkennbare Nichtkonformität nicht ignorieren.
Besonders relevant ist der weite Produktbegriff. Erfasst sind Produkte mit digitalen Elementen, also Hardware und Software mit vorgesehener oder vernünftigerweise vorhersehbarer Verbindung zu Geräten oder Netzwerken. Deshalb betrifft der CRA nicht nur klassische Gerätehersteller, sondern auch Anbieter von B2B-Software, SaaS-Produkten, Embedded Systems, Smart-Home-Lösungen oder industrieller Steuerungstechnik. Für die praktische Umsetzung lohnt sich ergänzend unser Beitrag zu CRA-Anforderungen.
Kernpflichten: Security by Design, SBOM, CE-Kennzeichnung
Die zentralen Pflichten des CRA lassen sich in drei Blöcke aufteilen. Erstens verlangt die Verordnung Security by Design und Security by Default. Hersteller müssen Sicherheitsrisiken schon vor dem Inverkehrbringen bewerten und durch technische und organisatorische Maßnahmen reduzieren. Dazu gehören sichere Entwicklungsprozesse, Tests, nachvollziehbare Dokumentation und das Vermeiden typischer Schwachstellen wie unsichere Standardkonfigurationen oder schlecht gepflegte Abhängigkeiten.
Zweitens spielt die SBOM eine wichtige Rolle. Eine Software Bill of Materials macht sichtbar, welche Software-Komponenten und Bibliotheken in einem Produkt stecken. Das ist für Lieferkettensicherheit, Schwachstellenmanagement und Patch-Prozesse zentral. Gerade bei komplexen Produkten mit Open-Source-Bausteinen oder mehreren Zulieferern ist eine SBOM oft die Grundlage dafür, Sicherheitslücken schnell zu identifizieren und Prioritäten richtig zu setzen.
Drittens verbindet der CRA Cybersicherheit mit Konformität. Hersteller müssen technische Unterlagen, Risikoanalysen und Nachweise so aufbauen, dass eine Konformitätsbewertung möglich ist. Danach folgt die CE-Kennzeichnung als sichtbares Zeichen, dass das Produkt die einschlägigen Anforderungen erfüllt. Für die Marktüberwachung ist das entscheidend, weil Behörden nicht nur das Produkt selbst, sondern auch die Nachweis- und Update-Prozesse prüfen können. Passend dazu ist auch das Glossar zu Marktüberwachung relevant.
Fristen: September 2026 und Dezember 2027
Die wichtigste zeitliche Einordnung lautet: Der CRA ist seit dem 10. Dezember 2024 in Kraft, aber seine Pflichten gelten gestuft. Ab dem 11. September 2026 greifen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Ab dem 11. Dezember 2027 werden die übrigen CRA-Anforderungen voll anwendbar, also insbesondere Security by Design, Konformitätsbewertung und CE-Kennzeichnung.
Für Hersteller heißt das praktisch: September 2026 ist kein Vollstart der gesamten Verordnung, sondern der Beginn der Meldepflichten. Dezember 2027 ist der harte Termin für die umfassende Produkt-Compliance. Wer erst 2027 mit Risikoanalyse, SBOM, Produktdokumentation und Update-Prozessen beginnt, wird diese Frist regelmäßig nicht belastbar einhalten. Eine kompakte Zeitachse finden Sie auch auf unserer Seite zu CRA-Fristen.
Abgrenzung zu NIS2 und AI Act
Der CRA ist keine allgemeine Governance-Verordnung für alle Unternehmen, sondern ein Produktrecht für digitale Produkte. NIS2 richtet sich dagegen an Organisationen in besonders wichtigen oder wichtigen Sektoren und fokussiert Governance, Risikomanagement und organisatorische Resilienz. Der AI Act wiederum regelt KI-Systeme nach Risikoklassen und Pflichten für Anbieter und Betreiber. Die Überschneidungen sind real, aber die Blickrichtung ist jeweils anders.
Praktisch heißt das: NIS2 fragt, wie eine Organisation ihre Cybersicherheit steuert. Der CRA fragt, ob ein konkretes Produkt mit digitalen Elementen sicher entwickelt, dokumentiert und betrieben wird. Der AI Act fragt, ob ein KI-System regulatorisch zulässig und korrekt eingeordnet ist. Gerade im Finanzsektor kann zusätzlich DORA relevant werden, weil dort digitale operationale Resilienz für beaufsichtigte Finanzunternehmen im Mittelpunkt steht. Unternehmen mit vernetzten KI-Produkten müssen diese Regime deshalb getrennt, aber abgestimmt betrachten.
Häufig gestellte Fragen (FAQ)
Gilt der CRA auch für Software?
Ja. Der CRA erfasst ausdrücklich auch Software, sofern sie als Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird und keine spezifische Ausnahme greift. Für reine Open-Source-Konstellationen ohne kommerzielle Bereitstellung gelten Besonderheiten, aber sobald Software Teil eines vermarkteten Produkts ist, rückt die CRA-Logik schnell in den Vordergrund.
Was bedeutet SBOM?
SBOM steht für Software Bill of Materials. Gemeint ist eine strukturierte Komponentenliste, mit der Hersteller Bibliotheken, Abhängigkeiten und weitere Software-Bausteine nachvollziehbar erfassen. Ohne diese Transparenz werden Schwachstellenmanagement und sichere Updates gerade bei komplexen Lieferketten deutlich schwieriger.
Was passiert bei Verstößen?
Bei Verstößen drohen Marktüberwachungsmaßnahmen, Vertriebsbeschränkungen, Rücknahmen und erhebliche Bußgelder. Zusätzlich steigt das Risiko, dass CE-Nachweise nicht tragen, Meldungen zu spät erfolgen oder Produkte ohne belastbare Sicherheitsprozesse am Markt angreifbar bleiben.
Wenn Sie CRA-Pflichten nicht nur juristisch einordnen, sondern für Produkt-, Entwicklungs- und Compliance-Teams praktisch aufsetzen wollen, ist unser Kurs der nächste sinnvolle Schritt. Er hilft Ihnen, regulatorische Anforderungen strukturiert in Schulung, Rollenklärung und dokumentierbare Prozesse zu übersetzen.