{"id":95,"date":"2026-06-13T04:18:09","date_gmt":"2026-06-13T04:18:09","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/13\/cyber-resilience-act\/"},"modified":"2026-06-13T08:08:44","modified_gmt":"2026-06-13T08:08:44","slug":"cyber-resilience-act","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/13\/cyber-resilience-act\/","title":{"rendered":"Cyber Resilience Act: 90 Tage bis zur Meldepflicht [2026]"},"content":{"rendered":"\n

Am 11. September 2026 endet die Schonzeit. Ab diesem Tag m\u00fcssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die europ\u00e4ische Cybersicherheitsagentur ENISA und das zust\u00e4ndige nationale CSIRT melden. Es ist die erste scharfe Frist des EU Cyber Resilience Act (CRA), und sie liegt exakt 90 Tage vor uns. Wer Software, vernetzte Ger\u00e4te oder Industriekomponenten in der EU verkauft, hat ab diesem Datum kein Wahlrecht mehr.<\/p>\n\n\n\n

Der Cyber Resilience Act ist die erste horizontale Produktsicherheitsverordnung der EU, die Cybersicherheit \u00fcber den gesamten Lebenszyklus eines Produkts vorschreibt. Anders als die NIS2-Richtlinie<\/a>, die Betreiber kritischer Einrichtungen reguliert, nimmt der CRA die Produkte selbst und ihre Hersteller in die Pflicht. Vom smarten T\u00fcrschloss bis zur industriellen Steuerung, vom Passwortmanager bis zum Betriebssystem: Fast alles, was Code enth\u00e4lt und mit einem Netzwerk verbunden werden kann, f\u00e4llt in den Anwendungsbereich. Die Bu\u00dfgelder reichen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.<\/p>\n\n\n\n

Dieser Beitrag analysiert den Stand vom 13. Juni 2026: die Fristen, die Strafen, die Produktklassen, die Auswirkungen auf den deutschen Mittelstand und die Open-Source-Community sowie die offenen Streitpunkte, die in den kommenden Monaten \u00fcber Erfolg oder Chaos der Umsetzung entscheiden.<\/p>\n\n\n\n

Cyber Resilience Act: Was die EU-Verordnung 2024\/2847 vorschreibt<\/h2>\n\n\n\n

Der Cyber Resilience Act ist als Verordnung (EU) 2024\/2847 am 20. November 2024 im Amtsblatt der EU ver\u00f6ffentlicht worden und am 10. Dezember 2024 in Kraft getreten. Als Verordnung gilt er unmittelbar in allen 27 Mitgliedstaaten, ohne dass ein nationales Umsetzungsgesetz wie beim NIS2-Umsetzungsgesetz n\u00f6tig w\u00e4re. Das beseitigt einen ganzen Streitpunkt: W\u00e4hrend Deutschland sein NIS2-Gesetz erst Ende 2025 verabschiedete und damit die EU-Frist um mehr als ein Jahr riss, gilt der CRA f\u00fcr alle L\u00e4nder zeitgleich nach demselben Wortlaut.<\/p>\n\n\n\n

Der Kern der Verordnung sind verbindliche Cybersicherheitsanforderungen f\u00fcr Produkte mit digitalen Elementen, definiert in Anhang I. Hersteller m\u00fcssen Produkte sicher entwickeln (Security by Design), sie ohne bekannte ausnutzbare Schwachstellen ausliefern, \u00fcber den gesamten Support-Zeitraum Sicherheitsupdates bereitstellen und eine Software-St\u00fcckliste (SBOM) f\u00fchren. Die Konformit\u00e4t wird durch die CE-Kennzeichnung dokumentiert, die bislang f\u00fcr die elektrische Sicherheit von Ger\u00e4ten stand und nun um die digitale Sicherheit erweitert wird.<\/p>\n\n\n\n

Die Europ\u00e4ische Kommission begr\u00fcndet den Aufwand mit handfesten Zahlen. In ihrer Folgenabsch\u00e4tzung beziffert sie das j\u00e4hrliche Schadenspotenzial von Cyberkriminalit\u00e4t, das der CRA verringern soll, auf eine Gr\u00f6\u00dfenordnung von 180 bis 290 Milliarden Euro pro Jahr. Der Grundgedanke: Unsichere Produkte verursachen Kettenreaktionen. Eine einzige ungepatchte Komponente in einer Lieferkette kann tausende nachgelagerte Systeme kompromittieren, wie die gro\u00dfen Vorf\u00e4lle der vergangenen Jahre gezeigt haben.<\/p>\n\n\n\n

Die Fristen im \u00dcberblick: 11. Juni, 11. September 2026 und 11. Dezember 2027<\/h2>\n\n\n\n

Der CRA wird gestaffelt scharf gestellt. Drei Daten sind entscheidend, und das erste ist bereits verstrichen. Seit dem 11. Juni 2026 m\u00fcssen die Mitgliedstaaten die Konformit\u00e4tsbewertungsstellen (Notified Bodies) benannt haben, die sp\u00e4ter die Zertifizierung h\u00f6herklassiger Produkte \u00fcbernehmen. Ohne diese benannten Stellen kann der sp\u00e4tere Pflichtteil nicht funktionieren, weshalb dieser Termin den Aufbau der Pr\u00fcfinfrastruktur markiert.<\/p>\n\n\n\n

Der n\u00e4chste, weitaus folgenreichere Stichtag ist der 11. September 2026. Ab dann gelten die Meldepflichten f\u00fcr Hersteller. Wer von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erf\u00e4hrt, muss in einem dreistufigen Verfahren melden. Die vollst\u00e4ndige Anwendung aller Pflichten, einschlie\u00dflich der wesentlichen Sicherheitsanforderungen und der Konformit\u00e4tsbewertung, folgt am 11. Dezember 2027.<\/p>\n\n\n\n

Datum<\/th>Pflicht<\/th>Wer betroffen ist<\/th><\/tr><\/thead>
10. Dezember 2024<\/td>Inkrafttreten der Verordnung (EU) 2024\/2847<\/td>Alle Hersteller (Vorbereitungsphase)<\/td><\/tr>
11. Juni 2026<\/td>Benennung der Konformit\u00e4tsbewertungsstellen<\/td>Mitgliedstaaten, Notified Bodies<\/td><\/tr>
11. September 2026<\/td>Meldepflichten f\u00fcr Schwachstellen und Vorf\u00e4lle<\/td>Alle Hersteller von Produkten mit digitalen Elementen<\/td><\/tr>
11. Dezember 2027<\/td>Vollst\u00e4ndige Anwendung aller CRA-Pflichten<\/td>Hersteller, Importeure, H\u00e4ndler<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Diese Staffelung gibt Unternehmen ein 18-monatiges Zeitfenster zwischen Meldepflicht und Vollanwendung. Praktiker warnen jedoch davor, es als Aufschub misszuverstehen. Wer am 11. September 2026 keinen funktionierenden Meldeprozess hat, verst\u00f6\u00dft ab dem ersten Vorfall gegen die Verordnung. Und die technischen und organisatorischen Anforderungen f\u00fcr Dezember 2027, etwa SBOMs und nachweisbare Schwachstellenbehandlung, lassen sich nicht in wenigen Wochen aufbauen.<\/p>\n\n\n\n

Bu\u00dfgelder bis 15 Millionen Euro: Die Sanktionen im Detail<\/h2>\n\n\n\n

Der CRA staffelt seine Sanktionen nach Schwere des Versto\u00dfes, \u00e4hnlich der DSGVO. An der Spitze stehen Bu\u00dfgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag h\u00f6her ist. Dieser H\u00f6chstsatz greift bei Verst\u00f6\u00dfen gegen die wesentlichen Cybersicherheitsanforderungen aus Anhang I und gegen die Pflichten zur Schwachstellenbehandlung. Es ist der Kernbereich der Verordnung: Wer unsichere Produkte ausliefert oder Schwachstellen nicht behandelt, riskiert die h\u00e4rteste Strafe.<\/p>\n\n\n\n

Eine zweite Stufe sieht bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes f\u00fcr Verst\u00f6\u00dfe gegen die \u00fcbrigen Herstellerpflichten vor. Eine dritte Stufe greift bei falschen, unvollst\u00e4ndigen oder irref\u00fchrenden Angaben gegen\u00fcber den Markt\u00fcberwachungsbeh\u00f6rden: bis zu 5 Millionen Euro oder 1 Prozent des weltweiten Jahresumsatzes. F\u00fcr kleine und mittlere Unternehmen sieht die Verordnung vor, dass die Beh\u00f6rden die Verh\u00e4ltnism\u00e4\u00dfigkeit ber\u00fccksichtigen.<\/p>\n\n\n\n

Versto\u00df<\/th>Bu\u00dfgeld bis<\/th>Anteil Jahresumsatz<\/th><\/tr><\/thead>
Wesentliche Anforderungen (Anhang I), Schwachstellenbehandlung<\/td>15 Mio. Euro<\/td>2,5 %<\/td><\/tr>
\u00dcbrige Herstellerpflichten<\/td>10 Mio. Euro<\/td>2,0 %<\/td><\/tr>
Falsche Angaben gegen\u00fcber Beh\u00f6rden<\/td>5 Mio. Euro<\/td>1,0 %<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

In Deutschland \u00fcberwacht das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) zentrale Teile der Umsetzung. Die Markt\u00fcberwachungsbeh\u00f6rden k\u00f6nnen Produkte vom Markt nehmen, R\u00fcckrufe anordnen und Bu\u00dfgelder verh\u00e4ngen. Anders als bei vielen produktrechtlichen Vorschriften betrifft die Sanktion nicht nur den Hersteller, sondern auch Importeure und H\u00e4ndler, die nicht-konforme Produkte in Verkehr bringen.<\/p>\n\n\n\n

