Was Hersteller jetzt melden müssen, welche Fristen gelten und welche Pflichten im Dezember 2027 hinzukommen.
Ob Banking-Software, Kunden-App, Kartenleser oder Token: Wer Produkte mit digitalen Elementen entwickelt, unter eigener Marke vertreibt oder an Kunden weitergibt, für den ist der Cyber Resilience Act (CRA) relevant. Für Hersteller gilt seit dem 11. September 2026 die Frühwarnpflicht binnen 24 Stunden an das Bundesamt für Sicherheit in der Informationstechnik (BSI) und die Agentur der Europäischen Union für Cybersicherheit (ENISA). Bei Finanzunternehmen kommt dieser Meldeweg zum bereits etablierten im Rahmen des Digital Operational Resilience Act (DORA) hinzu, er ersetzt ihn nicht.
Artikel 14 des CRA (Verordnung (EU) 2024/2847) gilt seit dem 11. September 2026. Er ist die erste Pflicht aus dem CRA, die Unternehmen trifft, und sie trifft ausschließlich Hersteller. Händler und Einführer haben bis zum 11. Dezember 2027 keine eigenen Pflichten aus dem CRA. Die Produktanforderungen, die Konformitätsbewertung, die CE-Kennzeichnung und die Sanktionen folgen nach Artikel 71 am 11. Dezember 2027.
Gemeldet wird über die CRA Single Reporting Platform der ENISA.
Der CRA knüpft die Rolle an das Produkt und an den Umgang damit, nicht an die Branche.
Software, die ein Unternehmen entwickelt und an Kunden ausliefert, ist ein Produkt mit digitalen Elementen. Ob sie im Rechenzentrum des Kunden installiert wird, als Desktop-Client läuft oder als App auf dem Smartphone, spielt keine Rolle. Dasselbe gilt für Komponenten, die andere in ihre Produkte einbauen, ein Zahlungsmodul oder eine Bibliothek, auch wenn der Endkunde sie nie sieht. Das Unternehmen ist Hersteller und seit dem 11. September meldepflichtig. Erfasst ist auch das Backend, wenn es vom Hersteller oder in seiner Verantwortung entwickelt wurde und die Software ohne es eine ihrer Funktionen nicht erfüllen könnte.
Hier kommt es darauf an, wie das Produkt ins Unternehmen gekommen ist. Wurde es bei einem Dienstleister nach eigenen Vorgaben gebaut und wird es unter eigenem Namen vermarktet, ist das Unternehmen Hersteller und somit seit dem 11. September meldepflichtig. Wurde dagegen ein fertiges Produkt aus dem Katalog eines anderen Herstellers übernommen und nur mit der eigenen Marke versehen, etwa ein Standard-Kartenleser, greifen ab dem 11. Dezember 2027 nach Artikel 21 ebenfalls die Herstellerpflichten. Bis dahin besteht für dieses Produkt keine Meldepflicht. Als vereinfachte Faustregel, die Verordnung zieht die Grenze nicht ausdrücklich: Hat das Unternehmen Anforderungen vorgegeben und der Lieferant danach gebaut, ist es Hersteller. Wurde ein bestehendes Produkt nur mit dem eigenen Logo versehen, greift Artikel 21.
Gibt ein Unternehmen Kartenleser, Token oder Software eines Herstellers unverändert und unter dessen Namen an Kunden aus, ist es Händler. Bezieht es das Produkt direkt von einem Hersteller außerhalb der EU und bringt es als Erstes auf den EU-Markt, ist es Einführer. Ob die Kunden dafür zahlen, spielt keine Rolle, der CRA erfasst auch die kostenlose Abgabe im Rahmen der Geschäftstätigkeit. Die Pflichten für Händler und Einführer gelten ab dem 11. Dezember 2027, die Übersicht unten zeigt sie.
Software, die ein Unternehmen nur intern nutzt und nicht an Dritte gibt, fällt nicht unter den CRA. Das gilt auch für Online-Banking oder Kundenportale, die ausschließlich im Browser laufen. Der Kunde erhält einen Dienst, kein Produkt, denn reine Software-as-a-Service-Angebote nimmt der CRA aus. Für die Sicherheit dieser Software ist das Unternehmen als Betreiber verantwortlich, bei Finanzunternehmen nach DORA, bei anderen Unternehmen je nach Sektor und Größe nach NIS-2. Wer nur im Browser anbietet und keine App hat, sollte das schriftlich festhalten, damit die Frage nicht bei jeder Prüfung neu aufkommt. Kommt später eine App dazu, gehört ihr Backend zum Produkt, siehe Fall 01.
Hard- oder Software, die ein Unternehmen kauft und selbst nutzt, ohne sie weiterzugeben, macht es weder zum Hersteller noch zum Händler. Der CRA wirkt hier über den Lieferanten: Ab Dezember 2027 darf er nur noch Produkte mit CE-Kennzeichnung nach CRA in Verkehr bringen. Dass das Unternehmen dies beim Einkauf einfordert und dokumentiert, verlangt nicht der CRA, sondern bei Finanzunternehmen die Due Diligence nach DORA. Die Beschaffungsvorgaben sollten bis dahin darauf umgestellt sein.
Die fünf Fälle zeigen, wo ein Unternehmen steht. Die Übersicht zeigt, was daraus folgt. Der CRA kennt drei Rollen in der Lieferkette, und jede hat eigene Pflichten und einen eigenen Starttermin. Ein Unternehmen kann mehrere Rollen zugleich haben, je Produkt eine. Wer eine eigene App im Store hat und daneben Kartenleser eines anderen Herstellers ausgibt, ist für das eine Hersteller und für das andere Händler.
Zwei Ereignisse lösen die Pflicht aus: eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen und ein schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit. Aktiv ausgenutzt heißt nach dem CRA, dass verlässliche Nachweise vorliegen, dass jemand die Schwachstelle ohne Zustimmung des Systemeigners tatsächlich genutzt hat.
Die 24 Stunden sind die äußere Grenze, die Frühwarnung ist ohne unangemessene Verzögerung abzugeben. Eine Werktagsregel gibt es nicht: Wer am Freitagabend Kenntnis erlangt, hat spätestens am Samstagabend gemeldet. Kenntnis meint dabei nach den Leitlinien der EU-Kommission vom 27. Juli 2026 nicht den ersten Hinweis, sondern den Zeitpunkt, an dem der Hersteller nach einer ersten Prüfung mit hinreichender Sicherheit von einer aktiven Ausnutzung ausgeht. Die Erstbewertung liegt damit vor der Frist. Sie darf aber nicht hinausgezögert werden, um den Fristbeginn zu verschieben. Wer einen Hinweis liegen lässt, kann sich später nicht darauf berufen, die 24 Stunden hätten noch nicht begonnen.
Getrennt davon sind die betroffenen Nutzer ohne unangemessene Verzögerung über die Schwachstelle oder den Vorfall und über verfügbare Korrekturmaßnahmen zu informieren. Dafür nennt der CRA keine Stundenfrist.
Artikel 14 gilt nach Artikel 69 Absatz 3 auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, also für alles, was heute schon im Markt ist. Für die einzelne Meldung kommt es darauf an, wann der Hersteller belastbare Kenntnis von der aktiven Ausnutzung oder dem Vorfall erlangt. Eine Ausnutzung, die vor dem 11. September 2026 bekannt war und abgeschlossen ist, löst keine Nachmeldung aus. Bei fortdauernder oder neu festgestellter Ausnutzung ist die Meldepflicht anhand des aktuellen Kenntnisstands zu prüfen, und im Zweifel gehört der Fall früh in die rechtliche und technische Bewertung, nicht in die Ablage.
Dasselbe Ereignis, zwei Uhren. Für ein Finanzunternehmen mit eigener Software im Markt kann ein einziges Ereignis zwei Meldungen auslösen. Unter DORA ist ein schwerwiegender IKT-Vorfall binnen vier Stunden nach Klassifizierung an die BaFin zu melden. Unter dem CRA ist das Unternehmen Hersteller und meldet eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden nach Kenntnis an BSI und ENISA. Die Auslöser sind verschieden, und auch die Fristen laufen nicht gleich: DORA erlaubt es, eine Meldung bis 12 Uhr des nächsten Arbeitstags abzugeben, wenn die Frist auf ein Wochenende oder einen Feiertag fällt. Für Kreditinstitute, zentrale Gegenparteien, Handelsplätze und NIS-2-Einrichtungen gilt das bei Erst- und Zwischenmeldung nicht. Der CRA kennt eine solche Regel für niemanden. DORA fragt, ob kritische Dienste betroffen sind und ob ein böswilliger Zugriff auf die eigenen Systeme stattgefunden hat oder Schwellen bei Kunden, Dauer oder Schaden gerissen sind. Der CRA fragt, ob eine Schwachstelle im eigenen Produkt ausgenutzt wird. Drei Beispiele zeigen, wie die Auslöser auseinanderfallen:
Ein Angreifer nutzt eine Schwachstelle in der eigenen Banking-App und kommt an Kundendaten in den eigenen Systemen.
Warum: CRA wegen der aktiven Ausnutzung im Produkt. DORA, weil ein erfolgreicher böswilliger Zugriff auf Systeme, die kritische Dienste stützen, nach Artikel 8 der Delegierten Verordnung 2024/1772 als schwerwiegend einzustufen ist.
Eine Schwachstelle in der eigenen Info-App wird ausgenutzt, die App stützt keine kritische oder wichtige Funktion.
Warum: CRA wegen der Ausnutzung. DORA nicht, solange kein kritischer Dienst betroffen ist. Ob das so ist, entscheidet die Funktion der App, nicht ihr Name.
Das Kernbanksystem fällt vier Stunden aus, die eigene Software ist nicht die Ursache.
Warum: DORA, sofern die Klassifizierungsschwellen zu Dauer und betroffenen Diensten erreicht sind. CRA nicht, weil kein Produkt des Unternehmens beteiligt ist.
Wer beide Meldewege in einer Vorfallorganisation zusammenführt, braucht eine Entscheidungsregel, die bei jedem Ereignis beide Fragen stellt.
Die Plattform ist zentral, EU-weit einheitlich und englischsprachig. Eine Meldung, sie erreicht gleichzeitig das koordinierende CSIRT und die ENISA. Zuständig ist das CSIRT des Mitgliedstaats, in dem die wesentlichen Entscheidungen zur Cybersicherheit der Produkte getroffen werden. In Deutschland ist das das CERT-Bund im BSI. Die Bundesregierung hat das BSI gegenüber der Europäischen Kommission als notifizierende Behörde und als Marktüberwachungsbehörde für den CRA benannt. Die Marktüberwachung übernimmt das BSI ab dem 11. Dezember 2027.
Der Zugang läuft über ein EU-Login mit Multi-Faktor-Authentifizierung. Eine vorherige Registrierung ist nicht nötig, laut BSI dauern Registrierung und Meldung im Bedarfsfall wenige Minuten. Nach Auswahl des CSIRT und Eingabe der Herstellerdaten ist die Meldung sofort möglich. Ob die meldende Person für diesen Hersteller melden darf, prüft das CSIRT danach, parallel zur Meldung. Die ENISA rät ausdrücklich, sich erst zu registrieren, wenn eine Meldung ansteht. Für die Vertretung heißt das: Eine zweite Person kann als Backup erst eingeladen werden, wenn die erste bestätigt ist. Wer am Wochenende handlungsfähig sein will, hält deshalb bei mindestens zwei Personen EU-Login mit MFA, CSIRT-Zuordnung und Herstellerdaten bereit. Die Schritt-für-Schritt-Anleitung der ENISA und ein Video-Tutorial des BSI zeigen den Ablauf, die Technische Richtlinie TR-03183 des BSI ordnet die übrigen Herstellerpflichten ein.
Fünf Punkte, die ohne konkreten Vorfall erledigt werden können und vor der ersten Meldung stehen sollten.
Ab dem 11. Dezember 2027 sieht Artikel 64 für Verstöße gegen die Sicherheitsanforderungen und gegen die Pflichten aus Artikel 13 und 14 Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Bis dahin besteht die Meldepflicht, ohne dass ein Verstoß ein Bußgeld nach Artikel 64 auslöst. Andere Rechtsfolgen, etwa aufsichtliche Maßnahmen nach DORA oder Haftungsfragen, bleiben davon unberührt.
In den 15 Monaten bis dahin lässt sich der Meldeweg unter realen Bedingungen einüben, ohne dass ein Fehler ein Bußgeld nach dem CRA kostet. Die Meldungen gehen an das BSI, und das BSI prüft ab Dezember 2027 auch, ob Produkte die Anforderungen erfüllen. Wer jetzt sauber meldet, hat bis dahin Routine.
Die Meldepflicht ist dabei nur der Anfang. Bis Dezember 2027 folgen für Hersteller die Sicherheitsanforderungen nach Anhang I, das Schwachstellenmanagement über den gesamten Support-Zeitraum, die technische Dokumentation samt Software-Stückliste, die Konformitätsbewertung und die CE-Kennzeichnung. Für Einführer und Händler folgen die Prüf- und Informationspflichten, für alle Unternehmen die Umstellung der Beschaffung.
Wir unterstützen auf dem ganzen Weg: die Rolle je Produkt klären, den Meldeweg und die Entscheidungsregel zu DORA aufsetzen, die Lücke zu Anhang I ermitteln, Konformitätsbewertung und Dokumentation vorbereiten und die Beschaffungsvorgaben anpassen. Wer wissen möchte, wo das eigene Unternehmen steht, kann uns gern ansprechen.
