Cyber Resilience Act: €15 Mio. Strafe & Fristen [2026]

Am 11. September 2026 endet die Schonzeit. Ab diesem Tag müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die europäische Cybersicherheitsagentur ENISA und das zuständige 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äte oder Industriekomponenten in der EU verkauft, hat ab diesem Datum kein Wahlrecht mehr.

Der Cyber Resilience Act ist die erste horizontale Produktsicherheitsverordnung der EU, die Cybersicherheit über den gesamten Lebenszyklus eines Produkts vorschreibt. Anders als die NIS2-Richtlinie, die Betreiber kritischer Einrichtungen reguliert, nimmt der CRA die Produkte selbst und ihre Hersteller in die Pflicht. Vom smarten Türschloss bis zur industriellen Steuerung, vom Passwortmanager bis zum Betriebssystem: Fast alles, was Code enthält und mit einem Netzwerk verbunden werden kann, fällt in den Anwendungsbereich. Die Bußgelder reichen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

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 über Erfolg oder Chaos der Umsetzung entscheiden.

Cyber Resilience Act: Was die EU-Verordnung 2024/2847 vorschreibt

Der Cyber Resilience Act ist als Verordnung (EU) 2024/2847 am 20. November 2024 im Amtsblatt der EU veröffentlicht 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ötig wäre. Das beseitigt einen ganzen Streitpunkt: Während Deutschland sein NIS2-Gesetz erst Ende 2025 verabschiedete und damit die EU-Frist um mehr als ein Jahr riss, gilt der CRA für alle Länder zeitgleich nach demselben Wortlaut.

Der Kern der Verordnung sind verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, definiert in Anhang I. Hersteller müssen Produkte sicher entwickeln (Security by Design), sie ohne bekannte ausnutzbare Schwachstellen ausliefern, über den gesamten Support-Zeitraum Sicherheitsupdates bereitstellen und eine Software-Stückliste (SBOM) führen. Die Konformität wird durch die CE-Kennzeichnung dokumentiert, die bislang für die elektrische Sicherheit von Geräten stand und nun um die digitale Sicherheit erweitert wird.

Die Europäische Kommission begründet den Aufwand mit handfesten Zahlen. In ihrer Folgenabschätzung beziffert sie das jährliche Schadenspotenzial von Cyberkriminalität, das der CRA verringern soll, auf eine Größenordnung 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ßen Vorfälle der vergangenen Jahre gezeigt haben.

Die Fristen im Überblick: 11. Juni, 11. September 2026 und 11. Dezember 2027

Der CRA wird gestaffelt scharf gestellt. Drei Daten sind entscheidend, und das erste ist bereits verstrichen. Seit dem 11. Juni 2026 müssen die Mitgliedstaaten die Konformitätsbewertungsstellen (Notified Bodies) benannt haben, die später die Zertifizierung höherklassiger Produkte übernehmen. Ohne diese benannten Stellen kann der spätere Pflichtteil nicht funktionieren, weshalb dieser Termin den Aufbau der Prüfinfrastruktur markiert.

Der nächste, weitaus folgenreichere Stichtag ist der 11. September 2026. Ab dann gelten die Meldepflichten für Hersteller. Wer von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erfährt, muss in einem dreistufigen Verfahren melden. Die vollständige Anwendung aller Pflichten, einschließlich der wesentlichen Sicherheitsanforderungen und der Konformitätsbewertung, folgt am 11. Dezember 2027.

Datum	Pflicht	Wer betroffen ist
10. Dezember 2024	Inkrafttreten der Verordnung (EU) 2024/2847	Alle Hersteller (Vorbereitungsphase)
11. Juni 2026	Benennung der Konformitätsbewertungsstellen	Mitgliedstaaten, Notified Bodies
11. September 2026	Meldepflichten für Schwachstellen und Vorfälle	Alle Hersteller von Produkten mit digitalen Elementen
11. Dezember 2027	Vollständige Anwendung aller CRA-Pflichten	Hersteller, Importeure, Händler

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ößt ab dem ersten Vorfall gegen die Verordnung. Und die technischen und organisatorischen Anforderungen für Dezember 2027, etwa SBOMs und nachweisbare Schwachstellenbehandlung, lassen sich nicht in wenigen Wochen aufbauen.

