Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts

Der Aufhänger: Der Router, den niemand mehr repariert

Stell dir einen ganz gewöhnlichen WLAN-Router vor. Er steht in Millionen europäischen Wohnzimmern, macht seit vier Jahren treu seinen Dienst, und irgendwo in seiner Firmware schlummert eine Sicherheitslücke, die ein Angreifer aus der Ferne ausnutzen kann. Der Hersteller weiß davon – oder könnte es wissen. Aber das Gerät wurde als billiges Massenprodukt verkauft, die Marge war dünn, das Entwicklungsteam ist längst mit dem Nachfolgemodell beschäftigt. Ein Sicherheitsupdate? Kostet Geld, bringt keinen zusätzlichen Umsatz und niemand verlangt es rechtlich. Also passiert nichts. Der Router bleibt verwundbar, bis er im Elektroschrott landet – oder bis er Teil eines Botnetzes wird, das ganze Rechenzentren lahmlegt.

Diese Szene beschreibt kein Versagen einzelner Firmen. Sie beschreibt ein Marktversagen. Solange Sicherheit unsichtbar ist, keinen Kaufpreis rechtfertigt und niemand für ihr Fehlen haftet, wird sie systematisch zu wenig produziert. Der Käufer sieht dem Router nicht an, wie sicher er ist; er sieht den Preis, das Design und die Übertragungsrate. Und die Kosten einer schlechten Absicherung trägt am Ende nicht der Hersteller, sondern der gehackte Nutzer, das lahmgelegte Krankenhaus, die überlastete Infrastruktur. Sicherheit ist, in der Sprache der Ökonomen, eine negative Externalität – ein Schaden, den der Verursacher nicht bezahlt.

Genau an diesem Punkt setzt der Cyber Resilience Act an – kurz CRA, offiziell Verordnung (EU) 2024/2847. Er ist der Versuch der EU, Cybersicherheit in die Produkte selbst einzubauen, und zwar bevor sie auf den Markt kommen und über ihre gesamte erwartete Nutzungsdauer hinweg. Der CRA macht aus einer freiwilligen Tugend eine gesetzliche Pflicht: Wer in der EU ein Produkt mit digitalen Elementen verkauft, muss künftig belegen können, dass es sicher entworfen wurde, dass Schwachstellen behandelt werden und dass es für einen definierten Zeitraum Sicherheitsupdates erhält. Das sichtbare Symbol dieser Pflicht ist ein alter Bekannter: die CE-Kennzeichnung, die bisher für elektrische Sicherheit und elektromagnetische Verträglichkeit stand und nun um die Dimension der Cybersicherheit erweitert wird.

Für jemanden wie Sven – Senior AI Engineer mit einem Bein in der Cloud-Architektur und einem in der IT-Sicherheit – ist der CRA aus zwei Richtungen relevant. Als Ingenieur, der Software und vernetzte Systeme baut, definiert der CRA, welche Sicherheitseigenschaften, welche Dokumentation und welche Update-Zusagen ein Produkt haben muss, bevor es die EU-Grenze überschreiten darf. Und als jemand, der Open-Source-Komponenten einsetzt und zu ihnen beiträgt, betrifft ihn eine der heikelsten Fragen der ganzen Verordnung: Wie reguliert man Sicherheit in einer Welt, die auf freiwillig gepflegter, unbezahlter Software gebaut ist? Dieser Artikel nimmt dich auf die ganze Strecke mit: von der Grundidee über den Anwendungsbereich, die Pflichten des Herstellers, die drei Produktklassen und die Meldepflichten bis zu Open Source, Zeitplan und Sanktionen.

Teil 1: Warum der CRA? Zwei Probleme und ein Marktversagen

Die politische Geburtsstunde

