Cyber Resilience Act: Sicherheitsregeln für vernetzte Geräte und Software (Verordnung (EU) 2024/2847)
Smarte Geräte und Software sollen sicher entwickelt, bei bekannten Lücken betreut und mit einem klaren Support-Ende verkauft werden.
Auf dieser Seite · 16
In 60 Sekunden
- Worum geht es?
- Die EU setzt Sicherheitsregeln für vernetzte Geräte und Software fest. Dazu zählen etwa smarte Kameras, vernetzte Haushaltsgeräte, Betriebssysteme und Apps.
- Wichtigste Änderung
- Hersteller müssen seit dem 11.09.2026 ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden. Ab dem 11.12.2027 gelten umfassende Regeln: Produkte müssen sicher entwickelt werden, erhalten mindestens fünf Jahre lang Sicherheitsupdates und tragen beim Kauf eine Angabe des Support-Endes mit mindestens Monat und Jahr.
- Wer ist betroffen?
- Direkt betroffen sind vor allem Hersteller, Einführer und Händler von Hard- und Software sowie Verwalter quelloffener Software. Käuferinnen und Käufer sollen künftig transparent sehen, wie lange ein Produkt mit Sicherheitsupdates versorgt wird.
Die Zusammenfassung
Die Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung / Cyber Resilience Act, CRA) setzt erstmals EU-weit horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung zu einem Gerät oder Netz einschließt. Sie gilt als EU-Verordnung unmittelbar in allen Mitgliedstaaten. Der CRA trat am 10. Dezember 2024 in Kraft; seine Vorschriften greifen gestaffelt: Das Kapitel IV über die Notifizierung von Konformitätsbewertungsstellen gilt seit dem 11. Juni 2026, die Meldepflichten nach Art. 14 seit dem 11. September 2026 und die allgemeinen Produkt- und Herstellerpflichten ab dem 11. Dezember 2027 (Art. 71). Das deutsche Durchführungsgesetz (BT-Drs. 21/6134) soll die nationalen Zuständigkeiten regeln (u. a. Marktüberwachung durch das BSI), ist jedoch am Stichtag 29.09.2026 noch ein Regierungsentwurf im parlamentarischen Verfahren. [1][3][4][18][27]
Seit dem 11. September 2026 sind die Hersteller-Meldepflichten nach Art. 14 CRA operativ wirksam. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die von der ENISA betriebene zentrale Meldeplattform (Single Reporting Platform) an die zuständigen nationalen CSIRTs und die ENISA melden. Die Fristen sind gesetzlich streng getaktet: eine Frühwarnung unverzüglich, spätestens binnen 24 Stunden, eine ausführliche Meldung spätestens binnen 72 Stunden und ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme. Gemäß Art. 69 Abs. 3 gelten diese Meldepflichten auch für ältere Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. [1][3][4][9]
Ab dem 11. Dezember 2027 müssen Produkte Sicherheitsanforderungen bereits in Konzeption, Entwicklung und Fertigung erfüllen (Security by Design und Security by Default, Anhang I). Hersteller müssen Risiken bewerten, Schwachstellen während des gesamten Unterstützungszeitraums beheben und Sicherheitsupdates bereitstellen. Dieser Unterstützungszeitraum beträgt gemäß Art. 13 Abs. 8 Unterabsatz 3 grundsätzlich mindestens fünf Jahre; wird das Produkt voraussichtlich kürzer genutzt, muss der Zeitraum der erwarteten Nutzungsdauer entsprechen. Beim Kauf muss das Support-Enddatum mit mindestens Monat und Jahr angegeben werden (Art. 13 Abs. 19). Vor dem Inverkehrbringen müssen Hersteller ein Konformitätsbewertungsverfahren durchführen, eine EU-Konformitätserklärung ausstellen und die CE-Kennzeichnung anbringen. Das CE-Zeichen ist eine Konformitätserklärung des Herstellers, kein Garantieversprechen absoluter Angriffssicherheit. [1][3][13]
Für freie und quelloffene Software sieht der CRA differenzierte Regelungen vor: Freie Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, fällt nicht unter die Herstellerpflichten. Juristische Personen, die die Entwicklung von quelloffener Software für gewerbliche Nutzungen dauerhaft und systematisch unterstützen, ohne selbst Hersteller zu sein, werden als „Verwalter quelloffener Software“ (Open-Source-Stewards, Art. 3 Nr. 14, Art. 24) eingestuft. Für sie gelten eigene, angepasste Pflichten (Art. 24) und eine Meldepflicht erst ab Dezember 2027; die Geldbußen nach Art. 64 Abs. 3 bis 9 gelten für sie nicht (Art. 64 Abs. 10). [1][3][10][22]
Bei Verstößen gegen grundlegende Cybersicherheitsanforderungen sieht der CRA Verwaltungsgeldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor, bei sonstigen Pflichtverletzungen bis zu 10 Millionen Euro oder 2 % (Art. 64 Abs. 2 und 3). Für Kleinst- und Kleinunternehmen gelten Ausnahmen bezüglich der Fristen für Frühwarnungen (Art. 64 Abs. 10). Mehrere ergänzende Rechtsakte regeln Details: Die Delegierte Verordnung (EU) 2025/1535 nimmt bestimmte Fahrzeuge aus, die Durchführungsverordnung (EU) 2025/2392 beschreibt wichtige und kritische Produktklassen und die Delegierte Verordnung (EU) 2026/881 bestimmt Kriterien für eine ausnahmsweise verzögerte Weiterleitung von Meldungen durch CSIRTs. Bis zum 11. Dezember 2030 legt die Kommission ihren ersten Gesamtbewertungsbericht zum CRA vor (Art. 70 Abs. 1). [1][6][7][8]
Was steht wirklich drin?
Geltungsbereich für Hard- und Software (Art. 2, 3) [1][3][6]
Der CRA gilt horizontal für alle Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz umfasst. Ausgenommen sind Produkte, die bereits speziellen EU-Cybersicherheitsvorschriften unterliegen (etwa Medizinprodukte, Luftfahrt oder Kraftfahrzeuge; für Fahrzeuge der Klasse L gilt die Ausnahme nach der Delegierten Verordnung (EU) 2025/1535, außer für pedalbetriebene L1e-Fahrzeuge).
Sicherheit von Beginn an (Security by Design, Art. 13, Anhang I) [1][3]
Produkte müssen auf Grundlage einer Cybersicherheits-Risikobewertung so konzipiert, entwickelt und hergestellt werden, dass ein dem Risiko angemessenes Sicherheitsniveau gewährleistet ist. Dazu zählen unter anderem sichere Standardeinstellungen (Security by Default), Schutz vor unbefugtem Zugriff, Vertraulichkeit und Datenintegrität sowie die Kontrolle verwendeter Softwarekomponenten.
Schwachstellenbehandlung und Mindestunterstützungszeitraum (Art. 13 Abs. 8, 19) [1][3]
Hersteller müssen Schwachstellen wirksam behandeln und Sicherheitsupdates bereitstellen. Der Unterstützungszeitraum beträgt gemäß Art. 13 Abs. 8 Unterabsatz 3 mindestens fünf Jahre; wird das Produkt voraussichtlich kürzer genutzt, muss der Zeitraum der erwarteten Nutzungsdauer entsprechen. Das Enddatum des Unterstützungszeitraums muss beim Kauf mit mindestens Monat und Jahr angegeben werden (Art. 13 Abs. 19). Diese Pflichten gelten ab dem 11.12.2027.
Meldepflichten für Schwachstellen und Sicherheitsvorfälle (Art. 14, 16) [1][4][8][9]
Seit dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle unverzüglich, spätestens binnen 24 Stunden (Frühwarnung), und ausführlich binnen 72 Stunden über die zentrale ENISA-Meldeplattform an das zuständige CSIRT und die ENISA melden; ein Abschlussbericht folgt spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme. Gemäß Art. 69 Abs. 3 gelten diese Meldepflichten auch für ältere Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden. Die Delegierte Verordnung (EU) 2026/881 regelt eng begrenzte Ausnahmen für eine vorübergehend verzögerte Weiterleitung durch CSIRTs zur Abwehr von Sicherheitsrisiken.
Konformitätsbewertung und CE-Kennzeichnung (Art. 27–32) [1][3][7]
Vor dem Inverkehrbringen müssen Hersteller die Einhaltung der Anforderungen nachweisen, eine EU-Konformitätserklärung ausstellen und die CE-Kennzeichnung anbringen. Für Standardprodukte genügt meist eine interne Fertigungskontrolle; für wichtige (Klasse I und II) und kritische Produkte nach Durchführungsverordnung (EU) 2025/2392 sind harmonisierte Normen oder Drittprüfungen durch benannte Stellen vorgeschrieben.
Regeln für quelloffene Software und Open-Source-Stewards (Art. 3 Nr. 14, 24) [1][3][10]
Reine, nicht im Rahmen einer geschäftlichen Tätigkeit bereitgestellte freie und quelloffene Software fällt nicht unter die Herstellerpflichten. Juristische Personen, die die Entwicklung von quelloffener Software für gewerbliche Zwecke dauerhaft unterstützen (Verwalter quelloffener Software / Open-Source-Stewards), unterliegen eigenständigen Pflichten (Art. 24) und einer ab 11.12.2027 greifenden Meldepflicht; die Geldbußen nach Art. 64 Abs. 3 bis 9 gelten für sie nicht (Art. 64 Abs. 10).
Marktüberwachung und Geldbußen (Art. 52–64) [1][3][18][27]
Nationale Marktüberwachungsbehörden können Produkte prüfen, Rückrufe verlangen und Geldbußen verhängen. Die Höchstgrenzen liegen bei bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verletzung wesentlicher Anforderungen bzw. bis zu 10 Mio. Euro oder 2 % bei sonstigen Pflichtverletzungen (Art. 64 Abs. 2 und 3). Nach Art. 64 Abs. 10 gelten diese Bußgelder nicht für Kleinst- und Kleinunternehmen bezüglich der Fristen in Art. 14 Abs. 2 Buchst. a und Abs. 4 Buchst. a sowie nicht für Verwalter quelloffener Software bei jedem Verstoß gegen diese Verordnung. Der deutsche Gesetzentwurf (BT-Drs. 21/6134) soll das BSI als zuständige Behörde benennen.
Betroffene Gruppen
Hersteller von vernetzten Geräten und Software
stark betroffenMüssen Risikobeurteilungen, Security by Design, Schwachstellenmanagement, CE-Kennzeichnung und seit 11.09.2026 Vorfallmeldungen umsetzen. [1][3][4]
Kleine und mittlere Unternehmen (KMU) sowie Start-ups
stark betroffenUnterliegen denselben Grundpflichten; bei einzelnen Verfahren und Sanktionen gibt es Sonderregeln, etwa keine Geldbuße nach Art. 64 Abs. 3 bis 9 bei versäumter 24-Stunden-Frist (Art. 64 Abs. 10). [1][3][21][23]
Einführer und Händler (Importeure und Distributoren)
mittel betroffenDürfen nur konforme Produkte mit CE-Kennzeichnung und Support-Hinweisen vertreiben und müssen bei bekannt werdenden Sicherheitsrisiken Kontrollpflichten wahrnehmen. [1][3][13]
Verwalter quelloffener Software (Open-Source-Stewards)
mittel betroffenJuristische Personen, die quelloffene Software für gewerbliche Nutzungen dauerhaft unterstützen, haben eigene Pflichten; die Geldbußen nach Art. 64 Abs. 3 bis 9 gelten für sie nicht (Art. 64 Abs. 10). [1][3][10][22]
Freiwillige Beitragende im Open-Source-Bereich
wenig betroffenEine reine ehrenamtliche Mitarbeit an Projekten ohne gewerbliche Bereitstellung begründet keine Hersteller- oder Steward-Pflichten nach dem CRA. [1][10][22]
Nationale Behörden, CSIRTs, ENISA und Prüfstellen
stark betroffenBetreiben Meldeplattformen, überwachen den Markt und notifizieren Prüfstellen; in Deutschland soll der Entwurf 21/6134 das BSI als zentrale Marktüberwachungsbehörde beauftragen. [1][8][9][18][27]
Verbraucherinnen und Verbraucher
mittel betroffenHaben keine eigenen Pflichten, profitieren jedoch ab 11.12.2027 von transparenter Kennzeichnung des Support-Endes und garantiertem Mindestupdate-Zeitraum. [1][3][13]
Vorher / Nachher
EU-weite Cybersicherheitsregeln für digitale Produkte [1][3][14]
Es gab keinen allgemeinen EU-Rahmen für Cybersicherheitsanforderungen an vernetzte Hard- und Software; Vorgaben bestanden nur sektorspezifisch (z. B. Medizinprodukte).
Der CRA setzt horizontale, EU-weit einheitliche Sicherheitsanforderungen von der Produktentwicklung bis zum Support für alle vernetzten Produkte fest.
Sicherheitsbetreuung und Update-Verpflichtung [1][3]
Den CRA-spezifischen Prozess mit festgelegtem Unterstützungszeitraum und Schwachstellenbehandlung gab es vor dem CRA nicht; andere EU- und nationale Regeln galten daneben.
Hersteller müssen Sicherheitslücken über einen Unterstützungszeitraum von grundsätzlich mindestens fünf Jahren beheben und das Support-Enddatum beim Kauf ausweisen.
Meldung von Schwachstellen und Vorfällen [1][4][9]
Keine zentrale EU-Meldepflicht nach CRA-Art. 14 über eine gemeinsame Plattform; Meldungen richteten sich nach sektoralen oder nationalen Bestimmungen.
Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Vorfälle seit dem 11.09.2026 verbindlich über die zentrale ENISA-Plattform an CSIRTs und ENISA melden.
Auswirkungen
Direkte Folgen
Wahrscheinliche Folgen
Umstrittene Folgen
- Die Kommission und der EP-Berichterstatter erwarten sicherere Lieferketten; Bitkom sieht Mängel bei der praxistauglichen Umsetzung, FSFE und OpenSSF verweisen auf ungeklärte Rollen und Finanzierung in Open-Source-Lieferketten. Eine belastbare Kostenschätzung für alle Betroffenen gibt es nicht. [3][11][21][22][23]
Pro & Contra
Dafür
Einheitliche, verbindliche Sicherheitsanforderungen und garantierte Updates schließen weit verbreitete Sicherheitslücken in vernetzten Produkten und stärken die Cyber-Resilienz im gesamten Binnenmarkt. [3][11][13][21]
Position von: Europäische Kommission und Nicola Danti (EP-Berichterstatter) · mittel belegt
Gegenargument: Rechtliche Pflichten garantieren noch keine fehlerfreien Produkte; laut einer Bitkom-Umfrage (2026, 1.003 Unternehmen ab 10 Beschäftigten) wussten nur 29 % der Unternehmen, was der CRA für sie bedeutet.
Gemeinsame Regeln im Binnenmarkt schützen Verbraucher und sorgen für fairen Wettbewerb, auch bei Importen. [11][21]
Position von: Henna Virkkunen (EVP-Fraktion im Europäischen Parlament) · mittel belegt
Gegenargument: Zusätzliche Prüf- und Dokumentationspflichten verursachen Aufwand; Bitkom sieht noch Mängel bei der praxistauglichen Umsetzung.
Die gezielte Differenzierung zwischen kommerziellen Produkten und nicht-kommerzieller Open Source sowie die Schaffung der Steward-Rolle schützen die Innovationskraft freier Software. [10][11][22]
Position von: Karen Melchior (Renew Europe) und Europäische Kommission · mittel belegt
Gegenargument: Organisationen wie FSFE und OpenSSF betonen, dass die praktische Abgrenzung zwischen ehrenamtlicher Entwicklung und gewerblicher Tätigkeit in komplexen Lieferketten weiterhin Rechtsunsicherheiten birgt.
Dagegen
Das Ziel ist richtig, aber es „hapert“ an der praxistauglichen Umsetzung: Viele Unternehmen sind nicht vorbereitet, und die Meldeplattform ließ sich vor dem Start nicht testen. [1][3][21]
Position von: Bitkom e. V. (Digitalverband) · mittel belegt
Gegenargument: Die Anforderungen sind risikobasiert gestaffelt; für die meisten Produkte genügt ein internes Kontrollverfahren (Art. 32 Abs. 1), und die Produktpflichten gelten erst ab 11.12.2027.
In vernetzten Software-Lieferketten bleibt ungelöst, wie offene Entwicklergemeinschaften den steigenden administrativen Aufwand ohne dauerhafte finanzielle Unterstützung bewältigen sollen. [1][10][22][23]
Position von: Free Software Foundation Europe (FSFE) und OpenSSF · mittel belegt
Gegenargument: Die Herstellerpflicht liegt bei dem Unternehmen, das das Produkt vermarktet; wer nur beiträgt, wird dadurch nicht automatisch Verwalter; für Verwalter gelten die Geldbußen nach Art. 64 Abs. 3 bis 9 nicht (Art. 64 Abs. 10).
Abstimmungsergebnis
Europäisches Parlament (Plenum), 12.03.2024 · Namentliche Abstimmung [12][20][26]
Gesamtergebnis
Fraktionsstärke und Mehrheitsrichtung
- EVP (Christdemokraten)178Dafür
- S&D (Sozialdemokraten)140Dafür
- Renew Europe (Liberale)102Dafür
- Grüne/EFA72Dafür
- EKR/ECR (Konservative)68Dafür
- ID (Rechtsfraktion)59Enthaltung
- Fraktionslos49Dafür
- Die Linke (GUE/NGL)37Enthaltung
Zwei getrennte Größen: oben das amtliche Abstimmungsergebnis, darunter die Fraktionsstärke mit der Mehrheitsrichtung der jeweiligen Fraktion. Die Summen unterscheiden sich, weil nicht alle Abgeordneten teilnahmen und einzelne von ihrer Fraktion abwichen.
Stimmbegründungen
- EVP (Christdemokraten)Dafür
Mehrheit dafür; Henna Virkkunen sprach im Namen der Fraktion für den Kompromiss.
- Verbindliche Sicherheitsanforderungen und regelmäßige Updates für digitale Produkte durchsetzen. [11]
- Fairen Wettbewerb im Binnenmarkt sichern und Schutz vor unsicheren Importen gewährleisten. [11]
- Flexibilität für kleine Unternehmen. [11]
Henna Virkkunen sprach am 11.03.2024 im Namen der Fraktion; das belegt keine Begründung jeder Einzelstimme, 2 Enthaltungen bleiben eigenständig.
- S&D (Sozialdemokraten)Dafür
Mehrheit dafür; Beatrice Covassi sprach im Namen der Fraktion.
- Gemeinsame europäische Cybersicherheitsregeln schaffen und Verbraucher vor Schwachstellen schützen. [11]
- Gezielte Unterstützung, Tests und vereinfachte Konformitätsprüfungen für KMU bereitstellen. [11]
- Sicherheitskompetenzen und Ausbildung im digitalen Bereich europaweit fördern. [11]
Stellungnahme der Fraktionsrednerin in der Plenardebatte vom 11.03.2024; eine Gegenstimme innerhalb der Gruppe wird darin nicht begründet.
- Renew Europe (Liberale)Dafür
Mehrheit dafür; Bart Groothuis und Berichterstatter Nicola Danti befürworteten den Rechtsakt.
- Risiken durch fehlerhafte Produkte und Schwachstellen in vernetzten Lieferketten wirksam abwehren. [11]
- Bürgerinnen, Bürger und Unternehmen schützen. [11]
- Freie und quelloffene Software berücksichtigen. [11]
Die Plenaraussagen spiegeln die Position der Verhandler wider, keine individuelle Stimmerklärung jedes einzelnen Mitglieds.
- Grüne/EFADafür
Mehrheit dafür; Ignazio Corrao sprach im Namen der Fraktion.
- Verbindliche Cybersicherheit über den gesamten Lebenszyklus vernetzter Produkte garantieren. [11]
- Verbraucherschutz durch Transparenz stärken und KMU bei der Umsetzung unterstützen. [11]
- Einen verantwortungsvollen und vorsichtigen Umgang mit sensiblen Schwachstellendaten sichern. [11]
Gruppenäußerung in der Plenardebatte vom 11.03.2024; eine Enthaltung innerhalb der Gruppe wird darin nicht erläutert.
- EKR/ECR (Konservative)Dafür
Mehrheit der abgegebenen Stimmen: dafür; eine gemeinsame Begründung der Fraktion ist nicht belegt.
- Laut amtlicher Namensliste stimmten 51 Mitglieder dafür, 1 dagegen, 10 enthielten sich. [26]
- Eine Erklärung der Fraktion zu dieser Schlussabstimmung wurde in den ausgewerteten Quellen nicht gefunden; das Abstimmungsverhalten allein belegt kein Motiv. [26]
In der Plenardebatte vom 11.03.2024 sprach kein Mitglied dieser Fraktion zum CRA; aus dem Abstimmungsverhalten allein lässt sich kein Motiv ableiten.
- ID (Rechtsfraktion)Enthaltung
Mehrheit der abgegebenen Stimmen: Enthaltung; eine gemeinsame Begründung der Fraktion ist nicht belegt.
- Laut amtlicher Namensliste stimmten 3 Mitglieder dafür, 2 dagegen, 41 enthielten sich. [26]
- Eine Erklärung der Fraktion zu dieser Schlussabstimmung wurde in den ausgewerteten Quellen nicht gefunden; das Abstimmungsverhalten allein belegt kein Motiv. [26]
In der Plenardebatte vom 11.03.2024 sprach kein Mitglied dieser Fraktion zum CRA. Die nachträgliche Stimmabsichts-Korrektur von Gerolf Annemans (ID) zur Enthaltung ändert das amtliche Gesamtergebnis nicht.
- FraktionslosDafür
Mehrheit der abgegebenen Stimmen: dafür; eine gemeinsame Begründung der Fraktion ist nicht belegt.
- Laut amtlicher Namensliste stimmten 28 Mitglieder dafür, 3 dagegen, 5 enthielten sich. [26]
- Eine Erklärung der Fraktion zu dieser Schlussabstimmung wurde in den ausgewerteten Quellen nicht gefunden; das Abstimmungsverhalten allein belegt kein Motiv. [26]
In der Plenardebatte vom 11.03.2024 sprach kein fraktionsloses Mitglied zum CRA. Keine kollektive Stimmbegründung; bei fraktionslosen Abgeordneten gibt es keine gemeinsame politische Linie.
- Die Linke (GUE/NGL)Enthaltung
Mehrheit der abgegebenen Stimmen: Enthaltung; eine gemeinsame Begründung der Fraktion ist nicht belegt.
- Laut amtlicher Namensliste stimmten 8 Mitglieder dafür, 5 dagegen, 19 enthielten sich. [26]
- Eine Erklärung der Fraktion zu dieser Schlussabstimmung wurde in den ausgewerteten Quellen nicht gefunden; das Abstimmungsverhalten allein belegt kein Motiv. [26]
In der Plenardebatte vom 11.03.2024 sprach kein Mitglied dieser Fraktion zum CRA. Die frühere schriftliche Anfrage von Sandra Pereira aus dem Jahr 2023 belegt keine gemeinsame Begründung des späteren Abstimmungsverhaltens der Fraktion.
Erläuterungen
Die Reihenfolge folgt der Fraktionsstärke in dieser Abstimmung, bei Gleichstand dem Alphabet. Sie ist eine Sortierung, keine Wertung.
Zeitlicher Verlauf
Legislativvorschlag der Europäischen Kommission [15]
Die Europäische Kommission legt den Vorschlag COM(2022) 454 final für eine Verordnung über horizontale Cybersicherheitsanforderungen vor.
Ausschussbericht im Europäischen Parlament [16]
Der Ausschuss für Industrie, Forschung und Energie (ITRE) nimmt seinen Bericht A9-0253/2023 zum Cyber Resilience Act an.
Vorläufige politische Einigung im Trilog [14]
Europäisches Parlament und Rat erzielen eine vorläufige Einigung über den gemeinsamen Verordnungstext.
Plenardebatte im Europäischen Parlament [11]
In der Plenaraussprache in Straßburg begründen Berichterstatter und Fraktionsredner ihre Haltung zum Cyber Resilience Act.
Formelle Annahme durch den Rat der Europäischen Union [14]
Der Rat billigt den Standpunkt des Europäischen Parlaments förmlich und schließt das EU-Gesetzgebungsverfahren ab.
Unterzeichnung der Cyberresilienz-Verordnung [1]
Präsidentin des Europäischen Parlaments und Ratsvorsitz unterzeichnen die Verordnung (EU) 2024/2847.
Veröffentlichung im Amtsblatt der Europäischen Union [1]
Die Verordnung (EU) 2024/2847 wird im Amtsblatt ABl. L, 2024/2847 verkündet.
Erlass der Delegierten Verordnung zu Fahrzeugen [6]
Die Kommission erlässt die Delegierte Verordnung (EU) 2025/1535 zur Klarstellung der Bereichsausnahme für Fahrzeuge der Klasse L.
Vorschlag für den Digital Omnibus (COM(2025) 837) [17]
Die Europäische Kommission schlägt eine Vereinheitlichung von Vorfallmeldungen vor; der Entwurf ist am Stichtag nicht beschlossen.
Erlass der Durchführungsverordnung zu Produktklassen [7]
Die Kommission erlässt die Durchführungsverordnung (EU) 2025/2392 mit technischen Beschreibungen wichtiger und kritischer Produktkategorien.
Erlass der Delegierten Verordnung zur Meldungsweitergabe [8]
Die Kommission erlässt die Delegierte Verordnung (EU) 2026/881 zu Kriterien für eine ausnahmsweise verzögerte Weiterleitung durch CSIRTs.
Veröffentlichung von Anwendungshinweisen der Kommission [5]
Die Kommission veröffentlicht unverbindliche Leitlinien zur praktischen Umsetzung und Vorbereitung auf den CRA.
Kommissionsbericht über die Meldeplattform (Art. 70 Abs. 2) [1]
Die Europäische Kommission legt dem Parlament und dem Rat einen Bewertungsbericht über die Funktionsweise und Sicherheit der zentralen Meldeplattform vor.
Erste Gesamtbewertung des CRA durch die Kommission [1]
Frist nach Art. 70 Abs. 1 für den ersten umfassenden Bewertungsbericht der Europäischen Kommission über die Anwendung der Verordnung, danach alle vier Jahre.
Häufige Fragen
Gilt der Cyber Resilience Act bereits?
Teilweise. Die Verordnung trat am 10. Dezember 2024 in Kraft. Seit dem 11. Juni 2026 gelten Regeln zur Notifizierung von Prüfstellen und seit dem 11. September 2026 die Meldepflichten für Hersteller bei aktiv ausgenutzten Schwachstellen. Die grundlegenden Produktanforderungen, die CE-Kennzeichnung und die Update-Pflichten greifen erst ab dem 11. Dezember 2027. [1][3][4]
Welche Produkte fallen unter die neuen Regeln?
Erfasst sind alle Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt – von vernetzten Haushaltsgeräten und Smart-Home-Kameras bis hin zu Betriebssystemen und Apps. Produkte mit eigenen EU-Sicherheitsgesetzen (z. B. Medizinprodukte oder Fahrzeuge) sind ausgenommen. [1][3][6]
Wie lange müssen Hersteller künftig Sicherheitsupdates liefern?
Hersteller müssen den Unterstützungszeitraum festlegen; dieser beträgt grundsätzlich mindestens fünf Jahre (Art. 13 Abs. 8). Wird ein Produkt absehbar kürzer genutzt, muss der Zeitraum der erwarteten Nutzungsdauer entsprechen. Das Support-Ende muss beim Kauf gut sichtbar mit mindestens Monat und Jahr angegeben werden (Art. 13 Abs. 19). Diese Pflichten gelten ab dem 11. Dezember 2027. [1][3]
Bedeutet das CE-Zeichen, dass ein Gerät absolut sicher vor Hackerangriffen ist?
Nein. Die CE-Kennzeichnung ist die rechtsverbindliche Erklärung des Herstellers, dass das Produkt die gesetzlichen Sicherheitsanforderungen erfüllt und das vorgeschriebene Konformitätsbewertungsverfahren durchlaufen hat. Ein absoluter Schutz gegen künftige Angriffsmethoden lässt sich technisch nicht garantieren. [1][3][13]
Müssen Privatpersonen Sicherheitslücken selbst melden?
Nein. Die Pflicht zur Meldung aktiv ausgenutzter Sicherheitslücken und schwerer Vorfälle richtet sich an Hersteller (ab Dezember 2027 auch an Verwalter quelloffener Software). Sicherheitsforscher und Nutzer können Lücken weiterhin freiwillig melden. [1][3][4]
Gilt der Cyber Resilience Act auch für ältere Produkte, die ich schon besitze?
Die ab Dezember 2027 greifenden Produkt- und Kennzeichnungspflichten gelten nicht rückwirkend für bereits verkaufte Altgeräte, es sei denn, sie werden nach diesem Stichtag wesentlich verändert. Die seit dem 11. September 2026 geltenden Meldepflichten für aktiv ausgenutzte Schwachstellen nach Art. 14 gelten jedoch gemäß Art. 69 Abs. 3 auch für ältere, bereits im Markt befindliche Produkte. [1][3][4]
Sind kostenlose Open-Source-Projekte durch den CRA verboten?
Nein. Reine freie und quelloffene Software, die außerhalb einer geschäftlichen Tätigkeit entwickelt oder bereitgestellt wird, fällt nicht unter die Herstellerpflichten des CRA. Wird sie im Rahmen einer Geschäftstätigkeit bereitgestellt oder Teil eines vermarkteten Produkts, trägt dessen Hersteller die Pflichten. Organisationen, die Open-Source-Entwicklung für gewerbliche Nutzungen dauerhaft unterstützen (Verwalter quelloffener Software), haben eigene, angepasste Pflichten. [1][3][10][22]
Welche Strafen drohen bei Verstößen gegen den Cyber Resilience Act?
Bei Verstößen gegen wesentliche Cybersicherheitsanforderungen können Marktüberwachungsbehörden Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes verhängen, bei sonstigen Pflichtverletzungen bis zu 10 Millionen Euro oder 2 % (Art. 64). Für Kleinst- und Kleinunternehmen gelten Ausnahmen bei Fristverletzungen der Erstmeldung; für Verwalter quelloffener Software gelten die Geldbußen nach Art. 64 Abs. 3 bis 9 nicht (Art. 64 Abs. 10). [1][3][18]
Quellen
- [1]Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyberresilienz-Verordnung / CRA) — Amt für Veröffentlichungen der Europäischen Union (EUR-Lex), ABl. L, 2024/2847, 20.11.2024; Art. 1–72 und Anhänge I–VIII ↩
- [2]Konsolidierte Fassung der Verordnung (EU) 2024/2847, Stand 20.11.2024 — Amt für Veröffentlichungen der Europäischen Union (EUR-Lex), konsolidierter Text, Art. 71 ↩
- [3]The Cyber Resilience Act – Summary of the legislative text — Europäische Kommission, GD CONNECT, Kapitel I–VIII, Anhänge I–VIII ↩
- [4]CRA – Reporting obligations — Europäische Kommission, GD CONNECT, Abschnitte What are the main rules? und Where should manufacturers submit? ↩
- [5]CRA – Implementation — Europäische Kommission, GD CONNECT, Abschnitt Progress so far ↩
- [6]Delegierte Verordnung (EU) 2025/1535 (Fahrzeug-Ausnahme) — Amt für Veröffentlichungen der Europäischen Union (EUR-Lex), ABl. L, 2025/1535, Art. 1–2 ↩
- [7]Durchführungsverordnung (EU) 2025/2392 (Produktklassen) — Amt für Veröffentlichungen der Europäischen Union (EUR-Lex), ABl. L, 2025/2392, 01.12.2025, Anhang ↩
- [8]Delegierte Verordnung (EU) 2026/881 (Meldungsweitergabe) — Amt für Veröffentlichungen der Europäischen Union (EUR-Lex), ABl. L, 2026/881, 20.04.2026, Art. 1–6 ↩
- [9]Single Reporting Platform (SRP) — Agentur der Europäischen Union für Cybersicherheit (ENISA), Abschnitte Content und Get Started ↩
- [10]CRA – Open source — Europäische Kommission, GD CONNECT, Abschnitte How does the CRA address free and open-source software? und What are the main obligations? ↩
- [11]Wortprotokoll der EP-Plenardebatte vom 11.03.2024 — Europäisches Parlament / Amt für Veröffentlichungen der EU, ABl. C/2025/1694, Tagesordnungspunkt 13; Reden Danti, Virkkunen, Covassi, Groothuis, Corrao, Melchior ↩
- [12]EP-Protokoll und Abstimmungsergebnis vom 12.03.2024 — Europäisches Parlament / Amt für Veröffentlichungen der EU, ABl. C/2025/01699, TOP 8.11, Anlage I Nr. 11 und Anlage II Nr. 9.1 ↩
- [13]Cyber Resilience Act: MEPs adopt plans to boost security of digital products — Europäisches Parlament, Pressemitteilung des Europäischen Parlaments ↩
- [14]Council adopts new law on security requirements for digital products — Rat der Europäischen Union, Abschnitte Key elements und Background ↩
- [15]COM(2022) 454: Ursprünglicher Kommissionsvorschlag für den Cyber Resilience Act — Europäische Kommission, COM(2022) 454 final, Verfahren 2022/0272(COD) ↩
- [16]Bericht A9-0253/2023 des ITRE-Ausschusses zum Cyber Resilience Act — Europäisches Parlament, ITRE-Ausschuss, Bericht A9-0253/2023, Berichterstatter Nicola Danti ↩
- [17]Digital-Omnibus-Vorschlag COM(2025) 837 — Europäische Kommission / EUR-Lex, COM(2025) 837 final, Vorschlag für ein einheitliches Portal zur Vorfallmeldung ↩
- [18]Regierungsentwurf des deutschen CRA-Durchführungsgesetzes (BT-Drs. 21/6134) — Deutscher Bundestag / Bundesregierung, BT-Drs. 21/6134, Art. 1 und Begründung ↩
- [19]Bundesratsstellungnahme zum Durchführungsgesetz (BT-Drs. 21/6512) — Deutscher Bundestag / Bundesrat, BT-Drs. 21/6512, Unterrichtung durch die Bundesregierung über die Stellungnahme des Bundesrates (BR-Drs. 260/26) ↩
- [20]Namentliche EP-Stimmliste und Korrekturen zum Cyber Resilience Act — Europäisches Parlament / Amt für Veröffentlichungen der EU, ABl. C/2025/01699, Anlage II Nr. 9.1, namentliche Gruppenlisten und Corrections to votes ↩
- [21]Bitkom-Studie: Nur 3 von 10 Unternehmen auf den CRA vorbereitet — Bitkom e. V., Presseinformation und methodische Angaben (Befragung von 1.003 Unternehmen ab 10 Beschäftigten) ↩
- [22]FSFE-Stellungnahme zu Fragen und Herausforderungen des Cyber Resilience Act — Free Software Foundation Europe (FSFE), Abschnitte zur Open-Source-Steward-Rolle und Art. 25 ↩
- [23]OpenSSF-Studie zur Vorbereitung auf den Cyber Resilience Act — Open Source Security Foundation (OpenSSF) / Linux Foundation Research, Abschnitte Awareness and Implementation Readiness ↩
- [24]Schriftliche parlamentarische Anfrage E-002473/2023 zum CRA — Europäisches Parlament, Anfrage E-002473/2023 an die Europäische Kommission ↩
- [25]Analyse bestehender Normen und Lücken für den Cyber Resilience Act — Gemeinsame Forschungsstelle (JRC) / ENISA, Publication details und Abstract ↩
- [26]Ergebnisse der namentlichen Abstimmungen, 12.03.2024 (RCV-XML) — Europäisches Parlament, Identifier 166177, A9-0253/2023 – Nicola Danti – Accord provisoire – Am 2 ↩
- [27]Basisinformationen über den Vorgang: Gesetz zur Durchführung der Verordnung (EU) 2024/2847 (DIP 334566) — Deutscher Bundestag, BR-Drs. 260/26; BT-Drs. 21/6134, 21/6512; PlPr 21/83 ↩
Was kann ich tun?
Amtlichen EU-Verordnungstext nachschlagen
Die verbindlichen Artikel, Fristen und Anhänge der Verordnung (EU) 2024/2847 auf EUR-Lex einsehen.
Kommissionsübersicht zum Cyber Resilience Act lesen
Offizielle Leitfäden und strukturierte Zusammenfassungen der Generaldirektion CONNECT der Europäischen Kommission studieren.
Angaben zum Support-Ende beim Kauf prüfen
Beim Kauf nachfragen, bis wann Sicherheitslücken behoben werden; ab 11.12.2027 muss das Enddatum mit Monat und Jahr angegeben sein.
Meldeportal der ENISA für Hersteller nutzen
Als Hersteller von Produkten mit digitalen Elementen den operativen Meldeweg der Single Reporting Platform (SRP) aufrufen.
Laufendes deutsches Gesetzgebungsverfahren verfolgen
Den Beratungsstand des nationalen Durchführungsgesetzes (BT-Drs. 21/6134) im Dokumentationssystem des Bundestages einsehen.
Glossar
- Produkte mit digitalen Elementen
- Hardware- und Softwareprodukte sowie deren Fernverarbeitungslösungen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung zu einem Gerät oder Netz einschließt.
- CE-Kennzeichnung
- Kennzeichnung, durch die der Hersteller erklärt, dass das Produkt den geltenden Anforderungen aller anwendbaren EU-Harmonisierungsrechtsvorschriften entspricht; sie ist kein Garantieversprechen für absolute Angriffssicherheit.
- Verwalter quelloffener Software (Open-Source-Steward)
- Eine juristische Person, die kein Hersteller ist und die Entwicklung quelloffener Software für gewerbliche Tätigkeiten systematisch und nachhaltig unterstützt; für Verwalter gelten angepasste Pflichten; die Geldbußen nach Art. 64 Abs. 3 bis 9 gelten nicht.
- Schwachstellenbehandlung
- Prozess zur Identifizierung, Meldung, Behebung und Dokumentation von Sicherheitslücken in einem Produkt während des gesamten Unterstützungszeitraums.
- Unterstützungszeitraum
- Der vom Hersteller festgelegte Zeitraum, in dem Sicherheitslücken durch Updates behoben werden; er beträgt grundsätzlich mindestens fünf Jahre und muss beim Kauf mit mindestens Monat und Jahr angegeben werden.
- Konformitätsbewertung
- Verfahren zur Prüfung, ob die wesentlichen Cybersicherheitsanforderungen der Verordnung (EU) 2024/2847 an die Entwicklung und das Schwachstellenmanagement erfüllt sind.
- CSIRT
- Computer Security Incident Response Team; staatliches Notfall- und Reaktionsteam für Cybersicherheitsvorfälle, das Meldungen von Herstellern entgegennimmt und analysiert.
- Single Reporting Platform (SRP)
- Von der ENISA eingerichtete und betriebene zentrale europäische Meldeplattform zur Übermittlung von Schwachstellen- und Vorfallmeldungen an Behörden.
- Harmonisierte europäische Norm
- Von einer anerkannten europäischen Normungsorganisation erarbeitete technische Spezifikation, deren Fundstelle im EU-Amtsblatt veröffentlicht wurde und die eine Konformitätsvermutung begründet.
Korrekturen & Aktualisierungen
Bisher keine Korrekturen oder Aktualisierungen an diesem Dossier.
Fehler melden
Etwas falsch, veraltet oder unklar? Sag uns Bescheid — am besten mit Quelle oder Beleg, damit wir die Korrektur prüfen können. Belegte Korrekturen halten wir im Dossier sichtbar fest.
Hinweis per E-Mail senden