Bußgelder bis 15 Millionen Euro: Die Sanktionen im Detail

Der CRA staffelt seine Sanktionen nach Schwere des Verstoßes, ähnlich der DSGVO. An der Spitze stehen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Dieser Höchstsatz greift bei Verstößen 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ärteste Strafe.

Eine zweite Stufe sieht bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für Verstöße gegen die übrigen Herstellerpflichten vor. Eine dritte Stufe greift bei falschen, unvollständigen oder irreführenden Angaben gegenüber den Marktüberwachungsbehörden: bis zu 5 Millionen Euro oder 1 Prozent des weltweiten Jahresumsatzes. Für kleine und mittlere Unternehmen sieht die Verordnung vor, dass die Behörden die Verhältnismäßigkeit berücksichtigen.

Verstoß	Bußgeld bis	Anteil Jahresumsatz
Wesentliche Anforderungen (Anhang I), Schwachstellenbehandlung	15 Mio. Euro	2,5 %
Übrige Herstellerpflichten	10 Mio. Euro	2,0 %
Falsche Angaben gegenüber Behörden	5 Mio. Euro	1,0 %

In Deutschland überwacht das Bundesamt für Sicherheit in der Informationstechnik (BSI) zentrale Teile der Umsetzung. Die Marktüberwachungsbehörden können Produkte vom Markt nehmen, Rückrufe anordnen und Bußgelder verhängen. Anders als bei vielen produktrechtlichen Vorschriften betrifft die Sanktion nicht nur den Hersteller, sondern auch Importeure und Händler, die nicht-konforme Produkte in Verkehr bringen.

Die 24-Stunden-Regel: Das dreistufige Meldeverfahren ab September

Das Herzstück der ersten Pflichtphase ist die Meldekette für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle. Sie ist dreistufig aufgebaut und an die Logik anderer EU-Cybergesetze angelehnt, aber mit eigenen Fristen. Stufe eins ist eine Frühwarnung innerhalb von 24 Stunden, nachdem der Hersteller von der aktiven Ausnutzung Kenntnis erlangt. Adressaten sind das zuständige nationale CSIRT und ENISA über eine zentrale Meldeplattform.

Stufe zwei ist eine ausführlichere Schwachstellenmeldung innerhalb von 72 Stunden. Sie muss den allgemeinen Charakter der Schwachstelle, den Stand der Behebung und, soweit bekannt, korrigierende oder mildernde Maßnahmen enthalten. Stufe drei ist ein Abschlussbericht innerhalb von 14 Tagen nach Bereitstellung einer korrigierenden Maßnahme. Er beschreibt die Schwachstelle, ihre Auswirkungen und die ausgerollte Lösung.

Diese 24-Stunden-Frühwarnung 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ür Unternehmen, die bislang keinen formalen Prozess für Schwachstellenmanagement betreiben, ist das ein Kulturwandel. Wer die Mechanik von Schwachstellenbewertung und Offenlegung vertiefen will, findet in unserem Beitrag zur Citrix-NetScaler-Lücke ein konkretes Fallbeispiel für die Geschwindigkeit, mit der heute Lücken ausgenutzt werden.

Produktklassen: Vom Selbsttest bis zur Pflichtzertifizierung

Nicht jedes Produkt durchläuft dieselbe Prüfung. Der CRA gruppiert Produkte mit digitalen Elementen nach Risiko in vier Kategorien, und die Anforderungen steigen mit jeder Stufe. Die Standardkategorie umfasst nach Schätzungen der Kommission rund 90 Prozent aller betroffenen Produkte. Für sie genügt eine Selbstbewertung der Konformität durch den Hersteller, der anschließend die CE-Kennzeichnung anbringt. Dazu zählen etwa Textverarbeitung, Fotobearbeitung oder einfache vernetzte Geräte.

Wichtige Produkte Klasse I und Klasse II

Darüber liegen die wichtigen Produkte. Klasse I umfasst sicherheitsrelevante Software und Geräte wie Passwortmanager, VPN-Software, Virenschutz, Firewalls, Router und Netzwerkmanagement-Systeme. Hier kann der Hersteller die Konformität noch selbst bewerten, wenn er harmonisierte Normen vollständig 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ür sie ist die Einbindung einer benannten Stelle verpflichtend.

