CRA-Meldepflichten gelten für digitale Produkte
Die Meldepflichten aus Artikel 14 des EU Cyber Resilience Act, kurz CRA, sind in Kraft. Hersteller müssen aktiv ausgenutzte Sicherheitslücken und schwere Sicherheitsvorfälle innerhalb von 24 Stunden nach Bekanntwerden melden.
Die Vorgabe betrifft Produkte mit digitalen Elementen, die auf dem EU-Markt angeboten werden. Der Firmensitz spielt dabei keine entscheidende Rolle. Damit fallen grundsätzlich auch Hersteller aus der Schweiz, den USA oder anderen Drittstaaten in den Anwendungsbereich, sobald ihre Produkte in der EU bereitgestellt werden.
Der CRA wird häufig mit vernetzten Geräten für Verbraucher verbunden. Tatsächlich erfasst er einen deutlich breiteren Kreis aus Software und vernetzter Hardware. Welche Ausnahmen für einzelne Produktkategorien oder bestimmte Open-Source-Projekte gelten, lässt sich aus den bisher vorliegenden Angaben jedoch nicht abschließend ableiten.
24 Stunden für die erste Warnung
Die erste Meldung ist nur der Beginn eines mehrstufigen Verfahrens. Nach der Frühwarnung verlangt der CRA weitere Informationen sowie einen abschließenden Bericht.
| Pflicht | Frist |
|---|---|
| Frühwarnung zu aktiv ausgenutzter Schwachstelle oder schwerem Vorfall | Innerhalb von 24 Stunden nach Bekanntwerden |
| Detailliertere Folgemeldung | Innerhalb von 72 Stunden |
| Abschlussbericht zu einer Schwachstelle | Innerhalb von 14 Tagen nach Bereitstellung einer Korrektur oder Schutzmaßnahme |
| Abschlussbericht zu einem schweren Sicherheitsvorfall | Innerhalb eines Monats nach der ersten Meldung |
Die Meldungen müssen über die Single Reporting Platform der EU-Agentur ENISA an das zuständige nationale Computer Security Incident Response Team, kurz CSIRT, übermittelt werden. Wie reibungslos diese Plattform in der Praxis mit den nationalen Stellen zusammenspielt, muss sich noch zeigen.
Zusätzlich sind betroffene Nutzer unverzüglich über verfügbare Korrekturen oder Schutzmaßnahmen zu informieren. Eine interne Bearbeitung ohne geregelte externe Kommunikation reicht damit nicht aus.
Das 24-Stunden-Fenster erzeugt erheblichen Zeitdruck. Die weiteren Fristen sollen sicherstellen, dass zusätzliche Informationen schnell erfasst und veröffentlicht werden, erklärte Darren Anstee, CTO Security bei Netscout, sinngemäß übersetzt.
Ohne Komponentenübersicht wird die Frist zum Problem
Die kurze Meldefrist setzt voraus, dass Hersteller ihre Produkte, Abhängigkeiten und betroffenen Versionen bereits kennen. Erst nach einem Vorfall mit der Bestandsaufnahme zu beginnen, dürfte in vielen Fällen zu spät sein.
Dazu gehört eine belastbare Software Bill of Materials, kurz SBOM. Sie dokumentiert die in einem Produkt eingesetzten Softwarekomponenten und deren Abhängigkeiten. Gerade bei Anwendungen aus eigenem Code, Open-Source-Paketen, Drittanbieter-Komponenten und KI-Diensten kann diese Übersicht schnell komplex werden.
Angriffe auf Paketquellen zeigen, wie direkt solche Abhängigkeiten zum Sicherheitsrisiko werden können. Ein Beispiel ist die gemeldete Attacke auf RubyGems durch KI-Agenten. Auch die kritischen ServiceNow-Schwachstellen ohne Anmeldung verdeutlichen, wie wichtig bekannte Produktstände, klare Zuständigkeiten und vorbereitete Kundeninformationen sind.
Sichere Entwicklung, wirksames Schwachstellenmanagement und eine nachvollziehbare Software-Lieferkette müssen für Hersteller ganz oben auf die Prioritätenliste, erklärte Eran Kinsbruner von Checkmarx sinngemäß übersetzt.
Bis zu 15 Millionen € Geldbuße
Verstöße gegen die zentralen CRA-Pflichten können erhebliche Sanktionen auslösen. Für die schwersten Fälle sieht die Verordnung den jeweils höheren der folgenden Beträge vor.
| Berechnungsgrundlage | Maximale Geldbuße |
|---|---|
| Fester Betrag | 15 Millionen € |
| Umsatzabhängige Sanktion | 2,5 % des weltweiten Jahresumsatzes |
Für Hersteller wird damit nicht nur die technische Reaktion relevant. Meldewege, Freigaben, Dokumentation und Kundenkommunikation müssen so organisiert sein, dass sie auch außerhalb normaler Geschäftszeiten funktionieren können.
Weitere CRA-Pflichten folgen Ende 2027
Die meisten übrigen Bestimmungen des Cyber Resilience Act greifen am 11. Dezember 2027. Dazu zählen Security by Design, also die Berücksichtigung von Sicherheit bereits bei Entwicklung und Produktgestaltung, das Verbot unsicherer Standard-Passwörter und die Pflicht zur laufenden Pflege einer SBOM.
Hinzu kommen Konformitätsbewertungen und die CE-Kennzeichnung für erfasste Produkte. Hersteller müssen somit nicht nur einzelne Vorfälle melden, sondern ihre Sicherheitsprozesse über den gesamten Produktlebenszyklus nachvollziehbar gestalten.
Der organisatorische Aufwand steigt zusätzlich durch Überschneidungen mit NIS2, DORA, dem Data Act und dem AI Act. Für Unternehmen besteht die Schwierigkeit weniger darin, jede Regel isoliert zu lesen. Entscheidend ist, gemeinsame Prozesse für Meldewesen, Risikomanagement, Dokumentation und Verantwortlichkeiten aufzubauen.
Folgen für SaaS, Self-Hosting und Eigenentwicklung
Für SaaS-Anbieter entstehen zusätzliche Kosten für Bereitschaftsdienste, Schwachstellenmanagement, Komponentenverzeichnisse und regulatorische Meldungen. Es ist naheliegend, dass ein Teil dieses Aufwands langfristig in Abonnementpreise und Vertragsbedingungen einfließt. Kunden sollten deshalb prüfen, welche CRA-Leistungen ein Anbieter tatsächlich übernimmt und welche Pflichten beim Kunden verbleiben.
Self-Hosting und KI-gestützte Eigenentwicklung schaffen mehr Kontrolle über den Software-Stack, beseitigen regulatorische Pflichten aber nicht. Sobald ein Unternehmen erfasste digitale Produkte auf dem EU-Markt bereitstellt, muss es die erforderlichen Sicherheits-, Dokumentations- und Meldeprozesse selbst abbilden.
Für Unternehmen in Deutschland und Österreich führt der Weg über die zuständigen nationalen CSIRTs. Schweizer Hersteller sind ebenfalls betroffen, wenn sie ihre Produkte in der EU anbieten. Mittelständler sollten deshalb Zuständigkeiten, Eskalationswege, Komponentenlisten und Vorlagen für Erstmeldungen festlegen, bevor eine Sicherheitslücke die 24-Stunden-Uhr startet.