Am 15. September 2021 kündigte Kommissionspräsidentin Ursula von der Leyen in ihrer Rede zur Lage der Union einen „Cyber Resilience Act" an. Das Ziel war ehrgeizig: Europa solle in der Cybersicherheit eine Führungsrolle einnehmen. Der Kontext war eine Serie spektakulärer Angriffe mit globaler Reichweite – von Ransomware-Wellen, die Krankenhäuser und Pipelines trafen, bis zu Schwachstellen in weit verbreiteten Software-Bibliotheken, die praktisch das halbe Internet gleichzeitig verwundbar machten. Der Kommissionsvorschlag folgte im September 2022, und nach dem üblichen Gesetzgebungsverfahren zwischen Parlament, Rat und Kommission wurde die Verordnung Ende 2024 verabschiedet.

Die zwei Probleme

Der CRA benennt in seiner Begründung zwei konkrete Probleme, die er lösen will. Das erste ist der niedrige Cybersicherheitsstandard vieler Produkte: Zwei Drittel der Angriffe nutzen bekannte Schwachstellen aus, und ein erheblicher Teil der auf dem Markt befindlichen Produkte enthält solche Lücken. Das zweite ist das Informationsdefizit der Nutzer: Käufer können den Sicherheitszustand eines Produkts weder vor noch nach dem Kauf verlässlich beurteilen und wissen oft nicht einmal, ob und wie lange sie überhaupt Sicherheitsupdates erhalten.

Beide Probleme verweisen auf dieselbe ökonomische Wurzel. Weil Sicherheit unsichtbar ist und ihr Fehlen erst später und woanders Schaden anrichtet, hat kein einzelner Marktteilnehmer den Anreiz, mehr davon zu produzieren, als der Wettbewerb erzwingt. Wer freiwillig in Sicherheit investiert, verteuert sein Produkt gegenüber Konkurrenten, die es nicht tun – und der Käufer belohnt den Unterschied nicht, weil er ihn nicht sieht. Das Ergebnis ist ein Rennen nach unten. Regulierung ist in diesem Bild kein bürokratischer Selbstzweck, sondern der Versuch, eine Untergrenze einzuziehen, unter die niemand mehr fallen darf, damit sich Investitionen in Sicherheit nicht länger als Wettbewerbsnachteil auswirken.

Der Hebel: das Produkt, nicht die Organisation

Der entscheidende konzeptionelle Zug des CRA ist die Wahl des Regulierungspunkts. Andere europäische Cybersicherheitsgesetze setzen an der Organisation an: Die NIS2-Richtlinie verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zu einem Sicherheitsmanagement, DORA verpflichtet Finanzunternehmen zu operationaler Resilienz. Der CRA setzt dagegen am Produkt an. Er fragt nicht, ob ein Unternehmen ein Sicherheitsteam hat, sondern ob das konkrete Gerät oder die konkrete Software, die es verkauft, sicher gebaut wurde. Das macht den CRA zur perfekten Ergänzung: NIS2 und DORA sichern die Betreiber ab, der CRA sichert die Bausteine ab, aus denen diese Betreiber ihre Systeme zusammensetzen. Erst zusammen ergibt sich eine durchgängige Kette – vom einzelnen Mikrocontroller bis zur systemrelevanten Bank.

Man nennt den CRA deshalb eine horizontale Verordnung: Sie gilt nicht für eine Branche, sondern quer über alle Produktkategorien hinweg, vom smarten Türschloss über die industrielle Steuerung bis zum Betriebssystem. Und wie DORA ist auch der CRA eine Verordnung, kein Richtlinientext: Er gilt unmittelbar und einheitlich in allen Mitgliedstaaten, ohne dass er erst in nationales Recht übersetzt werden müsste. Das ist ein bewusster Kontrast zur NIS2-Richtlinie, deren nationale Umsetzung in vielen Staaten stockt und die dadurch von Land zu Land unterschiedlich aussieht.

Teil 2: Was ist ein „Produkt mit digitalen Elementen"?

Der CRA gilt für Produkte mit digitalen Elementen (englisch: products with digital elements, kurz PDE). Die Definition ist bewusst weit: Gemeint ist jedes Software- oder Hardwareprodukt samt seiner Datenfernverarbeitungslösungen, dessen bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte, logische oder physische Datenverbindung zu einem Gerät oder Netz einschließt. Vereinfacht: Fast alles, was Software enthält oder ist und irgendwie kommunizieren kann, fällt darunter – vom vernetzten Spielzeug über den Router und die Firewall bis zum Betriebssystem, zur mobilen App und zur Firmware eines Sensors. Auch Komponenten, die separat auf den Markt gebracht werden, sind erfasst; eine Software-Bibliothek, die ein anderer Hersteller einbaut, ist selbst ein Produkt im Sinne des CRA.

