Was ist der Cyber Resilience Act? Geltungsbereich, Produkte und wen er betrifft

Bis vor kurzem konnten digitale Produkte auf dem europäischen Markt eingeführt werden, ohne dass ihnen im Wesentlichen verbindliche Cybersicherheitsstandards auferlegt wurden. Die Hersteller entschieden selbst, wie viel Sicherheit sie einbauten, und Käufer hatten keine Garantien und keine Möglichkeit zum Vergleich. Wenn Schwachstellen auftraten, bestand keine gesetzliche Verpflichtung, diese zu melden oder zu beheben. Produkte konnten ohne Vorankündigung vom Markt genommen werden, wodurch sie anfällig für Cyberangriffe blieben.

Der Cyber Resilience Act (CRA) ist die erste EU-Verordnung, die Cybersicherheit als Grundvoraussetzung für die Markteinführung digitaler Produkte vorschreibt. Er wurde im Oktober 2024 verabschiedet, und seine wichtigsten Verpflichtungen treten im September 2026 in Kraft.[1] Wenn Sie ein digitales Produkt herstellen oder vertreiben, das auf dem EU-Markt verkauft wird, gilt diese Verordnung für Sie.

 

 

Was bedeutet „Cyber-Resilienz”?

Cyber-Resilienz bezeichnet die Fähigkeit, negative Cybersicherheitsereignisse zu antizipieren, ihnen standzuhalten, sich von ihnen zu erholen und sich an sie anzupassen. Der CRA setzt Cyber-Resilienz auf Marktebene um, indem er allgemeine Cybersicherheitserwartungen in rechtlich durchsetzbare Produktverpflichtungen umwandelt. Produkte müssen so konzipiert sein, dass sie gegen Angriffe widerstandsfähig sind, und Hersteller müssen Schwachstellen während des gesamten Lebenszyklus ihres Produkts aktiv verwalten.

Was ist ein „Produkt mit digitalen Elementen“?

Der CRA verwendet den Begriff „Produkt mit digitalen Elementen“, um seinen Anwendungsbereich zu definieren. Ein Produkt mit digitalen Elementen ist definiert als jedes Software- oder Hardwareprodukt – sowie dessen Lösungen zur Fernverarbeitung von Daten –, das sich direkt oder indirekt mit einem anderen Gerät oder Netzwerk verbinden kann [2]. Alles in allem umfasst dies praktisch jede Software, die auf einem Standard-Desktop-Computer, Laptop oder Mobiltelefon läuft, und sogar einfache Hardwaregeräte wie eine TV-Fernbedienung.

Zu den wichtigsten Produktgruppen gehören:

• Unternehmenssoftwareplattformen: ERP-Systeme, CRM-Software, Sicherheitstools und Kollaborationsplattformen
• Consumer-Hardware: Smart-Home-Geräte, vernetzte Haushaltsgeräte, Router und IP-Kameras
• Industrieprodukte: SPS, SCADA-Systeme, industrielle Sensoren und vernetzte Maschinen
• Entwicklertools: IDEs, CI/CD-Plattformen und Build-Tools mit Netzwerkkonnektivität
• Betriebssysteme: Desktop-, Server- und Embedded-OS-Produkte

 

Wer muss die Vorschriften einhalten?

Der CRA legt die Hauptpflicht bei den Herstellern: den juristischen Personen, die Produkte mit digitalen Elementen entwerfen, entwickeln oder produzieren und diese unter ihrem eigenen Namen oder ihrer eigenen Marke auf dem EU-Markt in Verkehr bringen. Doch damit ist es nicht getan. Auch Importeure und Händler tragen Verpflichtungen. Wenn Sie ein Produkt eines Drittanbieters auf den EU-Markt bringen oder es innerhalb der EU verfügbar machen, sind Sie dafür verantwortlich, zu überprüfen, ob es die CRA-Anforderungen erfüllt.

Der CRA gilt unabhängig davon, wo Sie ansässig sind. Ein US-amerikanischer Softwareanbieter, der an EU-Kunden verkauft, fällt in den Geltungsbereich. Werden die Produkte eines Nicht-EU-Herstellers von einem europäischen Vertreiber in der EU verkauft, tragen beide Parteien Verpflichtungen – der Hersteller als für das Produkt verantwortliche Stelle und der Vertreiber als Stelle, die es auf dem EU-Markt bereitstellt.

Die Höchststrafe für Verstöße gegen den CRA beträgt 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist – Zahlen, die die Aufmerksamkeit der Unternehmensleitung schnell auf sich ziehen.

Was fällt ausdrücklich nicht in den Geltungsbereich?

