Cyber Resilience Act: Was Softwarehersteller bis Ende 2027 erledigt haben müssen

Qualität und Sicherheit

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten melden – auch für Produkte, die schon lange verkauft werden. Ab dem 11. Dezember 2027 gilt der Cyber Resilience Act vollständig. Wer Software oder Geräte mit Software in der EU vertreibt, hat also noch gut ein Jahr, um Produkte und Abläufe anzupassen.

Wen der CRA betrifft

Der Cyber Resilience Act, die Verordnung (EU) 2024/2847, gilt für Produkte mit digitalen Elementen, die in der EU auf den Markt kommen. Dazu gehören Geräte mit eigener Steuerungssoftware ebenso wie reine Software, etwa Desktop-Programme oder CAD-Add-ins. Hersteller ist, wer ein solches Produkt unter eigenem Namen oder eigener Marke vermarktet, ob gegen Bezahlung oder unentgeltlich. Einige Produktgruppen mit eigenen Regeln, etwa Medizinprodukte, sind ausgenommen.

Die Fristen

Ihre Aufgaben bis Ende 2027

1. Den Meldeweg einrichten – sofort. Bei einer aktiv ausgenutzten Schwachstelle ist innerhalb von 24 Stunden eine Frühwarnung fällig, innerhalb von 72 Stunden eine Meldung und spätestens 14 Tage, nachdem eine Korrektur verfügbar ist, ein Abschlussbericht. Für schwerwiegende Sicherheitsvorfälle gelten dieselben Fristen für Frühwarnung und Meldung. Gemeldet wird über die einheitliche Meldeplattform der ENISA. Legen Sie fest, wer Hinweise entgegennimmt, bewertet und meldet – auch im Urlaub.
2. Produkte einordnen. Welche Produkte und Versionen sind betroffen? Handelt es sich um ein Standardprodukt, ein wichtiges oder ein kritisches Produkt? Davon hängt ab, ob Sie die Konformität selbst bewerten können oder eine benannte Stelle brauchen.
3. Eine Software-Stückliste (SBOM) erstellen. Der CRA verlangt eine Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten enthält. Am besten entsteht sie bei jedem Build automatisch, etwa im Format CycloneDX oder SPDX.
4. Schwachstellen behandeln. Gleichen Sie Ihre Komponenten regelmäßig mit öffentlichen Schwachstellendatenbanken ab. Sie brauchen eine Kontaktadresse für Meldungen von außen, ein Konzept zur koordinierten Offenlegung und regelmäßige Sicherheitstests. Behobene Schwachstellen veröffentlichen Sie mit einer Beschreibung für die Nutzer.
5. Den Update-Prozess festlegen. Sicherheitsupdates müssen die Kunden unverzüglich und grundsätzlich kostenlos erreichen, soweit technisch machbar getrennt von Funktionsupdates. Der Unterstützungszeitraum beträgt in der Regel mindestens fünf Jahre. Jedes Sicherheitsupdate bleibt danach mindestens zehn Jahre verfügbar oder bis zum Ende des Unterstützungszeitraums, je nachdem, was länger ist.
6. Das Produkt absichern. Gefordert sind unter anderem: keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, sichere Grundeinstellungen mit Rücksetzmöglichkeit, Schutz vor unbefugtem Zugriff, Verschlüsselung, eine möglichst kleine Angriffsfläche und die Protokollierung sicherheitsrelevanter Vorgänge.
7. Dokumentieren. Die technische Dokumentation umfasst Produktbeschreibung, Architektur, Bewertung der Cybersicherheitsrisiken, Verfahren zur Schwachstellenbehandlung und Informationen für die Nutzer. Sie ist die Grundlage der EU-Konformitätserklärung. Aufbewahren müssen Sie beides mindestens zehn Jahre oder für die Dauer des Unterstützungszeitraums, wenn dieser länger ist.

Wo Sie anfangen sollten

Beginnen Sie mit dem, was schon heute gilt und was sich später überall auszahlt: dem Meldeweg und der SBOM. Ohne Stückliste wissen Sie im Ernstfall nicht, ob eine neu bekannte Schwachstelle Ihr Produkt betrifft – und die 24-Stunden-Frist läuft trotzdem. Automatisierte Tests sind ein weiterer Baustein. Der CRA verlangt, die Sicherheit des Produkts regelmäßig und wirksam zu testen. Tests, die bei jedem Build laufen, liefern dafür nachvollziehbare Belege.

Bei Verstößen gegen die grundlegenden Anforderungen oder gegen die Pflichten aus Artikel 13 und 14 drohen Geldbußen bis 15 Millionen Euro oder bis 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Hinweis: Dieser Artikel gibt einen technischen Überblick und ist keine Rechtsberatung. Die verbindliche Einstufung Ihres Produkts klären Sie bitte mit Ihrer Rechtsabteilung oder Ihren Anwälten.

Typische Fehler

• Auf 2027 warten. Die Meldepflichten gelten seit dem 11. September 2026, für neue und für bestehende Produkte.
• „Unser Produkt ist alt, das betrifft uns nicht.“ Gemeldet werden muss trotzdem. Und wer ein Bestandsprodukt nach dem 11. Dezember 2027 wesentlich ändert, muss danach alle Anforderungen erfüllen.
• Die SBOM einmal von Hand erstellen. Mit dem nächsten Build ist sie veraltet. Sie gehört in den Build-Prozess.
• Zugekaufte und Open-Source-Komponenten übersehen. Schwachstellen stecken oft in Bibliotheken, nicht im eigenen Code.
• Sicherheitsupdates nur zusammen mit neuen Funktionen ausliefern. Kunden sollen eine Lücke schließen können, ohne eine neue Version einzuführen.
• Keine feste Kontaktadresse. Hinweise auf Schwachstellen landen im allgemeinen Postfach und bleiben dort liegen.

Quellen: Verordnung (EU) 2024/2847 (Cyber Resilience Act), insbesondere Art. 13, 14, 64, 69 und 71 sowie Anhang I, EUR-Lex; Cadida: Cyber Resilience Act. Stand: Oktober 2026.