Ebenso wichtig ist, was nicht erfasst ist. Der CRA greift nur, wenn ein Produkt „auf dem Markt bereitgestellt" wird, also im Rahmen einer geschäftlichen Tätigkeit geliefert wird. Rein private, nicht kommerzielle Software fällt heraus. Und mehrere Kategorien sind ausgenommen, weil sie bereits durch eigene, sektorspezifische EU-Gesetze abgedeckt sind: Medizinprodukte, Kraftfahrzeuge, die zivile Luftfahrt und bestimmte Bereiche wie militärische oder nationale Sicherheit. Hier gilt wieder das Prinzip lex specialis – das speziellere Gesetz geht vor, um Doppelregulierung zu vermeiden. Auch reine Cloud-Dienste (Software as a Service) fallen grundsätzlich nicht unter den CRA, sondern werden von NIS2 erfasst – es sei denn, die Datenfernverarbeitung ist ein integraler Bestandteil eines Produkts (etwa die Cloud-Anbindung, ohne die ein smartes Gerät eine seiner Funktionen nicht erfüllen könnte). Diese Grenzziehung zwischen „Produkt" und „Dienst" ist eine der subtileren und in der Praxis umstrittensten Fragen des CRA.

Teil 3: Die Wirtschaftsakteure und die Pflichten des Herstellers

Der CRA verteilt Pflichten entlang der Lieferkette auf vier Wirtschaftsakteure: den Hersteller, den Bevollmächtigten, den Importeur und den Händler. Das Gewicht liegt eindeutig beim Hersteller – der natürlichen oder juristischen Person, die ein Produkt unter ihrem Namen oder ihrer Marke auf den Markt bringt. Importeur und Händler haben vor allem Prüf- und Sorgfaltspflichten: Sie müssen sicherstellen, dass ein Produkt die CE-Kennzeichnung trägt, die geforderten Informationen mitliefert und aus konformer Herstellung stammt, und sie dürfen ein Produkt nicht in Verkehr bringen oder bereitstellen, von dem sie wissen, dass es nicht konform ist.

Der Kern: Sicherheit über den Lebenszyklus

Die zentrale Pflicht des Herstellers steht in Artikel 13 und wird durch die Anhänge – vor allem Anhang I – ausgefüllt. Sie lautet im Kern: Ein Produkt muss über seinen gesamten Lebenszyklus sicher sein, von Entwurf und Entwicklung über die Produktion bis zur Wartung während des Nutzungszeitraums. Um das zu erreichen, muss der Hersteller eine Cybersicherheits-Risikobewertung durchführen. Diese Risikobewertung ist kein einmaliges Dokument, sondern der Ausgangspunkt für alle weiteren Entscheidungen: Sie bestimmt, welche der grundlegenden Anforderungen wie umzusetzen sind, und sie muss in allen Phasen – Planung, Entwurf, Entwicklung, Produktion, Lieferung und Wartung – berücksichtigt werden.

Setzt der Hersteller Komponenten Dritter ein – und welches moderne Produkt tut das nicht? –, muss er mit gebührender Sorgfalt sicherstellen, dass diese Komponenten die Sicherheit seines Produkts nicht untergraben. Diese Klausel ist der direkte gesetzgeberische Reflex auf die Ära der Lieferketten-Angriffe: Wer eine verwundbare oder gar bösartige Bibliothek einbaut, kann sich nicht mehr darauf herausreden, sie stamme von jemand anderem.

Anhang I: die grundlegenden Anforderungen in zwei Teilen

Das inhaltliche Herzstück des CRA ist Anhang I, der die grundlegenden Cybersicherheitsanforderungen festlegt und aus zwei Teilen besteht.