Die 24-Stunden-Regel: Das dreistufige Meldeverfahren ab September<\/h2>\n\n\n\n

Das Herzst\u00fcck der ersten Pflichtphase ist die Meldekette f\u00fcr aktiv ausgenutzte Schwachstellen und schwerwiegende Vorf\u00e4lle. Sie ist dreistufig aufgebaut und an die Logik anderer EU-Cybergesetze angelehnt, aber mit eigenen Fristen. Stufe eins ist eine Fr\u00fchwarnung innerhalb von 24 Stunden, nachdem der Hersteller von der aktiven Ausnutzung Kenntnis erlangt. Adressaten sind das zust\u00e4ndige nationale CSIRT und ENISA \u00fcber eine zentrale Meldeplattform.<\/p>\n\n\n\n

Stufe zwei ist eine ausf\u00fchrlichere Schwachstellenmeldung innerhalb von 72 Stunden. Sie muss den allgemeinen Charakter der Schwachstelle, den Stand der Behebung und, soweit bekannt, korrigierende oder mildernde Ma\u00dfnahmen enthalten. Stufe drei ist ein Abschlussbericht innerhalb von 14 Tagen nach Bereitstellung einer korrigierenden Ma\u00dfnahme. Er beschreibt die Schwachstelle, ihre Auswirkungen und die ausgerollte L\u00f6sung.<\/p>\n\n\n\n

