Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) ist ein EU-Gesetz, das Mindestanforderungen an die Cybersicherheit von Produkten mit digitalen Elementen stellt. Er gilt für Hardware und Software, die in der EU auf den Markt kommt, und verpflichtet Hersteller, Sicherheit schon bei der Entwicklung einzuplanen, Schwachstellen zu melden und über einen festgelegten Zeitraum Sicherheitsupdates zu liefern.

Bisher war Sicherheit bei vielen Geräten und Programmen eine freiwillige Qualität. Mit dem CRA wird sie Teil der Produktkonformität, ähnlich wie elektrische Sicherheit: Ohne Erfüllung der Anforderungen gibt es kein CE-Kennzeichen.

Worum es beim CRA geht

Erfasst sind „Produkte mit digitalen Elementen“: alles, was Software enthält oder selbst Software ist und sich mit einem Gerät oder Netzwerk verbinden kann. Dazu zählen vernetzte Maschinensteuerungen, Router, smarte Haushaltsgeräte, Industriekameras, aber auch Desktop-Programme und Apps, die verkauft werden. Die Verordnung trat am 10. Dezember 2024 in Kraft und wird in Stufen wirksam; welche Pflicht ab welchem Datum greift, steht im nächsten Abschnitt.

Ausgenommen sind Bereiche mit eigenen Regeln, etwa Medizinprodukte, Fahrzeuge und Luftfahrt. Reine Online-Dienste ohne Produktbestandteil, also klassisches SaaS, fallen in der Regel nicht unter den CRA, sondern unter andere Regelwerke wie NIS2.

Fristen 2026/2027: was ab wann gilt

Der CRA greift nicht auf einen Schlag. Die Verordnung (EU) 2024/2847 nennt dafür diese Daten:

Daraus ergibt sich eine Reihenfolge für die beiden Jahre:

• 2026: festlegen, wer eine Meldung bewertet, wer sie innerhalb von 24 Stunden absetzt und über welchen Zugang. Dazu gehört ein veröffentlichter Kontaktweg, über den Dritte Schwachstellen melden können.
• 2027: je Produkt Risikobewertung und technische Dokumentation, eine vollständige Stückliste der Softwarekomponenten (SBOM), der Unterstützungszeitraum in Vertrag und Produktinformation, dann Konformitätsbewertung und CE-Kennzeichen vor dem nächsten Inverkehrbringen.
• Dauerhaft: Sicherheitsupdates über den zugesagten Zeitraum bereitstellen – und belegen können, dass sie die Geräte beim Kunden erreichen.

Alte Produktlinien brauchen den längsten Vorlauf: Welche Komponenten in einem Gerät stecken und welche davon vor Dezember 2027 ersetzt werden müssen, zeigt eine Bestandsaufnahme, wie sie am Anfang einer IT-Modernisierung steht. Für die Einordnung des einzelnen Produkts ist der Wortlaut der Verordnung maßgeblich, nicht diese Übersicht.

Welche Pflichten Hersteller haben

Die Anforderungen lassen sich in drei Gruppen zusammenfassen:

1. Sicherheit durch Entwicklung. Produkte kommen ohne bekannte ausnutzbare Schwachstellen auf den Markt, mit sicheren Voreinstellungen, Schutz vor unbefugtem Zugriff und so wenig Angriffsfläche wie möglich. Grundlage ist eine dokumentierte Risikobewertung.
2. Umgang mit Schwachstellen. Hersteller führen eine Stückliste der verwendeten Softwarekomponenten, die sogenannte SBOM, nehmen Hinweise auf Lücken entgegen und beheben sie. Sicherheitsupdates stellen sie über den gesamten Unterstützungszeitraum bereit, der sich an der erwarteten Nutzungsdauer orientiert und in der Regel mindestens fünf Jahre beträgt.
3. Meldung und Konformität. Aktiv ausgenutzte Schwachstellen werden innerhalb von 24 Stunden mit einer Frühwarnung über die zentrale Meldeplattform der ENISA gemeldet, weitere Angaben folgen innerhalb von 72 Stunden. Vor dem Inverkehrbringen durchläuft das Produkt eine Konformitätsbewertung, für die meisten Produkte als Selbstbewertung, für wichtige und kritische Produkte strenger.

Auch Importeure und Händler haben Pflichten: Sie dürfen nur Produkte anbieten, deren Hersteller die Anforderungen erfüllt.

Beispiele aus dem Mittelstand