Teil I betrifft die Eigenschaften des Produkts – die Anforderungen an ein sicheres Design. Hierunter fallen Prinzipien wie: Das Produkt wird ohne bekannte ausnutzbare Schwachstellen ausgeliefert; es wird mit einer sicheren Standardkonfiguration ausgeliefert (security by default), etwa ohne fest einprogrammierte Standardpasswörter; es schützt Vertraulichkeit und Integrität von Daten durch Verschlüsselung, wo angemessen; es setzt Zugriffskontrolle durch; es minimiert die Angriffsfläche; es sieht Schutzmechanismen gegen unbefugten Zugriff vor und protokolliert sicherheitsrelevante Ereignisse. Diese Prinzipien – oft als etwa dreizehn Einzelanforderungen zusammengefasst – kodifizieren das, was Sicherheitsexperten seit Jahren als security by design und security by default predigen, und machen es aus einer Empfehlung zu einer rechtlichen Pflicht.

Teil II betrifft die Behandlung von Schwachstellen – also nicht das Produkt zum Zeitpunkt des Verkaufs, sondern seine Pflege über die Zeit. Der Hersteller muss die Schwachstellen seines Produkts (einschließlich seiner Komponenten) identifizieren und dokumentieren, unter anderem in einer Software-Stückliste (SBOM, Software Bill of Materials) – einem strukturierten Verzeichnis aller enthaltenen Komponenten. Er muss Schwachstellen unverzüglich beheben, Sicherheitsupdates bereitstellen, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen betreiben und eine Kontaktstelle für Meldungen einrichten. Entscheidend: Sicherheitsupdates müssen grundsätzlich kostenlos und, wo technisch möglich, automatisch bereitgestellt werden.

Der Support-Zeitraum: ein Verfallsdatum für Verwundbarkeit

Eine der praktisch folgenreichsten Neuerungen ist die Pflicht, einen Support-Zeitraum festzulegen. Für diesen Zeitraum garantiert der Hersteller, dass er Schwachstellen behandelt und Sicherheitsupdates liefert. Der Support-Zeitraum muss der erwarteten Nutzungsdauer des Produkts entsprechen und soll in der Regel mindestens fünf Jahre betragen (kürzer nur, wenn die erwartete Lebensdauer nachweislich geringer ist). Das Enddatum – mit Monat und Jahr – muss dem Käufer zum Zeitpunkt des Kaufs klar und verständlich mitgeteilt werden.

Ich bin der Meinung, dass diese scheinbar bürokratische Anforderung eine der elegantesten des ganzen Gesetzes ist. Sie greift genau das Problem des Aufhänger-Routers an: Bisher war völlig unklar, wie lange ein Produkt Updates bekommt, und Hersteller stellten den Support still und heimlich ein. Der CRA zwingt sie, sich vorab und öffentlich festzulegen. Damit wird die Frage „Wie lange ist dieses Gerät sicher?" vom unsichtbaren Nachgedanken zu einer Angabe auf der Verpackung – vergleichbar mit einem Mindesthaltbarkeitsdatum für Cybersicherheit.

Teil 4: Die drei Produktklassen und die Konformitätsbewertung

Nicht jedes Produkt trägt dasselbe Risiko. Ein smartes Thermometer ist etwas anderes als ein Betriebssystem oder ein Hardware-Sicherheitsmodul, in dem kryptografische Schlüssel liegen. Der CRA trägt dem Rechnung, indem er Produkte in drei Risikostufen einteilt und daran die Strenge der Konformitätsbewertung knüpft – also des Verfahrens, mit dem ein Hersteller nachweist, dass er die Anforderungen erfüllt.

Die drei Stufen

Für die große Mehrheit der Produkte – die Standardklasse – genügt eine Selbstbewertung: Der Hersteller prüft sein Produkt intern gegen die Anforderungen (das sogenannte interne Kontrollverfahren, Modul A), stellt die technische Dokumentation zusammen, unterzeichnet die EU-Konformitätserklärung und bringt die CE-Kennzeichnung an. Es ist wichtig, das zu betonen, weil in der Debatte oft der Eindruck entsteht, jedes Produkt müsse extern zertifiziert werden: Das stimmt nicht. Der Aufwand ist real, aber für die meisten Produkte bleibt er in der Hand des Herstellers.