Diese 24-Stunden-Fr\u00fchwarnung ist operativ anspruchsvoll. Sie verlangt, dass Hersteller rund um die Uhr in der Lage sind, eine ausgenutzte Schwachstelle zu erkennen, zu bewerten und zu melden. F\u00fcr Unternehmen, die bislang keinen formalen Prozess f\u00fcr Schwachstellenmanagement betreiben, ist das ein Kulturwandel. Wer die Mechanik von Schwachstellenbewertung und Offenlegung vertiefen will, findet in unserem Beitrag zur Citrix-NetScaler-L\u00fccke<\/a> ein konkretes Fallbeispiel f\u00fcr die Geschwindigkeit, mit der heute L\u00fccken ausgenutzt werden.<\/p>\n\n\n\n

Produktklassen: Vom Selbsttest bis zur Pflichtzertifizierung<\/h2>\n\n\n\n

Nicht jedes Produkt durchl\u00e4uft dieselbe Pr\u00fcfung. Der CRA gruppiert Produkte mit digitalen Elementen nach Risiko in vier Kategorien, und die Anforderungen steigen mit jeder Stufe. Die Standardkategorie umfasst nach Sch\u00e4tzungen der Kommission rund 90 Prozent aller betroffenen Produkte. F\u00fcr sie gen\u00fcgt eine Selbstbewertung der Konformit\u00e4t durch den Hersteller, der anschlie\u00dfend die CE-Kennzeichnung anbringt. Dazu z\u00e4hlen etwa Textverarbeitung, Fotobearbeitung oder einfache vernetzte Ger\u00e4te.<\/p>\n\n\n\n