Kritische Produkte mit Pflichtzertifizierung

Die höchste Stufe bilden die kritischen Produkte, etwa Hardware-Sicherheitsmodule, Smartcards und Smart-Meter-Gateways. Für sie kann die Kommission eine verpflichtende europäische Cybersicherheitszertifizierung vorschreiben. Diese Abstufung soll den Aufwand dort konzentrieren, wo das Risiko am größten ist, und kleine Anbieter unkritischer Produkte nicht überfordern. Ob die Trennlinien in der Praxis tragen, wird sich erst zeigen, wenn die ersten Produkte durch die Verfahren laufen.

CRA versus NIS2: Produkt gegen Betreiber

Der häufigste 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äuser, Logistiker oder Hersteller ab bestimmten Größen, ihre eigenen Netz- und Informationssysteme abzusichern. Der CRA verpflichtet die Hersteller der Produkte, die diese Organisationen einsetzen.

Ein deutscher Maschinenbauer kann von beiden Regimen zugleich erfasst sein. Als Betreiber muss er unter NIS2 seine internen Systeme härten, Vorfälle 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 überschneiden sich nicht, sie ergänzen sich. Eine Übersicht über die deutsche NIS2-Lage liefert unser Beitrag zur NIS2-Umsetzung in Deutschland.

Merkmal	Cyber Resilience Act	NIS2-Richtlinie
Rechtsform	Verordnung (direkt anwendbar)	Richtlinie (nationale Umsetzung)
Reguliert	Produkte mit digitalen Elementen	Betreiber von Einrichtungen
Adressat	Hersteller, Importeure, Händler	Wesentliche und wichtige Einrichtungen
Höchstbußgeld	15 Mio. Euro / 2,5 % Umsatz	10 Mio. Euro / 2 % Umsatz
Meldefrist (Frühwarnung)	24 Stunden	24 Stunden
Volle Anwendung	11. Dezember 2027	seit 6. Dezember 2025 (DE)

Open Source unter Druck: Der Streit um die Software-Verwalter

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äres Open-Source-Projekt pflegt, das später in tausenden kommerziellen Produkten landet, könnte für Schwachstellen haftbar gemacht werden, ohne je Geld damit verdient zu haben. Die Eclipse Foundation, OpenSSF und zahlreiche Maintainer liefen Sturm.

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ützen, ohne sie kommerziell zu vertreiben, etwa Stiftungen wie Eclipse oder die Apache Software Foundation. Verwalter unterliegen leichteren, angepassten Pflichten und können nicht mit Bußgeldern belegt werden. Rein nicht-kommerzielle Einzelentwickler fallen ganz aus dem Anwendungsbereich.

Damit ist der Streit entschärft, aber nicht beendet. Die Grenzziehung zwischen kommerzieller und nicht-kommerzieller Tätigkeit 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älle klären sollen. Bis dahin herrscht in vielen Projekten Unsicherheit über den eigenen Status.

Was Experten sagen: Stimmen aus Behörden und Wirtschaft

Die Bewertungen des CRA fallen je nach Perspektive unterschiedlich aus. Aus Sicht der EU-Behörden ist die Verordnung ein überfälliger Schritt. “Der Cyber Resilience Act schließt eine Lücke, die jahrelang offen war: Erstmals tragen die Hersteller die Verantwortung für die Sicherheit ihrer digitalen Produkte über deren gesamten Lebenszyklus”, lautet sinngemäß die Positionierung der Europäischen Kommission, die den CRA als notwendige Ergänzung zu NIS2 versteht.

Aus der deutschen Wirtschaft kommen gemischte Töne. Der Digitalverband Bitkom unterstützt das Ziel sicherer Produkte, warnt aber seit Jahren vor dem bürokratischen Aufwand. “Gerade für 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. Ähnlich äußern sich Branchenvertreter aus dem Maschinenbau, die auf die Doppelbelastung durch CRA und NIS2 verweisen.

Aus der Open-Source-Welt überwiegt vorsichtige Erleichterung. Mike Milinkovich, langjähriger Geschäftsführer der Eclipse Foundation, hatte sich intensiv für die Steward-Regelung eingesetzt und bewertet das Ergebnis als tragfähigen Kompromiss, der ehrenamtliche Entwickler schützt und zugleich Verantwortung dort verankert, wo Geld verdient wird. Das BSI wiederum betont seine Rolle als Aufsichts- und Unterstützungsbehörde und verweist Hersteller frühzeitig auf den Aufbau von Schwachstellenmanagement und Meldeprozessen.

