News
Der Cyber Resilience Act ist für viele Unternehmen früher praktisch relevant geworden, als es der allgemeine Zeitplan der EU-Verordnung vermuten lässt. Zwar gelten die meisten Anforderungen des CRA erst ab 11. Dezember 2027 vollständig. Eine zentrale Ausnahme ist jedoch seit 11. September 2026 wirksam: Hersteller von Produkten mit digitalen Elementen müssen bestimmte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Grundlage ist Artikel 14 der Verordnung (EU) 2024/2847.
„Wir werden sicherstellen, dass alle digitalen Produkte auf dem EU-Markt vor Cyberbedrohungen geschützt sind.“
Henna Virkkunen, Exekutiv-Vizepräsidentin der Europäischen Kommission für Tech-Souveränität, Sicherheit und Demokratie, anlässlich der CRA-Leitlinien im März 2026.
Damit beginnt für betroffene Unternehmen eine operative Phase des Cyber Resilience Act. Entscheidend ist allerdings die genaue Abgrenzung: Seit September gelten nicht sämtliche Sicherheits-, Dokumentations- und Konformitätsanforderungen des CRA. Neu anwendbar sind insbesondere die gesetzlichen Meldepflichten. Wer Hardware oder Software unter eigenem Namen auf dem EU-Markt anbietet, sollte deshalb prüfen, ob die eigenen Produkte in den Anwendungsbereich fallen und ob für Sicherheitsvorfälle bereits ein belastbarer Meldeprozess vorhanden ist.
Die wichtigsten Punkte im Überblick
-
Meldepflicht seit 11. September 2026
-
Frühwarnung grundsätzlich binnen 24 Stunden
-
Hauptmeldung grundsätzlich binnen 72 Stunden
-
Abschlussberichte folgen nach festen Fristen
-
Meldung erfolgt zentral über ENISA
-
Vollständiger CRA gilt ab Dezember 2027