Wichtige Produkte Klasse I und Klasse II<\/h3>\n\n\n\n

Dar\u00fcber liegen die wichtigen Produkte. Klasse I umfasst sicherheitsrelevante Software und Ger\u00e4te wie Passwortmanager, VPN-Software, Virenschutz, Firewalls, Router und Netzwerkmanagement-Systeme. Hier kann der Hersteller die Konformit\u00e4t noch selbst bewerten, wenn er harmonisierte Normen vollst\u00e4ndig anwendet, sonst muss eine benannte Stelle eingebunden werden. Klasse II umfasst kritischere Produkte wie Betriebssysteme, industrielle Firewalls, Mikroprozessoren und Mikrocontroller mit Sicherheitsfunktionen sowie Hardware mit Sicherheitsboxen. F\u00fcr sie ist die Einbindung einer benannten Stelle verpflichtend.<\/p>\n\n\n\n

Kritische Produkte mit Pflichtzertifizierung<\/h3>\n\n\n\n

Die h\u00f6chste Stufe bilden die kritischen Produkte, etwa Hardware-Sicherheitsmodule, Smartcards und Smart-Meter-Gateways. F\u00fcr sie kann die Kommission eine verpflichtende europ\u00e4ische Cybersicherheitszertifizierung vorschreiben. Diese Abstufung soll den Aufwand dort konzentrieren, wo das Risiko am gr\u00f6\u00dften ist, und kleine Anbieter unkritischer Produkte nicht \u00fcberfordern. Ob die Trennlinien in der Praxis tragen, wird sich erst zeigen, wenn die ersten Produkte durch die Verfahren laufen.<\/p>\n\n\n\n

CRA versus NIS2: Produkt gegen Betreiber<\/h2>\n\n\n\n

Der h\u00e4ufigste Irrtum in der aktuellen Debatte ist, CRA und NIS2 zu verwechseln. Beide sind EU-Cybergesetze, beide treten kurz hintereinander in Kraft, aber sie regulieren verschiedene Dinge. NIS2 verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen, also Organisationen wie Energieversorger, Krankenh\u00e4user, Logistiker oder Hersteller ab bestimmten Gr\u00f6\u00dfen, ihre eigenen Netz- und Informationssysteme abzusichern. Der CRA verpflichtet die Hersteller der Produkte, die diese Organisationen einsetzen.<\/p>\n\n\n\n

Ein deutscher Maschinenbauer kann von beiden Regimen zugleich erfasst sein. Als Betreiber muss er unter NIS2 seine internen Systeme h\u00e4rten, Vorf\u00e4lle an das BSI melden und ein Risikomanagement nachweisen. Als Hersteller vernetzter Maschinen muss er unter CRA sicherstellen, dass seine Produkte sicher entworfen sind, Updates erhalten und Schwachstellen gemeldet werden. Die Pflichten \u00fcberschneiden sich nicht, sie erg\u00e4nzen sich. Eine \u00dcbersicht \u00fcber die deutsche NIS2-Lage liefert unser Beitrag zur NIS2-Umsetzung in Deutschland<\/a>.<\/p>\n\n\n\n

Merkmal<\/th>Cyber Resilience Act<\/th>NIS2-Richtlinie<\/th><\/tr><\/thead>
Rechtsform<\/td>Verordnung (direkt anwendbar)<\/td>Richtlinie (nationale Umsetzung)<\/td><\/tr>
Reguliert<\/td>Produkte mit digitalen Elementen<\/td>Betreiber von Einrichtungen<\/td><\/tr>
Adressat<\/td>Hersteller, Importeure, H\u00e4ndler<\/td>Wesentliche und wichtige Einrichtungen<\/td><\/tr>
H\u00f6chstbu\u00dfgeld<\/td>15 Mio. Euro \/ 2,5 % Umsatz<\/td>10 Mio. Euro \/ 2 % Umsatz<\/td><\/tr>
Meldefrist (Fr\u00fchwarnung)<\/td>24 Stunden<\/td>24 Stunden<\/td><\/tr>
Volle Anwendung<\/td>11. Dezember 2027<\/td>seit 6. Dezember 2025 (DE)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Open Source unter Druck: Der Streit um die Software-Verwalter<\/h2>\n\n\n\n

