Der Cyber Resilience Act (CRA) ist die EU-Verordnung für Cybersecurity digitaler Produkte und verpflichtet Hersteller zu Security by Design, Schwachstellenmanagement und CE-Kennzeichnung, in Ergänzung zu NIS2 Art. 21 und den Cybersecurity-Anforderungen aus Art. 15 der EU-VO 2024/1689. Für Hersteller heißt das: Produkte mit digitalen Elementen müssen nach der EU-VO 2024/2847 spätestens ab dem 11. Dezember 2027 nachweisbar sicher entwickelt, dokumentiert, überwacht und aktualisiert werden.
Wenn Sie zuerst einzelne Teilfragen vertiefen möchten, finden Sie ergänzend unsere Cluster-Beiträge zu den CRA-Anforderungen, den CRA-Fristen, zum Vergleich CRA vs. NIS2, zur SBOM-Pflicht, zur CE-Kennzeichnung unter dem CRA und zum Zusammenspiel von CRA, NIS2 und AI Act. Für den Mittelstand mit parallel laufenden AI-Act-Aufgaben ist außerdem der Leitfaden zur KI-Verordnung im Mittelstand relevant.
Was ist der Cyber Resilience Act (EU-VO 2024/2847)?
Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847 und schafft erstmals ein unionsweit einheitliches Cybersecurity-Regime für Produkte mit digitalen Elementen. Gemeint sind nicht nur klassische IoT-Geräte, sondern auch Software, eingebettete Systeme, industrielle Steuerungen, vernetzte Medizintechnik, Consumer-Hardware und zahlreiche B2B-Produkte, die mit Geräten oder Netzen verbunden werden können.
Der Kern der EU-VO 2024/2847 ist ein Produktrecht, kein allgemeines Unternehmensrecht. Die Verordnung verlangt, dass Sicherheit bereits in Entwicklung, Konstruktion, Auslieferung und Support eines Produkts angelegt wird. Hersteller müssen Risiken analysieren, technische und organisatorische Schutzmaßnahmen vorsehen, Schwachstellen über den Lebenszyklus hinweg behandeln und eine nachvollziehbare Dokumentation für Marktaufsicht und Konformitätsbewertung bereithalten.
Rechtssystematisch ähnelt der CRA damit eher anderen produktbezogenen EU-Regimen als allgemeinen Governance-Vorgaben. Anders als NIS2, die organisatorische Sicherheitsmaßnahmen bei betroffenen Einrichtungen fordert, fokussiert der CRA auf das konkrete Produkt. Und anders als der AI Act, der risikobasiert bestimmte KI-Anwendungen reguliert, erfasst der CRA digitale Produkte unabhängig davon, ob darin künstliche Intelligenz steckt oder nicht. Treffen CRA und AI Act zusammen, müssen Hersteller beide Ebenen sauber trennen: Produkt-Cybersicherheit nach EU-VO 2024/2847 und KI-spezifische Anforderungen nach EU-VO 2024/1689.
Für deutsche Unternehmen ist wichtig, dass der CRA als Verordnung unmittelbar gilt. Es gibt also keinen nationalen Umsetzungsspielraum wie bei einer Richtlinie, sondern einen direkten europäischen Pflichtenkatalog. Primärquellen für die operative Arbeit sind der Volltext der Verordnung (EU) 2024/2847 im EUR-Lex, die CRA-Übersichten der EU-Kommission und die fachlichen Hinweise des BSI.
Wen betrifft der CRA — Hersteller, Importeure, Händler
Der CRA betrifft in erster Linie Hersteller, weil sie das Produkt entwerfen, entwickeln, fertigen oder unter eigener Marke in Verkehr bringen. Als Hersteller gilt nicht nur der Produzent im engeren Sinn. Auch Unternehmen, die ein Fremdprodukt unter eigener Marke vertreiben, können in die Herstellerrolle fallen und tragen dann die Hauptverantwortung für Konformität, Dokumentation, Sicherheitsupdates und Schwachstellenmanagement.
Importeure sind ebenfalls betroffen, wenn sie Produkte aus Drittländern in den EU-Markt einführen. Ihre Aufgabe ist nicht die vollständige technische Neuentwicklung der Konformität, wohl aber die Prüfung, ob der Hersteller die erforderlichen Unterlagen, Kennzeichnungen und Erklärungen bereitgestellt hat. Wer als Importeur Produkte ohne belastbare CRA-Unterlagen einführt, übernimmt damit ein erhebliches Risiko für Rückrufe, Vertriebsstopps und marktaufsichtliche Maßnahmen.
Händler tragen die geringste, aber keineswegs irrelevante Pflichtendichte. Sie müssen prüfen, ob erkennbare formale Mängel vorliegen, etwa fehlende Kennzeichnungen oder offensichtliche Hinweise auf Nichtkonformität. Stellen Händler fest, dass ein Produkt die Anforderungen der EU-VO 2024/2847 nicht erfüllt, dürfen sie es nicht einfach weiter vertreiben. Stattdessen müssen sie mit Hersteller, Importeur und gegebenenfalls Behörden kooperieren.
Für die Praxis hilft folgende Abgrenzung: Wer das Produkt verantwortet, trägt die tiefsten CRA-Pflichten. Wer es importiert, muss die Konformität plausibilisieren. Wer es weiterverkauft, muss erkennbare Verstöße adressieren. Unternehmen sollten diese Rollen nicht nur juristisch, sondern auch vertraglich und organisatorisch klären, insbesondere wenn Entwicklung, OEM-Fertigung, Markenauftritt und Support auf mehrere Gesellschaften verteilt sind.
Wichtig ist außerdem der sachliche Anwendungsbereich. Die Verordnung spricht von Produkten mit digitalen Elementen. Darunter fallen Produkte mit beabsichtigter oder vernünftigerweise vorhersehbarer direkter oder indirekter Verbindung zu einem Gerät oder Netz. Das umfasst klassische Hardware mit Embedded Software ebenso wie eigenständige Softwareprodukte. Für die Frage, ob reine Software erfasst ist, ist also nicht entscheidend, ob ein physisches Gerät mitgeliefert wird, sondern ob die Software als marktbezogenes digitales Produkt in den CRA-Anwendungsbereich fällt.
Die wichtigsten Pflichten im Überblick
Die wichtigste Botschaft des CRA lautet: Sicherheit muss vor dem Markteintritt beginnen und nach dem Verkauf fortgeführt werden. Hersteller dürfen Cybersecurity nicht mehr als nachgelagerte Supportfrage behandeln, sondern müssen sie im Produktlebenszyklus verankern. Das betrifft Entwicklung, Test, Beschaffung, Release-Management, Support, Incident Response und die technische Dokumentation.
Security by Design und Security by Default
Security by Design bedeutet unter der EU-VO 2024/2847, dass Sicherheitsanforderungen bereits in Architektur, Entwicklung und Produktgestaltung eingebaut werden. Gemeint ist kein bloßes Bekenntnis, sondern ein belastbarer Entwicklungsprozess mit Risikoanalyse, Bedrohungsmodellierung, sicheren Standardeinstellungen, geeigneten Authentifizierungs- und Update-Mechanismen sowie einer nachvollziehbaren Entscheidung, wie bekannte Schwachstellenklassen vermieden werden.
Security by Default ergänzt diesen Ansatz um die Auslieferungsphase. Produkte sollen im Standardzustand so konfiguriert sein, dass sie ohne unnötige Sicherheitsrisiken betrieben werden können. Unsichere Werkseinstellungen, Standardpasswörter, unnötig offene Dienste oder fehlende Schutzmechanismen widersprechen dieser Logik. Gerade bei IoT-, OT- und SaaS-nahen Produkten wird die Frage relevant, welche Einstellungen ein durchschnittlicher Kunde vernünftigerweise selbst absichern kann und welche Pflichten deshalb beim Hersteller bleiben.
Vulnerability Handling (Schwachstellenmanagement)
Schwachstellenmanagement ist eine Kernpflicht der EU-VO 2024/2847 und endet nicht mit dem Release. Hersteller müssen Prozesse etablieren, um neue Schwachstellen zu beobachten, zu bewerten, zu priorisieren und zu beheben. Dazu gehört auch ein geregelter Umgang mit Meldungen externer Sicherheitsforscher, Kunden oder Lieferanten. Ein Produkt ohne funktionsfähigen Vulnerability-Handling-Prozess ist unter dem CRA kein reifes Produkt, sondern ein Compliance-Risiko.
Besonders praxisrelevant ist die Meldeebene. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle im Zusammenhang mit betroffenen Produkten in engen Fristen melden. Unternehmen, die dafür heute noch keine Eskalationswege, Verantwortlichkeiten und Kontaktpunkte definiert haben, geraten schnell in Zeitdruck. Vertiefend dazu finden Sie unseren Beitrag zu den CRA-Fristen.
SBOM-Pflicht (Software Bill of Materials)
Die SBOM ist im CRA kein bloßes Nice-to-have, sondern ein zentrales Instrument für Transparenz in der Software-Lieferkette. Eine Software Bill of Materials dokumentiert, welche Komponenten, Bibliotheken, Pakete und Abhängigkeiten in einem Produkt enthalten sind. Ohne diese Transparenz lassen sich bekannte Schwachstellen in Drittkomponenten weder schnell erkennen noch sauber priorisieren.
Für Hersteller ist die SBOM-Pflicht deshalb organisatorisch anspruchsvoll. Sie betrifft nicht nur Open-Source-Komponenten, sondern das gesamte Component-Tracking, die Versionierung, das Release-Management und die Lieferantenkommunikation. Wer heute keine verlässliche Stückliste seiner Software-Komponenten erzeugen kann, wird im Ernstfall weder belastbar patchen noch sauber nachweisen können, welche Produkte betroffen sind. Mehr dazu finden Sie in unserem Schwerpunkt zur CRA-SBOM.
CE-Kennzeichnung für Cybersecurity
Die EU-VO 2024/2847 verankert Cybersecurity ausdrücklich im europäischen Konformitätsrahmen. Hersteller müssen nach erfolgreicher Konformitätsbewertung eine EU-Konformitätserklärung erstellen und das Produkt CE-kennzeichnen, soweit es in den CRA-Anwendungsbereich fällt. Die CE-Kennzeichnung wird damit auch zum sichtbaren Ergebnis einer dokumentierten Cybersecurity-Prüfung.
Für Unternehmen ist dabei wichtig: Die CE-Kennzeichnung ersetzt keine echte Sicherheitsarbeit. Sie bestätigt nicht, dass ein Produkt unangreifbar ist, sondern dass die einschlägigen CRA-Anforderungen eingehalten und das Verfahren ordnungsgemäß durchlaufen wurden. Wer die CE-Kennzeichnung nur als Label betrachtet und nicht als Ergebnis technischer und prozessualer Nachweisführung, unterschätzt die regulatorische Tiefe des Regimes. Einen eigenen Überblick zur Umsetzung finden Sie unter CRA-CE-Kennzeichnung sowie ergänzend im Glossar zur CE-Kennzeichnung für KI.
CRA-Fristen — September 2026 und Dezember 2027
Die zwei operativ wichtigsten CRA-Daten sind der 11. September 2026 und der 11. Dezember 2027. Ab September 2026 greifen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle. Ab Dezember 2027 gilt die EU-VO 2024/2847 vollständig, also einschließlich der übrigen Produkt- und Konformitätspflichten.
Unternehmen sollten diese Daten nicht als weit entfernte Endpunkte lesen, sondern rückwärts planen. Wer erst 2027 mit Security-by-Design-Prozessen, SBOM-Erstellung, technischer Dokumentation und Lieferketten-Transparenz beginnt, wird typische Vorlaufzeiten in Entwicklung, Einkauf und Konformitätsverfahren unterschätzen. Gerade für komplexe Produkte mit langer Produktlebensdauer ist 2026 bereits die operative Einführungsphase.
Die folgende Übersicht verdichtet die Fristen auf die entscheidenden Handlungspunkte:
| Datum | Was gilt? | Praktische Konsequenz |
|---|---|---|
| 10. Dezember 2024 | Inkrafttreten der EU-VO 2024/2847 | Der CRA ist geltendes EU-Recht und sollte in Roadmaps, Budgets und Produktstrategie verankert werden. |
| 11. September 2026 | Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle | ENISA-Meldeprozesse, Eskalationswege, Verantwortlichkeiten und Incident-Kommunikation müssen einsatzfähig sein. |
| 11. Dezember 2027 | Vollständige Anwendung aller CRA-Pflichten | Neue Produkte im Anwendungsbereich müssen CRA-konform entwickelt, dokumentiert, bewertet und gekennzeichnet sein. |
Die Fristlogik ist auch deshalb relevant, weil sich CRA, NIS2 und AI Act zeitlich überlappen. Viele Unternehmen müssen 2026 und 2027 gleichzeitig Produkt-Cybersicherheit, organisatorische Cybersicherheit und KI-Governance ausbauen. Wer diese Programme getrennt plant, dupliziert Aufwand. Wer sie hingegen gemeinsam strukturiert, kann Rollen, Meldeketten, Lieferantenanforderungen und Dokumentationslogik besser verzahnen. Genau dazu dient unser Überblick CRA, NIS2 und AI Act.
Produktkategorien — Standard, Klasse I, Klasse II
Der CRA unterscheidet Produkte mit digitalen Elementen nach Risikoklassen, weil sich daraus die Tiefe der Konformitätsbewertung ableitet. Für viele Hersteller ist diese Einordnung ein früher Engpass: Wer die eigene Produktkategorie falsch einstuft, baut entweder unnötige Prozesse auf oder unterschätzt die regulatorischen Anforderungen.
Vereinfacht lässt sich zwischen Standardprodukten, wichtigen Produkten der Klasse I und wichtigen Produkten der Klasse II unterscheiden. Standardprodukte unterliegen den allgemeinen CRA-Anforderungen, können aber im Regelfall leichter in interne Konformitätsverfahren eingeordnet werden. Produkte der Klasse I und II gelten als besonders sensible oder sicherheitsrelevante digitale Produkte und können strengere Bewertungsanforderungen auslösen.
Die genaue Einordnung hängt von den Anhängen der Verordnung und vom Produkttyp ab. Typische Beispiele für erhöhte Sensibilität sind Produkte mit sicherheitskritischen Netzwerk-, Authentifizierungs-, Zugangs- oder Betriebssystemfunktionen. Hersteller sollten deshalb nicht nur die Marketingkategorie eines Produkts betrachten, sondern den regulatorischen Funktionskern.
| Produktkategorie | Typische Einordnung | Konformitätslogik | Praktischer Fokus |
|---|---|---|---|
| Standard | Gewöhnliche Produkte mit digitalen Elementen ohne Einstufung als wichtiges oder kritisches Produkt | Grundpflichten der EU-VO 2024/2847, in vielen Fällen interne Konformitätsbewertung | Secure Development, Dokumentation, SBOM, Update- und Supportprozesse |
| Klasse I | Wichtige Produkte mit digitalen Elementen, bei denen die Regulierungsintensität steigt | Je nach Fall strengere Nachweis- und Bewertungsanforderungen | Frühe Produktklassifizierung, technische Nachweisführung, Prüftiefe erhöhen |
| Klasse II | Besonders wichtige Produkte mit hohen Anforderungen an Sicherheit und Vertrauen | Erhöhte regulatorische Aufmerksamkeit und potenziell aufwendigere Konformitätsbewertung | Governance über Entwicklung, Test, Lieferkette und Lifecycle lückenlos absichern |
Die Kategorie beeinflusst nicht nur die regulatorische Prüfung, sondern auch Ressourcenplanung, Zulieferermanagement und Time-to-Market. Unternehmen sollten deshalb spätestens in der Produktplanung festhalten, welche CRA-Kategorie voraussichtlich einschlägig ist, welche Nachweise benötigt werden und ob externe Stellen oder zusätzliche Prüfverfahren einzuplanen sind. Ein vertiefender Einstieg dazu folgt im Cluster-Artikel CRA-Anforderungen.
In der Praxis empfiehlt sich dafür ein kurzer Klassifizierungs-Workshop je Produktlinie. Daran sollten Produktmanagement, Entwicklung, Security, Regulatory Affairs, Qualitätsmanagement und Einkauf beteiligt sein. Ziel ist nicht nur eine juristische Etikettierung, sondern eine gemeinsame Sicht auf Architektur, Lieferkette, sicherheitskritische Funktionen und die Frage, welche Nachweise später tatsächlich verfügbar sein müssen. Genau hier scheitern viele Programme: Die Rechtsabteilung kennt die Produktdetails nicht, die Entwicklung kennt den Anhang der Verordnung nicht, und der Einkauf hat keinen vollständigen Überblick über Drittkomponenten.
Besonders wichtig ist die Verzahnung mit dem Supportmodell. Ein Produkt mit langer Feldlaufzeit, mehreren Hardware-Revisionen oder vielen kundenspezifischen Varianten braucht deutlich früher eine CRA-fähige Struktur als ein einfaches Softwareprodukt mit wenigen Releases. Hersteller sollten daher nicht nur die erstmalige Konformität betrachten, sondern auch die Betriebsrealität nach dem Inverkehrbringen: Wie lange werden Sicherheitsupdates bereitgestellt? Welche Komponenten können kurzfristig ersetzt werden? Wie werden Sicherheitsinformationen an Kunden, Servicepartner und Händler verteilt?
Bußgelder bei Verstößen — Bis 15 Mio. EUR oder 2,5% Umsatz
Die EU-VO 2024/2847 verknüpft Produkt-Cybersicherheit mit spürbaren Sanktionsrisiken. Bei bestimmten Verstößen können Bußgelder bis zu 15 Mio. EUR oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes verhängt werden. Für Unternehmen ist das weniger wegen der reinen Maximalzahl wichtig als wegen der Signalwirkung: CRA-Compliance ist kein freiwilliges Best-Practice-Programm, sondern ein einklagbares Marktregime.
Praktisch sind Bußgelder allerdings nicht das einzige Risiko. Ebenso relevant sind Vertriebsverbote, Marktaufsichtsmaßnahmen, Rückrufe, Reputationsschäden und Vertragsfolgen in der Lieferkette. Ein Hersteller, der Sicherheitsmängel zu spät erkennt oder schlecht dokumentiert, verliert nicht nur Geld, sondern unter Umständen auch Vertriebsmöglichkeiten, Ausschreibungen und Kundenvertrauen.
Gerade KMU sollten deshalb nicht auf die absolute Bußgeldhöhe starren, sondern auf die Vermeidbarkeit des Risikos. Viele typische Verstöße entstehen nicht aus technischer Unmöglichkeit, sondern aus fehlender Zuständigkeit, unklaren Daten über Komponenten, unzureichender Dokumentation oder zu spät etablierten Meldeprozessen. Diese Defizite sind teuer, aber grundsätzlich beherrschbar, wenn sie früh adressiert werden.
Auch wirtschaftlich sollte CRA-Compliance nicht nur als Kostenblock gelesen werden. Hersteller mit sauberen Secure-Development-Prozessen, verlässlicher SBOM, klaren Updatezusagen und belastbarer Dokumentation gewinnen in Ausschreibungen und Lieferketten an Glaubwürdigkeit. Gerade größere Kunden werden ihre Lieferanten ab 2026 und 2027 deutlich intensiver nach Produkt-Cybersicherheit fragen. In vielen Fällen ist die eigentliche Managementfrage deshalb nicht, ob CRA-Aufwand entsteht, sondern ob dieser Aufwand proaktiv und steuerbar oder reaktiv und chaotisch anfällt.
CRA und Open Source — Sonderregelungen für FOSS
Der CRA enthält eine wichtige, aber eng zu lesende Sonderregelung für freie und quelloffene Software. Reine FOSS-Entwicklung ohne kommerzielle Bereitstellung ist unter bestimmten Voraussetzungen ausgenommen. Das schützt offene Entwicklungsmodelle davor, pauschal wie klassische Hersteller behandelt zu werden.
Diese Ausnahme wird in der Praxis jedoch oft überschätzt. Sobald Open-Source-Komponenten in ein kommerzielles Produkt integriert werden, verschwindet die Herstellerverantwortung nicht. Im Gegenteil: Wer ein kommerzielles Produkt mit Open-Source-Bausteinen in Verkehr bringt, bleibt für die Gesamtkonformität verantwortlich. Die Frage lautet also nicht, ob Open Source genutzt wird, sondern in welchem Bereitstellungskontext.
Zudem kennt der CRA für bestimmte Open-Source-Akteure eine leichtere Steward-Logik. Das bedeutet aber nicht, dass Unternehmen Open Source ohne Governance in Produkte übernehmen können. Gerade weil SBOM, Schwachstellenmanagement und Patch-Fähigkeit zentrale Pflichten sind, müssen Open-Source-Abhängigkeiten noch strukturierter gepflegt werden als bisher. Für technologieübergreifende Governance kann ergänzend ein AI-Management-System nach ISO 42001 sinnvoll sein, insbesondere wenn CRA, NIS2 und AI Act in einem gemeinsamen Steuerungsmodell zusammengeführt werden.
Was Unternehmen jetzt tun sollten — 5-Punkte-Plan
Der beste Einstieg in CRA-Compliance ist kein abstraktes Großprogramm, sondern ein belastbarer Fünf-Punkte-Plan. Unternehmen sollten jetzt ihre Produktlandschaft, Verantwortlichkeiten und Nachweise so ordnen, dass die Meldepflichten ab September 2026 und die Vollanwendung ab Dezember 2027 realistisch erreichbar werden.
- Produkte im Anwendungsbereich identifizieren. Listen Sie alle Produkte mit digitalen Elementen auf, einschließlich Software, Embedded Systems, IoT-Komponenten und White-Label-Produkte.
- Rollen und Produktkategorien festlegen. Klären Sie pro Produkt, wer Hersteller, Importeur oder Händler ist und ob Standard, Klasse I oder Klasse II einschlägig sein könnte.
- Secure-Development- und SBOM-Prozesse aufbauen. Verankern Sie Risikoanalyse, Dependency-Management, Komponententransparenz, Schwachstellentests und Update-Prozesse im Entwicklungsablauf.
- Melde- und Supportstrukturen vorbereiten. Definieren Sie Ansprechpartner, Fristen, Eskalationsstufen und Kommunikationswege für ENISA-Meldungen, Kundeninformationen und Patch-Entscheidungen.
- Regulatorische Schnittstellen zusammenführen. Stimmen Sie CRA, NIS2 und AI Act dort ab, wo Meldepflichten, Lieferkettenkontrollen, Dokumentation und Verantwortlichkeiten ineinandergreifen.
Dieser fünfte Punkt wird häufig unterschätzt. Viele Hersteller betreiben nicht nur Produktentwicklung, sondern auch interne KI-Systeme, kritische IT-Prozesse oder Lieferketten mit regulatorischer Doppellast. Wer zugleich den CRA umsetzen und Mitarbeiter für den AI Act befähigen muss, sollte Governance nicht in Silos organisieren. Unser Kurs zum EU AI Act hilft dabei, die AI-Act-Seite mit Schulungsnachweis und Grundverständnis sauber abzudecken, während CRA-spezifische Produktpflichten im technischen Compliance-Programm verankert werden.
Für die Umsetzung empfiehlt sich ein gestaffeltes Vorgehen über 12 bis 18 Monate. In Phase eins steht die Bestandsaufnahme: Produkte, Komponenten, Lieferanten, Supportzusagen und Verantwortlichkeiten werden erfasst. In Phase zwei folgen Klassifizierung, Zielarchitektur und Gap-Analyse gegen die CRA-Pflichten. In Phase drei werden Secure-Development-Standards, SBOM-Prozesse, Testtiefe, Meldelogik und Dokumentationsbausteine verbindlich eingeführt. Phase vier dient der Absicherung über Pilotprodukte, interne Audits und Management-Freigaben. Dieses Stufenmodell ist für Mittelständler meist realistischer als der Versuch, alle Produktlinien gleichzeitig auf CRA-Niveau zu heben.
Häufig gestellte Fragen (FAQ)
Gilt der CRA auch für reine Software?
Ja. Der CRA erfasst nicht nur Hardware, sondern auch eigenständige Software, wenn sie als Produkt mit digitalen Elementen in den Markt gebracht wird oder typischerweise mit Geräten oder Netzen verbunden wird. Reine, nicht-kommerzielle Open-Source-Software kann ausgenommen sein; kommerziell bereitgestellte Software fällt dagegen regelmäßig in den Anwendungsbereich.
Was ist der Unterschied zwischen CRA und NIS2?
Der CRA ist produktbezogen, NIS2 organisationsbezogen. Die EU-VO 2024/2847 regelt Cybersecurity-Anforderungen für Produkte mit digitalen Elementen, während NIS2 Sicherheitsmaßnahmen und Meldepflichten für betroffene Einrichtungen und kritische Organisationen festlegt. Beide Regime überschneiden sich bei Risikomanagement und Schwachstellenprozessen, aber nicht beim Adressatenkreis. Einen Überblick finden Sie in CRA vs. NIS2.
Brauchen KMU einen Cybersecurity-Beauftragten?
Die EU-VO 2024/2847 schreibt keinen pauschalen Cybersecurity-Beauftragten für jedes KMU vor. Praktisch brauchen kleinere Hersteller aber klar definierte Verantwortlichkeiten für Produktklassifizierung, Schwachstellenmanagement, ENISA-Meldungen, Dokumentation und Lieferkettenkontrolle. Ob das eine eigene Rolle oder ein klar benannter Verantwortlicher im bestehenden Team ist, hängt von Produktportfolio und Risikoklasse ab.
Wie hängen CRA, NIS2 und AI Act zusammen?
CRA, NIS2 und AI Act regeln unterschiedliche Ebenen derselben Realität. Der CRA fokussiert Produkt-Cybersicherheit, NIS2 die organisatorische Cybersicherheit und der AI Act zusätzliche Anforderungen für KI-Systeme. Unternehmen mit vernetzten Produkten und KI-Funktionen müssen deshalb häufig mehrere Regime parallel beachten. Für die Gesamtperspektive ist der Artikel CRA, NIS2 und AI Act der sinnvollste Einstieg.
Müssen bestehende Produkte nachgerüstet werden?
Produkte, die bereits vor dem 11. Dezember 2027 rechtmäßig in Verkehr gebracht wurden, werden nicht automatisch wie Neuprodukte behandelt. Dennoch bleibt die Frage der Nachrüstung praktisch relevant, wenn Produkte weiter unterstützt, aktualisiert oder nach diesem Datum neu in Verkehr gebracht werden. Unternehmen sollten deshalb früh prüfen, welche Produktlinien technisch und wirtschaftlich auf CRA-Niveau gebracht werden müssen.
Was kostet CRA-Compliance für Hersteller?
Die Verordnung nennt keine festen Umsetzungskosten, und es gibt keine allgemeingültige Zahl pro Unternehmen. Der Aufwand hängt vor allem davon ab, ob sichere Entwicklungsprozesse, SBOM-Erzeugung, technische Dokumentation, Schwachstellenhandling und Lieferantensteuerung bereits vorhanden sind. Für viele Hersteller ist nicht die einzelne Maßnahme teuer, sondern die verspätete Einführung eines zusammenhängenden Systems.
Fazit: CRA-Compliance ist jetzt ein Produkt-Thema der Geschäftsleitung
Der CRA ist kein Randthema der IT-Abteilung, sondern ein Produkt- und Managementthema. Wer Produkte mit digitalen Elementen auf dem EU-Markt anbietet, muss bis spätestens zum 11. Dezember 2027 nachweisen können, dass Cybersecurity im Produktlebenszyklus mitgedacht, dokumentiert und operativ beherrscht wird. Der früheste Stresstest kommt bereits ab dem 11. September 2026 über die Meldepflichten.
Für viele Unternehmen lautet die pragmatische Priorität deshalb: Anwendungsbereich klären, Produktkategorien einstufen, SBOM-Fähigkeit herstellen, Meldewege definieren und CRA, NIS2 sowie AI Act zusammen denken. Wenn parallel die Befähigung Ihrer Teams für den AI Act noch offen ist, starten Sie mit unserem Kurs zum EU AI Act, lesen Sie ergänzend den Vergleich CRA vs. NIS2 und ordnen Sie die KI-seitigen Mittelstandsaufgaben im Leitfaden zur KI-Verordnung im Mittelstand ein.