Bei wichtigen Produkten (Anhang III) steigt die Anforderung. Bei Klasse I – etwa Passwortmanagern oder VPNs – darf der Hersteller nur dann selbst bewerten, wenn er anerkannte harmonisierte Normen (oder gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema) anwendet; andernfalls muss eine unabhängige benannte Stelle (notified body) prüfen. Bei Klasse II – etwa Betriebssystemen, Firewalls oder industriellen Routern – ist die Prüfung durch eine benannte Stelle immer verpflichtend.

Bei kritischen Produkten (Anhang IV) ist die Latte am höchsten: Hierzu zählen Geräte mit besonders hoher Sicherheitsrelevanz wie Hardware-Sicherheitsmodule, Smart-Meter-Gateways sowie Smartcards und Geräte mit sicheren Elementen. Für sie kann die Kommission eine europäische Cybersicherheitszertifizierung (etwa nach dem EUCC-Schema) verpflichtend machen. Die technischen Beschreibungen dieser wichtigen und kritischen Kategorien hat die Kommission in einer eigenen Durchführungsverordnung – (EU) 2025/2392 vom 28. November 2025 – präzisiert, damit Hersteller verlässlich einordnen können, in welche Klasse ihr Produkt fällt.

Harmonisierte Normen und die Vermutungswirkung

Ein zentrales Werkzeug, das den ganzen Mechanismus zum Laufen bringt, ist die Vermutungswirkung: Wendet ein Hersteller eine im Amtsblatt gelistete harmonisierte europäische Norm an, so wird vermutet, dass sein Produkt die entsprechenden grundlegenden Anforderungen erfüllt. Das verwandelt abstrakte Rechtspflichten in konkrete, prüfbare technische Standards und ist der Grund, warum die europäischen Normungsorganisationen (CEN, CENELEC, ETSI) derzeit unter Hochdruck an CRA-Normen arbeiten. Verzögert sich diese Normung, verlieren Hersteller das einfachste Mittel, um Konformität nachzuweisen – ein wunder Punkt im Zeitplan, den viele Beobachter mit Sorge betrachten.

Die CE-Kennzeichnung: ein altes Symbol mit neuer Bedeutung

Am Ende steht ein vertrautes Zeichen: die CE-Kennzeichnung. Sie ist seit Jahrzehnten das Sichtbarmachen der Konformität mit EU-Produktrecht im Rahmen des sogenannten Neuen Rechtsrahmens (New Legislative Framework). Bisher stand sie für Dinge wie elektrische Sicherheit oder elektromagnetische Verträglichkeit; mit dem CRA bekommt sie eine neue Dimension. Ein CE-Zeichen auf einem Produkt mit digitalen Elementen bedeutet künftig auch: „Dieser Hersteller erklärt, die grundlegenden Cybersicherheitsanforderungen zu erfüllen." Damit wandert Cybersicherheit in denselben rechtlichen Rahmen, in dem physische Produktsicherheit längst zu Hause ist – ein bemerkenswerter symbolischer und praktischer Schritt.

Teil 5: Die Meldepflichten – die 24-Stunden-Uhr

Neben den produktbezogenen Pflichten enthält der CRA in Artikel 14 eine scharfe Meldepflicht, die schon vor dem großen Stichtag greift. Sobald ein Hersteller von einer aktiv ausgenutzten Schwachstelle in seinem Produkt oder von einem schwerwiegenden Sicherheitsvorfall erfährt, der die Sicherheit des Produkts beeinträchtigt, beginnt eine gestaffelte Uhr:

• Frühwarnung binnen 24 Stunden nach Kenntnisnahme;
• Hauptmeldung binnen 72 Stunden mit genaueren Angaben;
• ein Abschlussbericht – bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist; bei schwerwiegenden Vorfällen binnen eines Monats nach der 72-Stunden-Meldung.