Kein Teil des CRA hat so viel Widerstand erzeugt wie die Behandlung von Open-Source-Software. Der erste Entwurf von 2022 drohte, ehrenamtliche Entwickler und Stiftungen mit denselben Pflichten zu belegen wie kommerzielle Konzerne. Die Sorge: Wer ein popul\u00e4res Open-Source-Projekt pflegt, das sp\u00e4ter in tausenden kommerziellen Produkten landet, k\u00f6nnte f\u00fcr Schwachstellen haftbar gemacht werden, ohne je Geld damit verdient zu haben. Die Eclipse Foundation, OpenSSF und zahlreiche Maintainer liefen Sturm.<\/p>\n\n\n\n

Die finale Fassung schuf daraufhin eine eigene Rolle: den Open-Source-Software-Verwalter (Open Source Software Steward). Das sind Organisationen, die die Entwicklung von Open-Source-Software systematisch und nachhaltig unterst\u00fctzen, ohne sie kommerziell zu vertreiben, etwa Stiftungen wie Eclipse oder die Apache Software Foundation. Verwalter unterliegen leichteren, angepassten Pflichten und k\u00f6nnen nicht mit Bu\u00dfgeldern belegt werden. Rein nicht-kommerzielle Einzelentwickler fallen ganz aus dem Anwendungsbereich.<\/p>\n\n\n\n

Damit ist der Streit entsch\u00e4rft, aber nicht beendet. Die Grenzziehung zwischen kommerzieller und nicht-kommerzieller T\u00e4tigkeit bleibt unscharf. Wer ein Open-Source-Projekt anbietet und zugleich kostenpflichtigen Support verkauft, bewegt sich in einer Grauzone. Die Community wartet auf Leitlinien der Kommission, die diese F\u00e4lle kl\u00e4ren sollen. Bis dahin herrscht in vielen Projekten Unsicherheit \u00fcber den eigenen Status.<\/p>\n\n\n\n

Was Experten sagen: Stimmen aus Beh\u00f6rden und Wirtschaft<\/h2>\n\n\n\n

Die Bewertungen des CRA fallen je nach Perspektive unterschiedlich aus. Aus Sicht der EU-Beh\u00f6rden ist die Verordnung ein \u00fcberf\u00e4lliger Schritt. “Der Cyber Resilience Act schlie\u00dft eine L\u00fccke, die jahrelang offen war: Erstmals tragen die Hersteller die Verantwortung f\u00fcr die Sicherheit ihrer digitalen Produkte \u00fcber deren gesamten Lebenszyklus”, lautet sinngem\u00e4\u00df die Positionierung der Europ\u00e4ischen Kommission, die den CRA als notwendige Erg\u00e4nzung zu NIS2 versteht.<\/p>\n\n\n\n

Aus der deutschen Wirtschaft kommen gemischte T\u00f6ne. Der Digitalverband Bitkom unterst\u00fctzt das Ziel sicherer Produkte, warnt aber seit Jahren vor dem b\u00fcrokratischen Aufwand. “Gerade f\u00fcr den Mittelstand sind die Dokumentations- und Nachweispflichten eine erhebliche Belastung. Wir brauchen praxistaugliche harmonisierte Normen und klare Leitlinien, sonst droht Rechtsunsicherheit”, lautet die wiederkehrende Position des Verbands. \u00c4hnlich \u00e4u\u00dfern sich Branchenvertreter aus dem Maschinenbau, die auf die Doppelbelastung durch CRA und NIS2 verweisen.<\/p>\n\n\n\n

Aus der Open-Source-Welt \u00fcberwiegt vorsichtige Erleichterung. Mike Milinkovich, langj\u00e4hriger Gesch\u00e4ftsf\u00fchrer der Eclipse Foundation, hatte sich intensiv f\u00fcr die Steward-Regelung eingesetzt und bewertet das Ergebnis als tragf\u00e4higen Kompromiss, der ehrenamtliche Entwickler sch\u00fctzt und zugleich Verantwortung dort verankert, wo Geld verdient wird. Das BSI wiederum betont seine Rolle als Aufsichts- und Unterst\u00fctzungsbeh\u00f6rde und verweist Hersteller fr\u00fchzeitig auf den Aufbau von Schwachstellenmanagement und Meldeprozessen.<\/p>\n\n\n\n

