Glossar · EU-Cybersicherheit Cyber Resilience Act (CRA)
Die EU-Verordnung von 2024, die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen über deren gesamten Lebenszyklus festlegt, mit voller Anwendbarkeit ab 2027.
## Was der Cyber Resilience Act tatsächlich bewirkt
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist die EU-Verordnung, die Cybersicherheitsanforderungen für **Produkte mit digitalen Elementen** festlegt. Im Oktober 2024 verabschiedet, mit voller Anwendbarkeit ab Dezember 2027, verhängt er Pflichten gegenüber Herstellern über den gesamten Produktlebenszyklus.
Während NIS2 die Cybersicherheit von Organisationen adressiert, die kritische Dienste betreiben, adressiert der CRA die Cybersicherheit der Produkte selbst — Software, Hardware, IoT-Geräte und jedes Produkt, das digitale Komponenten enthält.
## Was „Produkte mit digitalen Elementen" bedeutet
Der CRA hat einen extrem breiten Anwendungsbereich. „Produkte mit digitalen Elementen" umfasst:
- **Softwareprodukte** — Betriebssysteme, Anwendungen, Softwarebibliotheken
- **Hardware mit eingebetteter Software** — IoT-Geräte, Router, intelligente Geräte
- **Vernetzte Produkte** — alles mit Netzwerkkonnektivität
- **Komponenten und integrierte Software** — sowohl eigenständige als auch integrierte digitale Elemente
Der Anwendungsbereich ist bewusst breit. Die Begründung der Kommission: Cybersicherheitsausfälle in vernetzten Produkten können die Sicherheit des breiteren Ökosystems beeinträchtigen.
Einige enge Ausnahmen gelten: Produkte, die unter sektorspezifische Cybersicherheitsverordnungen fallen (Medizinprodukte unter MDR, Automobil unter spezifischen Rahmen), haben alternative Compliance-Pfade. Open-Source-Software, die in nicht-kommerziellem Kontext entwickelt wird, hat leichtere Pflichten.
## Kernpflichten
Der CRA verhängt Pflichten über den Produktlebenszyklus:
### Pflichten vor Markteintritt
Bevor Produkte auf den EU-Markt gebracht werden:
- **Risikobewertung** — Cybersicherheitsrisiken über den Produktlebenszyklus identifizieren
- **Security by Design** — angemessene technische und organisatorische Sicherheitsmaßnahmen umsetzen
- **Schwachstellenmanagement** — Prozesse zur Schwachstellenidentifizierung und -behebung etablieren
- **Konformitätsbewertung** — überprüfen, dass das Produkt CRA-Anforderungen erfüllt (kann für höher riskante Produkte Drittanbieterbewertung erfordern)
- **Dokumentation** — umfassende technische Dokumentation einschließlich Sicherheitsarchitektur
- **CE-Kennzeichnung** — Produkte müssen CE-Kennzeichnung tragen, die Konformität anzeigt
### Pflichten nach Markteintritt
Nach dem Verkauf der Produkte:
- **Sicherheitsupdates** — Updates für den Supportzeitraum bereitstellen (Standard 5 Jahre, länger für einige Kategorien)
- **Schwachstellenmeldung** — aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA melden
- **Vorfallmeldung** — schwerwiegende Sicherheitsvorfälle an Behörden melden
- **Koordinierte Schwachstellenoffenlegung** — mit Sicherheitsforschenden zusammenarbeiten
- **Betreiber- und Nutzerinformation** — klare Sicherheitsinformationen für Nutzer
### Laufende Pflichten
Über den Produktlebenszyklus:
- **Sichere Standardkonfiguration** — Mindestsicherheitsbasis
- **Authentifizierungsmechanismen** — starke Authentifizierung erforderlich, wo anwendbar
- **Verschlüsselungsunterstützung** — für Produkte, die sensible Daten verarbeiten
- **Zugriffskontrollen** — angemessene Autorisierungsmechanismen
- **Protokollierung und Überwachung** — Protokollierung sicherheitsrelevanter Ereignisse
## Risikobasierte Produktklassifizierung
Der CRA klassifiziert Produkte in Kategorien mit unterschiedlichen Konformitätsbewertungsanforderungen:
### Standardkategorie
Die meisten Produkte fallen in die Standardkategorie, die Selbstbewertung der Konformität erfordert. Hersteller schließen die Bewertung ab und bringen die CE-Kennzeichnung an.
### Wichtige Kategorie (Klasse I und Klasse II)
Produkte mit höheren Cybersicherheitsrisiken sehen sich strengeren Anforderungen gegenüber:
**Klasse I** — Produkte einschließlich Identitätsmanagementsystemen, Passwortmanagern, Antivirensoftware, Netzwerksicherheitstools, generischen Hypervisoren und VPN-Lösungen. Selbstbewertung mit optionaler Drittanbieterüberprüfung.
**Klasse II** — Betriebssysteme für Server und Workstations, Smartcards und zertifizierte Boot-Loader, Schlüsselverwaltungssysteme für kritische Infrastruktur. Verpflichtende Drittanbieter-Konformitätsbewertung.
### Kritische Kategorie
Produkte mit den höchsten Cybersicherheitsrisiken erfordern die strengste Bewertung, einschließlich für Produkte, die kritische Infrastruktur und zentrale Souveränitätsanwendungen unterstützen.
## Bußgeldstruktur
CRA-Strafen sind erheblich:
- **Bis zu 15 Millionen Euro oder 2,5% des weltweiten Jahresumsatzes** (je nachdem, welcher Betrag höher ist) für Nichteinhaltung wesentlicher Anforderungen
- **Bis zu 10 Millionen Euro oder 2% des Umsatzes** für Nichteinhaltung anderer Pflichten
- **Bis zu 5 Millionen Euro oder 1% des Umsatzes** für falsche oder irreführende Angaben
Für KMU sind Bußgelder auf proportional niedrigere Schwellen begrenzt.
## Warum der CRA für europäische Tech relevant ist
Der CRA schafft erhebliche Implikationen:
### Softwareprodukte sind jetzt regulierte Produkte
Historisch wurde Software weniger streng reguliert als physische Produkte mit digitalen Elementen. Der CRA ändert dies — Softwareprodukte sehen sich grundlegenden Cybersicherheitsanforderungen ähnlich wie Hardware gegenüber.
Für europäische Softwareunternehmen schafft dies Compliance-Aufwand, aber auch Wettbewerbsmöglichkeit. EU-native Softwareunternehmen, die CRA-Compliance von Anfang an in die Produktarchitektur einbauen, haben Vorteile gegenüber Nachrüst-Compliance.
### Open-Source-Behandlung
Der CRA enthält Bestimmungen, die die Last für Open-Source-Software reduzieren, die in nicht-kommerziellem Kontext entwickelt wird. Kommerzielle Open-Source-Distributionen und Softwareunternehmen, die Open-Source-Komponenten nutzen, sehen sich vollen Pflichten gegenüber.
Dies war umstritten. Vertreter der Open-Source-Gemeinschaft argumentierten für leichtere Behandlung; Sicherheitsvertreter argumentierten für volle Abdeckung. Der endgültige Rahmen verlangt von Herstellern, die Open-Source-Komponenten nutzen, sicherzustellen, dass diese Komponenten CRA-Anforderungen als integriert erfüllen.
### Umgestaltung des IoT-Produktmarkts
Märkte für vernetzte Produkte sehen sich erheblichem CRA-Compliance-Aufwand gegenüber. Billige IoT-Geräte von Herstellern, die nicht compliant sein können oder wollen, werden den EU-Markt verlassen. Dies:
- Erhöht die Preise für vernetzte Produkte
- Reduziert die Vielfalt am unteren Marktende
- Schafft Wettbewerbsmöglichkeit für EU-basierte Hersteller, die CRA-konforme Produkte bauen
### Implikationen für die Software-Lieferkette
Hersteller, die Softwarekomponenten von Drittanbietern nutzen, müssen sicherstellen, dass diese Komponenten CRA-Anforderungen erfüllen. Dies schafft Lieferkettendruck:
- Softwarezulieferer sehen sich Compliance-Pflichten gegenüber ihren Herstellerkunden gegenüber
- In kommerziellen Produkten genutzte Open-Source-Komponenten sehen sich strengerer Prüfung gegenüber
- Software Bills of Materials (SBOMs) werden wichtiger
## Zeitplan und aktueller Stand
CRA-Umsetzung phasenweise:
- **Dezember 2024**: Verordnung tritt in Kraft
- **September 2026**: Schwachstellenmeldepflichten gelten
- **Dezember 2027**: Volle Anwendbarkeit aller Pflichten
Wir befinden uns in der Übergangsphase. Hersteller bereiten sich auf die Schwachstellenmeldung im September 2026 und die volle Compliance im Dezember 2027 vor.
## Verhältnis zu anderen EU-Verordnungen
Der CRA fügt sich in die breitere EU-Cybersicherheits- und Digitalregulierung ein:
**vs. NIS2** — NIS2 adressiert Organisationen, die kritische Dienste betreiben. CRA adressiert Produkte. Zusammen decken sie sowohl organisatorische als auch produktbezogene Cybersicherheit ab.
**vs. Data Act** — Data Act adressiert Datenzugang und -portabilität. CRA adressiert Cybersicherheit der Produkte, die diese Daten erzeugen. Komplementäre Rahmen.
**vs. AI Act** — AI Act adressiert Risiken von KI-Systemen (Sicherheit, Fairness, Grundrechte). CRA adressiert Cybersicherheit von Produkten einschließlich KI-Systemen. Beide gelten für KI-Produkte.
**vs. DSGVO** — DSGVO adressiert Schutz personenbezogener Daten. CRA adressiert breit Produktcybersicherheit. Komplementär im Kontext personenbezogener Daten.
Für Produkte, die unter mehrere Verordnungen fallen, erfordert Compliance ausdrückliche Abbildung.
## Was 2026-2027 bringt
- **Frist Schwachstellenmeldung September 2026** — erster großer operativer Meilenstein
- **Volle Anwendbarkeit Dezember 2027** — umfassende Durchsetzung beginnt
- **Erste größere Durchsetzungsmaßnahmen** wahrscheinlich 2027-2028
- **Durchführungsrechtsakte und harmonisierte Normen** in fortlaufender Entwicklung
- **Branchenspezifische Leitlinien** für verschiedene Produktkategorien
Der CRA ist die ehrgeizigste Cybersicherheitsverordnung der EU vom Anwendungsbereich her. Die Umsetzung wird europäische Software- und Hardwaremärkte bis 2028 und darüber hinaus erheblich prägen.
## Was das für europäische Unternehmen bedeutet
Für europäische Software- und Hardwareunternehmen:
### 1. CRA-Compliance ist ein Wettbewerbsmerkmal
In der EU gebaute Produkte mit starker CRA-Compliance-Position positionieren sich günstig gegenüber billigeren nicht-konformen Alternativen. Dokumentieren Sie die Compliance-Arbeit.
### 2. Open-Source-Nutzung erfordert Sorgfalt
Die Nutzung von Open-Source-Komponenten in kommerziellen Produkten erfordert die Sicherstellung, dass diese Komponenten CRA-Anforderungen erfüllen. Auditieren Sie Ihre Software-Lieferkette.
### 3. Security-by-Design als Standard
Produkte ohne CRA-konforme Sicherheitsarchitektur zu bauen, schafft technische Schulden, die vor Dezember 2027 bezahlt werden müssen. Neue Produktentwicklung sollte CRA-Anforderungen von Anfang an einbeziehen.
### 4. SBOM und Schwachstellenmanagement sind operative Anforderungen
Software Bills of Materials, Schwachstellenmanagementprozesse und koordinierte Offenlegungsprogramme sind für Produkte im EU-Markt nicht mehr optional.
### 5. Update-Supportzeiträume zählen
Produkte müssen mit Sicherheitsupdates für standardmäßig 5-Jahres-Zeiträume unterstützt werden. Dies betrifft die Lebenszyklusökonomie von Produkten — insbesondere für IoT-Hersteller, die billige Geräte mit historisch kurzen Supportzeiträumen verkaufen.
Für europäische Tech-Käufer schafft der CRA strukturelle Qualitätsverbesserungen bei in EU-Märkten verfügbaren Produkten. Billige, aber unsichere vernetzte Produkte werden weniger verfügbar; ordnungsgemäß entwickelte Alternativen werden wettbewerbsfähiger.
War das hilfreich?
Danke für Ihr Feedback!