Die Meldungen laufen über eine zentrale Meldeplattform (Single Reporting Platform), die von der EU-Cybersicherheitsagentur ENISA betrieben wird, und gehen an das nationale Computer-Notfallteam (CSIRT) des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat, sowie an ENISA selbst. Bemerkenswert ist der Anwendungsbereich: Die Meldepflicht gilt für alle auf dem EU-Markt bereitgestellten Produkte – auch für solche, die bereits vor dem großen Stichtag im Dezember 2027 in Verkehr gebracht wurden.

Diese Meldepflicht ist nicht unumstritten. Kritiker – darunter namhafte Sicherheitsforscher – haben eingewandt, dass die Pflicht, aktiv ausgenutzte, aber noch ungepatchte Schwachstellen binnen 24 Stunden an staatliche Stellen zu melden, ein heikles Wissen bei Behörden konzentriert, bevor ein Fix existiert. Im schlimmsten Fall, so die Sorge, entstünde eine Datenbank hochbrisanter Zero-Day-Informationen, die selbst zum Angriffsziel oder – in den falschen Händen – zur Waffe werden könnte. Die Verordnung versucht, dem mit strengen Vertraulichkeitsregeln und einer Begrenzung des Zugriffs zu begegnen; ob die Balance zwischen Transparenz und Geheimnisschutz gelingt, wird sich erst in der Praxis ab September 2026 zeigen.

Teil 6: Open Source – die schwierigste Frage

Kein Thema hat die Entstehung des CRA so aufgewühlt wie die Frage nach der quelloffenen Software. Der Grund ist ein struktureller: Die gesamte moderne digitale Welt ruht auf freier Software, die überwiegend von unbezahlten Freiwilligen oder kleinen Stiftungen gepflegt wird. Würde man diese Freiwilligen mit denselben Pflichten belegen wie einen milliardenschweren Gerätehersteller, wäre die Folge absehbar: Viele würden ihre Projekte lieber einstellen oder Europa den Rücken kehren, als eine juristische Haftung für Software zu übernehmen, die sie kostenlos und in ihrer Freizeit verschenken. Der frühe Entwurf des CRA löste deshalb einen Sturm der Entrüstung in der Open-Source-Gemeinschaft aus.

Der finale Text zieht daraufhin eine sorgfältige Linie. Nicht kommerziell bereitgestellte Open-Source-Software fällt grundsätzlich nicht unter den CRA. Ein einzelner Entwickler, der ein Projekt auf einer Plattform veröffentlicht, wird nicht zum haftenden Hersteller. Erst wenn Software „auf dem Markt bereitgestellt" wird – also im Rahmen einer kommerziellen Tätigkeit –, greifen die Pflichten, und dann treffen sie denjenigen, der sie kommerzialisiert.

Für einen Zwischenbereich schafft der CRA eine neue, eigens erfundene Rolle: den Open-Source-Software-Verwalter (open-source software steward). Gemeint sind juristische Personen – typischerweise Stiftungen –, die die Entwicklung bestimmter, für kommerzielle Zwecke genutzter freier Software systematisch und nachhaltig unterstützen und ihre Lebensfähigkeit sichern. Solche Verwalter unterliegen abgemilderten Pflichten: Sie müssen eine Cybersicherheitsrichtlinie haben, mit den Marktüberwachungsbehörden kooperieren und bestimmte Schwachstellen und Vorfälle melden – aber sie sind nicht dem vollen Pflichtenkatalog eines Herstellers unterworfen. Und ganz wichtig: Open-Source-Verwalter können für Verstöße gegen den CRA nicht mit Geldbußen belegt werden.

Hier lohnt ein Blick zurück auf einen anderen Artikel in diesem Vault. Der Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs beschreibt, wie ein einziger überlasteter Freiwilliger, der eine unscheinbare Kompressionsbibliothek pflegte, zum Einfallstor für einen beinahe katastrophalen Angriff auf das halbe Linux-Ökosystem wurde. Der CRA ist, unter anderem, die regulatorische Antwort auf genau diese Fragilität. Doch die Ironie ist scharf: Das Problem der xz-Affäre war nicht zu wenig Regulierung, sondern zu wenig Ressourcen für einen erschöpften Menschen. Ob eine Cybersicherheitsrichtlinie auf dem Papier einen unterfinanzierten Maintainer wirklich schützt – oder ihn nur zusätzlich belastet –, ist eine der offenen Fragen, die der CRA aufwirft, aber nicht abschließend beantwortet.