Auswirkungen auf den deutschen Markt und den Mittelstand<\/h2>\n\n\n\n

Deutschland ist als Industrie- und Exportnation besonders betroffen. Maschinenbau, Automatisierungstechnik, Medizinger\u00e4tehersteller mit digitalen Komponenten, IoT-Anbieter und Softwareh\u00e4user fallen in gro\u00dfer Zahl unter den CRA. Da die Verordnung an das Inverkehrbringen auf dem EU-Markt ankn\u00fcpft, gilt sie unabh\u00e4ngig vom Sitz des Herstellers. Ein US-amerikanischer oder asiatischer Anbieter, der in die EU verkauft, muss dieselben Anforderungen erf\u00fcllen wie ein deutscher.<\/p>\n\n\n\n

F\u00fcr den Mittelstand liegt die H\u00fcrde weniger im Prinzip als im Aufwand. Security by Design, SBOMs, Schwachstellenmanagement und ein 24-Stunden-Meldeprozess setzen Prozesse und Personal voraus, die in kleineren Unternehmen oft fehlen. Anders als Gro\u00dfkonzerne k\u00f6nnen viele Mittelst\u00e4ndler keine eigene Produktsicherheitsabteilung aufbauen. Der Markt f\u00fcr CRA-Beratung, automatisierte SBOM-Werkzeuge und Schwachstellen-Monitoring w\u00e4chst entsprechend, \u00e4hnlich wie es bei der NIS2-Welle zu beobachten war.<\/p>\n\n\n\n

Hinzu kommt der Zeitdruck. Produkte mit langen Entwicklungszyklen, etwa Industriesteuerungen oder Medizintechnik, die heute geplant werden, m\u00fcssen bei Markteinf\u00fchrung nach Dezember 2027 bereits CRA-konform sein. Wer jetzt nicht plant, baut Produkte, die er sp\u00e4ter nicht verkaufen darf. Diese Vorlaufzeit erkl\u00e4rt, warum der CRA trotz der scheinbar fernen Vollanwendung schon heute Investitionsentscheidungen pr\u00e4gt.<\/p>\n\n\n\n

Historischer Kontext: Von Log4Shell zur Produkthaftung<\/h2>\n\n\n\n

Der CRA ist keine Idee aus dem Nichts. Er ist die regulatorische Antwort auf eine Serie von Vorf\u00e4llen, die gezeigt haben, wie verwundbar digitale Lieferketten sind. Die Log4Shell-Schwachstelle Ende 2021 in der weit verbreiteten Java-Bibliothek Log4j legte offen, dass eine einzige Komponente Millionen von Systemen weltweit gef\u00e4hrden kann. SolarWinds, Kaseya und zahllose IoT-Botnetze aus unsicheren Billigger\u00e4ten verst\u00e4rkten den Eindruck, dass Marktkr\u00e4fte allein keine Produktsicherheit erzeugen.<\/p>\n\n\n\n

Der Grundgedanke des CRA spiegelt damit eine \u00e4ltere Entwicklung: die \u00dcbertragung von Produkthaftungslogik auf Software. Jahrzehntelang wurde Software per Lizenzvertrag praktisch ohne Sicherheitsgew\u00e4hr verkauft. Der CRA dreht dieses Verh\u00e4ltnis um. Sicherheit wird zur Produkteigenschaft, die nachweisbar sein muss, vergleichbar mit der elektrischen Sicherheit eines Haushaltsger\u00e4ts. Die j\u00e4hrliche Bedrohungsbilanz, dokumentiert etwa im BSI-Lagebericht<\/a>, lieferte die empirische Begr\u00fcndung f\u00fcr diesen Paradigmenwechsel.<\/p>\n\n\n\n