• Produkte, die unter gleichwertige branchenspezifische Rechtsvorschriften fallen, wie bestimmte Medizinprodukte, Luftfahrtausrüstung und Kraftfahrzeuge, bei denen bestehende Vorschriften vergleichbare Cybersicherheitsanforderungen vorsehen
• Rein nichtkommerzielle Open-Source-Software (der CRA gilt weiterhin für Open-Source-Komponenten kommerzieller Produkte und Open-Source-Verwalter)
• Produkte im Bereich der nationalen Sicherheit, der Nachrichtendienste und des Militärs
• Produkte, die nicht auf dem Markt erhältlich sind und ausschließlich für bestimmte Zwecke entwickelt wurden, wie z. B. Evaluierungsprototypen

Was verlangt der CRA konkret?

Im Kern verlangt der CRA von den Herstellern vier Dinge:

1. Sichere digitale Produkte entwickeln: Produkte von Anfang an unter Berücksichtigung der Cybersicherheit entwerfen, entwickeln und produzieren – nicht erst nachträglich. Produkte müssen ohne bekannte ausnutzbare Schwachstellen, mit minimaler Angriffsfläche und in einer sicheren Standardkonfiguration ausgeliefert werden.
2. Aktive Unterstützung der Produktsicherheit: Kostenlose Bereitstellung von Sicherheitsupdates für mindestens fünf Jahre. Verantwortungsvolle Dokumentation und Verwaltung von Sicherheitslücken. Führung einer Software-Stückliste (SBOM), in der alle Softwarekomponenten aufgeführt sind.
3. Ausgenutzte Schwachstellen melden: Ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden und innerhalb von 72 Stunden vollständige technische Details übermitteln. [3]
4. Konformität bewerten und nachweisen: Führen Sie vor der Markteinführung eine Cybersicherheits-Risikobewertung durch. Bewahren Sie die technische Dokumentation 10 Jahre lang auf. Bringen Sie die CE-Kennzeichnung an, um die Konformität nachzuweisen. [4]

Die Frist im September 2026: Warum sie jetzt wichtig ist

Die meisten Hersteller konzentrieren sich auf das Datum der vollständigen Durchsetzung im Dezember 2027 – doch die unmittelbar dringlichere Frist ist der 11. September 2026, mit dem die Meldepflichten für Sicherheitslücken beginnen. Das ist in weniger als fünf Monaten. Ab diesem Datum muss jede aktiv ausgenutzte Sicherheitslücke in Ihren Produkten innerhalb von 24 Stunden einen formellen Meldeprozess an die europäischen Cybersicherheitsbehörden auslösen. [5]

Der Aufbau und das Testen des internen Prozesses dafür erfordern Vorbereitung. Nicht nur ein Richtliniendokument, sondern ein tatsächlicher operativer Arbeitsablauf mit Tools, Eskalationswegen und Mitarbeiterschulungen. Für Sicherheits- und Technikleiter ist der September 2026 die Frist, die Budgetgespräche jetzt rechtfertigt – nicht erst nach dem Datum der vollständigen Durchsetzung im Jahr 2027, wenn das Zeitfenster für eine geordnete Umsetzung bereits geschlossen sein wird.

Was die CRA-Konformität in der Praxis tatsächlich erfordert

Die Erfüllung dieser Verpflichtungen erfordert eine technische Grundlage: Sie müssen wissen, welche Komponenten in Ihren Produkten enthalten sind, nachverfolgen, welche CVEs diese betreffen, und über eine Möglichkeit verfügen, Prioritäten für die Behebung von Schwachstellen zu setzen. In der Praxis bedeutet dies, dass Tools für das Schwachstellenmanagement in Ihre Pipeline integriert werden müssen – nicht als reine Compliance-Maßnahme, sondern als kontinuierlicher Prozess, der einen CRA-konformen Prüfpfad erzeugt. Der CRA schreibt kein bestimmtes Tool vor, sondern das Ergebnis: eine dokumentierte, nachvollziehbare und wiederholbare Schwachstellenbehandlung.

Richtig umgesetzt können diese Prozesse auch den Arbeitsalltag der Entwickler weniger chaotisch gestalten: weniger Notfall-Patch-Zyklen, umsetzbare Warnmeldungen statt einer Flut von rohen CVE-Daten und klare Prioritäten bei der Triage, sodass das Team das behebt, was tatsächlich wichtig ist, anstatt alles auf einmal.

Wenn Sie gerade planen, wie dieser Prozess in Ihrem Unternehmen aussehen soll, werden unsere kommenden Beiträge die Kernkomponenten eines CRA-fähigen Schwachstellenmanagement-Workflows behandeln – einschließlich dessen, was eine SBOM enthalten muss, wie die Bewertung der Ausnutzbarkeit in der Praxis funktioniert und wo Open-Source-Tools ins Spiel kommen.