• Maschinenbauer mit Fernwartung: Die Steuerung seiner Anlagen hat eine Weboberfläche und eine Verbindung zum Hersteller. Beides zählt zum Produkt. Er braucht eine SBOM der Steuerungssoftware, einen Prozess für Schwachstellenmeldungen und einen Plan, wie Updates zu den Anlagen beim Kunden kommen.
• Hersteller von Messgeräten mit App: Gerät und Begleit-App bilden gemeinsam das Produkt. Die App darf keine Standardpasswörter setzen, und die Kommunikation zwischen App und Gerät muss verschlüsselt sein.
• Softwarehaus mit Kaufsoftware: Eine lokal installierte Branchenlösung, die in der EU verkauft wird, fällt unter den CRA. Die Wartungsverträge müssen zum geforderten Update-Zeitraum passen.

CRA, NIS2 und Produkthaftung

Der CRA regelt das Produkt, NIS2 regelt das Unternehmen, das wichtige Dienste betreibt. Ein Betreiber kann unter NIS2 fallen und Produkte einsetzen, deren Hersteller dem CRA unterliegen. Beide Regelwerke ergänzen sich: Sichere Produkte erleichtern sicheren Betrieb.

Hinzu kommt die neue EU-Produkthaftungsrichtlinie, die Software ausdrücklich als Produkt behandelt. Wer Sicherheitsupdates schuldig bleibt, riskiert also nicht nur Bußgelder nach dem CRA, sondern auch Haftung für Schäden. Abzugrenzen ist schließlich der EU AI Act, der KI-Systeme reguliert; ein KI-Produkt mit digitalen Elementen kann beiden Verordnungen unterliegen.

Fallstricke in der Umsetzung

• Unbekannte Abhängigkeiten: Moderne Software besteht zu großen Teilen aus fremden Bibliotheken. Ohne vollständige Stückliste lässt sich eine Schwachstelle darin weder erkennen noch melden.
• Alte Produktlinien: Geräte, die nach Ende 2027 neu in Verkehr gebracht werden, müssen die Anforderungen erfüllen, auch wenn die Entwicklung Jahre zurückliegt. Schlecht dokumentierte Altsysteme werden so zum Risiko.
• Kein Update-Weg: Wer Updates nur per Techniker vor Ort einspielen kann, hat bei einer kritischen Lücke ein Zeitproblem.
• Meldung ohne Prozess: Eine 24-Stunden-Frist ist nur einzuhalten, wenn feststeht, wer entscheidet und wer meldet.

Den Verordnungstext finden Sie auf EUR-Lex, Hinweise zur Umsetzung veröffentlicht das BSI. Ob Ihr Produkt erfasst ist und in welche Kategorie es fällt, sollten Sie im Einzelfall rechtlich prüfen lassen.

In der Praxis: Software, die den CRA mitdenkt

Wenn wir Individualsoftware für Produkte entwickeln, etwa die Weboberfläche einer Maschine oder die App zu einem Gerät, planen wir die CRA-Anforderungen von Anfang an ein: dokumentierte Abhängigkeiten, automatische Tests, sichere Voreinstellungen und ein Update-Weg, der ohne Technikereinsatz funktioniert. Den Code übergeben wir dokumentiert, damit er übernehmbar bleibt.

Für bestehende Produkte beginnt die Arbeit meist mit einer Bestandsaufnahme im Rahmen der IT-Modernisierung: Welche Komponenten stecken drin, welche sind veraltet, was muss ersetzt werden? Laufende Sicherheitsupdates übernehmen wir anschließend im Rahmen von Betrieb und Wartung.

Häufige Fragen

Gilt der CRA auch für Open-Source-Software?

Open-Source-Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, ist ausgenommen. Für Organisationen, die Open-Source-Projekte dauerhaft unterstützen, gibt es erleichterte Pflichten. Wer Open-Source-Komponenten in ein eigenes Produkt einbaut, bleibt als Hersteller voll verantwortlich.

Betrifft der CRA auch Software, die nur für einen Kunden gebaut wird?

Maßgeblich ist, ob ein Produkt auf dem Markt bereitgestellt wird. Bei Einzelanfertigungen für einen Auftraggeber hängt das von der Konstellation ab. Das sollten Sie mit Blick auf den konkreten Vertrag rechtlich klären lassen.

Welche Strafen drohen bei Verstößen?

Für Verstöße gegen die grundlegenden Anforderungen sieht der CRA Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor. Marktüberwachungsbehörden können Produkte außerdem vom Markt nehmen lassen.