International steht die EU mit diesem Ansatz nicht allein, aber an der Spitze. Gro\u00dfbritannien hat mit dem PSTI Act \u00e4hnliche, aber engere Regeln f\u00fcr Verbraucherger\u00e4te erlassen. Die USA setzen bislang st\u00e4rker auf freiwillige Programme wie das Cyber Trust Mark. Der CRA ist der bisher umfassendste Versuch, verbindliche Mindeststandards \u00fcber eine ganze Produktwelt zu legen, und d\u00fcrfte wie schon die DSGVO globale Wirkung entfalten.<\/p>\n\n\n\n

Was Hersteller jetzt tun sollten: Vorbereitung auf September 2026<\/h2>\n\n\n\n

Mit 90 Tagen bis zur Meldepflicht ist Vorbereitung kein Zukunftsthema mehr. Der erste Schritt ist die Bestandsaufnahme: Welche Produkte fallen in den Anwendungsbereich, und in welche Klasse geh\u00f6ren sie? Erst diese Einordnung zeigt, ob eine Selbstbewertung gen\u00fcgt oder eine benannte Stelle eingebunden werden muss. Parallel sollten Hersteller einen Meldeprozess etablieren, der die 24-Stunden-Frist technisch und organisatorisch tragen kann, inklusive klarer Zust\u00e4ndigkeiten und einer Rufbereitschaft.<\/p>\n\n\n\n

Zweiter Schwerpunkt ist die technische Grundlage. Eine vollst\u00e4ndige Software-St\u00fcckliste (SBOM) ist die Voraussetzung daf\u00fcr, im Ernstfall \u00fcberhaupt zu wissen, welche Komponente betroffen ist. Ein kontinuierliches Schwachstellen-Monitoring, das bekannte CVEs gegen den eigenen Produktbestand abgleicht, macht aus der Pflicht einen funktionierenden Prozess. Wer eine Software-St\u00fcckliste pflegt, kryptografische Verfahren korrekt einsetzt und Updates signiert ausliefert, erf\u00fcllt einen Gro\u00dfteil der wesentlichen Anforderungen aus Anhang I.<\/p>\n\n\n\n