Teil 7: Zeitplan und Sanktionen

Der Zeitstrahl

Der CRA gilt nicht auf einen Schlag, sondern gestaffelt – ein bewusster Kontrast zu DORA, das an einem einzigen Stichtag voll wirksam wurde.

Für Bestandsprodukte gilt eine pragmatische Regel: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen erst dann unter die vollen CRA-Pflichten, wenn sie ab diesem Datum wesentlich verändert werden. Die Meldepflichten hingegen gelten, wie erwähnt, für alle bereitgestellten Produkte.

Die Sanktionen: drei Stufen

Artikel 64 legt die Bußgeldrahmen fest, deren konkrete Ausgestaltung die Mitgliedstaaten national vornehmen (in Deutschland voraussichtlich unter Federführung des BSI und der Marktüberwachung). Die Verordnung staffelt die Höchstbeträge nach der Schwere des Verstoßes in drei Stufen:

Wie beim EU AI Act und bei DORA orientiert sich der Höchstbetrag also am weltweiten Umsatz – ein Mechanismus, der sicherstellt, dass die Strafe auch für globale Konzerne spürbar bleibt und nicht als Betriebskosten abgetan werden kann. Zugleich zeigt der CRA an entscheidenden Stellen Augenmaß: Kleinstunternehmen und kleine Unternehmen können nicht dafür bestraft werden, dass sie die 24-Stunden-Meldefrist verpassen, und Open-Source-Verwalter sind von Geldbußen ausgenommen. Diese Ausnahmen sind kein Schlupfloch, sondern der Versuch, Verhältnismäßigkeit zu wahren und die zerbrechlichsten Teile des Ökosystems nicht zu erdrücken.

Teil 8: Der CRA im Kontext – Nachbarn im Regelungsgeflecht

Der CRA steht nicht allein, sondern ist ein Baustein in einer ganzen Architektur europäischer Digitalregulierung. Seine Verwandtschaftsverhältnisse helfen, ihn einzuordnen.

Der engste konzeptionelle Nachbar ist die NIS2-Richtlinie. Während NIS2 die Organisationen absichert, die kritische Dienste betreiben, sichert der CRA die Produkte ab, die diese Organisationen einsetzen. Ein Betreiber, der unter NIS2 sichere Systeme betreiben muss, kann sich künftig darauf verlassen, dass die Bausteine dieser Systeme unter dem CRA eine Sicherheitsuntergrenze einhalten. Ähnlich verhält es sich mit DORA: Der Finanzsektor bezieht seine IT-Produkte künftig von Herstellern, die dem CRA unterliegen – die produktseitige Absicherung ergänzt die betreiberseitige Resilienz.

Interessant ist auch das Verhältnis zum EU AI Act. Für Hochrisiko-KI-Systeme, die zugleich Produkte mit digitalen Elementen sind, sieht der Gesetzgeber eine Brücke vor: Erfüllt ein solches System die grundlegenden Cybersicherheitsanforderungen des CRA, gilt es insoweit auch für die Cybersicherheitsanforderungen des AI Act als konform. Damit wird Doppelarbeit vermieden – ein CE-Zeichen kann mehrere Konformitäten zugleich bezeugen. Und schließlich berührt der CRA jene tieferliegenden technischen Themen, die anderswo im Vault behandelt werden: Seine Forderung nach dauerhafter Schwachstellenbehandlung schließt das Langfristrisiko ein, dass heutige Verschlüsselung eines Tages von Quantencomputern gebrochen wird; und seine Logik der grundlegenden Produktsicherheit betrifft unmittelbar jene Klasse von Hardware-Schwachstellen, bei denen eine scheinbar harmlose Optimierung zur systemischen Lücke wurde.

Querverweise im Vault

