trustspace

Tag: cyber resilience act

  • Cyber Resilience Act umsetzen: Roadmap in klaren Schritten

    Cyber Resilience Act umsetzen: Roadmap in klaren Schritten

    Das Wichtigste in Kürze

    • Rechtsnatur: Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847 und gilt EU-weit unmittelbar. Eine nationale Umsetzung ist nicht nötig, in Deutschland überwacht das BSI die Einhaltung.
    • Zwei Fristen takten den Fahrplan: Die Melde- und Berichtspflichten greifen ab dem 11. September 2026, die volle Anwendung folgt am 11. Dezember 2027.
    • Roadmap in sechs Phasen: von Produktinventar über Risikobewertung und Security by Design bis zum laufenden Post-Market-Monitoring.
    • Konformitätsbewertung: Standardprodukte dürfen sich selbst bewerten, wichtige Produkte der Klasse II und kritische Produkte müssen zwingend über eine notifizierte Stelle.
    • Lieferkette: Lieferantenselbstauskunft und Komponenten-SBOM einfordern, denn fremder Code in Ihrem Produkt wird zu Ihrer Verantwortung.
    • Bußgeldrahmen: bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist.

     

    Der Cyber Resilience Act, auf Deutsch auch Cyberresilienz-Verordnung genannt, verpflichtet erstmals alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen zu einem Mindestmaß an Cybersicherheit über den gesamten Produktlebenszyklus. Die Fristen laufen, und die eigentliche Frage lautet für die meisten Unternehmen längst nicht mehr ob, sondern wie sie den Cyber Resilience Act umsetzen. Ohne strukturierten Fahrplan zerfasert das Vorhaben schnell in eine unübersichtliche Sammlung von Einzelmaßnahmen.

    Dieser Leitfaden liefert genau diesen Fahrplan: eine Roadmap in sechs klaren Phasen, von der ersten Bestandsaufnahme bis zur laufenden Marktüberwachung, jeweils mit Ziel, konkreten Aufgaben, typischer Dauer und Verantwortlichen. Dazu klären wir die zwei Punkte, an denen sich die meisten Fragen entzünden: Selbstbewertung oder notifizierte Stelle sowie die Einbindung der Lieferkette. Wer eine strukturierte Unterstützung bei der CRA-Umsetzung sucht, findet hier die inhaltliche Grundlage.

     

    „Nationale Umsetzung“ des Cyber Resilience Act? Ein verbreitetes Missverständnis

    Ein häufig gesuchter Begriff ist die „nationale Umsetzung“ des Cyber Resilience Act. Er trifft die Rechtslage nicht ganz: Der CRA ist eine EU-Verordnung, keine Richtlinie. Verordnungen gelten in allen Mitgliedstaaten unmittelbar und müssen nicht erst durch ein nationales Gesetz in deutsches Recht überführt werden. Anders als bei der NIS2-Richtlinie, die auf ihr deutsches Umsetzungsgesetz wartet, gibt es beim CRA also keine nationale Umsetzung, auf die man warten könnte. Die Pflichten aus der Verordnung (EU) 2024/2847 gelten für jeden betroffenen Hersteller in der Union nach demselben Wortlaut.

    Was national sehr wohl geregelt wird, sind die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Doppelrolle: als Marktüberwachungsbehörde und als notifizierende Behörde, die ab 2026 die Konformitätsbewertungsstellen benennt. Es kann Korrekturmaßnahmen verlangen, Produkte einschränken, vom Markt nehmen oder zurückrufen und Bußgelder verhängen. Deutschland setzt die europäischen Vorgaben eins zu eins um und verzichtet auf nationale Sonderregeln. Sie richten sich also direkt nach dem Verordnungstext, nicht nach einem noch ausstehenden deutschen Gesetz.

     

    Zwei Fristen bestimmen die Reihenfolge

    Bevor die Roadmap beginnt, lohnt der Blick auf den Zeitplan, denn er entscheidet über die Priorisierung. Der CRA ist am 10. Dezember 2024 in Kraft getreten, seine Pflichten greifen aber gestaffelt.

    Datum Was gilt ab dann
    11. September 2026 Melde- und Berichtspflichten (Art. 14): aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen gemeldet werden, die erste Frühwarnung binnen 24 Stunden.
    11. Dezember 2027 Volle Anwendung: alle grundlegenden Anforderungen, Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation müssen erfüllt sein.

    Daraus folgt eine klare Priorisierung: Die Meldeprozesse kommen zuerst. Wer erst ab Ende 2027 an CE und Konformität denkt, übersieht, dass die 24-Stunden-Meldepflicht über ein Jahr früher scharf geschaltet wird und bereits im Sommer 2026 stehen muss.

     

    Die CRA-Roadmap in sechs Phasen

    Die folgende Roadmap gliedert die Umsetzung in sechs aufeinander aufbauende Phasen. Die Zeitangaben sind Erfahrungswerte für ein mittelständisches Portfolio und variieren mit Zahl und Komplexität der Produkte.

    Phase Ziel Typische Dauer Verantwortliche
    1. Produktinventar & Betroffenheit Alle Produkte mit digitalen Elementen erfassen, Betroffenheit und Risikoklasse bestimmen 2–3 Wochen Produktmanagement, Compliance
    2. Gap-Analyse (Annex I) Ist-Zustand gegen die grundlegenden Anforderungen abgleichen, Lücken dokumentieren 2–3 Wochen Security, Entwicklung
    3. Risikobewertung Cybersicherheitsrisiken je Produkt analysieren, Schutzmaßnahmen ableiten 2–4 Wochen Security, Produktmanagement
    4. Security by Design & Prozesse Schwachstellenmanagement, SBOM, Update- und Meldeprozesse aufbauen und in die Entwicklung integrieren 2–9 Monate Entwicklung, Security, DevOps
    5. Doku, Konformität & CE Technische Dokumentation erstellen, Konformität bewerten, EU-Konformitätserklärung und CE-Kennzeichnung 5–14 Wochen Compliance, QA, ggf. notifizierte Stelle
    6. Post-Market-Compliance Monitoring, Sicherheitsupdates, Meldepflichten dauerhaft erfüllen laufend Security, Support, PSIRT

    Phase 1: Produktinventar und Betroffenheitsanalyse

    Ziel der ersten Phase ist ein vollständiges Bild darüber, welche Ihrer Produkte überhaupt in den Anwendungsbereich fallen. Erfasst wird jedes Produkt mit digitalen Elementen, also Hardware und Software mit direkter oder indirekter Datenverbindung zu einem Gerät oder Netz. Zu jedem Produkt gehört die Einordnung in eine Risikoklasse (Standard, wichtig, kritisch), denn davon hängt der spätere Konformitätsweg ab. Eine erste Orientierung, ob und wie stark Ihr Portfolio betroffen ist, liefert der Betroffenheits-Check zum Cyber Resilience Act. Verantwortlich sind Produktmanagement und Compliance, die typische Dauer liegt bei zwei bis drei Wochen.

    Phase 2: Gap-Analyse gegen Annex I

    In Phase 2 wird jedes betroffene Produkt gegen die grundlegenden Cybersicherheitsanforderungen aus Annex I abgeglichen. Annex I hat zwei Teile: Teil I beschreibt die Produkteigenschaften (etwa sichere Standardkonfiguration, Schutz von Vertraulichkeit und Integrität, minimierte Angriffsfläche), Teil II den Umgang mit Schwachstellen über den Support-Zeitraum. Ergebnis ist eine dokumentierte Lückenliste je Produkt: Was ist erfüllt, was fehlt, wo besteht Handlungsbedarf. Welche Pflichten im Einzelnen dahinterstehen, führt der Beitrag zu den CRA-Pflichten aus Annex I aus. Zuständig sind Security und Entwicklung, üblich sind zwei bis drei Wochen.

    Phase 3: Risikobewertung je Produkt

    Die Verordnung verlangt, dass Hersteller eine Cybersicherheits-Risikobewertung durchführen und deren Ergebnis in die Gestaltung des Produkts einfließen lassen. In dieser Phase werden je Produkt die relevanten Bedrohungen modelliert, mögliche Angriffswege bewertet und daraus die notwendigen Schutzmaßnahmen abgeleitet. Die Risikobewertung ist kein Selbstzweck, sondern die Begründung für die gewählten Sicherheitsfunktionen, und wird Teil der technischen Dokumentation. Verantwortlich sind Security und Produktmanagement, die typische Dauer beträgt zwei bis vier Wochen.

    Phase 4: Security by Design und die Kernprozesse

    Phase 4 ist das Herzstück und regelmäßig die längste Etappe, weil hier aus Analyse konkrete Technik und gelebte Prozesse werden. Die Anforderungen aus Annex I werden in Produktentwicklung und Lieferkette verankert, inklusive secure defaults, Update-Mechanismen und Härtung. Drei Prozesse verdienen besondere Aufmerksamkeit:

    • Schwachstellenmanagement: ein fortlaufender Prozess, der Schwachstellen in eigenen und fremden Komponenten identifiziert, bewertet, behebt und die Behebung nachweist, über den gesamten Support-Zeitraum.
    • SBOM (Software Bill of Materials): eine Stückliste der Softwarekomponenten in einem gängigen, maschinenlesbaren Format, die laut Annex I mindestens die Abhängigkeiten oberster Ebene abdeckt und aktuell gehalten wird.
    • Meldeprozesse: ein einsatzbereiter Ablauf, um aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle fristgerecht zu melden. Dieser Prozess sollte wegen der Frist 11. September 2026 vorgezogen werden.

    Der Support-Zeitraum für Sicherheitsupdates bemisst sich an der erwarteten Nutzungsdauer und beträgt in der Regel mindestens fünf Jahre, sofern die Nutzung nicht kürzer ist. Verantwortlich sind Entwicklung, Security und DevOps, die Dauer reicht je nach Produkt von zwei bis neun Monaten.

    Phase 5: Technische Dokumentation, Konformitätsbewertung und CE

    In Phase 5 wird das Erreichte prüf- und nachweisbar gemacht. Zunächst entsteht die technische Dokumentation, die Risikobewertung, SBOM, Sicherheitsmaßnahmen und Testnachweise bündelt und der Marktüberwachung auf Verlangen vorgelegt wird. Darauf folgen die Konformitätsbewertung (Selbstbewertung oder notifizierte Stelle, siehe unten), die EU-Konformitätserklärung und die CE-Kennzeichnung, mit der das Produkt in Verkehr gebracht werden darf. Verantwortlich sind Compliance und QA, bei bewertungspflichtigen Produkten zusätzlich eine notifizierte Stelle. Rechnen Sie mit drei bis sechs Wochen für die Dokumentation und zwei bis acht Wochen für die Bewertung.

    Phase 6: Post-Market-Compliance

    Mit dem CE-Zeichen ist die Arbeit nicht beendet, sondern verlagert sich in den Dauerbetrieb. In Phase 6 überwachen Sie Ihre Produkte am Markt fortlaufend auf neue Schwachstellen, stellen kostenfreie Sicherheitsupdates über den Support-Zeitraum bereit und halten die Meldepflichten ein: die 24-Stunden-Frühwarnung an das zuständige CSIRT und ENISA über die zentrale Meldeplattform, gefolgt von einer Meldung binnen 72 Stunden und einem Abschlussbericht. Diese Phase läuft ohne Ende und braucht feste Zuständigkeiten, idealerweise ein Product Security Incident Response Team (PSIRT).

     

    TrustSpace Profi-Tipp: Meldeprozesse zuerst, nicht CE zuerst

    Viele Roadmaps stellen den Meldeprozess ans Ende, weil er in Phase 6 lebt. Das ist ein Fristen-Fehler, denn die 24-Stunden-Meldepflicht gilt ab dem 11. September 2026, mehr als ein Jahr vor der vollen Anwendung. Ziehen Sie den Aufbau eines belastbaren Melde-Workflows deshalb parallel zu Phase 4 vor: Wer meldet an wen, über welche Plattform, mit welchen Eskalationsstufen? So ist der zeitkritischste Baustein einsatzbereit, bevor der Rest der Konformitätsarbeit steht.

     

    Selbstbewertung oder notifizierte Stelle? Der Weg hängt von der Produktklasse ab

    Eine der meistgestellten Fragen betrifft den Konformitätsweg: selbst bewerten oder durch eine notifizierte Stelle prüfen lassen? Die Antwort ergibt sich aus Art. 32 und Annex VIII und hängt an der Risikoklasse des Produkts.

    Produktklasse Beispiele Konformitätsweg
    Standardprodukte (Mehrheit) Textverarbeitung, Foto-Apps, smarte Lautsprecher, Festplatten, Spiele Selbstbewertung über die interne Kontrolle (Modul A)
    Wichtige Produkte, Klasse I (Annex III) Passwort- und Identitätsmanager, Betriebssysteme, Router, VPN, Virenschutz, SIEM Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen, sonst notifizierte Stelle (Modul B+C oder H)
    Wichtige Produkte, Klasse II (Annex III) Firewalls, IDS/IPS, Hypervisoren, Container-Runtimes, manipulationssichere Mikroprozessoren Immer notifizierte Stelle (Modul B+C oder H) — harmonisierte Normen ändern das nicht
    Kritische Produkte (Annex IV) Hardware-Sicherheitsmodule, Smartcards, Smart-Meter-Gateways Höchste Stufe: gegebenenfalls verpflichtendes europäisches Cybersicherheits-Zertifizierungsschema

    Die drei Verfahren aus Annex VIII: Modul A ist die interne Kontrolle, also die reine Selbstbewertung ohne externe Beteiligung. Modul B+C kombiniert eine EU-Baumusterprüfung durch eine notifizierte Stelle (B) mit der Produktkonformität auf Basis interner Fertigungskontrolle (C). Modul H ist die umfassende Qualitätssicherung, bei der die notifizierte Stelle das Qualitätsmanagementsystem des Herstellers bewertet. Sobald ein Produkt in die Klasse II der wichtigen oder in die kritischen Produkte fällt, führt kein Weg an einer notifizierten Stelle vorbei, selbst bei vollständiger Anwendung harmonisierter Normen.

     

    Die Lieferkette einbinden: Selbstauskunft und Komponenten-SBOM

    Kaum ein Produkt besteht heute vollständig aus Eigenentwicklung. Fremde Bibliotheken, Open-Source-Komponenten und zugelieferte Module stecken in nahezu jeder Software. Der Cyber Resilience Act macht Sie als Hersteller des Endprodukts für dessen gesamte Cybersicherheit verantwortlich, einschließlich der Fremdkomponenten. Fremder Code wird damit zu Ihrer Verantwortung, und die Lieferkette ist ein eigener Arbeitsstrang der Umsetzung.

    Zwei Instrumente sind hier zentral. Erstens die Lieferantenselbstauskunft: eine strukturierte Abfrage bei jedem Zulieferer, wie er die CRA-relevanten Anforderungen erfüllt, ob und wie lange er Sicherheitsupdates liefert und wie er mit Schwachstellen umgeht. Zweitens die Komponenten-SBOM: eine maschinenlesbare Stückliste der in den zugelieferten Komponenten enthaltenen Softwarebestandteile. Nur so können Sie beim Bekanntwerden einer Schwachstelle in einer weit verbreiteten Bibliothek innerhalb von Stunden beantworten, ob und wo Ihr Produkt betroffen ist. Beides gehört vertraglich verankert, denn ohne Mitwirkung der Lieferanten bleiben blinde Flecken, für die am Ende Sie geradestehen.

     

    TrustSpace Profi-Tipp: Die Roadmap braucht ein System, keine Tabellensammlung

    Produktinventar, Gap-Analyse, Risikobewertung, Schwachstellen, SBOM, Meldeprozesse und Dokumentation lassen sich theoretisch in Tabellen führen, verlieren dort aber schnell den Zusammenhang. Genau diese Prozesse strukturiert die TrustSpace ISMS-Software: Sie verknüpft Assets mit Risiken, Schwachstellen und Maßnahmen, vergibt Verantwortlichkeiten samt Fristen und stellt Vorlagen für technische Dokumentation und Konformitätserklärung bereit. So wird aus der sechsphasigen Roadmap ein steuerbarer, jederzeit nachweisbarer Prozess, der den Dokumentationsaufwand spürbar senkt.

     

    Fazit: Umsetzung ist Prozess, nicht Projekt

    Den Cyber Resilience Act umzusetzen ist kein einmaliges Projekt mit Enddatum, sondern der Aufbau dauerhafter Fähigkeiten. Die sechs Phasen geben die Reihenfolge vor, doch sie ist nicht starr: Der Meldeprozess muss wegen der Frist 11. September 2026 vorgezogen werden, die volle Konformität mit CE-Kennzeichnung folgt bis zum 11. Dezember 2027. Wer früh mit einem vollständigen Produktinventar und einer sauberen Klassifizierung beginnt, verschafft sich den größten Vorteil, denn davon hängen Gap-Analyse, Risikobewertung und Konformitätsweg ab.

    Entscheidend ist, die Umsetzung als zusammenhängenden Prozess zu führen, nicht als Sammlung isolierter Aufgaben. Mit einer klaren Roadmap, vorgezogenen Meldeprozessen und werkzeuggestützter Steuerung wird aus einer regulatorischen Pflicht ein belastbarer Baustein Ihrer Produktsicherheit.

     

    Häufige Fragen (FAQ)

    Braucht der Cyber Resilience Act eine nationale Umsetzung in Deutschland?

    Nein. Der Cyber Resilience Act ist eine EU-Verordnung (Verordnung (EU) 2024/2847) und gilt in allen Mitgliedstaaten unmittelbar, ohne ein nationales Umsetzungsgesetz. National geregelt werden nur die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das BSI die Rolle der Marktüberwachungs- und notifizierenden Behörde.

    Ab wann gelten welche Pflichten des Cyber Resilience Act?

    Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Melde- und Berichtspflichten gelten ab dem 11. September 2026, darunter die Pflicht, aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden. Die volle Anwendung mit allen grundlegenden Anforderungen, Konformitätsbewertung und CE-Kennzeichnung folgt am 11. Dezember 2027.

    Wann darf ich mein Produkt selbst bewerten und wann muss eine notifizierte Stelle prüfen?

    Standardprodukte, also die große Mehrheit, dürfen sich per interner Kontrolle (Modul A) selbst bewerten. Wichtige Produkte der Klasse I dürfen das nur bei vollständiger Anwendung harmonisierter Normen, sonst ist eine notifizierte Stelle nötig. Wichtige Produkte der Klasse II und kritische Produkte müssen in jedem Fall über eine notifizierte Stelle beziehungsweise ein Zertifizierungsschema.

    Was ist eine SBOM und fordert der Cyber Resilience Act sie verpflichtend?

    Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts. Der CRA verlangt in Annex I, dass Hersteller mindestens die Abhängigkeiten oberster Ebene in einem gängigen, maschinenlesbaren Format dokumentieren und aktuell halten. Die SBOM ist Teil der technischen Dokumentation und wird den Marktüberwachungsbehörden auf Verlangen vorgelegt, sie muss aber nicht zwingend öffentlich sein.

    Wie binde ich meine Lieferanten in die CRA-Umsetzung ein?

    Über zwei Instrumente: eine Lieferantenselbstauskunft zu den CRA-Anforderungen und zur Update-Versorgung sowie eine Komponenten-SBOM, die die Softwarebestandteile der zugelieferten Komponenten offenlegt. Beides gehört vertraglich verankert, denn als Hersteller des Endprodukts haften Sie auch für die integrierten Fremdkomponenten.

  • Cyber Resilience Act Bußgelder & Sanktionen: Was Verstöße kosten

    Cyber Resilience Act Bußgelder & Sanktionen: Was Verstöße kosten

    Das Wichtigste in Kürze

    • Höchststrafe: Verstöße gegen die grundlegenden Cybersicherheitsanforderungen des Cyber Resilience Act (CRA) können mit bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.
    • Drei Bußgeldstufen: Artikel 64 der Verordnung (EU) 2024/2847 staffelt die Geldbußen nach Schwere der Pflichtverletzung (15/2,5 %, 10/2 %, 5/1 %).
    • Oft teurer als das Bußgeld: Marktrücknahme, Verkaufsverbot und der Verlust der CE-Kennzeichnung schneiden ein Produkt vom EU-Markt ab, unabhängig von jeder Geldstrafe.
    • Zuständigkeit in Deutschland: Vollzug und Bußgelder liegen bei den nationalen Marktüberwachungsbehörden; laut CRA-Durchführungsgesetz (Gesetzgebungsverfahren 2026) soll das BSI zentrale Marktüberwachungsbehörde werden.
    • Fristen: Der CRA gilt seit dem 10.12.2024, die Meldepflichten greifen ab dem 11.09.2026, die volle Anwendung inklusive Sanktionen ab dem 11.12.2027.
    • KMU: Behörden berücksichtigen die Unternehmensgröße, doch Verhältnismäßigkeit ist keine Entwarnung. Die Pflichten gelten auch für kleine und mittlere Hersteller.

     

    Für die Geschäftsführung ist der Cyber Resilience Act zunächst eine Zahl: Bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes kann ein Verstoß kosten. Diese Obergrenze allein bewegt Budgets, doch sie erzählt nur die halbe Geschichte. Die neue Cyberresilienz-Verordnung verknüpft Bußgelder mit einer Reihe weiterer Konsequenzen, die einen Hersteller oder Importeur oft härter treffen als jede Geldstrafe: Ein Produkt darf schlicht nicht mehr verkauft werden.

    Dieser Beitrag ordnet die Sanktionen sachlich ein. Er erklärt die Bußgeldstaffelung nach Artikel 64, benennt, wer die Strafen verhängt, und zeigt die nicht-monetären Folgen, die in der Risikobetrachtung häufig unterschätzt werden. Ein Rechenbeispiel stellt den möglichen Bußgeldrahmen den Kosten einer proaktiven Vorbereitung gegenüber. Wer die zeitliche Dimension einordnen will, findet die Details in der Übersicht der Fristen und Stichtage des Cyber Resilience Act.

     

    Wie hoch sind die Bußgelder unter dem Cyber Resilience Act?

    Der CRA ist eine EU-Verordnung und gilt damit unmittelbar in allen Mitgliedstaaten, ohne dass es einer nationalen Umsetzung bedarf. Die konkrete Höhe der Geldbußen legt Artikel 64 der Verordnung (EU) 2024/2847 fest. Er unterscheidet drei Stufen, abhängig davon, gegen welche Pflicht verstoßen wurde. Bei Unternehmen gilt jeweils der höhere der beiden genannten Werte, also entweder der feste Eurobetrag oder der prozentuale Anteil am weltweiten Jahresumsatz des vorangegangenen Geschäftsjahres.

    Art des Verstoßes Maximales Bußgeld
    Grundlegende Anforderungen
    Verstoß gegen die grundlegenden Cybersicherheitsanforderungen (Anhang I) sowie gegen die Pflichten der Hersteller aus Artikel 13 und 14 (u. a. Schwachstellenbehandlung und Meldepflichten)    		 bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes
    Sonstige Pflichten
    Verstoß gegen andere Pflichten der Verordnung (u. a. bestimmte Pflichten von Importeuren, Händlern und notifizierten Stellen)    		 bis 10 Mio. € oder 2 % des weltweiten Jahresumsatzes
    Falschauskünfte
    Erteilung falscher, unvollständiger oder irreführender Auskünfte gegenüber notifizierten Stellen und Marktüberwachungsbehörden    		 bis 5 Mio. € oder 1 % des weltweiten Jahresumsatzes

    Die genaue Bußgeldhöhe im Einzelfall ist kein Automatismus. Artikel 64 verpflichtet die Behörden, alle relevanten Umstände zu würdigen, insbesondere Art, Schwere und Dauer des Verstoßes und seiner Folgen, etwaige frühere Verstöße desselben Wirtschaftsakteurs sowie dessen Größe und Marktanteil. Ausdrücklich genannt ist dabei die Rücksichtnahme auf Kleinstunternehmen sowie kleine und mittlere Unternehmen einschließlich Start-ups. Eine Sonderstellung nehmen Verwalter quelloffener Software (Open-Source-Software-Stewards) ein: Sie sind von den Geldbußen des Artikels 64 ausgenommen, auch wenn andere Pflichten für sie fortbestehen.

    Wichtig für die Risikobewertung ist, dass ein Bußgeld nicht isoliert steht. Es kann zusätzlich zu anderen korrigierenden oder einschränkenden Maßnahmen verhängt werden, welche die Marktüberwachungsbehörden für denselben Verstoß anordnen. Genau diese begleitenden Maßnahmen sind es, die betriebswirtschaftlich oft schwerer wiegen.

     

    Wer verhängt die Bußgelder?

    Weil der CRA nur den Rahmen setzt und die konkreten Sanktionsregeln den Mitgliedstaaten überlässt, verhängen nationale Behörden die Bußgelder. Zuständig ist die jeweilige Marktüberwachungsbehörde, die auch die Konformität der Produkte am Markt kontrolliert. Anders als bei einer zentralen EU-Aufsicht gibt es also 27 nationale Vollzugsstränge, die sich untereinander abstimmen.

    In Deutschland wird der nationale Rahmen über das CRA-Durchführungsgesetz geschaffen, das sich Mitte 2026 im Gesetzgebungsverfahren befindet (erste Lesung im Bundestag am 11.06.2026). Nach dem vorliegenden Entwurf soll das Bundesamt für Sicherheit in der Informationstechnik (BSI) die zentrale Marktüberwachungs- und notifizierende Behörde werden. Eine Ausnahme ist vorgesehen für Produkte, die zugleich als Hochrisiko-KI-System unter die KI-Verordnung fallen; hier soll die für die KI-Aufsicht benannte Behörde zuständig sein, in Deutschland voraussichtlich die Bundesnetzagentur. Da das Gesetz noch nicht final verabschiedet ist, sollten Hersteller die Zuständigkeit vor einer konkreten Meldung oder Anfrage gegenprüfen. Am Grundsatz ändert das nichts: Der Vollzug erfolgt national, und die Behörden erhalten weitreichende Prüf- und Anordnungsbefugnisse.

     

    Was oft mehr schmerzt: die Folgen jenseits des Bußgeldes

    Ein Bußgeld ist eine einmalige, wenn auch schmerzhafte Belastung. Die folgenden Konsequenzen greifen tiefer in das Geschäftsmodell ein, weil sie die Marktfähigkeit des Produkts selbst betreffen. Für die Geschäftsführung sind sie deshalb der eigentliche Kern der CRA-Risikobetrachtung.

    Marktrücknahme und Verkaufsverbot

    Stellt die Marktüberwachungsbehörde ein nicht konformes Produkt mit digitalen Elementen fest, kann sie den Wirtschaftsakteur verpflichten, die Nichtkonformität zu beheben. Bleibt das aus oder besteht ein erhebliches Cybersicherheitsrisiko, reichen die Befugnisse bis zur Anordnung, das Produkt vom Markt zu nehmen oder zurückzurufen und die Bereitstellung auf dem Markt einzuschränken oder zu untersagen. Ein solcher Rückruf trifft nicht nur den Umsatz mit dem betroffenen Produkt, sondern verursacht Logistik-, Nachbesserungs- und Kommunikationskosten und bindet Ressourcen über Monate.

    Die CE-Kennzeichnung als Voraussetzung für den Marktzugang

    Mit dem CRA wird Cybersicherheit erstmals zu einer grundlegenden Produkteigenschaft und damit zur Bedingung für die CE-Kennzeichnung. Ein Produkt mit digitalen Elementen darf nur dann auf dem EU-Markt bereitgestellt werden, wenn es die Anforderungen erfüllt und die Konformitätsbewertung bestanden hat; erst danach darf die CE-Kennzeichnung angebracht werden (Artikel 30). Fehlt sie oder wurde sie zu Unrecht angebracht, ist das Produkt nicht verkehrsfähig. Der Marktzugang zum gesamten Europäischen Wirtschaftsraum hängt damit unmittelbar an der CRA-Konformität, nicht erst an der Frage eines möglichen Bußgeldes.

    Reputations- und Lieferkettenfolgen

    Der wirtschaftlich unterschätzte Hebel liegt in der Lieferkette. Wer Komponenten oder Software an andere Hersteller liefert, wird zunehmend erleben, dass seine B2B-Kunden die CRA-Konformität vertraglich einfordern, denn deren eigene Konformität hängt an den zugelieferten Bausteinen. Ein Hersteller, der die Anforderungen nicht nachweisen kann, verliert damit nicht nur Endkunden, sondern fällt als Zulieferer aus. Eine öffentlich gewordene Marktrücknahme oder ein gemeldeter, schlecht behandelter Sicherheitsvorfall wirkt zudem als Reputationsschaden weit über den unmittelbaren Fall hinaus.

    Zivilrechtliche Haftungsrisiken

    Parallel zum CRA hat die EU die Produkthaftung modernisiert. Die neue Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853, in Kraft seit dem 08.12.2024, umzusetzen bis zum 09.12.2026) definiert Software ausdrücklich als Produkt, unabhängig davon, ob sie auf einem Gerät gespeichert, aus der Cloud bezogen oder als Software-as-a-Service betrieben wird. Verfehlt ein Produkt den einschlägigen Sicherheitsstandard, wie ihn etwa der CRA vorgibt, kann das die Annahme eines Produktfehlers stützen. Ausdrücklich erfasst wird auch das Fehlen sicherheitsrelevanter Updates. Neben dem verwaltungsrechtlichen Bußgeld kann also ein zivilrechtliches Haftungsrisiko treten, das bis zum Ersatz von Schäden an Daten reicht.

     

    Rechenbeispiel: Was 2,5 Prozent für einen Mittelständler bedeuten

    Ein Zahlenbeispiel macht die Dimension greifbar. Angenommen, ein mittelständischer Hersteller vernetzter Geräte erzielt 50 Millionen Euro Jahresumsatz. 2,5 Prozent davon sind 1,25 Millionen Euro. Weil Artikel 64 aber den höheren der beiden Werte ansetzt, ist für dieses Unternehmen nicht der Prozentwert, sondern die feste Obergrenze von 15 Millionen Euro der maßgebliche Rahmen. Der prozentuale Deckel greift erst bei sehr großen Konzernen mit einem Jahresumsatz oberhalb von rund 600 Millionen Euro, ab denen 2,5 Prozent die 15 Millionen übersteigen.

    Das ist die für viele Geschäftsführer kontraintuitive Pointe: Gerade der Mittelstand haftet nicht nur mit einem kleinen Prozentsatz, sondern potenziell mit einem festen Betrag, der ein Vielfaches des Jahresgewinns ausmachen kann. Selbst wenn die Behörde die Verhältnismäßigkeit wahrt und deutlich unter dem Höchstmaß bleibt, kann ein Bußgeld im einstelligen Millionenbereich die Jahresrendite eines margenschwachen Betriebs übersteigen. Hinzu kommen die oben genannten nicht-monetären Folgen.

    Dem steht der Aufwand einer geordneten Vorbereitung gegenüber. Der Aufbau von Security-by-Design-Prozessen, einer Software-Stückliste (SBOM), einer nachweisbaren Schwachstellenbehandlung und der Konformitätsdokumentation bewegt sich für einen Mittelständler typischerweise im niedrigen sechsstelligen Bereich, verteilt über die Vorlaufzeit bis zur vollen Anwendung, und schafft zugleich einen Marktvorteil. Der Vergleich fällt eindeutig aus: Proaktive Compliance ist regelmäßig um eine Größenordnung günstiger als das Risiko, das sie abwendet. Eine strukturierte Herangehensweise beschreibt der Leitfaden dazu, wie sich die CRA-Anforderungen jetzt umsetzen lassen.

     

    TrustSpace Profi-Tipp: Sanktionsrisiko als Budgetargument nutzen

    Der wirksamste Hebel gegen das Bußgeldrisiko ist kein Rechtsgutachten, sondern ein belegbarer Prozess: dokumentierte Konformitätsbewertung, gepflegte SBOM, gelebte Schwachstellenbehandlung und funktionierende Meldewege. Wer diese Nachweise vorhält, entzieht dem höchsten Bußgeldtatbestand die Grundlage und ist zugleich lieferkettenfähig. Eine ISMS-Plattform bündelt Anforderungen, Verantwortlichkeiten und Nachweise an einem Ort. So lässt sich die CRA-Compliance mit TrustSpace umsetzen und im Audit wie gegenüber B2B-Kunden belastbar dokumentieren.

     

    Was bedeutet das für KMU?

    Der CRA nimmt kleine und mittlere Unternehmen nicht aus der Pflicht, mildert aber an mehreren Stellen ab. Bei der Bußgeldbemessung ist die Unternehmensgröße ausdrücklich zu berücksichtigen, und die Verordnung sieht für bestimmte Nachweise vereinfachte Formate vor. Das ist Verhältnismäßigkeit, keine Ausnahme: Die grundlegenden Anforderungen an sichere Produkte, die Konformitätsbewertung und die Meldepflichten gelten auch für den kleinen Hersteller.

    Für KMU liegt der entscheidende Vorteil im frühen Start. Wer die Prozesse bis zur vollen Anwendung schrittweise aufbaut, verteilt den Aufwand und vermeidet den teuren Endspurt kurz vor dem Stichtag. Die Sanktionslogik ähnelt darin der Regulierung im NIS-2-Umfeld; wer den Beitrag Bußgelder und Haftung unter NIS 2 kennt, erkennt das Muster: gestaffelte Bußgelder, persönliche Verantwortung der Leitungsebene und ein starker Anreiz, Nachweise vorab zu strukturieren statt reaktiv zu erklären.

     

    Fazit: Das Bußgeld ist nur die sichtbare Spitze

    Die Bußgelder des Cyber Resilience Act sind mit bis zu 15 Millionen Euro oder 2,5 Prozent des Weltumsatzes bewusst abschreckend gestaltet, und für den Mittelstand ist es die feste Obergrenze, die den Rahmen setzt. Doch die eigentliche Steuerungswirkung entfaltet der CRA über die Konsequenzen jenseits des Bußgeldes: Marktrücknahme, Verkaufsverbot, der Verlust der CE-Kennzeichnung als Eintrittskarte in den EU-Markt und die zivilrechtliche Haftung. Zusammengenommen entscheiden sie darüber, ob ein Produkt überhaupt verkäuflich bleibt.

    Für die Geschäftsführung folgt daraus eine klare Priorisierung. Das Sanktionsrisiko ist real, aber beherrschbar, sofern die Konformität frühzeitig und nachweisbar aufgebaut wird. Die Kosten dafür sind planbar und liegen deutlich unter dem Schaden, den ein Verstoß auslösen kann. Bis zur vollen Anwendung am 11.12.2027 bleibt Zeit, diese Nachweise zu strukturieren; genutzt sein will sie jetzt.

     

    Häufige Fragen (FAQ)

    Wie hoch ist das maximale Bußgeld unter dem Cyber Resilience Act?

    Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen (Anhang I) sowie gegen die Herstellerpflichten aus Artikel 13 und 14 drohen Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des Vorjahres, je nachdem, welcher Betrag höher ist. Für sonstige Pflichtverletzungen liegt die Grenze bei 10 Millionen Euro oder 2 Prozent, für Falschauskünfte bei 5 Millionen Euro oder 1 Prozent.

    Wer verhängt die Bußgelder in Deutschland?

    Der CRA überlässt die Sanktionsregeln den Mitgliedstaaten; zuständig sind die nationalen Marktüberwachungsbehörden. In Deutschland soll nach dem CRA-Durchführungsgesetz, das sich 2026 im Gesetzgebungsverfahren befindet, das BSI zentrale Marktüberwachungsbehörde werden. Für Produkte, die zugleich Hochrisiko-KI-Systeme sind, ist voraussichtlich die Bundesnetzagentur zuständig.

    Ab wann können Bußgelder verhängt werden?

    Der CRA gilt seit dem 10.12.2024, doch die Pflichten greifen gestaffelt. Die Melde- und Berichtspflichten gelten ab dem 11.09.2026, die volle Anwendung mit den durchsetzbaren Produktanforderungen und den zugehörigen Sanktionen ab dem 11.12.2027. Bis dahin sollten Hersteller die Konformität aufgebaut haben.

    Sind kleine und mittlere Unternehmen von den Bußgeldern ausgenommen?

    Nein. KMU müssen die Anforderungen des CRA erfüllen. Die Verordnung sieht jedoch Erleichterungen vor: Bei der Bußgeldbemessung ist die Unternehmensgröße zu berücksichtigen, und für bestimmte Nachweise gelten vereinfachte Formate. Verhältnismäßigkeit bedeutet also Abmilderung, nicht Befreiung.

    Was ist schlimmer als das Bußgeld selbst?

    Häufig die begleitenden Maßnahmen. Marktüberwachungsbehörden können anordnen, ein nicht konformes Produkt vom Markt zu nehmen oder zurückzurufen. Ohne CE-Kennzeichnung ist ein Produkt nicht verkehrsfähig, und B2B-Kunden verlangen in der Lieferkette den Konformitätsnachweis. Diese Folgen können ein Produkt vollständig vom Markt drängen, unabhängig von der Höhe einer Geldstrafe.

  • CRA vs. NIS2, DORA, ISO 27001 & RED: Wie die Regularien zusammengreifen

    CRA vs. NIS2, DORA, ISO 27001 & RED: Wie die Regularien zusammengreifen

    Das Wichtigste in Kürze

    • Zwei Welten plus ein Fundament: Der Cyber Resilience Act (CRA) und die Radio Equipment Directive (RED) regulieren Produkte, NIS2 und DORA regulieren Organisationen, und die ISO 27001 ist der freiwillige Standard, auf dem beide Welten aufsetzen.
    • CRA: Verordnung (EU) 2024/2847, unmittelbar geltend für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen. Vollanwendung ab 11. Dezember 2027.
    • NIS2 und DORA: Sie verpflichten Organisationen zu Cyber-Risikomanagement und Meldepflichten, NIS2 branchenübergreifend, DORA speziell im Finanzsektor.
    • RED läuft aus: Die Cybersicherheitspflichten der delegierten Verordnung (EU) 2022/30 werden zum 11. Dezember 2027 vom CRA abgelöst und aufgehoben.
    • Kernpunkt: Wer NIS2-pflichtig ist und Produkte herstellt, braucht beides. Ein sauber aufgesetztes ISMS liefert die Nachweise für CRA, NIS2, DORA und ISO 27001 aus einer Quelle, statt vier getrennter Compliance-Silos.

     

    Kaum ein Unternehmen wird heute nur von einer einzigen Cybersicherheits-Regulierung erfasst. Ein mittelständischer Maschinenbauer, der vernetzte Anlagen ausliefert, fällt unter den Cyber Resilience Act und ab 2027 unter die neue Maschinenverordnung, ist als Unternehmen einer kritischen Branche zugleich NIS2-pflichtig und zertifiziert sich für Ausschreibungen nach ISO 27001. Vier Regelwerke, vier Fristen, vier Bußgeldregime, die auf den ersten Blick nichts miteinander zu tun haben. Die Folge ist oft ein teurer Reflex: Für jede Vorschrift wird ein eigenes Projekt aufgesetzt, mit eigener Dokumentation, eigenem Verantwortlichen und eigenem Audit-Kalender.

    Dieser Vergleich ordnet das Dickicht. Er erklärt die eine Grundunterscheidung, die alles verständlich macht, stellt die fünf zentralen Regelwerke in einer Übersicht gegenüber und geht jede Paarung mit dem CRA einzeln durch. Am Ende steht die entscheidende Erkenntnis für die Planung: Wo sich die Regularien überschneiden, entstehen nicht zwangsläufig mehr Silos, sondern die Chance, ein einziges Managementsystem als gemeinsames Fundament zu nutzen. Die deutsche Bezeichnung Cyberresilienz-Verordnung meint dasselbe wie der englische Begriff Cyber Resilience Act, unter dem gesucht und international kommuniziert wird.

     

    Produkt, Organisation oder freiwilliger Standard: die eine Grundunterscheidung

    Der Schlüssel zum Verständnis liegt in einer simplen Frage: Was genau reguliert das jeweilige Regelwerk? Sobald diese Achse klar ist, sortieren sich alle Überschneidungen von selbst.

    Produkt-Regulierung setzt am einzelnen Gerät oder der einzelnen Software an. Der Cyber Resilience Act, die Radio Equipment Directive und die kommende Maschinenverordnung schreiben vor, welche Cybersicherheitseigenschaften ein Produkt haben muss, bevor es in den EU-Markt kommt. Adressat ist der, der das Produkt bereitstellt: Hersteller, Importeur, Händler. Der Nachweis erfolgt über CE-Kennzeichnung und Konformitätsbewertung.

    Organisations-Regulierung setzt am Unternehmen als Ganzem an. NIS2 und DORA fragen nicht, ob ein bestimmtes Produkt sicher ist, sondern ob die Organisation ihre Risiken beherrscht: Gibt es Risikomanagement, Meldeprozesse, Business Continuity, Lieferantensteuerung? Adressat ist die Geschäftsführung der betroffenen Einrichtung.

    Der freiwillige Standard ISO/IEC 27001 steht quer zu beiden. Er zwingt niemanden per Gesetz, liefert aber die international anerkannte Blaupause für genau das Managementsystem, das die organisatorischen Pflichten aus NIS2 und DORA und die Prozessanforderungen des CRA in geordnete Bahnen lenkt. Deshalb ist er kein vierter Konkurrent, sondern das gemeinsame Fundament.

     

    Die fünf Regelwerke im direkten Vergleich

    Die folgende Übersicht stellt die zentralen Merkmale nebeneinander. Sie zeigt auf einen Blick, warum sich die Regularien nicht ausschließen, sondern ineinandergreifen.

    Regelwerk Typ Reguliert was Gilt für wen Zentrale Fristen Sanktionen (Höchststufe)
    Cyber Resilience Act (EU) 2024/2847 Produkt-Verordnung, unmittelbar geltend Cybersicherheit von Produkten mit digitalen Elementen über den Lebenszyklus Hersteller, Importeure, Händler In Kraft 10.12.2024, Meldepflichten ab 11.09.2026, Vollanwendung 11.12.2027 bis 15 Mio. € oder 2,5 % Weltumsatz
    NIS2-Richtlinie (EU) 2022/2555 Richtlinie, nationale Umsetzung nötig Risikomanagement und Meldepflichten von Organisationen in kritischen Sektoren Wesentliche und wichtige Einrichtungen in 18 Sektoren (ab 50 Mitarbeitende oder 10 Mio. € Umsatz) EU-Frist 17.10.2024, in Deutschland seit 06.12.2025 bis 10 Mio. € oder 2 % Weltumsatz (wesentlich)
    DORA (EU) 2022/2554 Verordnung, sektorspezifisch Digitale operationale Resilienz im Finanzsektor Rund 22.000 Finanzunternehmen und ihre kritischen IKT-Drittdienstleister Gilt seit 17.01.2025 aufsichtsrechtliche Maßnahmen, Zwangs- und Bußgelder
    ISO/IEC 27001:2022 Freiwilliger internationaler Standard Aufbau und Betrieb eines Informationssicherheits-Managementsystems (ISMS) Jede Organisation freiwillig, oft vom Kunden oder Vertrag gefordert Keine gesetzliche Frist, Zertifikat drei Jahre gültig Keine gesetzlichen, Verlust der Zertifizierung
    RED 2014/53/EU + del. VO (EU) 2022/30 Produkt-Richtlinie (Funkanlagen) Cybersicherheit vernetzter Funkanlagen (Art. 3.3 d, e, f) Hersteller von Funk- und Funknetz-Produkten Cyber-Pflichten seit 01.08.2025, Ablösung durch CRA am 11.12.2027 national geregelte Marktüberwachung

    Die Maschinenverordnung (EU) 2023/1230 gehört als sechstes Regelwerk in die Spalte der Produkt-Regulierung, dazu weiter unten mehr. Wichtig ist das Muster: Zwei der fünf greifen am Produkt, zwei an der Organisation, eines ist freiwillig. Wer diese Sortierung verinnerlicht hat, versteht jede einzelne Paarung in Sekunden.

     

    CRA vs. NIS2: Produkt trifft Organisation

    Diese beiden werden am häufigsten verwechselt, weil beide „Cybersicherheit” und „EU” im Titel tragen. Tatsächlich stehen sie nebeneinander, nicht gegeneinander. Der CRA verlangt, dass ein Produkt sicher ist. NIS2 verlangt, dass eine Organisation ihre IT-Risiken beherrscht, unter anderem indem sie in ihrer Lieferkette auf die Sicherheit eingesetzter Produkte achtet.

    Damit greifen sie ineinander: Der CRA sorgt für ein höheres Grundniveau bei genau den Produkten, die NIS2-pflichtige Unternehmen einkaufen und betreiben. Wer die Grundzüge der Organisationspflicht nachlesen will, findet sie in der Zusammenfassung der NIS-2-Richtlinie. Der praktische Knackpunkt entsteht bei Unternehmen, die beides sind: NIS2-pflichtige Einrichtung und Hersteller von Produkten mit digitalen Elementen. Ein Energieversorger, der eigene Steuerungshardware baut, oder ein Industriebetrieb, der vernetzte Sensoren vertreibt, muss die Organisationspflichten aus NIS2 und die Produktpflichten aus dem CRA parallel erfüllen. Beide teilen sich denselben Unterbau aus Risikoanalyse, Schwachstellenmanagement und Vorfallmeldung, nur mit unterschiedlichem Bezugsobjekt. Ob Ihr Unternehmen produktseitig überhaupt in den Anwendungsbereich fällt, lässt sich vorab klären, indem Sie die Betroffenheit vom Cyber Resilience Act prüfen.

     

    CRA vs. DORA: der Finanzsektor als Sonderfall

    DORA (Digital Operational Resilience Act, Verordnung (EU) 2022/2554) ist die Organisations-Regulierung des Finanzsektors und gilt bereits seit dem 17. Januar 2025. Sie verpflichtet rund 22.000 Banken, Versicherer, Wertpapier- und Kryptodienstleister sowie ihre kritischen IKT-Drittanbieter zu striktem IKT-Risikomanagement, Vorfallmeldungen, regelmäßigen Resilienztests und einer engmaschigen Steuerung von Drittparteienrisiken. Ein Überblick über die Einzelpflichten findet sich in den DORA-Anforderungen für Finanzunternehmen.

    Zum CRA verhält sich DORA nach dem Grundsatz lex specialis: Das speziellere Gesetz geht dem allgemeineren vor. Für Belange, die DORA für den Finanzsektor bereits abschließend regelt, tritt der CRA zurück. Das entbindet ein Finanzunternehmen aber nicht generell: Stellt es selbst Produkte mit digitalen Elementen für den Markt her, gelten für diese Produkte weiterhin die CRA-Regeln, während DORA die organisatorische Resilienz des Unternehmens adressiert. Auch hier ist die Trennlinie wieder das Bezugsobjekt: DORA schaut auf die Organisation, der CRA auf das Produkt.

     

    CRA vs. ISO 27001: Pflicht trifft freiwilligen Standard

    Der CRA ist geltendes EU-Recht mit empfindlichen Bußgeldern. Die ISO/IEC 27001 ist ein freiwilliger Standard ohne gesetzliche Sanktion. Trotzdem ist die ISO 27001 das nützlichste Werkzeug, um den CRA praktisch zu erfüllen, denn ihr Kern ist ein Informationssicherheits-Managementsystem mit genau den Prozessen, die der CRA für Hersteller voraussetzt: Risikomanagement, Schwachstellenbehandlung, dokumentierte Verantwortlichkeiten, Umgang mit Sicherheitsvorfällen und kontinuierliche Verbesserung.

    Der CRA fordert diese Prozesse produktbezogen und verlangt zusätzlich technische Nachweise wie eine Software-Stückliste (SBOM), einen definierten Support-Zeitraum und die konkreten Anforderungen aus Annex I des Cyber Resilience Act. Die ISO 27001 wiederum liefert den organisatorischen Rahmen, in dem sich diese Nachweise sauber führen lassen. Eine bestehende ISO-27001-Zertifizierung erfüllt den CRA nicht automatisch, verkürzt aber den Weg dorthin erheblich, weil das Managementsystem bereits steht und nur um die produktspezifischen Bausteine ergänzt werden muss.

     

    TrustSpace Profi-Tipp: Erst die Prozesse, dann die Produkte

    Unternehmen, die schon ein ISMS nach ISO 27001 betreiben, sollten den CRA nicht als neues Projekt aufsetzen, sondern als Erweiterung des bestehenden Systems. Schwachstellenmanagement, Incident Response und Risikobewertung existieren dann bereits, sie müssen nur vom Organisations- auf den Produktkontext ausgeweitet werden. Wo dieser Rahmen noch fehlt oder der Zeithorizont bis zur Vollanwendung 2027 knapp wird, hilft eine strukturierte Beratung zum Cyber Resilience Act, die vorhandene Nachweise auf die Produktpflichten abbildet, statt alles neu aufzubauen.

     

    CRA vs. RED: vom Funkgeräte-Sonderweg zur einheitlichen Produktregel

    Die Radio Equipment Directive (RED, Richtlinie 2014/53/EU) war der erste EU-Rechtsakt, der verbindliche Cybersicherheitsanforderungen an Produkte stellte, allerdings nur an Funkanlagen. Über die delegierte Verordnung (EU) 2022/30 wurden die grundlegenden Anforderungen des Artikels 3 Absatz 3 Buchstaben d, e und f für bestimmte vernetzte Funkgeräte aktiviert, etwa zum Schutz des Netzes, personenbezogener Daten und vor Betrug. Diese Cybersicherheitspflichten gelten seit dem 1. August 2025, nachdem der ursprüngliche Termin um ein Jahr verschoben worden war. Die einschlägige harmonisierte Norm ist die EN 18031.

    Dieser Sonderweg für Funkgeräte ist eine Übergangslösung. Ab dem 11. Dezember 2027, mit der Vollanwendung des CRA, wird die delegierte Verordnung (EU) 2022/30 nicht mehr angewendet und von der Europäischen Kommission aufgehoben. Der CRA übernimmt die Cybersicherheitsziele der RED vollständig in seinem Annex I, aber eben nicht mehr nur für Funkanlagen, sondern für alle Produkte mit digitalen Elementen. Für Funkgeräte, die zwischen dem 1. August 2025 und dem 10. Dezember 2027 in Verkehr gebracht werden, bleiben die RED-Cybersicherheitsanforderungen weiterhin durchsetzbar. Praktisch bedeutet das: Wer heute in RED-Konformität investiert, arbeitet bereits auf das CRA-Zielbild hin, muss aber den Übergang aktiv planen, weil ab 2027 die CRA-Konformität nachzuweisen ist.

     

    Maschinenverordnung (EU) 2023/1230: Cybersicherheit wird Maschinensicherheit

    In dieselbe Familie der Produkt-Regulierung gehört die neue Maschinenverordnung (EU) 2023/1230, die ab dem 20. Januar 2027 unmittelbar in allen Mitgliedstaaten gilt und die bisherige Maschinenrichtlinie 2006/42/EG ersetzt. Erstmals enthält sie Cybersicherheit als grundlegende Sicherheitsanforderung: Maschinen mit digitalen Elementen müssen so konstruiert sein, dass ihre Sicherheitsfunktionen nicht durch unbefugte digitale Zugriffe manipuliert werden können.

    Für Maschinenbauer heißt das, dass sich CRA und Maschinenverordnung überlappen. Der CRA adressiert die Cybersicherheit der digitalen Elemente an sich, die Maschinenverordnung verknüpft sie mit der klassischen Betriebs- und Personensicherheit der Maschine. Beide fordern dieselbe Denkweise von Security by Design, Risikobeurteilung und Dokumentation, nur unter unterschiedlicher rechtlicher Flagge. Auch hier zahlt ein einmal aufgesetzter, produktbezogener Sicherheitsprozess doppelt ein.

     

    Der gemeinsame Nenner: ein ISMS als Fundament für alle vier

    Stellt man die Regelwerke nebeneinander, fällt auf, wie stark sich ihre inhaltlichen Bausteine gleichen. Risikomanagement, Schwachstellenbehandlung, Umgang mit Sicherheitsvorfällen, Lieferantensteuerung und lückenlose Nachweisführung tauchen in jedem einzelnen auf, nur mit verschobenem Bezugsobjekt und unterschiedlicher Frist.

    Gemeinsamer Baustein CRA NIS2 DORA ISO 27001
    Risikomanagement produktbezogen organisationsweit IKT-bezogen Kern des ISMS
    Schwachstellenmanagement Pflicht (Annex I) Teil der Maßnahmen Teil des IKT-Risikos Control A.8.8
    Vorfallmeldung an ENISA/CSIRT an Behörde/CSIRT an Aufsicht Managementprozess
    Lieferanten-/Drittparteirisiko Komponenten, SBOM Lieferkette IKT-Drittanbieter Control-Bereich A.5.19 ff.
    Nachweis und Dokumentation technische Doku, CE Nachweispflicht Aufsichts-Reporting Auditnachweise

    Genau darin liegt die eigentliche Botschaft dieses Vergleichs: Kein Unternehmen sollte für CRA, NIS2, DORA und ISO 27001 vier getrennte Compliance-Silos aufbauen. Ein einmal sauber aufgesetztes Informationssicherheits-Managementsystem bildet das gemeinsame Fundament. Aus ihm heraus werden dieselben Kernprozesse für jede Regulierung nur passend zugeschnitten und mit dem jeweils geforderten Nachweis bedient, statt sie viermal parallel zu pflegen. Das spart nicht nur Aufwand, sondern verhindert auch Widersprüche zwischen den Dokumentationen, die in Audits regelmäßig auffallen.

     

    Fazit: unterschiedliche Flaggen, gemeinsames Fundament

    Der Cyber Resilience Act, NIS2, DORA, die ISO 27001, die RED und die Maschinenverordnung wirken auf den ersten Blick wie sechs unverbundene Baustellen. Der Blick auf die eine Achse ordnet alles: CRA, RED und Maschinenverordnung regulieren Produkte, NIS2 und DORA regulieren Organisationen, und die ISO 27001 ist der freiwillige Standard, der beiden Welten ihren methodischen Rahmen gibt. Überall dort, wo ein Unternehmen von mehreren Regelwerken gleichzeitig erfasst wird, überlappen sich die inhaltlichen Anforderungen weit stärker, als es die getrennten Gesetzestexte vermuten lassen.

    Wer das erkennt, plant nicht mehr in Einzelprojekten, sondern baut ein Managementsystem, das mehrere Regularien zugleich bedient. Die Fristen bis 2027 sind eng genug, um jetzt mit dieser Konsolidierung zu beginnen, statt später vier getrennte Nachweisketten nachträglich zusammenzuführen.

     

    Häufige Fragen (FAQ)

    Was ist der Unterschied zwischen CRA und NIS2?

    Der Cyber Resilience Act reguliert Produkte: Er schreibt Herstellern, Importeuren und Händlern vor, welche Cybersicherheitseigenschaften ein Produkt mit digitalen Elementen haben muss. NIS2 reguliert Organisationen: Es verpflichtet Unternehmen kritischer Sektoren zu Risikomanagement und Meldeprozessen. Ein Unternehmen kann beide Pflichten gleichzeitig haben, wenn es einer NIS2-Branche angehört und zugleich Produkte herstellt.

    Gilt der CRA zusätzlich zu DORA für Finanzunternehmen?

    DORA ist für den Finanzsektor das speziellere Recht (lex specialis) und geht dem CRA vor, soweit es die Belange abschließend regelt. Stellt ein Finanzunternehmen aber selbst Produkte mit digitalen Elementen für den Markt her, gelten für diese Produkte weiterhin die Anforderungen des CRA. DORA adressiert die organisatorische Resilienz, der CRA das Produkt.

    Ersetzt der Cyber Resilience Act die ISO 27001?

    Nein. Der CRA ist verpflichtendes EU-Recht, die ISO 27001 ein freiwilliger Standard. Eine ISO-27001-Zertifizierung erfüllt den CRA nicht automatisch, liefert aber das Managementsystem mit genau den Prozessen, die der CRA voraussetzt. Ein bestehendes ISMS verkürzt den Weg zur CRA-Konformität deutlich, weil nur die produktspezifischen Bausteine ergänzt werden müssen.

    Was passiert mit den RED-Cybersicherheitsanforderungen?

    Die Cybersicherheitspflichten der delegierten Verordnung (EU) 2022/30 gelten seit dem 1. August 2025 für vernetzte Funkanlagen. Mit der Vollanwendung des CRA am 11. Dezember 2027 werden sie aufgehoben und vom CRA abgelöst, der dieselben Ziele in seinem Annex I für alle Produkte mit digitalen Elementen übernimmt. Für Funkgeräte, die vorher in Verkehr gebracht wurden, bleiben die RED-Anforderungen durchsetzbar.

    Kann ein Managementsystem mehrere dieser Regularien gleichzeitig abdecken?

    Ja, das ist der wirtschaftlich sinnvollste Weg. Risikomanagement, Schwachstellenbehandlung, Vorfallmeldung, Lieferantensteuerung und Nachweisführung sind in CRA, NIS2, DORA und ISO 27001 dieselben Kernprozesse, nur mit anderem Bezugsobjekt. Ein einmal aufgesetztes ISMS liefert diese Nachweise für alle Regularien aus einer Quelle und macht vier getrennte Compliance-Silos überflüssig.

  • Cyber Resilience Act Anforderungen: Die Pflichten aus Annex I verständlich erklärt

    Cyber Resilience Act Anforderungen: Die Pflichten aus Annex I verständlich erklärt

    Das Wichtigste in Kürze

    • Rechtsgrundlage: Die materiellen Pflichten des Cyber Resilience Act (Verordnung (EU) 2024/2847) stehen gebündelt in Anhang I (Annex I) — er ist das Herzstück jeder CRA-Konformität.
    • Zwei Teile: Teil I definiert die sicherheitsbezogenen Produkteigenschaften (Security by Design), Teil II acht Prozessanforderungen an die Schwachstellenbehandlung über den gesamten Support-Zeitraum.
    • Kernpflichten: sichere Standardkonfiguration, keine bekannten ausnutzbaren Schwachstellen, eine Software-Stückliste (SBOM) sowie kostenlose, zeitnahe Sicherheitsupdates.
    • Nachweis: technische Dokumentation (Anhang VII), Risikobewertung, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung belegen die Einhaltung.
    • Betriebspflicht: Ab dem 11.09.2026 gelten die Meldepflichten nach Art. 14 — eine aktiv ausgenutzte Schwachstelle ist binnen 24 Stunden als Frühwarnung an CSIRT und ENISA zu melden.
    • ISMS als Rahmen: Viele Annex-I-Pflichten (Prozesse, Dokumentation, Schwachstellenmanagement) lassen sich strukturiert über ein Informationssicherheits-Managementsystem abbilden.

     

    Wer festgestellt hat, dass sein Produkt unter den Cyber Resilience Act fällt, steht sofort vor der eigentlichen Frage: Was genau muss ich jetzt tun? Die Antwort steht nicht verteilt über die gesamte Verordnung, sondern konzentriert in einem einzigen Dokument — dem Anhang I. Dort listet der Gesetzgeber die grundlegenden Cybersicherheitsanforderungen auf, die jedes Produkt mit digitalen Elementen erfüllen muss, bevor es in der EU auf den Markt kommt.

    Dieser Leitfaden übersetzt Anhang I in Praxis-Sprache: Er gliedert die Anforderungen in ihre zwei Teile, erklärt zu jeder Pflicht, was operativ dahintersteht, und zeigt, wie Sie die Einhaltung nachweisen — von der technischen Dokumentation über die Konformitätsbewertung bis zur CE-Kennzeichnung. Am Ende ordnen wir ein, welche Pflichten Hersteller, Importeure und Händler jeweils treffen.

     

    Anhang I: das Herzstück der CRA-Anforderungen

    Der Cyber Resilience Act, im Deutschen auch Cyberresilienz-Verordnung genannt, gilt EU-weit unmittelbar — es gibt kein nationales Umsetzungsgesetz. Die Pflichten ergeben sich aus dem Verordnungstext selbst, und die inhaltlich zentralen stehen in Anhang I unter der Überschrift „Grundlegende Cybersicherheitsanforderungen”.

    Anhang I ist in zwei Teile geteilt, und diese Trennung ist der Schlüssel zum Verständnis der Verordnung. Teil I beschreibt Eigenschaften, die das Produkt selbst mitbringen muss — sicheres Design und sichere Entwicklung. Teil II beschreibt Prozesse, die der Hersteller dauerhaft betreiben muss — den Umgang mit Schwachstellen, nachdem das Produkt auf dem Markt ist. Vereinfacht: Teil I ist eine Momentaufnahme des Produkts, Teil II eine laufende Verpflichtung über den gesamten Lebenszyklus.

    Der CRA ist dabei nur eine von mehreren Regulierungen, die parallel auf Unternehmen einwirken. Wie er sich zu verwandten Rahmenwerken verhält, erläutert der Beitrag Cyber Resilience Act im Vergleich zu NIS2, DORA und ISO 27001 im Detail — für die konkreten Produktpflichten bleibt jedoch Anhang I der maßgebliche Text.

     

    Annex I Teil I: sichere Produkteigenschaften (Security by Design)

    Teil I verlangt, dass ein Produkt mit digitalen Elementen so konzipiert, entwickelt und hergestellt wird, dass es ein angemessenes Cybersicherheitsniveau bietet. Aus einer vorgeschalteten Risikobewertung leitet der Hersteller ab, welche der folgenden Anforderungen relevant sind. Die folgende Tabelle übersetzt sie in ihre praktische Bedeutung.

    Anforderung (Annex I, Teil I) Was das operativ bedeutet
    Keine bekannten ausnutzbaren Schwachstellen Bekannte Lücken sind vor Markteinführung geschlossen; ein Produkt mit offenem, bekanntem CVE darf nicht ausgeliefert werden.
    Sichere Standardkonfiguration Sicher voreingestellter Auslieferungszustand (Secure by Default) mit Reset-Möglichkeit — keine Standardpasswörter, keine unnötig offenen Dienste.
    Behebbarkeit über Sicherheitsupdates Schwachstellen lassen sich per Update beheben, wo sinnvoll automatisch; die Update-Fähigkeit ist technisch von Anfang an eingeplant.
    Schutz vor unbefugtem Zugriff Angemessene Zugangskontrolle über Authentifizierung und Identitäts- bzw. Zugriffsmanagement.
    Vertraulichkeit der Daten Schutz gespeicherter und übertragener Daten durch Verschlüsselung nach dem Stand der Technik (at rest und in transit).
    Integrität Schutz von Daten, Befehlen, Programmen und Konfiguration gegen unbefugte Manipulation.
    Datenminimierung Verarbeitet werden nur die für den vorgesehenen Zweck erforderlichen Daten.
    Verfügbarkeit und DoS-Resilienz Wesentliche Funktionen bleiben auch nach einem Vorfall verfügbar; Widerstand gegen Denial-of-Service-Angriffe.
    Minimierte Angriffsfläche Reduktion externer Schnittstellen und nicht benötigter Funktionen auf das Notwendige.
    Wirkungsbegrenzung (Exploitation Mitigation) Technische Mechanismen begrenzen den Schaden, falls es doch zu einem Vorfall kommt.
    Sicherheitsrelevante Protokollierung Aufzeichnung und Überwachung interner Aktivitäten wie Datenzugriffe und -änderungen.
    Sichere Datenlöschung Nutzer können alle Daten und Einstellungen sicher und dauerhaft entfernen.

    Keine dieser Anforderungen gilt für jedes Produkt gleich. Der CRA folgt einem risikobasierten Ansatz: Welche Maßnahmen in welcher Tiefe nötig sind, ergibt sich aus der Cybersicherheits-Risikobewertung, die der Hersteller ohnehin durchführen und dokumentieren muss — ein einfacher Sensor braucht andere Vorkehrungen als eine industrielle Steuerung.

     

    Annex I Teil II: Pflichten zum Schwachstellenmanagement

    Teil II wird von vielen Herstellern unterschätzt, weil er nicht mit dem Verkauf endet, sondern dann erst richtig beginnt: Er verlangt einen dauerhaften Prozess zur Behandlung von Schwachstellen über den gesamten Support-Zeitraum. Acht Anforderungen bilden diesen Prozess:

    • Software-Stückliste (SBOM): Der Hersteller dokumentiert die Komponenten seines Produkts in einer maschinenlesbaren Software Bill of Materials, die zumindest die wichtigsten Abhängigkeiten abdeckt (etablierte Formate: CycloneDX, SPDX). Ohne diese Transparenz lässt sich nicht sagen, welche Fremdkomponente von einer neuen Schwachstelle betroffen ist.
    • Schwachstellen unverzüglich beheben: Bekannt gewordene Lücken werden ohne unnötige Verzögerung adressiert, insbesondere durch Sicherheitsupdates.
    • Regelmäßige Tests und Prüfungen: Die Produktsicherheit wird wirksam und wiederkehrend getestet und überprüft, nicht nur einmalig vor dem Launch.
    • Offenlegung behobener Schwachstellen: Ist ein Update verfügbar, werden Informationen zu den behobenen Schwachstellen geteilt und öffentlich bereitgestellt, samt Beschreibung.
    • Policy zur koordinierten Offenlegung: Der Hersteller etabliert und lebt eine Coordinated-Vulnerability-Disclosure-Policy, die den geordneten Umgang mit gemeldeten Lücken regelt.
    • Kontaktadresse für Meldungen: Es gibt eine benannte Anlaufstelle, an die Sicherheitsforscher und Dritte potenzielle Schwachstellen melden können.
    • Sichere Update-Verteilung: Updates werden über sichere Mechanismen ausgeliefert, damit Lücken zeitnah und ohne neue Risiken geschlossen werden.
    • Kostenlose Sicherheitsupdates: Verfügbare Sicherheitsupdates werden unverzüglich und — sofern nicht anders vereinbart — kostenlos bereitgestellt, getrennt von reinen Funktionsupdates.

    Wer ein gelebtes Schwachstellenmanagement mit klaren Phasen bereits betreibt, hat den Kern von Teil II schon abgedeckt — der CRA gibt diesem Prozess lediglich einen verbindlichen gesetzlichen Rahmen und ergänzt die Melde- und Offenlegungspflichten.

     

    TrustSpace Profi-Tipp: SBOM ist kein Einmal-Dokument

    Die häufigste Fehlannahme lautet, die Software-Stückliste sei ein Nachweis, den man einmal erstellt und ablegt. Tatsächlich verlangt Anhang I, dass die SBOM über den gesamten Support-Zeitraum aktuell gehalten wird. Sinnvoll ist deshalb, sie in die CI/CD-Pipeline zu integrieren und automatisiert gegen Schwachstellendatenbanken abzugleichen. So wird aus einer statischen Liste ein Frühwarnsystem, das genau die Meldepflichten aus Art. 14 bedienbar macht.

     

    Der Support-Zeitraum: wie lange Sie liefern müssen

    Eine der praktisch folgenreichsten Vorgaben betrifft den Support-Zeitraum. Der Hersteller muss festlegen, wie lange er Sicherheitsupdates bereitstellt, und diesen Zeitraum an der realistisch erwarteten Nutzungsdauer des Produkts ausrichten. Als Faustregel gilt ein Zeitraum von mindestens fünf Jahren — kürzer nur, wenn das Produkt erkennbar für eine kürzere Nutzung bestimmt ist.

    Das Ende des Support-Zeitraums muss bereits zum Kaufzeitpunkt klar angegeben werden, mindestens mit Monat und Jahr. Für die Produktplanung heißt das, Update-Fähigkeit und Wartungsbudget über Jahre einzukalkulieren — eine Verpflichtung, die weit über den Verkaufsmoment hinausreicht.

     

    Wie weise ich die Konformität nach?

    Die Anforderungen aus Anhang I zu erfüllen ist das eine — sie belegen zu können das andere. Der CRA verlangt einen durchgängigen Nachweis, der auf drei Säulen ruht.

    1. Risikobewertung und technische Dokumentation. Grundlage ist eine dokumentierte Cybersicherheits-Risikobewertung, aus der hervorgeht, welche Anforderungen aus Anhang I für das Produkt gelten und wie sie umgesetzt wurden. Sie fließt in die technische Dokumentation ein, deren Mindestinhalt Anhang VII vorgibt: Produktbeschreibung, Design- und Entwicklungsinformationen, Bewertung der grundlegenden Anforderungen, SBOM und Angaben zum Support-Zeitraum. Diese Unterlagen sind mindestens zehn Jahre nach dem Inverkehrbringen — oder für die Dauer des Support-Zeitraums, je nachdem was länger ist — für die Marktüberwachungsbehörden bereitzuhalten.

    2. Konformitätsbewertung. Anschließend wird die Übereinstimmung mit den Anforderungen in einem geregelten Verfahren bewertet. Welches Verfahren zulässig ist, hängt von der Risikoklasse des Produkts ab:

    Produktkategorie Zulässiges Bewertungsverfahren
    Standardprodukte (nicht gesondert gelistet) Interne Selbstbewertung (Modul A) durch den Hersteller ausreichend.
    Wichtige Produkte, Klasse I (Anhang III) Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen oder eines Cybersicherheitsschemas; sonst notifizierte Stelle.
    Wichtige Produkte, Klasse II (Anhang III) Verpflichtende Drittprüfung durch eine notifizierte Stelle.
    Kritische Produkte (Anhang IV) Gegebenenfalls europäisches Cybersicherheits-Zertifizierungsschema erforderlich.

    3. EU-Konformitätserklärung und CE-Kennzeichnung. Ist die Bewertung positiv, stellt der Hersteller die EU-Konformitätserklärung aus (Muster in Anhang V) und bringt die CE-Kennzeichnung an. Erst sie signalisiert, dass das Produkt die Anforderungen des CRA und aller weiteren einschlägigen EU-Vorschriften erfüllt. Wie sich diese Nachweisschritte in einen Gesamtfahrplan einordnen, zeigt der Leitfaden zur CRA-Umsetzung in klaren Schritten.

     

    Meldepflichten nach Art. 14 als laufende Betriebspflicht

    Anhang I regelt Produkt und Prozesse — die Meldepflichten nach Art. 14 kommen als eigenständige Betriebspflicht hinzu und greifen früher als die Vollanwendung: bereits ab dem 11.09.2026. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gestaffelt nach Fristen an das CSIRT ihres Hauptniederlassungs-Mitgliedstaats und an die EU-Agentur ENISA melden.

    Frist Meldung bei aktiv ausgenutzter Schwachstelle
    24 Stunden Frühwarnung an CSIRT und ENISA.
    72 Stunden Vollständigere Meldung mit ersten Bewertungen und, soweit verfügbar, Korrekturmaßnahmen.
    14 Tage Abschlussbericht, nachdem eine Korrektur- oder Abhilfemaßnahme bereitsteht.

    Für schwerwiegende Sicherheitsvorfälle gilt dieselbe 24- und 72-Stunden-Taktung, der Abschlussbericht ist hier binnen eines Monats fällig. Diese enge Taktung macht das Schwachstellenmanagement aus Teil II zum operativen Bereitschaftsprozess — 24 Stunden lassen keinen Raum für erst dann aufzubauende Strukturen.

     

    Hersteller, Importeur, Händler: wer trägt welche Pflicht?

    Die Hauptlast trägt der Hersteller, doch der CRA nimmt die gesamte Lieferkette in die Verantwortung. Wer als Importeur oder Händler ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt rechtlich selbst als Hersteller und übernimmt dessen volle Pflichten aus Art. 13 und 14.

    Rolle Kernpflichten
    Hersteller Anhang I erfüllen, Risikobewertung und technische Dokumentation erstellen, Konformitätsbewertung durchführen, CE anbringen, Support-Zeitraum festlegen, Schwachstellen behandeln und melden.
    Importeur Nur konforme Produkte in Verkehr bringen; prüfen, dass Konformitätsbewertung, CE-Kennzeichnung, EU-Konformitätserklärung und Dokumentation vorliegen; Risiken an Hersteller und Behörden melden.
    Händler Mit gebotener Sorgfalt prüfen, dass CE-Kennzeichnung und erforderliche Unterlagen vorhanden sind; keine erkennbar nicht-konformen Produkte bereitstellen; bei Kenntnis von Schwachstellen informieren.

     

    Von der Anforderung zum Prozess: Annex I über ein ISMS abdecken

    Bei genauem Hinsehen sind viele Annex-I-Pflichten keine reinen Produktthemen, sondern Managementaufgaben: dokumentiertes Schwachstellenmanagement, gepflegte Komponenten- und Asset-Übersicht, definierte Verantwortlichkeiten, wiederkehrende Tests, nachvollziehbare Risikobewertungen und belastbare Nachweise. Genau das ist der Gegenstand eines Informationssicherheits-Managementsystems (ISMS).

    Ein ISMS — etwa nach ISO 27001 — liefert die Struktur, um diese Pflichten nicht als lose Einzelmaßnahmen, sondern als ineinandergreifende, auditierbare Prozesse zu betreiben. Das Schwachstellenmanagement aus Teil II deckt sich weitgehend mit der ISO-Control zur Handhabung technischer Schwachstellen; Dokumentation und Risikobewertung sind ohnehin Kern jedes Managementsystems. Wer bereits ein ISMS betreibt, fängt für den CRA nicht bei null an, sondern erweitert seine vorhandenen Prozesse gezielt um die produktbezogenen Anforderungen.

    Genau an dieser Schnittstelle setzt die CRA-Compliance-Beratung von TrustSpace an: Sie verbindet die Anforderungen aus Anhang I mit einem strukturierten Managementsystem, sodass Nachweisführung, Schwachstellenprozess und Meldepflichten aus einer Hand belegbar werden — statt in verstreuten Dokumenten und Ad-hoc-Reaktionen.

     

    TrustSpace Profi-Tipp: mit der Risikobewertung starten, nicht mit der Checkliste

    Viele Unternehmen arbeiten Anhang I als Abhakliste von oben nach unten ab. Wirksamer ist der umgekehrte Weg: zuerst die Cybersicherheits-Risikobewertung für das konkrete Produkt, denn sie bestimmt, welche Anforderungen in welcher Tiefe greifen. Aus ihr leiten sich Maßnahmen, Konformitätsroute und Support-Zeitraum ab — und der Aufwand fließt dorthin, wo das Risiko tatsächlich liegt.

     

    Fazit: Anhang I ist die To-do-Liste des CRA

    Der Cyber Resilience Act wirkt umfangreich, doch die eigentlichen Pflichten lassen sich auf einen klaren Kern eindampfen. Anhang I Teil I definiert, wie das Produkt beschaffen sein muss: sicher konfiguriert, frei von bekannten Lücken, aktualisierbar, verschlüsselt, mit minimierter Angriffsfläche. Teil II definiert den Prozess dahinter: Schwachstellen dokumentieren, beheben, offenlegen und über den Support-Zeitraum begleiten, gestützt auf eine aktuelle SBOM.

    Nachgewiesen wird all das über Risikobewertung, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung, ergänzt um die laufenden Meldepflichten nach Art. 14. Wer diese Anforderungen nicht als Einzelaufgaben, sondern als zusammenhängenden, in ein Managementsystem eingebetteten Prozess versteht, verwandelt eine regulatorische Pflicht in einen belastbaren Nachweis von Produktsicherheit — und erspart sich die Hektik, kurz vor der Vollanwendung am 11.12.2027 Strukturen aufzubauen, die längst hätten laufen sollen.

     

    Häufige Fragen (FAQ)

    Was steht konkret in Annex I des Cyber Resilience Act?

    Anhang I enthält die grundlegenden Cybersicherheitsanforderungen des CRA in zwei Teilen. Teil I beschreibt sicherheitsbezogene Produkteigenschaften wie sichere Standardkonfiguration, Verschlüsselung, minimierte Angriffsfläche und die Freiheit von bekannten ausnutzbaren Schwachstellen. Teil II beschreibt acht Prozessanforderungen zur Schwachstellenbehandlung, darunter die Erstellung einer SBOM, die unverzügliche Behebung von Schwachstellen und kostenlose Sicherheitsupdates.

    Was ist eine SBOM und warum verlangt der CRA sie?

    Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten und Abhängigkeiten eines Produkts. Anhang I Teil II verlangt sie, damit Hersteller jederzeit nachvollziehen können, welche Komponente von einer neu bekannt gewordenen Schwachstelle betroffen ist. Gängige Formate sind CycloneDX und SPDX; die Liste muss über den gesamten Support-Zeitraum aktuell gehalten werden.

    Wie weise ich die Einhaltung der CRA-Anforderungen nach?

    Der Nachweis ruht auf einer dokumentierten Risikobewertung, der technischen Dokumentation nach Anhang VII, einer Konformitätsbewertung, der EU-Konformitätserklärung und der CE-Kennzeichnung. Je nach Risikoklasse des Produkts genügt eine Selbstbewertung oder es ist die Prüfung durch eine notifizierte Stelle erforderlich. Die Unterlagen sind mindestens zehn Jahre bereitzuhalten.

    Gelten die CRA-Pflichten auch für Importeure und Händler?

    Ja. Importeure dürfen nur konforme Produkte in Verkehr bringen und müssen prüfen, dass CE-Kennzeichnung, Konformitätserklärung und Dokumentation vorliegen. Händler prüfen mit gebotener Sorgfalt das Vorhandensein der CE-Kennzeichnung und der Unterlagen. Wer ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt als Hersteller und trägt dessen volle Pflichten.

    Ab wann gelten die Meldepflichten nach Art. 14?

    Die Meldepflichten greifen ab dem 11.09.2026 und damit vor der Vollanwendung des CRA am 11.12.2027. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle sind binnen 24 Stunden als Frühwarnung, binnen 72 Stunden als Meldung und mit Abschlussbericht (14 Tage bei Schwachstellen, ein Monat bei Vorfällen) an das zuständige CSIRT und an ENISA zu melden.

  • Cyber Resilience Act Fristen & Zeitplan: Diese Deadlines zählen

    Cyber Resilience Act Fristen & Zeitplan: Diese Deadlines zählen

    Das Wichtigste in Kürze

    • Rechtsgrundlage: Der Cyber Resilience Act (Verordnung (EU) 2024/2847, deutsch Cyberresilienz-Verordnung) ist am 10. Dezember 2024 in Kraft getreten und gilt EU-weit unmittelbar, ganz ohne nationale Umsetzung.
    • Drei entscheidende Stichtage: 11. Juni 2026 (Regelungen zu notifizierten Stellen), 11. September 2026 (Melde- und Berichtspflichten nach Art. 14) und 11. Dezember 2027 (Vollanwendung aller übrigen Pflichten).
    • 24-Stunden-Meldepflicht ab 11.09.2026: Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung an den zuständigen CSIRT und die ENISA melden.
    • Vollanwendung ab 11.12.2027: Ab diesem Tag greifen CE-Kennzeichnung, Konformitätsbewertung, grundlegende Sicherheitsanforderungen und die technische Dokumentation.
    • Handlungsdruck: Wer 2027 konform sein will, muss 2026 starten. Gap-Analyse, Security by Design, Dokumentation und Konformitätsbewertung brauchen realistisch zwölf bis achtzehn Monate Vorlauf.

     

    Der Cyber Resilience Act ist keine ferne Ankündigung mehr, sondern ein laufender Countdown. Die Verordnung ist bereits in Kraft, und die erste harte Frist greift in wenigen Wochen: Ab dem 11. September 2026 gilt die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen. Damit ist der CRA für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen keine Frage des Ob mehr, sondern des Wann und Wie schnell. Wer die Stichtage kennt und rückwärts plant, behält die Kontrolle. Wer wartet, gerät unter Zeitdruck bei einem Vorhaben, das sich nicht in Wochen erledigen lässt.

    Dieser Beitrag ordnet die Fristen des Cyber Resilience Act chronologisch, erklärt für jeden Stichtag konkret, was gilt und wer handeln muss, und rechnet vor, warum der Startpunkt für die meisten Unternehmen im Jahr 2026 liegt. Einen vollständigen Überblick zum Cyber Resilience Act mit Scope, Produktklassen und Sanktionen finden Sie auf unserer Themenseite. Hier steht der Zeitplan im Mittelpunkt.

     

    Cyber Resilience Act: Ab wann gilt was?

    Der Cyber Resilience Act ist am 20. November 2024 im Amtsblatt der EU veröffentlicht worden und zwanzig Tage später, am 10. Dezember 2024, in Kraft getreten. Damit begann die gestaffelte Übergangsfrist. Anders als bei einer Richtlinie mussten die Mitgliedstaaten den CRA nicht erst in nationales Recht überführen: Als Verordnung gilt er in allen 27 EU-Staaten unmittelbar und einheitlich. Für Unternehmen heißt das, dass die Termine fest stehen und nicht von einer nationalen Umsetzung abhängen.

    Die Verordnung wird nicht auf einen Schlag wirksam, sondern in drei Stufen. Diese Staffelung ist bewusst gewählt: Zuerst muss die Infrastruktur für die Konformitätsbewertung stehen, dann greifen die Meldepflichten, und erst am Ende folgt die volle Produktverantwortung. Die folgende Timeline zeigt die vier zentralen Daten im Überblick.

    Datum Was gilt ab diesem Tag Wer muss handeln
    10.12.2024 Der Cyber Resilience Act tritt in Kraft, die Übergangsfrist beginnt. Alle Wirtschaftsakteure: Der Countdown läuft, die Vorbereitung sollte anlaufen.
    11.06.2026 Die Regelungen zu notifizierten Stellen (Kapitel IV) gelten. Konformitätsbewertungsstellen können benannt werden; Hersteller kritischer Produkte sichern sich Prüfkapazität.
    11.09.2026 Die Melde- und Berichtspflichten nach Art. 14 gelten. Hersteller: 24-Stunden-Frühwarnung an CSIRT und ENISA bei aktiv ausgenutzten Schwachstellen und schweren Vorfällen.
    11.12.2027 Vollanwendung aller übrigen Pflichten des Cyber Resilience Act. Hersteller, Importeure und Händler: CE-Kennzeichnung, Konformitätsbewertung, grundlegende Anforderungen, Dokumentation.

    Ob und wie stark diese Termine Sie treffen, hängt von Ihrer Rolle in der Lieferkette ab. Der erste Schritt zur Einordnung ist deshalb die Frage, wer vom Cyber Resilience Act betroffen ist: vom Hersteller physischer Geräte mit Software über den Anbieter reiner Softwareprodukte bis zum Importeur, der Produkte aus Drittländern in den EU-Markt bringt.

     

    11. Juni 2026: Die notifizierten Stellen gehen an den Start

    Der erste operative Stichtag betrifft nicht die Hersteller direkt, ist für sie aber trotzdem wichtig. Ab dem 11. Juni 2026 gelten die Vorschriften des Kapitels IV zur Benennung von Konformitätsbewertungsstellen. Das sind die unabhängigen Prüforganisationen, die bei bestimmten Produktkategorien die Konformität mit dem CRA bewerten und die dafür von den Mitgliedstaaten offiziell notifiziert, also autorisiert, werden müssen.

    Für Hersteller von Produkten der höheren Risikoklassen, die eine Bewertung durch eine solche Stelle brauchen, ist das ein leises, aber wichtiges Signal: Die Prüfinfrastruktur baut sich erst ab Mitte 2026 auf. Erfahrungsgemäß sind die Kapazitäten notifizierter Stellen zu Beginn knapp und die Nachfrage vor einer großen EU-Frist hoch. Wer eine externe Konformitätsbewertung einplanen muss, sollte den Prüfweg früh klären und sich nicht darauf verlassen, kurz vor Ende 2027 noch kurzfristig einen Termin zu bekommen.

     

    11. September 2026: Was die 24-Stunden-Meldepflicht konkret bedeutet

    Der Stichtag mit der höchsten Dringlichkeit ist der 11. September 2026. Ab diesem Tag gelten die Melde- und Berichtspflichten nach Artikel 14 des Cyber Resilience Act, und zwar unabhängig davon, ob die übrigen Produktpflichten schon greifen. Hersteller müssen ab dann zwei Arten von Ereignissen aktiv melden: aktiv ausgenutzte Schwachstellen in ihren Produkten mit digitalen Elementen und schwere Sicherheitsvorfälle, die die Sicherheit dieser Produkte beeinträchtigen.

    Die Meldung folgt einer festen, mehrstufigen Kaskade mit engen Fristen. Sie läuft über eine einheitliche Meldeplattform an den zuständigen nationalen CSIRT (Computer Security Incident Response Team), der die Information zeitgleich der EU-Cybersicherheitsagentur ENISA zur Verfügung stellt:

    • Frühwarnung binnen 24 Stunden: Innerhalb eines Tages, nachdem der Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schweren Vorfall Kenntnis erlangt, muss eine erste Frühwarnung abgesetzt werden.
    • Meldung binnen 72 Stunden: Spätestens nach drei Tagen folgt eine ausführlichere Meldung mit einer ersten Bewertung des Vorfalls und, soweit verfügbar, Angaben zu Korrektur- oder Abhilfemaßnahmen.
    • Abschlussbericht: Bei aktiv ausgenutzten Schwachstellen ist spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme ein Abschlussbericht fällig, bei schweren Vorfällen innerhalb eines Monats.

    Der Kern dieser Regelung ist die 24-Stunden-Frist. Sie zwingt Unternehmen dazu, Erkennung, Bewertung und Meldeweg vorher organisiert zu haben, denn 24 Stunden reichen nicht, um erst im Ernstfall Zuständigkeiten zu klären. Wer bis September 2026 keinen definierten Prozess hat, wer eine relevante Schwachstelle erkennt, wer die Meldung verantwortet und über welchen Kanal sie erfolgt, riskiert im Vorfall einen Fristverstoß. Diese Pflicht greift zudem für Produkte, die bereits im Markt sind, nicht nur für neu in Verkehr gebrachte. Genau deshalb ist der 11. September 2026 für viele Hersteller die eigentlich erste harte CRA-Frist.

     

    TrustSpace Profi-Tipp: Den Meldeprozess vor dem Ernstfall proben

    Ein Meldeprozess, der nur auf dem Papier existiert, hält der 24-Stunden-Frist nicht stand. Definieren Sie vor September 2026 klar, wer eine aktiv ausgenutzte Schwachstelle bewertet, wer die Meldung an den CSIRT freigibt und wer sie technisch absetzt, und halten Sie einen Kontakt- und Eskalationsplan bereit. Ein kurzer Trockenlauf mit einem fiktiven Vorfall zeigt schneller als jede Richtlinie, wo die Kette hakt, und macht aus einer abstrakten Pflicht einen belastbaren Ablauf.

     

    11. Dezember 2027: Die Vollanwendung des Cyber Resilience Act

    Der 11. Dezember 2027 ist der Stichtag, an dem der Cyber Resilience Act in vollem Umfang gilt. Ab diesem Tag dürfen Produkte mit digitalen Elementen nur noch auf dem EU-Markt bereitgestellt werden, wenn sie die grundlegenden Cybersicherheitsanforderungen erfüllen, eine Konformitätsbewertung durchlaufen haben, mit der CE-Kennzeichnung versehen sind und über eine vollständige technische Dokumentation verfügen. Damit wird Cybersicherheit zur Marktzugangsvoraussetzung, vergleichbar mit anderen CE-Anforderungen an die Produktsicherheit.

    Hinter diesem einen Datum steht die Masse der Arbeit. Security by Design über den gesamten Produktlebenszyklus, ein Schwachstellen-Handling mit Bereitstellung von Sicherheitsupdates über einen definierten Supportzeitraum, eine Software-Stückliste (SBOM) und die lückenlose Dokumentation der Sicherheitsmaßnahmen gehören dazu. Welche Pflichten und Anforderungen des CRA im Einzelnen bis zu diesem Termin erfüllt sein müssen, entscheidet maßgeblich über den Aufwand und damit über den nötigen Vorlauf.

     

    Warum Sie 2026 starten müssen, um 2027 konform zu sein

    Bis Dezember 2027 klingt nach viel Zeit. Rechnet man den typischen Projektverlauf jedoch rückwärts, schrumpft der Puffer schnell. Ein CRA-Konformitätsprojekt durchläuft für die meisten Hersteller vier Phasen, die aufeinander aufbauen und sich nur begrenzt parallelisieren lassen:

    • Gap-Analyse und Produktklassifizierung (1 bis 3 Monate): Bestandsaufnahme aller Produkte mit digitalen Elementen, Einordnung in die CRA-Kategorien und Abgleich des Ist-Zustands mit den grundlegenden Anforderungen.
    • Umsetzung von Security by Design und Prozessen (6 bis 12 Monate): technische Anpassungen an den Produkten, Aufbau des Schwachstellen-Handlings, Update-Mechanismen, SBOM-Erstellung und die Verankerung im Entwicklungsprozess.
    • Technische Dokumentation und Nachweise (2 bis 4 Monate, überlappend): Erstellung der technischen Unterlagen, der Risikobewertung und der Konformitätsdokumentation, die den Nachweis der Anforderungen belegen.
    • Konformitätsbewertung und CE-Kennzeichnung (1 bis 3 Monate, ggf. mit externer Stelle): interne Bewertung oder Prüfung durch eine notifizierte Stelle, abschließende Konformitätserklärung und Anbringen der CE-Kennzeichnung.

    In Summe sind das realistisch zwölf bis achtzehn Monate, bei komplexen Produktportfolios oder externer Bewertung eher mehr. Zieht man vom 11. Dezember 2027 diese Dauer ab, landet der sinnvolle Startpunkt spätestens in der ersten Jahreshälfte 2026. Hinzu kommt, dass die 24-Stunden-Meldepflicht ohnehin schon ab September 2026 steht. Wer diesen Prozess aufsetzt, hat einen guten Teil der organisatorischen Grundlagen für die spätere Vollanwendung bereits geschaffen. Beide Fristen sprechen damit für denselben Startzeitpunkt.

     

    TrustSpace Profi-Tipp: Mit der Gap-Analyse beginnen, nicht mit der Technik

    Der häufigste Fehler ist, sofort in einzelne technische Maßnahmen zu springen, ohne den Gesamtstand zu kennen. Wirksamer ist es, zuerst mit einer strukturierten Gap-Analyse zu klären, welche Produkte betroffen sind, in welche CRA-Klasse sie fallen und wo die größten Lücken liegen. Diese Standortbestimmung braucht wenige Wochen, verhindert aber teure Fehlinvestitionen und macht aus einem diffusen Pflichtenberg einen priorisierten, planbaren Fahrplan bis 2027. Eine ISMS-Plattform wie TrustSpaceOS hilft, Anforderungen, Maßnahmen und Nachweise dabei an einem Ort nachvollziehbar zu verwalten.

     

    Bestandsprodukte: Welche Stichtagsregelung gilt

    Eine der häufigsten Fragen betrifft Produkte, die vor dem 11. Dezember 2027 bereits auf dem Markt sind. Hier trennt der Cyber Resilience Act sauber zwischen zwei Pflichtenkreisen. Die grundlegenden Produktanforderungen samt CE-Kennzeichnung und Konformitätsbewertung gelten für ein Bestandsprodukt erst dann, wenn es nach dem Stichtag eine wesentliche Änderung (substantial modification) erfährt, etwa durch ein größeres Funktionsupdate, das die ursprüngliche Konformitätsbewertung berührt. Bleibt ein Produkt unverändert, fällt es nicht rückwirkend unter die volle Produktverantwortung.

    Die Melde- und Berichtspflichten nach Artikel 14 dagegen greifen für alle Produkte, die sich im Verkehr befinden, unabhängig vom Zeitpunkt der Markteinführung. Eine aktiv ausgenutzte Schwachstelle in einem bereits ausgelieferten Produkt muss also ab dem 11. September 2026 gemeldet werden, auch wenn das Produkt lange vor dem CRA in den Markt kam. Zu beachten ist außerdem eine Übergangsregel für Bescheinigungen: EU-Baumusterprüfbescheinigungen und Zulassungsentscheidungen zu Cybersicherheitsanforderungen bleiben bis zum 11. Juni 2028 gültig, sofern sie nicht vorher auslaufen. Die Stichtagsregelung entlastet Bestandsprodukte also bei den Produktanforderungen, nicht aber bei der laufenden Sicherheitsverantwortung.

     

    Fazit: Die Fristen stehen, der Startschuss ist überfällig

    Der Zeitplan des Cyber Resilience Act ist eindeutig und nicht verhandelbar. In Kraft seit dem 10. Dezember 2024, greifen die Regelungen zu notifizierten Stellen ab dem 11. Juni 2026, die 24-Stunden-Meldepflicht ab dem 11. September 2026 und die Vollanwendung ab dem 11. Dezember 2027. Diese vier Daten geben den Takt vor, und der erste operativ spürbare Termin liegt bereits in wenigen Wochen.

    Für Hersteller, Importeure und Händler bedeutet das keinen Grund zur Panik, wohl aber zum Handeln. Wer die Rückwärtsrechnung ernst nimmt, erkennt, dass 2026 das Jahr des Starts ist, nicht 2027. Eine frühe Gap-Analyse, ein belastbarer Meldeprozess vor September 2026 und ein realistischer Projektplan bis zur Vollanwendung verwandeln einen abstrakten Countdown in ein steuerbares Vorhaben. Die Fristen kommen ohnehin. Wer sie kennt und rückwärts plant, entscheidet selbst über das Tempo.

     

    Häufige Fragen (FAQ)

    Ab wann gilt der Cyber Resilience Act?

    Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Er gilt jedoch gestaffelt: Die Regelungen zu notifizierten Stellen greifen ab dem 11. Juni 2026, die Melde- und Berichtspflichten nach Artikel 14 ab dem 11. September 2026 und die vollständigen Produktpflichten ab dem 11. Dezember 2027.

    Was passiert am 11. September 2026?

    Ab dem 11. September 2026 gelten die Meldepflichten nach Artikel 14. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung an den zuständigen CSIRT und die ENISA melden, gefolgt von einer ausführlicheren Meldung nach 72 Stunden und einem Abschlussbericht. Diese Pflicht gilt auch für bereits im Markt befindliche Produkte.

    Muss der Cyber Resilience Act in nationales Recht umgesetzt werden?

    Nein. Der Cyber Resilience Act ist eine EU-Verordnung (Verordnung (EU) 2024/2847) und gilt damit in allen Mitgliedstaaten unmittelbar und einheitlich. Eine gesonderte Umsetzung in deutsches Recht ist nicht erforderlich, die Fristen stehen EU-weit fest.

    Gilt der CRA auch für Produkte, die schon auf dem Markt sind?

    Teilweise. Die grundlegenden Produktanforderungen mit CE-Kennzeichnung greifen für Bestandsprodukte erst, wenn sie nach dem 11. Dezember 2027 eine wesentliche Änderung erfahren. Die Melde- und Berichtspflichten nach Artikel 14 gelten dagegen ab dem 11. September 2026 für alle Produkte im Verkehr, unabhängig vom Zeitpunkt der Markteinführung.

    Warum sollte man mit der CRA-Vorbereitung schon 2026 beginnen?

    Weil ein Konformitätsprojekt aus Gap-Analyse, Umsetzung von Security by Design, technischer Dokumentation und Konformitätsbewertung realistisch zwölf bis achtzehn Monate dauert. Zieht man diese Dauer vom Stichtag 11. Dezember 2027 ab, liegt der sinnvolle Startpunkt in der ersten Jahreshälfte 2026, zumal die Meldepflicht ohnehin bereits ab September 2026 gilt.

  • Wen betrifft der Cyber Resilience Act? Betroffenheit in 5 Minuten prüfen

    Wen betrifft der Cyber Resilience Act? Betroffenheit in 5 Minuten prüfen

    Das Wichtigste in Kürze

    • Wer betroffen ist: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) gilt für alle, die „Produkte mit digitalen Elementen” auf dem EU-Markt bereitstellen, also Hardware und Software mit direkter oder indirekter Datenverbindung zu einem Gerät oder Netz.
    • Welche Rollen zählen: Pflichten treffen Hersteller, Importeure und Händler unterschiedlich stark, dazu kommt die neue Sonderrolle des Open-Source-Software-Verwalters (Steward).
    • Nicht kommerziell = außen vor: Produkte, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt werden, fallen nicht unter den CRA.
    • Sektor-Ausnahmen: Bereits reguliert und damit ausgenommen sind unter anderem Medizinprodukte, Kraftfahrzeuge, zivile Luftfahrt und Schiffsausrüstung; reine Cloud-Dienste (SaaS) fallen ebenfalls nicht direkt darunter.
    • Bestandsschutz: Produkte, die vor dem 11.12.2027 auf den Markt kamen, unterliegen dem CRA erst, wenn sie danach wesentlich verändert werden.
    • Fristen: In Kraft seit 10.12.2024, Meldepflichten ab 11.09.2026, volle Anwendung ab 11.12.2027.

     

    Kaum eine EU-Regulierung hat 2026 so viele Hersteller und Händler verunsichert wie der Cyber Resilience Act. Die Frage, die sich fast jedes Unternehmen mit einem vernetzten Produkt zuerst stellt, ist einfach: Bin ich überhaupt betroffen? Die Antwort entscheidet darüber, ob ab Ende 2027 erheblicher Aufwand für Konformitätsbewertung, Dokumentation und Schwachstellenbehandlung ansteht oder ob das Angebot in eine Ausnahme fällt. Wer sie falsch einschätzt, riskiert im schlimmsten Fall Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

    Dieser Leitfaden beantwortet die Betroffenheitsfrage systematisch und führt Sie mit einer klaren Prüf-Logik in fünf Schritten durch die Selbsteinordnung. Wenn Sie die Bewertung anschließend rechtssicher absichern oder Ihre Pflichten priorisieren wollen, hilft eine spezialisierte Cyber Resilience Act Beratung für Hersteller und Händler dabei, den konkreten Handlungsbedarf für Ihr Portfolio zu bestimmen.

     

    Was ist der Cyber Resilience Act?

    Der Cyber Resilience Act, deutsch auch Cyberresilienz-Verordnung, ist mit der Verordnung (EU) 2024/2847 das erste horizontale EU-Gesetz, das verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen über deren gesamten Lebenszyklus stellt. „Horizontal” bedeutet, dass er nicht auf eine einzelne Branche zielt, sondern grundsätzlich alle vernetzten Produkte erfasst, vom smarten Türschloss bis zur Softwarebibliothek.

    Als Verordnung gilt der CRA EU-weit unmittelbar, ohne nationale Umsetzung und in allen Mitgliedstaaten identisch. In Kraft ist er seit dem 10. Dezember 2024, die zentralen Pflichten greifen gestaffelt bis zur vollen Anwendung am 11. Dezember 2027. Genau deshalb lohnt sich die Betroffenheitsprüfung jetzt: Die Vorlaufzeit ist knapper, als sie wirkt.

     

    Für wen gilt der Cyber Resilience Act?

    Der Anwendungsbereich des CRA ist bewusst weit gefasst. Erfasst wird jedes Produkt mit digitalen Elementen, das im Rahmen einer Geschäftstätigkeit auf dem Unionsmarkt bereitgestellt wird, nicht nur bei klassischen IT-Herstellern, sondern bei praktisch jedem Anbieter vernetzter Produkte. Ob Ihr Unternehmen betroffen ist, hängt an zwei Fragen: Handelt es sich um ein Produkt mit digitalen Elementen, und welche Rolle nehmen Sie in der Lieferkette ein?

    Was ist ein „Produkt mit digitalen Elementen”?

    Der CRA definiert ein Produkt mit digitalen Elementen als ein Software- oder Hardware-Produkt einschließlich seiner Fern-Datenverarbeitungslösungen. Das entscheidende Kriterium: Die bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung schließt eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz ein. Diese Definition ist absichtlich breit und deckt sowohl fertige Produkte als auch Komponenten ab, die separat auf den Markt gebracht werden.

    Ein häufig übersehener Punkt sind die sogenannten Fern-Datenverarbeitungslösungen. Eine Datenverarbeitung aus der Ferne, ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte und die vom Hersteller oder unter seiner Verantwortung entwickelt wurde, gilt als Teil des Produkts und fällt in den Anwendungsbereich. Ein reiner Cloud-Dienst, der eigenständig als Software as a Service angeboten wird, ist dagegen kein Produkt mit digitalen Elementen und wird nicht vom CRA erfasst. Die Grenze verläuft also nicht bei „Cloud ja oder nein”, sondern bei der Frage, ob die Fernverarbeitung fester Bestandteil der Produktfunktion ist.

    Welche Rollen die Verordnung kennt

    Der CRA verteilt die Pflichten entlang der Lieferkette. Welche Anforderungen konkret gelten, hängt davon ab, welche Rolle ein Unternehmen für ein bestimmtes Produkt einnimmt:

    • Hersteller: Trägt die Hauptlast. Er muss Produkte sicher entwerfen (Security by Design), über den gesamten Lebenszyklus eine Cybersicherheits-Risikobewertung führen, technische Dokumentation und Konformitätsbewertung erstellen, die CE-Kennzeichnung anbringen und Schwachstellen im Supportzeitraum behandeln.
    • Importeur: In der EU niedergelassene Person, die ein Produkt eines außerhalb der EU ansässigen Herstellers auf den Markt bringt. Er darf nur konforme Produkte in Verkehr bringen und prüft vorab, dass Konformitätsbewertung, CE-Kennzeichnung und Dokumentation vorliegen.
    • Händler: Jeder weitere Akteur in der Lieferkette, der ein Produkt bereitstellt, ohne seine Eigenschaften zu verändern. Er handelt mit gebotener Sorgfalt und prüft, ob CE-Kennzeichnung und Unterlagen vorhanden sind.
    • Open-Source-Software-Verwalter (Steward): Eine juristische Person, die die Entwicklung bestimmter, für kommerzielle Tätigkeiten bestimmter Open-Source-Software nachhaltig und systematisch unterstützt. Sie trifft ein abgestufter, leichterer Pflichtenkatalog (Cybersicherheitspolitik, Meldung von Schwachstellen und Vorfällen), Bußgelder sind für Steward-Verstöße ausgeschlossen.

    Wichtig ist die Umkehrregel: Wer als Importeur oder Händler ein Produkt unter eigenem Namen oder eigener Marke anbietet oder es wesentlich verändert, gilt selbst als Hersteller und trägt dessen volle Pflichten. Ein „nur Wiederverkäufer” wird so schneller zum Hersteller im Sinne des CRA, als vielen bewusst ist.

     

    Betroffenheit in 5 Schritten prüfen

    Ob der CRA für ein konkretes Produkt gilt, lässt sich mit fünf aufeinander aufbauenden Fragen einordnen. Ein „Nein” beendet die Prüfung meist mit dem Ergebnis „nicht betroffen”.

    Schritt 1: Hat Ihr Produkt digitale Elemente?

    Enthält Ihr Produkt Software, Firmware oder eine sonstige digitale Komponente? Reine mechanische Erzeugnisse ohne jede Software fallen nicht darunter. Sobald Code im Spiel ist, ist das erste Kriterium erfüllt.

    Schritt 2: Besteht eine Datenverbindung zu Gerät oder Netz?

    Umfasst die bestimmungsgemäße oder vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem anderen Gerät oder einem Netzwerk? Diese Hürde ist niedrig: Auch eine indirekte Verbindung, etwa über eine Schnittstelle oder ein anderes Produkt, genügt. Vollständig isolierte Geräte sind die seltene Ausnahme.

    Schritt 3: Bringen Sie das Produkt auf dem EU-Markt in Verkehr?

    Wird das Produkt im Rahmen einer Geschäftstätigkeit auf dem Unionsmarkt bereitgestellt? Der CRA gilt marktbezogen, nicht sitzbezogen: Auch ein Hersteller außerhalb der EU ist betroffen, sobald sein Produkt auf dem EU-Markt angeboten wird. Nicht kommerziell bereitgestellte Produkte fallen heraus.

    Schritt 4: Greift eine Sektor-Ausnahme?

    Ist Ihr Produkt bereits durch eine sektorspezifische EU-Regulierung abgedeckt, etwa als Medizinprodukt, Kraftfahrzeug, Luftfahrterzeugnis oder Schiffsausrüstung? Dann ist es vom CRA ausgenommen, weil die Cybersicherheit dort bereits geregelt ist. Ohne einschlägige Ausnahme bleibt es im Scope.

    Schritt 5: Welche Rolle nehmen Sie ein?

    Sind Sie Hersteller, Importeur oder Händler, und bieten Sie das Produkt unter eigenem Namen an oder verändern es wesentlich? Diese Antwort bestimmt nicht mehr das Ob, sondern das Ausmaß Ihrer Pflichten. Wer unter eigener Marke auftritt oder substanziell modifiziert, rutscht in die Herstellerrolle mit den weitreichendsten Anforderungen.

     

    Um diese fünf Schritte noch schneller durchzugehen, stellen wir an dieser Stelle in Kürze einen interaktiven Betroffenheitschecker bereit. Er führt Sie mit wenigen Fragen durch die Prüf-Logik und gibt eine erste Einordnung, ob und in welcher Rolle Ihr Produkt unter den Cyber Resilience Act fällt. Bis dahin helfen die folgenden Produktbeispiele und Ausnahmen bei der Einordnung.

     

    Betroffene und nicht betroffene Produkte im Vergleich

    Die abstrakte Definition wird an konkreten Beispielen greifbarer. Die folgende Übersicht zeigt typische Produkte, die klar in den Anwendungsbereich fallen, und solche, die durch eine Ausnahme oder mangels digitaler Elemente außen vor bleiben.

    Vom CRA erfasst Nicht (direkt) erfasst
    Smart-Home-Geräte (Kameras, Türschlösser, Thermostate) Medizinprodukte (geregelt über Verordnung (EU) 2017/745)
    Laptops, Smartphones, Router und Netzwerktechnik Kraftfahrzeuge (geregelt über Verordnung (EU) 2019/2144)
    Betriebssysteme, Firewalls, VPN-Software Zivile Luftfahrterzeugnisse (Verordnung (EU) 2018/1139)
    Industrielle Steuerungssysteme und IoT-Sensorik Schiffsausrüstung (Richtlinie 2014/90/EU)
    Mobile Apps, Firmware, Software-Bibliotheken und SDKs Eigenständige SaaS-/Cloud-Dienste (fallen unter NIS 2)
    Passwortmanager und Antivirensoftware Nicht kommerzielle, quelloffene Software

    Die rechte Spalte ist kein Freibrief. Wird eine Komponente, die für ein ausgenommenes Produkt bestimmt ist, separat auf den Markt gebracht, kann sie für sich genommen wieder in den Anwendungsbereich fallen. Und eine Sektor-Ausnahme heißt nicht, dass keine Cybersicherheitspflichten bestehen, sondern nur, dass sie aus einem anderen Rechtsakt kommen.

     

    Die wichtigsten Ausnahmen im Detail

    Der Anwendungsbereich ist weit, die Ausnahmen sind eng und klar definiert. Wer sich auf eine beruft, sollte deren Grenzen genau kennen.

    Bereits regulierte Sektoren

    Produkte, deren Cybersicherheit schon durch spezifische EU-Rechtsakte geregelt ist, nimmt der CRA aus, um Doppelregulierung zu vermeiden. Dazu zählen Medizinprodukte und In-vitro-Diagnostika (Verordnungen (EU) 2017/745 und 2017/746), Kraftfahrzeuge (Verordnung (EU) 2019/2144), zivile Luftfahrt (Verordnung (EU) 2018/1139) und Schiffsausrüstung (Richtlinie 2014/90/EU). Ebenfalls ausgenommen sind Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder der Verteidigung entwickelt werden, sowie Produkte zur Verarbeitung von Verschlusssachen.

    Software as a Service und Open-Source

    Reine SaaS-Angebote sind keine Produkte mit digitalen Elementen und werden von der NIS-2-Richtlinie erfasst; erst eine fest ins Produkt integrierte Fern-Datenverarbeitung fällt unter den CRA. Ähnlich abgestuft ist Open Source: Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, fällt nicht unter den CRA. Erst der Vertrieb im Rahmen einer kommerziellen Tätigkeit löst Pflichten aus, und selbst dann in reduzierter Form. Für die neue Rolle des Open-Source-Software-Verwalters gelten leichtere Anforderungen, Bußgelder sind für sie ausdrücklich ausgeschlossen.

     

    TrustSpace Profi-Tipp: Betroffenheit je Produkt, nicht je Unternehmen

    Die Betroffenheit wird nicht pauschal für das Unternehmen, sondern für jedes einzelne Produkt und jede Rolle bestimmt. Ein Mittelständler kann für sein vernetztes Gerät Hersteller sein, für eine importierte Zusatzkomponente Importeur und für eine ausgenommene Medizinprodukt-Variante gar nicht betroffen. Legen Sie deshalb früh ein Produktinventar an, das je Position Produktart, Rolle und mögliche Ausnahme festhält. Diese Matrix ist die Grundlage jeder späteren Konformitätsplanung.

     

    Besonderheiten für KMU und kleine Hersteller

    Der CRA nimmt kleine und mittlere Unternehmen nicht vom Anwendungsbereich aus, mildert aber an mehreren Stellen die Last. Kleinstunternehmen und kleine Unternehmen dürfen zum Beispiel nicht mit einem Bußgeld belegt werden, wenn sie die 24-Stunden-Frist für die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle verfehlen. Für „wichtige” Produkte, die sonst eine Drittprüfung verlangen, können Open-Source-Hersteller unter Umständen die Selbstbewertung nutzen, sofern sie die technische Dokumentation öffentlich machen.

    Darüber hinaus verpflichtet die Verordnung Behörden und Mitgliedstaaten, KMU durch Leitlinien und vereinfachte Dokumentation zu entlasten. Der Grundsatz der Verhältnismäßigkeit zieht sich durch: Der Aufwand soll zur Unternehmensgröße und zum Produktrisiko passen. Die grundlegenden Sicherheitsanforderungen und die Konformitätsbewertung entfallen für KMU aber nicht, sie sind lediglich pragmatischer ausgestaltet.

     

    Bestandsschutz: Was gilt für Produkte vor dem Stichtag?

    Eine der häufigsten Sorgen betrifft das bestehende Portfolio. Hier gibt die Verordnung Entwarnung mit einer klaren Übergangsregel: Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 auf den Markt gebracht wurden, unterliegen dem CRA nur dann, wenn sie ab diesem Datum wesentlich verändert werden. Ein unverändert weiterlaufendes Bestandsprodukt muss also nicht nachträglich CRA-konform gemacht werden.

    Der entscheidende Begriff ist die „wesentliche Änderung”. Ein sicherheitsrelevantes Funktionsupdate oder ein spürbarer Eingriff in Konzeption und Zweck kann die volle CRA-Pflicht auslösen, ein reines Sicherheits-Patch dagegen in der Regel nicht. Wer den Support für ein Bestandsprodukt über 2027 hinaus plant, sollte diese Grenze im Änderungsmanagement beobachten. Wie sich diese und die übrigen Stichtage staffeln, zeigt unsere Übersicht über alle Fristen und Deadlines des Cyber Resilience Act im Detail.

    Steht Ihre Betroffenheit fest, folgt die geordnete Umsetzung, von der Risikobewertung über die technische Dokumentation bis zur Konformitätsbewertung. Eine strukturierte Roadmap zur CRA-Umsetzung hilft dabei, die verbleibende Zeit bis zur vollen Anwendung sinnvoll einzuteilen.

     

    Fazit: Erst einordnen, dann umsetzen

    Der Cyber Resilience Act ist bewusst breit angelegt, und die meisten Unternehmen, die vernetzte Hardware oder Software kommerziell anbieten, fallen darunter. Die eigentliche Kunst liegt nicht in der Ja-Nein-Frage, sondern in der präzisen Einordnung: Produkt mit digitalen Elementen, greift eine der eng gefassten Sektor-Ausnahmen, und welche Rolle nehmen Sie in der Lieferkette ein? Die fünf Prüfschritte liefern dafür einen verlässlichen roten Faden.

    Weil die Betroffenheit je Produkt und je Rolle unterschiedlich ausfällt, ist ein sauberes Produktinventar die beste Vorbereitung. Wer jetzt einordnet, gewinnt Vorlaufzeit bis zur vollen Anwendung am 11. Dezember 2027 und vermeidet, dass aus einer unterschätzten Pflicht ein teures Bußgeldrisiko wird. Die Betroffenheitsprüfung ist damit der erste Baustein einer belastbaren CRA-Strategie.

     

    Häufige Fragen (FAQ)

    Gilt der Cyber Resilience Act auch für Unternehmen außerhalb der EU?

    Ja. Der CRA ist marktbezogen, nicht sitzbezogen. Ein Hersteller mit Sitz außerhalb der EU ist betroffen, sobald sein Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird. In diesem Fall übernimmt häufig ein in der EU niedergelassener Importeur zusätzliche Prüfpflichten, bevor das Produkt in Verkehr gebracht werden darf.

    Fällt reine Software auch unter den CRA?

    Ja. Der Anwendungsbereich umfasst ausdrücklich Software, sofern sie eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz vorsieht. Das schließt Betriebssysteme, Anwendungen, mobile Apps, Firmware sowie separat vertriebene Bibliotheken und SDKs ein. Nur eigenständige Cloud-Dienste (SaaS) und nicht kommerzielle Open-Source-Software bleiben außen vor.

    Ist mein SaaS-Produkt vom Cyber Resilience Act betroffen?

    Ein rein als Cloud-Dienst angebotenes SaaS-Produkt ist kein Produkt mit digitalen Elementen und daher nicht direkt vom CRA erfasst, sondern eher von der NIS-2-Richtlinie. Anders liegt der Fall, wenn eine Cloud-Funktion als Fern-Datenverarbeitungslösung fest zu einem Gerät oder einer Anwendung gehört: Dann gilt sie als Teil des Produkts und ist mit reguliert.

    Müssen bestehende Produkte nachträglich CRA-konform gemacht werden?

    In der Regel nicht. Produkte, die vor dem 11. Dezember 2027 auf den Markt gebracht wurden, unterliegen dem CRA erst dann, wenn sie ab diesem Datum wesentlich verändert werden. Ein unverändert weiterlaufendes Bestandsprodukt genießt Bestandsschutz. Ein sicherheitsrelevantes Funktionsupdate kann die Pflicht jedoch auslösen.

    Was passiert bei Verstößen gegen den Cyber Resilience Act?

    Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für andere Verstöße gelten niedrigere Stufen. Kleinstunternehmen und kleine Unternehmen sind von der Bußgeldpflicht bei verspäteter Meldung ausgenommen.