Was der Cyber Resilience Act regelt
Der CRA schafft erstmals einen horizontalen EU-Rechtsrahmen für die Cybersicherheit von Produkten mit digitalen Elementen. Er erfasst grundsätzlich Hardware- und Softwareprodukte, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Die Verordnung betrifft sowohl fertige Produkte als auch separat in Verkehr gebrachte Hardware- oder Softwarekomponenten.
Infokasten: Was ist ein „Produkt mit digitalen Elementen“?
Der CRA versteht darunter ein Software- oder Hardwareprodukt einschließlich seiner erforderlichen Datenfernverarbeitungslösungen. Dazu können auch einzeln vertriebene Software- oder Hardwarekomponenten gehören. Entscheidend für den Anwendungsbereich ist grundsätzlich auch eine direkte oder indirekte Verbindungsmöglichkeit zu einem Gerät oder Netzwerk.
Der Anwendungsbereich ist entsprechend weit. Die EU-Kommission nennt unter anderem vernetzte Haushaltsgeräte, Computerspiele und mobile Anwendungen als Beispiele für Produktgruppen, die grundsätzlich vom CRA erfasst werden können. Gleichzeitig bestehen gesetzliche Ausnahmen, insbesondere für bestimmte Medizinprodukte und In-vitro-Diagnostika, bestimmte Kraftfahrzeugprodukte, zertifizierte Luftfahrtprodukte sowie Schiffsausrüstung, soweit die jeweils in Artikel 2 genannten EU-Regelwerke greifen. Auch ausschließlich für nationale Sicherheit oder Verteidigung entwickelte oder entsprechend modifizierte Produkte sind ausgenommen.
Praxisbeispiel: Softwareentwicklung und die Frage nach der Herstellerrolle
Wie relevant die Abgrenzung bei modernen Softwareprojekten ist, zeigt der Blick auf Unternehmen wie CPI Technologies. Der Softwareentwickler realisiert unter anderem SaaS-Plattformen, mobile Anwendungen, KI-Systeme sowie Blockchain- und Web3-Lösungen. Gerade bei solchen Projekten ist für den Cyber Resilience Act jedoch entscheidend, die Rollen sauber auseinanderzuhalten: Ein Unternehmen, das Software für einen Auftraggeber entwickelt, ist nicht allein deshalb automatisch Hersteller im Sinne des CRA. Nach der Verordnung ist Hersteller grundsätzlich, wer ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter dem eigenen Namen oder der eigenen Marke vermarktet.
Für Softwareprojekte bedeutet das: Nicht allein die technische Entwicklung entscheidet über die regulatorische Rolle. Maßgeblich ist auch, unter wessen Namen und Verantwortung das konkrete Produkt auf den Markt gelangt. Ob und welche CRA-Pflichten das Unternehmen CPI Technologies, einen Auftraggeber oder andere Beteiligte bei einem bestimmten Projekt treffen, lässt sich deshalb nur anhand des jeweiligen Produkts und der konkreten Rollenverteilung beurteilen.
Wer seit September unmittelbar betroffen ist
Die seit 11. September 2026 geltende Meldepflicht aus Artikel 14 richtet sich an Hersteller. Hersteller ist nach dem CRA nicht nur, wer ein Produkt tatsächlich selbst produziert. Erfasst wird auch, wer ein Produkt entwickeln oder herstellen lässt und es anschließend unter seinem eigenen Namen oder seiner eigenen Marke vermarktet – unabhängig davon, ob das Produkt verkauft, anderweitig monetarisiert oder unentgeltlich angeboten wird.
Das ist für Softwareunternehmen besonders relevant. Ein Unternehmen kann rechtlich Hersteller sein, obwohl wesentliche Teile der Entwicklung durch externe Dienstleister erfolgen. Entscheidend ist die Rolle, unter der das Produkt auf den Markt gelangt.
Eine Besonderheit gilt für sogenannte Open-Source-Software-Stewards. Für sie sieht Artikel 24 eigene Pflichten vor. Deren gesetzliche Meldepflichten beginnen nach Angaben der EU-Kommission und ENISA jedoch erst am 11. Dezember 2027. Wird freie oder quelloffene Software dagegen durch einen Hersteller im Sinne des CRA kommerziell in Verkehr gebracht, können die Herstellerpflichten einschlägig sein. Reine Beiträge zu Open-Source-Projekten, die nicht in der Verantwortung des Entwicklers stehen und nicht im Rahmen einer kommerziellen Bereitstellung erfolgen, behandelt der CRA gesondert.
Was seit 11. September gemeldet werden muss
Artikel 14 unterscheidet im Kern zwei meldepflichtige Sachverhalte: aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen. Nicht jede theoretisch denkbare Sicherheitslücke löst deshalb automatisch die CRA-Meldepflicht aus.
Eine „aktiv ausgenutzte Schwachstelle“ liegt nach der gesetzlichen Definition vor, wenn verlässliche Nachweise dafür bestehen, dass ein böswilliger Akteur die Schwachstelle ohne Zustimmung des Systemeigentümers tatsächlich ausgenutzt hat. Die bloße Existenz einer ausnutzbaren Sicherheitslücke reicht für diese spezielle Meldepflicht damit nicht aus.
Bei Sicherheitsvorfällen setzt Artikel 14 ebenfalls konkrete Voraussetzungen. Ein Vorfall gilt insbesondere als schwerwiegend, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Ebenfalls erfasst sind Vorfälle, die zur Einschleusung oder Ausführung schädlichen Codes im Produkt oder in den Netz- und Informationssystemen eines Nutzers geführt haben oder führen können.
Infokasten: Schwachstelle oder Sicherheitsvorfall?
Eine Schwachstelle ist zunächst eine Schwäche oder ein Fehler, der durch eine Cyberbedrohung ausgenutzt werden kann. Für die seit September geltende Pflicht kommt es bei Schwachstellen auf deren aktive Ausnutzung an. Ein schwerwiegender Vorfall betrifft dagegen ein tatsächliches Sicherheitsereignis mit den in Artikel 14 beschriebenen erheblichen Auswirkungen oder entsprechenden möglichen Auswirkungen.
24 Stunden, 72 Stunden und Abschlussbericht
Besonders relevant für Unternehmen sind die kurzen gesetzlichen Fristen. Sie beginnen grundsätzlich mit der Kenntnis des Herstellers von dem jeweiligen meldepflichtigen Sachverhalt. Artikel 14 verlangt eine gestufte Meldung.
| Stufe | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Sicherheitsvorfall |
|---|---|---|
| Frühwarnung | unverzüglich, spätestens binnen 24 Stunden | unverzüglich, spätestens binnen 24 Stunden |
| Hauptmeldung | unverzüglich, spätestens binnen 72 Stunden | unverzüglich, spätestens binnen 72 Stunden |
| Abschlussbericht | spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme | innerhalb eines Monats nach der 72-Stunden-Meldung |
Bei einer aktiv ausgenutzten Schwachstelle soll die 72-Stunden-Meldung unter anderem Informationen zum betroffenen Produkt, zur Art der Ausnutzung und Schwachstelle sowie zu bereits ergriffenen oder für Nutzer möglichen Korrektur- und Minderungsmaßnahmen enthalten. Der spätere Abschlussbericht umfasst unter anderem Schweregrad und Auswirkungen, gegebenenfalls verfügbare Informationen zum Angreifer und Angaben zu Sicherheitsupdates oder anderen Korrekturmaßnahmen.
Bei einem schwerwiegenden Vorfall enthält die 72-Stunden-Meldung insbesondere Informationen zur Art des Vorfalls, eine erste Bewertung sowie ergriffene und für Nutzer mögliche Gegenmaßnahmen. Der Abschlussbericht muss unter anderem den Vorfall und seine Auswirkungen detailliert beschreiben, die wahrscheinliche Bedrohungsart oder Ursache nennen und die umgesetzten beziehungsweise laufenden Minderungsmaßnahmen darstellen.
Auch die Nutzer müssen informiert werden
Die Meldung an die Behörden ist nicht die einzige Verpflichtung aus Artikel 14. Hat ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem entsprechenden schwerwiegenden Vorfall, muss er auch die betroffenen Nutzer informieren und, soweit angemessen, sämtliche Nutzer des betroffenen Produkts. Erforderlichenfalls müssen dabei auch Maßnahmen erläutert werden, mit denen Nutzer die Auswirkungen begrenzen oder den Fehler beheben können.
Damit enthält der CRA neben der Behördenmeldung eine eigenständige Kommunikationspflicht gegenüber den Nutzern. Meldung an ENISA beziehungsweise das zuständige CSIRT und Information der Betroffenen sind rechtlich nicht dasselbe.
Wo wird gemeldet?
Für die Meldungen hat ENISA die CRA Single Reporting Platform (SRP) eingerichtet. Sie ist seit dem 11. September 2026 operativ. Hersteller sollen ihre verpflichtenden CRA-Meldungen über diese zentrale Plattform einreichen, statt verschiedene nationale Stellen einzeln zu kontaktieren.
Die Meldung wird grundsätzlich dem als Koordinator bestimmten Computer Security Incident Response Team – kurz CSIRT – des Mitgliedstaates zugeordnet, in dem der Hersteller seine Hauptniederlassung in der EU hat. Die Informationen sind grundsätzlich gleichzeitig für ENISA zugänglich; das zuständige CSIRT übernimmt die weitere Verteilung an betroffene Mitgliedstaaten. Für besondere Ausnahmefälle bestehen Regeln, nach denen die Weitergabe bestimmter sensibler Informationen aus Gründen der Cybersicherheit zeitweise verzögert werden kann. Die Einzelheiten wurden durch einen delegierten Rechtsakt der Kommission konkretisiert.
ENISA stellt für die Nutzung der Plattform inzwischen FAQs, Benutzerhandbücher und weitere Hilfestellungen bereit. Für die dafür vorgesehenen Nutzerkonten wird nach den aktuellen ENISA-Hinweisen unter anderem ein EU-Login mit Mehrfaktor-Authentifizierung benötigt.
Infokasten: ENISA, CSIRT und SRP
ENISA ist die Agentur der Europäischen Union für Cybersicherheit. CSIRTs sind nationale beziehungsweise zuständige Teams für die Behandlung von IT-Sicherheitsvorfällen. Die Single Reporting Platform (SRP) ist die von ENISA betriebene zentrale elektronische Plattform für die CRA-Meldungen.
Die Meldepflicht gilt auch für ältere Produkte
Ein Punkt kann leicht übersehen werden: Die neuen Berichtspflichten betreffen nicht nur Produkte, die nach September 2026 oder nach der vollständigen Anwendung des CRA verkauft werden.
Artikel 69 Absatz 3 bestimmt ausdrücklich, dass Artikel 14 auch für Produkte mit digitalen Elementen gilt, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, sofern sie grundsätzlich in den Anwendungsbereich des CRA fallen. Die Übergangsregel, mit der ältere Produkte von einem großen Teil der späteren CRA-Anforderungen ausgenommen werden, schützt deshalb nicht vor den seit September geltenden Meldepflichten.
Das kann praktisch bedeuten, dass Hersteller auch ihren bereits vorhandenen Produktbestand betrachten müssen und nicht nur aktuelle Neuentwicklungen.
Was seit September noch nicht vollständig gilt
Der 11. September 2026 ist nicht der allgemeine Starttermin des gesamten Cyber Resilience Act. Artikel 71 legt die vollständige Anwendung grundsätzlich auf den 11. Dezember 2027 fest. Vorgezogen wurden Artikel 14 mit den beschriebenen Meldepflichten sowie bereits seit 11. Juni 2026 das Kapitel über die Notifizierung von Konformitätsbewertungsstellen.
Die umfassenden Herstelleranforderungen an Produktentwicklung, Cybersicherheitsrisikobewertung, Schwachstellenmanagement, technische Dokumentation, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung gehören damit grundsätzlich zur nächsten Stufe des CRA. Die Kommission weist ausdrücklich darauf hin, dass die Hauptpflichten erst am 11. Dezember 2027 vollständig anwendbar werden.
Das bedeutet allerdings nicht, dass Unternehmen diese Themen bis Ende 2027 ignorieren können. Die Kommission hat bereits im Juli 2026 umfangreiche Leitlinien veröffentlicht, die Unternehmen bei der Vorbereitung unter anderem auf Risikobewertung, Supportzeiträume, Anwendungsbereich und spätere Konformitätsanforderungen unterstützen sollen.
Und was ist mit den hohen CRA-Bußgeldern?
Der CRA enthält einen erheblichen Sanktionsrahmen. Artikel 64 sieht für Verstöße gegen die grundlegenden Cybersicherheitsanforderungen sowie gegen die Verpflichtungen der Artikel 13 und 14 administrative Geldbußen von bis zu 15 Millionen Euro oder – bei Unternehmen – bis zu 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, wobei der höhere Betrag maßgeblich sein kann.
Bei der zeitlichen Einordnung ist jedoch Vorsicht erforderlich. Artikel 71 erklärt zum 11. September 2026 ausdrücklich Artikel 14 für vorzeitig anwendbar; der allgemeine Geltungsbeginn der übrigen Bestimmungen ist der 11. Dezember 2027. Artikel 64 gehört nicht zu den in Artikel 71 ausdrücklich vorgezogenen Vorschriften. Deshalb wäre es verkürzt, die in Artikel 64 genannten CRA-Bußgeldrahmen pauschal als bereits seit September 2026 geltendes Sanktionsregime darzustellen.
Der Verordnungstext enthält zudem eine besondere Regel für Kleinst- und Kleinunternehmen: Für das bloße Verpassen der 24-Stunden-Frist aus Artikel 14 Absatz 2 Buchstabe a beziehungsweise Absatz 4 Buchstabe a sind nach dem korrigierten Artikel 64 Absatz 10 keine administrativen Geldbußen nach Artikel 64 vorgesehen. Die Berichtspflicht selbst entfällt dadurch nicht. Ein offizielles Corrigendum vom 2. Juli 2025 hatte den Wortlaut dieser Ausnahme ausdrücklich korrigiert.
CRA und NIS2 sind nicht dasselbe
Der Cyber Resilience Act ergänzt die europäische Cybersicherheitsregulierung und insbesondere die NIS2-Richtlinie, ersetzt sie aber nicht. Der CRA setzt vor allem beim Produkt und beim Hersteller an: Hardware und Software sollen bestimmte Cybersicherheitsanforderungen erfüllen und Schwachstellen während ihres Lebenszyklus behandelt werden. NIS2 adressiert dagegen bestimmte Unternehmen und Einrichtungen sowie deren Maßnahmen zur Sicherheit von Netz- und Informationssystemen und deren eigene Meldepflichten. Die Kommission bezeichnet den CRA ausdrücklich als Ergänzung zu NIS2.
Unternehmen, die sowohl unter NIS2-Regelungen als auch unter den CRA fallen, müssen deshalb die jeweils einschlägigen Pflichten getrennt prüfen. Eine CRA-Meldung sollte nicht ohne rechtliche Prüfung automatisch als Erfüllung anderer gesetzlicher Meldepflichten behandelt werden.
Was Unternehmen jetzt organisatorisch klären sollten
Aus den seit September geltenden Fristen ergibt sich vor allem ein organisatorisches Thema. Eine 24-Stunden-Frist funktioniert nur, wenn Sicherheitsmeldungen intern schnell erkannt, technisch bewertet und an eine entscheidungsbefugte Stelle weitergegeben werden können. Unternehmen mit Produkten im CRA-Anwendungsbereich sollten deshalb eindeutig festlegen, wer Sicherheitsmeldungen überwacht, wer einen möglichen CRA-Fall rechtlich und technisch bewertet, wer die Meldung freigibt und wer Zugriff auf die ENISA-Plattform besitzt.
Ebenso relevant ist die Produktübersicht. Da Artikel 14 auch bereits vor Dezember 2027 in Verkehr gebrachte Produkte erfasst, sollte nachvollziehbar sein, welche Hard- und Softwareprodukte unter eigenem Namen beziehungsweise eigener Marke auf dem EU-Markt angeboten wurden und für welche Produkte noch Nutzer betroffen sein können. Diese organisatorische Vorbereitung ändert nichts an den gesetzlichen Kriterien für eine Meldung, erleichtert aber die Einhaltung der kurzen gesetzlichen Fristen.
Fazit
Seit dem 11. September 2026 ist der Cyber Resilience Act für Hersteller digitaler Produkte nicht mehr ausschließlich ein Thema für die Vorbereitung auf 2027. Artikel 14 gilt bereits jetzt. Aktiv ausgenutzte Schwachstellen und bestimmte schwerwiegende Sicherheitsvorfälle müssen innerhalb klar definierter Fristen über die zentrale ENISA-Plattform gemeldet werden; zusätzlich können Informationspflichten gegenüber Nutzern entstehen.
Gleichzeitig sollte sauber zwischen dieser ersten Anwendungsstufe und dem vollständigen CRA unterschieden werden. Risikobewertungen, umfassende Produktanforderungen, Konformitätsverfahren und weitere Herstellerpflichten werden grundsätzlich erst mit der vollständigen Anwendung am 11. Dezember 2027 verbindlich. Genau diese zeitliche Trennung ist für Unternehmen derzeit entscheidend.
Nein. Die Verordnung trat am 10. Dezember 2024 in Kraft, gilt grundsätzlich aber erst ab 11. Dezember 2027 vollständig. Artikel 14 mit den Meldepflichten gilt bereits seit 11. September 2026; die Regelungen über die Notifizierung von Konformitätsbewertungsstellen gelten seit 11. Juni 2026.
Nein. Die Pflicht des Artikels 14 erfasst insbesondere aktiv ausgenutzte Schwachstellen. Dafür verlangt die Verordnung verlässliche Nachweise einer tatsächlichen unbefugten Ausnutzung durch einen böswilligen Akteur. Daneben bestehen Meldepflichten für die gesetzlich definierten schwerwiegenden Sicherheitsvorfälle.
Artikel 14 knüpft die Frist an den Zeitpunkt, zu dem der Hersteller von der aktiv ausgenutzten Schwachstelle beziehungsweise dem schwerwiegenden Vorfall Kenntnis erlangt. Die Frühwarnung muss unverzüglich und in jedem Fall spätestens innerhalb von 24 Stunden erfolgen.
Ja. Artikel 69 Absatz 3 stellt ausdrücklich klar, dass die Meldepflichten des Artikels 14 auch für Produkte gelten, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, sofern sie in den sachlichen Anwendungsbereich des CRA fallen.
Nicht pauschal. Für sogenannte Open-Source-Software-Stewards gelten die speziellen Meldepflichten aus Artikel 24 Absatz 3 nach den offiziellen Angaben erst ab 11. Dezember 2027. Hersteller, die ein Open-Source-Produkt im Sinne des CRA kommerziell in Verkehr bringen, können dagegen bereits den Herstellerregelungen unterfallen.
Über die CRA Single Reporting Platform der ENISA. Die Plattform ist seit 11. September 2026 operativ und dient als zentraler elektronischer Meldeweg für die gesetzlichen CRA-Meldungen.
Quellen
Verordnung (EU) 2024/2847 – Cyber Resilience Act, Amtsblatt der Europäischen Union / EUR-Lex, insbesondere Art. 2, 3, 14, 64, 69 und 71.
Europäische Kommission – Cyber Resilience Act: Reporting obligations, aktualisiert am 11. September 2026.
Europäische Kommission – Cyber Resilience Act: Summary of the legislative text.
Europäische Kommission – Frequently Asked Questions on CRA implementation, Stand 4. September 2026.
ENISA – CRA Single Reporting Platform, einschließlich FAQ und Nutzerhinweisen, Stand September 2026.
Corrigendum zur Verordnung (EU) 2024/2847, Amtsblatt der Europäischen Union vom 2. Juli 2025.
Abruf der Quellen: 21. September 2026.
Rechtlicher Hinweis
Dieser Beitrag dient ausschließlich der allgemeinen Information über den Cyber Resilience Act und ersetzt keine rechtliche oder technische Beratung im Einzelfall. Ob ein bestimmtes Unternehmen, Produkt, eine Schwachstelle oder ein Sicherheitsvorfall den Regelungen des CRA unterliegt beziehungsweise eine Meldepflicht auslöst, ist anhand der konkreten Umstände und der jeweils geltenden Rechtslage zu prüfen.







Noch kein Kommentar vorhanden.