Auswirkungen auf den deutschen Markt und den Mittelstand

Deutschland ist als Industrie- und Exportnation besonders betroffen. Maschinenbau, Automatisierungstechnik, Medizingerätehersteller mit digitalen Komponenten, IoT-Anbieter und Softwarehäuser fallen in großer Zahl unter den CRA. Da die Verordnung an das Inverkehrbringen auf dem EU-Markt anknüpft, gilt sie unabhängig vom Sitz des Herstellers. Ein US-amerikanischer oder asiatischer Anbieter, der in die EU verkauft, muss dieselben Anforderungen erfüllen wie ein deutscher.

Für den Mittelstand liegt die Hürde 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ßkonzerne können viele Mittelständler keine eigene Produktsicherheitsabteilung aufbauen. Der Markt für CRA-Beratung, automatisierte SBOM-Werkzeuge und Schwachstellen-Monitoring wächst entsprechend, ähnlich wie es bei der NIS2-Welle zu beobachten war.

Hinzu kommt der Zeitdruck. Produkte mit langen Entwicklungszyklen, etwa Industriesteuerungen oder Medizintechnik, die heute geplant werden, müssen bei Markteinführung nach Dezember 2027 bereits CRA-konform sein. Wer jetzt nicht plant, baut Produkte, die er später nicht verkaufen darf. Diese Vorlaufzeit erklärt, warum der CRA trotz der scheinbar fernen Vollanwendung schon heute Investitionsentscheidungen prägt.

Historischer Kontext: Von Log4Shell zur Produkthaftung

Der CRA ist keine Idee aus dem Nichts. Er ist die regulatorische Antwort auf eine Serie von Vorfällen, 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ährden kann. SolarWinds, Kaseya und zahllose IoT-Botnetze aus unsicheren Billiggeräten verstärkten den Eindruck, dass Marktkräfte allein keine Produktsicherheit erzeugen.

Der Grundgedanke des CRA spiegelt damit eine ältere Entwicklung: die Übertragung von Produkthaftungslogik auf Software. Jahrzehntelang wurde Software per Lizenzvertrag praktisch ohne Sicherheitsgewähr verkauft. Der CRA dreht dieses Verhältnis um. Sicherheit wird zur Produkteigenschaft, die nachweisbar sein muss, vergleichbar mit der elektrischen Sicherheit eines Haushaltsgeräts. Die jährliche Bedrohungsbilanz, dokumentiert etwa im BSI-Lagebericht, lieferte die empirische Begründung für diesen Paradigmenwechsel.

International steht die EU mit diesem Ansatz nicht allein, aber an der Spitze. Großbritannien hat mit dem PSTI Act ähnliche, aber engere Regeln für Verbrauchergeräte erlassen. Die USA setzen bislang stärker auf freiwillige Programme wie das Cyber Trust Mark. Der CRA ist der bisher umfassendste Versuch, verbindliche Mindeststandards über eine ganze Produktwelt zu legen, und dürfte wie schon die DSGVO globale Wirkung entfalten.

Was Hersteller jetzt tun sollten: Vorbereitung auf September 2026

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ören sie? Erst diese Einordnung zeigt, ob eine Selbstbewertung genügt 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ändigkeiten und einer Rufbereitschaft.

Zweiter Schwerpunkt ist die technische Grundlage. Eine vollständige Software-Stückliste (SBOM) ist die Voraussetzung dafür, im Ernstfall überhaupt 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ückliste pflegt, kryptografische Verfahren korrekt einsetzt und Updates signiert ausliefert, erfüllt einen Großteil der wesentlichen Anforderungen aus Anhang I.

# Beispiel: SBOM im CycloneDX-Format mit dem Open-Source-Werkzeug Syft erzeugen
syft packages dir:./mein-produkt -o cyclonedx-json > sbom.json

# Anschliessend gegen bekannte Schwachstellen pruefen (Grype)
grype sbom:./sbom.json --fail-on high

