Cyber Resilience Act: Meldepflichten für Hersteller ab September
Ab dem 11. September 2026 müssen Hersteller von Software und vernetzter Hardware aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb von 24 Stunden melden. Ab dem 11. Dezember 2027 gelten zusätzlich Sicherheitsanforderungen an Entwicklung, Updates, Dokumentation und CE-Kennzeichnung.
Eine Schonfrist für Produkte, die schon auf dem Markt sind, gibt es bei der Meldepflicht nicht: Sie gilt ab dem 11. September 2026 auch für Software und Geräte, die vorher verkauft wurden (Art. 69 Abs. 3 CRA). Wer bis dahin nicht festgelegt hat, wer im Unternehmen einen Hinweis auf eine Schwachstelle annimmt, bewertet und binnen 24 Stunden meldet, merkt das spätestens an einem Freitagabend.
Der Beitrag ordnet ein, wer als Hersteller gilt und was bis zum 11. September 2026 zu tun ist. Wie wir Sicherheitsanforderungen in Entwicklungsprojekten verankern, beschreibt unsere Seite zu Sicherheit und Compliance.
Der Rahmen
Was der Cyber Resilience Act regelt
Der Cyber Resilience Act (CRA) ist die Verordnung (EU) 2024/2847. Er ist am 10. Dezember 2024 in Kraft getreten und gilt als EU-Verordnung direkt in allen Mitgliedstaaten, ohne Umsetzung in nationales Recht. Er legt Cybersicherheitsanforderungen für „Produkte mit digitalen Elementen“ fest.
Darunter fallen Software- und Hardwareprodukte einschließlich ihrer Lösungen zur Datenfernverarbeitung, sofern sie eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz haben. Beispiele sind Desktop- und Mobil-Apps, installierbare Unternehmenssoftware, Firmware, Router, smarte Haushaltsgeräte und Industriesteuerungen.
Nicht erfasst sind Produkte, für die eigene EU-Regeln gelten: Medizinprodukte und In-vitro-Diagnostika, Kraftfahrzeuge, zertifizierte Luftfahrtprodukte und Schiffsausrüstung. Ausgenommen sind auch Produkte, die ausschließlich für nationale Sicherheit oder Verteidigung entwickelt werden.
Cloud-Dienste, die außerhalb der Verantwortung eines Herstellers entworfen und entwickelt wurden, fallen nicht unter den CRA. Für Cloud-Dienstmodelle wie Software as a Service verweist Erwägungsgrund 12 auf die NIS2-Richtlinie (EU) 2022/2555. Anders liegt es, wenn ein Cloud-Dienst als Datenfernverarbeitung zu einem Produkt gehört, etwa das Backend einer App, ohne das die App eine ihrer Funktionen nicht erfüllen kann (Erwägungsgrund 11 und Art. 3 Nr. 2 CRA).
Rolle klären
Wer als Hersteller gilt
Hersteller ist nach Art. 3 Nr. 13 CRA, wer Produkte mit digitalen Elementen entwickelt oder herstellt oder entwickeln oder herstellen lässt und sie unter eigenem Namen oder eigener Marke vermarktet. Das gilt unabhängig davon, ob das Produkt verkauft, über Werbung oder Daten monetarisiert oder kostenlos abgegeben wird.
Für Unternehmen im Mittelstand ergeben sich daraus einige typische Fälle:
Eigene Software als Produkt: Wer eine Anwendung, App oder Firmware unter eigenem Namen vertreibt, ist Hersteller, auch wenn eine Agentur den Code schreibt.
Vernetzte Geräte: Wer Maschinen, Zähler oder Steuerungen mit Software ausliefert, ist für die Software im Gerät verantwortlich.
Händler und Importeure: Sie haben eigene, geringere Pflichten. Wer ein Produkt unter eigener Marke anbietet oder wesentlich verändert, wird selbst zum Hersteller.
Open Source: Freie Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, ist nicht erfasst. Für Organisationen, die Open-Source-Projekte dauerhaft für die kommerzielle Nutzung unterstützen, gibt es die eigene Rolle „Verwalter quelloffener Software“ mit leichteren Pflichten.
Wenn Sie eine Software in Ihr Produkt einbauen, etwa eine Open-Source-Bibliothek, bleiben Sie für das Gesamtprodukt verantwortlich. Schwachstellen in solchen Komponenten müssen Sie beheben und dem Verantwortlichen der Komponente melden (Art. 13 Abs. 6 CRA).
Ab 11. September 2026
Meldepflichten ab 11. September 2026
Art. 14 CRA gilt nach Art. 71 Abs. 2 ab dem 11. September 2026, und zwar auch für Produkte, die schon vor diesem Datum auf dem Markt waren (Art. 69 Abs. 3 CRA). Zu melden sind zwei Arten von Ereignissen: aktiv ausgenutzte Schwachstellen in Ihrem Produkt und schwere Vorfälle, die die Sicherheit des Produkts beeinträchtigen.
Was als aktiv ausgenutzt und als schwer gilt
Eine Schwachstelle gilt als aktiv ausgenutzt, wenn verlässliche Belege dafür vorliegen, dass ein Angreifer sie in einem System ohne Erlaubnis des Inhabers ausgenutzt hat. Eine bekannte, aber nicht ausgenutzte Lücke löst die Meldepflicht nach Art. 14 noch nicht aus, muss aber im Rahmen Ihrer Schwachstellenbehandlung behoben werden. Ein Vorfall gilt als schwer, wenn er die Verfügbarkeit, Echtheit, Integrität oder Vertraulichkeit wichtiger Daten oder Funktionen des Produkts beeinträchtigt oder beeinträchtigen kann, oder wenn er dazu geführt hat oder führen kann, dass Schadcode in das Produkt oder die Systeme der Nutzer gelangt.
Ein Beispiel: Ein Angreifer verschafft sich Zugang zu Ihrem Update-Server und verteilt eine manipulierte Version Ihrer App. Das ist ein schwerer Vorfall, der gemeldet werden muss, auch wenn noch kein Kunde einen Schaden gemeldet hat.
Die Fristen laufen ab dem Zeitpunkt, an dem Sie Kenntnis erlangen:
Frühwarnung: unverzüglich, spätestens innerhalb von 24 Stunden.
Meldung: spätestens nach 72 Stunden, mit Angaben zum Produkt, zur Art der Ausnutzung und zu ersten Gegenmaßnahmen.
Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur oder Abhilfe verfügbar ist, bei schweren Vorfällen innerhalb eines Monats nach der Meldung.
Gemeldet wird einmal über die zentrale Meldeplattform, die die EU-Agentur für Cybersicherheit ENISA aufbaut. Die Meldung geht an das als Koordinator benannte CSIRT des Mitgliedstaats, in dem Sie Ihre Hauptniederlassung haben, und gleichzeitig an ENISA. Zusätzlich müssen Sie betroffene Nutzer über die Schwachstelle oder den Vorfall und über mögliche Schutzmaßnahmen informieren (Art. 14 Abs. 8 CRA).
Die Pflicht trifft auch kleine Hersteller. Kleinst- und Kleinunternehmen sind lediglich von Bußgeldern ausgenommen, wenn sie die 24-Stunden-Frist der Frühwarnung verpassen (Art. 64 Abs. 10 CRA). Die übrigen Fristen und die Meldung selbst gelten für sie ebenso.
Aktualisierung vom 02.11.2026: Die Meldepflichten gelten seit dem 11.09.2026 unverändert, die zentrale Meldeplattform ist seitdem in Betrieb. Hersteller vernetzter Geräte trifft daneben der EU Data Act, siehe EU Data Act: Was Hersteller vernetzter Geräte leisten müssen. Wer KI-Funktionen in Produkte einbaut, findet die Pflichten der KI-Verordnung im Beitrag EU AI Act: Welche Pflichten ab August 2026 gelten.
Ab 11. Dezember 2027
Was ab Dezember 2027 zusätzlich gilt
Ab dem 11. Dezember 2027 gilt die Verordnung vollständig. Neue Produkte dürfen dann nur noch auf den Markt, wenn sie die grundlegenden Anforderungen aus Anhang I erfüllen. Dazu gehören unter anderem:
Auslieferung ohne bekannte ausnutzbare Schwachstellen und mit sicherer Standardkonfiguration
ein Prozess zur Behandlung von Schwachstellen, einschließlich einer Kontaktstelle für Meldungen von außen
Sicherheitsupdates während eines Unterstützungszeitraums, der mindestens fünf Jahre beträgt (Art. 13 Abs. 8 CRA), kürzer nur bei kürzerer erwarteter Nutzungsdauer
eine Software-Stückliste (SBOM), die zumindest die direkten Abhängigkeiten auflistet
technische Dokumentation, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung
Für die meisten Produkte reicht eine Selbstbewertung. Für bestimmte „wichtige“ und „kritische“ Produkte, etwa Passwortmanager, Firewalls oder Betriebssysteme, verlangt die Verordnung strengere Verfahren, teilweise mit einer benannten Stelle. Die Regeln für diese Prüfstellen gelten schon ab dem 11. Juni 2026.
Verstöße gegen die grundlegenden Anforderungen und gegen die Pflichten aus Art. 13 und 14 können mit Bußgeldern bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2 CRA).
Vorbereitung
Erste Schritte für kleine Hersteller
Für kleine Hersteller ist bis zum 11. September 2026 die Reihenfolge wichtiger als Vollständigkeit:
Produkte und Rolle klären: Welche Ihrer Produkte haben digitale Elemente? Sind Sie Hersteller, Importeur oder Händler?
Zuständigkeit festlegen: Wer im Unternehmen nimmt Hinweise auf Schwachstellen an, bewertet sie und meldet? Wer vertritt diese Person am Wochenende und im Urlaub?
Kontaktstelle veröffentlichen: Eine feste Adresse für Sicherheitsmeldungen, etwa über eine Datei security.txt nach RFC 9116 auf Ihrer Website.
Abhängigkeiten kennen: Eine Liste aller eingebundenen Bibliotheken und Komponenten mit Versionen. Daraus entsteht später die SBOM.
Ablauf für den Ernstfall schreiben: Ein kurzer Plan zur Incident-Response mit den drei Meldefristen, Vorlagen für die Meldungen und dem Weg zur Kundeninformation.
Unterstützungszeitraum festlegen: Für jedes Produkt entscheiden, wie lange Sie Sicherheitsupdates liefern. Ab Dezember 2027 müssen Sie diesen Zeitraum angeben.
Updates zuverlässig ausliefern: Ein Prozess, mit dem ein Patch schnell bei allen Kunden ankommt. Warum das der wirksamste Schutz ist, beschreibt unser Beitrag zur Patch-Disziplin.
Softwarehäuser und junge SaaS-Unternehmen trifft der CRA oft gleichzeitig mit anderen Anforderungen ihrer Kunden. Welche Fragen sich für Softwarehersteller und SaaS-Startups daraus in der Entwicklung ergeben, beschreiben wir auf der Branchenseite.
Kurz beantwortet
Häufige Fragen
-
Das hängt davon ab, ob die Software als Produkt auf dem Markt bereitgestellt wird und wer sie unter seinem Namen vertreibt. Wer eine Anwendung im Auftrag entwickelt, die der Kunde unter eigener Marke anbietet, macht damit meist den Kunden zum Hersteller. Bei rein internen Anwendungen und Grenzfällen kommt es auf die Einzelheiten von Vertrieb und Vertrag an.
-
Freie und quelloffene Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, fällt nicht unter den CRA. Wer Open-Source-Komponenten in ein kommerzielles Produkt einbaut, ist aber als Hersteller für das ganze Produkt verantwortlich. Organisationen, die Open-Source-Projekte dauerhaft für die kommerzielle Nutzung unterstützen, haben als „Verwalter quelloffener Software“ eigene, leichtere Pflichten.
Meldeprozess und Produktsicherheit vorbereiten
Wir helfen Herstellern von Web- und Mobilanwendungen, Abhängigkeiten zu erfassen, Update-Prozesse aufzubauen und den Ablauf für Sicherheitsmeldungen technisch abzubilden.
Nachweise
Quellen und Stand
Geprüft am 02.11.2026: Verordnung (EU) 2024/2847 mit Erwägungsgründen 11 und 12 sowie die Seiten der EU-Kommission zu den Meldepflichten. Dieser Beitrag ist keine Rechtsberatung. Ob Sie als Hersteller gelten, klären Sie mit einem Anwalt.
Artikel teilen