# Beispiel: SBOM im CycloneDX-Format mit dem Open-Source-Werkzeug Syft erzeugen\nsyft packages dir:.\/mein-produkt -o cyclonedx-json > sbom.json\n\n# Anschliessend gegen bekannte Schwachstellen pruefen (Grype)\ngrype sbom:.\/sbom.json --fail-on high<\/code><\/pre>\n\n\n\n
Dritter Punkt ist die Dokumentation. Der CRA verlangt eine technische Dokumentation, die Konformit\u00e4t nachweist, sowie eine EU-Konformit\u00e4tserkl\u00e4rung als Grundlage der CE-Kennzeichnung. Wer diese Unterlagen fr\u00fch anlegt und mit jedem Release fortschreibt, vermeidet den Stau kurz vor Dezember 2027. Unternehmen, die bereits NIS2-Prozesse aufgebaut haben, k\u00f6nnen viele Bausteine wiederverwenden, da sich Risikomanagement und Meldewege \u00fcberschneiden.<\/p>\n\n\n\n
F\u00fcnf Prognosen: Wie sich der CRA bis 2028 entwickelt<\/h2>\n\n\n\n
Erstens:<\/strong> Die harmonisierten Normen werden zum Engpass. Ohne fertige, anwendbare Normen m\u00fcssen Hersteller die abstrakten Anforderungen aus Anhang I selbst interpretieren. Verz\u00f6gerungen bei den Normungsgremien CEN und CENELEC d\u00fcrften die Praxis bis weit ins Jahr 2027 hinein pr\u00e4gen und f\u00fcr Rechtsunsicherheit sorgen.<\/p>\n\n\n\n
Zweitens:<\/strong> Die Meldepflicht ab September 2026 wird die Zahl der offiziell gemeldeten Schwachstellen sprunghaft erh\u00f6hen. ENISA und die nationalen CSIRTs werden eine deutlich h\u00f6here Meldelast verarbeiten m\u00fcssen, was Fragen nach Kapazit\u00e4t und Vertraulichkeit der eingehenden Daten aufwirft.<\/p>\n\n\n\n
Drittens:<\/strong> Ein Markt f\u00fcr CRA-Compliance-Werkzeuge wird entstehen, der SBOM-Generierung, Schwachstellen-Monitoring und automatisierte Dokumentation b\u00fcndelt. Anbieter, die NIS2- und CRA-Compliance in einer Plattform verbinden, d\u00fcrften im DACH-Mittelstand besonders gefragt sein.<\/p>\n\n\n\n
Viertens:<\/strong> Die ersten Durchsetzungsf\u00e4lle werden fr\u00fchestens 2028 \u00f6ffentlich sichtbar. Markt\u00fcberwachungsbeh\u00f6rden werden zun\u00e4chst auf grobe Verst\u00f6\u00dfe und nicht-konforme Importprodukte zielen, bevor sie sich an komplexe Einzelf\u00e4lle wagen. Der Abschreckungseffekt entsteht durch wenige medienwirksame F\u00e4lle.<\/p>\n\n\n\n
F\u00fcnftens:<\/strong> Der Br\u00fcssel-Effekt wird sich wiederholen. Globale Hersteller werden CRA-Anforderungen aus Effizienzgr\u00fcnden weltweit anwenden, statt EU-Sonderversionen zu pflegen. Damit wird der CRA, \u00e4hnlich der DSGVO, faktisch zum globalen Mindeststandard f\u00fcr Produktsicherheit.<\/p>\n\n\n\n
H\u00e4ufige Fragen zum Cyber Resilience Act (FAQ)<\/h2>\n\n\n\n
Ab wann gilt der Cyber Resilience Act konkret?<\/h3>\n\n\n\n
Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten f\u00fcr Schwachstellen und Vorf\u00e4lle gelten ab dem 11. September 2026. Alle \u00fcbrigen Pflichten, einschlie\u00dflich der Konformit\u00e4tsbewertung und CE-Kennzeichnung, gelten ab dem 11. Dezember 2027.<\/p>\n\n\n\n
Welche Produkte fallen unter den CRA?<\/h3>\n\n\n\n
Alle Produkte mit digitalen Elementen, also Hardware und Software, die direkt oder indirekt mit einem Netzwerk verbunden werden k\u00f6nnen. Ausgenommen sind Produkte, die bereits eigenen Regimen unterliegen, etwa Medizinprodukte, Kraftfahrzeuge, Luftfahrt und bestimmte Open-Source-Software ohne kommerziellen Vertrieb.<\/p>\n\n\n\n
Wie hoch sind die Bu\u00dfgelder?<\/h3>\n\n\n\n
Bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes bei Verst\u00f6\u00dfen gegen die wesentlichen Anforderungen. Bis zu 10 Millionen Euro oder 2 Prozent bei sonstigen Pflichtverst\u00f6\u00dfen. Bis zu 5 Millionen Euro oder 1 Prozent bei falschen Angaben gegen\u00fcber Beh\u00f6rden.<\/p>\n\n\n\n
Was ist der Unterschied zwischen CRA und NIS2?<\/h3>\n\n\n\n
Der CRA reguliert Produkte und ihre Hersteller, NIS2 reguliert die Betreiber von Einrichtungen und ihre internen Systeme. Ein Unternehmen kann von beiden zugleich betroffen sein: als Betreiber unter NIS2 und als Hersteller unter CRA.<\/p>\n\n\n\n
Sind Open-Source-Entwickler vom CRA betroffen?<\/h3>\n\n\n\n
Rein nicht-kommerzielle Einzelentwickler fallen nicht unter die vollen Herstellerpflichten und k\u00f6nnen nicht mit Bu\u00dfgeldern belegt werden. Organisationen, die Open-Source-Software systematisch unterst\u00fctzen (Open-Source-Software-Verwalter), unterliegen leichteren, angepassten Pflichten.<\/p>\n\n\n\n
Was muss ich bis September 2026 vorbereiten?<\/h3>\n\n\n\n
Vor allem einen funktionierenden Meldeprozess f\u00fcr aktiv ausgenutzte Schwachstellen mit 24-Stunden-Fr\u00fchwarnung, dazu eine Software-St\u00fcckliste (SBOM) und ein kontinuierliches Schwachstellen-Monitoring. Diese Bausteine bilden die Grundlage f\u00fcr die Meldepflicht und die sp\u00e4tere Vollanwendung.<\/p>\n\n\n\n
Verwandte Beitr\u00e4ge<\/h3>\n\n\n\n