Dritter Punkt ist die Dokumentation. Der CRA verlangt eine technische Dokumentation, die Konformität nachweist, sowie eine EU-Konformitätserklärung als Grundlage der CE-Kennzeichnung. Wer diese Unterlagen früh anlegt und mit jedem Release fortschreibt, vermeidet den Stau kurz vor Dezember 2027. Unternehmen, die bereits NIS2-Prozesse aufgebaut haben, können viele Bausteine wiederverwenden, da sich Risikomanagement und Meldewege überschneiden.

Fünf Prognosen: Wie sich der CRA bis 2028 entwickelt

Erstens: Die harmonisierten Normen werden zum Engpass. Ohne fertige, anwendbare Normen müssen Hersteller die abstrakten Anforderungen aus Anhang I selbst interpretieren. Verzögerungen bei den Normungsgremien CEN und CENELEC dürften die Praxis bis weit ins Jahr 2027 hinein prägen und für Rechtsunsicherheit sorgen.

Zweitens: Die Meldepflicht ab September 2026 wird die Zahl der offiziell gemeldeten Schwachstellen sprunghaft erhöhen. ENISA und die nationalen CSIRTs werden eine deutlich höhere Meldelast verarbeiten müssen, was Fragen nach Kapazität und Vertraulichkeit der eingehenden Daten aufwirft.

Drittens: Ein Markt für CRA-Compliance-Werkzeuge wird entstehen, der SBOM-Generierung, Schwachstellen-Monitoring und automatisierte Dokumentation bündelt. Anbieter, die NIS2- und CRA-Compliance in einer Plattform verbinden, dürften im DACH-Mittelstand besonders gefragt sein.

Viertens: Die ersten Durchsetzungsfälle werden frühestens 2028 öffentlich sichtbar. Marktüberwachungsbehörden werden zunächst auf grobe Verstöße und nicht-konforme Importprodukte zielen, bevor sie sich an komplexe Einzelfälle wagen. Der Abschreckungseffekt entsteht durch wenige medienwirksame Fälle.

Fünftens: Der Brüssel-Effekt wird sich wiederholen. Globale Hersteller werden CRA-Anforderungen aus Effizienzgründen weltweit anwenden, statt EU-Sonderversionen zu pflegen. Damit wird der CRA, ähnlich der DSGVO, faktisch zum globalen Mindeststandard für Produktsicherheit.

Häufige Fragen zum Cyber Resilience Act (FAQ)

Ab wann gilt der Cyber Resilience Act konkret?

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten für Schwachstellen und Vorfälle gelten ab dem 11. September 2026. Alle übrigen Pflichten, einschließlich der Konformitätsbewertung und CE-Kennzeichnung, gelten ab dem 11. Dezember 2027.

Welche Produkte fallen unter den CRA?

Alle Produkte mit digitalen Elementen, also Hardware und Software, die direkt oder indirekt mit einem Netzwerk verbunden werden können. Ausgenommen sind Produkte, die bereits eigenen Regimen unterliegen, etwa Medizinprodukte, Kraftfahrzeuge, Luftfahrt und bestimmte Open-Source-Software ohne kommerziellen Vertrieb.

Wie hoch sind die Bußgelder?

Bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes bei Verstößen gegen die wesentlichen Anforderungen. Bis zu 10 Millionen Euro oder 2 Prozent bei sonstigen Pflichtverstößen. Bis zu 5 Millionen Euro oder 1 Prozent bei falschen Angaben gegenüber Behörden.

Was ist der Unterschied zwischen CRA und NIS2?

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.

Sind Open-Source-Entwickler vom CRA betroffen?

Rein nicht-kommerzielle Einzelentwickler fallen nicht unter die vollen Herstellerpflichten und können nicht mit Bußgeldern belegt werden. Organisationen, die Open-Source-Software systematisch unterstützen (Open-Source-Software-Verwalter), unterliegen leichteren, angepassten Pflichten.

Was muss ich bis September 2026 vorbereiten?

Vor allem einen funktionierenden Meldeprozess für aktiv ausgenutzte Schwachstellen mit 24-Stunden-Frühwarnung, dazu eine Software-Stückliste (SBOM) und ein kontinuierliches Schwachstellen-Monitoring. Diese Bausteine bilden die Grundlage für die Meldepflicht und die spätere Vollanwendung.

Cyber Resilience Act: 90 Tage bis zur Meldepflicht [2026]