• NIS2 und was sie für mittelständische IT-Beratungsunternehmen in Deutschland wirklich bedeutet – der engste Nachbar: NIS2 sichert die Organisationen, der CRA die Produkte.
• Wenn die IT nicht ausfallen darf: DORA und die digitale operationale Resilienz des Finanzsektors – betreiberseitige Resilienz im Finanzsektor, die der CRA produktseitig ergänzt.
• Die Pyramide des Risikos: Wie der EU AI Act künstliche Intelligenz bändigt – und warum das die ganze Welt betrifft – dieselbe risikobasierte Regulierungsphilosophie; CRA-Konformität kann AI-Act-Cybersicherheit mit abdecken.
• Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs – die Fragilität der Open-Source-Lieferkette, auf die der CRA reagiert.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – ein Langfristrisiko, das die CRA-Schwachstellenbehandlung mit erfassen muss.
• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – wie aus einer Optimierung eine systemische Produktschwachstelle wird.

Erkenntnis zum Mitnehmen

Wenn du aus diesem Artikel eine einzige Sache mitnimmst, dann diese: Der CRA verlagert die Verantwortung für Cybersicherheit von den Nutzern zurück zu den Herstellern – und macht sie zu einer Produkteigenschaft, die man belegen, kennzeichnen und über die Zeit pflegen muss. Bisher war Sicherheit ein unsichtbares Extra, das der Markt systematisch zu wenig belohnte; künftig ist sie eine Eintrittskarte für den EU-Binnenmarkt. Kein CE-Zeichen ohne Sicherheitszusage, kein Verkauf ohne festgelegten Support-Zeitraum, keine Ausrede mehr für fest einprogrammierte Standardpasswörter oder heimlich eingestellte Updates.

Für die tägliche Ingenieurspraxis heißt das ganz konkret: Behandle Software-Stücklisten (SBOM), koordinierte Schwachstellenoffenlegung und automatische, kostenlose Sicherheitsupdates nicht als lästige Compliance-Anhängsel, sondern als erstklassige Designanforderungen, die von Anfang an in die Architektur gehören. Wer heute ein Produkt entwirft, sollte wissen, aus welchen Komponenten es besteht, wie er sie über Jahre aktuell hält und wie er im Ernstfall binnen Stunden eine ausgenutzte Schwachstelle melden kann. Und wer Open-Source-Komponenten einsetzt, sollte nicht nur ihre Lizenz prüfen, sondern auch, wie gesund und gut gepflegt das Projekt dahinter ist – denn im Fehlerfall ist es die eigene Sorgfaltspflicht, die zählt. Der CRA ist, richtig gelesen, weniger ein Bürokratie- als ein Ingenieurauftrag: Er zwingt dazu, Sicherheit von der ersten Entwurfsentscheidung an einzubauen, statt sie nachträglich zu behaupten.

Reflexionsfrage

Der CRA verlangt, dass jeder Hersteller weiß, aus welchen Komponenten sein Produkt besteht (SBOM), und dass er zum Verkaufszeitpunkt öffentlich festlegt, wie lange er es mit Sicherheitsupdates versorgt. Denke an ein Produkt oder System, an dem du gerade arbeitest oder das du kennst: Könntest du auf Anhieb eine vollständige Liste aller darin enthaltenen Fremdkomponenten vorlegen – und traust du dir zu, verbindlich zu versprechen, dass jede einzelne davon fünf Jahre lang sicher gehalten wird?

Quellen

• The Cyber Resilience Act – Summary of the legislative text – Europäische Kommission, Shaping Europe's digital future
• Regulation (EU) 2024/2847 (Cyber Resilience Act) – Volltext auf EUR-Lex
• Cyber Resilience Act – Conformity assessment – Europäische Kommission
• Commission Implementing Regulation (EU) 2025/2392 – technische Beschreibungen wichtiger und kritischer Produkte
• Cyber Resilience Act – Wikipedia (Überblick, Entstehung, Kritik)
• The Cyber Resilience Act Explained: Scope, Classes & Deadlines – cyberresilienceact.eu

← All articles