Cyber Resilience Act: Compliance-Roadmap für Hersteller und Importeure
CRA-Überblick, Timeline, Produktkategorien und 5-Schritte-Roadmap. Pragmatischer Compliance-Leitfaden für Hersteller digitaler Produkte.
€15 Mio. Strafe oder 2,5% des weltweiten Jahresumsatzes. Das droht Herstellern, die digitale Produkte ohne angemessene Cybersecurity auf den EU-Markt bringen.
Der Cyber Resilience Act (CRA) ist seit September 2024 veröffentlicht und wird die Spielregeln für alle Produkte mit digitalen Elementen grundlegend verändern. Anders als NIS2 oder der EU AI Act zielt der CRA direkt auf die Produkte selbst -- nicht auf die Unternehmen, die sie betreiben.
Was ist der CRA?
Der Cyber Resilience Act ist eine EU-Verordnung, die verbindliche Cybersecurity-Anforderungen für alle Produkte mit digitalen Elementen einführt. Das umfasst sowohl Hardware mit eingebetteter Software als auch reine Softwareprodukte -- von IoT-Geräten über Betriebssysteme bis hin zu Passwort-Managern.
Das Ziel: Sicherheit wird zur Voraussetzung für den Marktzugang. Wer in der EU verkaufen will, muss Cybersecurity nachweisbar in Design, Entwicklung und den gesamten Produktlebenszyklus integrieren.
Warum jetzt? Die EU reagiert auf eine klare Realität: Rund 70% der Cyberangriffe nutzen Schwachstellen in Produkten aus, die mit unzureichenden Security-Standards auf den Markt gebracht wurden. Der CRA soll dieses systemische Problem an der Wurzel lösen.
Timeline: Was gilt, was kommt
| Datum | Meilenstein | Bedeutung |
|---|---|---|
| Sep 2024 | CRA im EU-Amtsblatt veröffentlicht | Gesetzgebung abgeschlossen |
| Nov 2024 | Inkrafttreten (20 Tage nach Veröffentlichung) | Fristen beginnen zu laufen |
| Sep 2026 | Meldepflichten aktiv | Hersteller müssen aktiv ausgenutzte Schwachstellen melden |
| Dez 2027 | Vollständige Compliance | Alle Anforderungen gelten, CE-Kennzeichnung verpflichtend |
Für Ihre Planung: Zwischen September 2026 und Dezember 2027 liegt nur ein gutes Jahr. Die Meldepflichten kommen zuerst -- und erfordern bereits funktionsfähige Prozesse für Schwachstellen-Management und Incident Response. Wer erst 2027 anfängt, wird auch die Meldepflichten 2026 nicht erfüllen.
Wer ist betroffen?
Der CRA richtet sich an die gesamte Lieferkette digitaler Produkte. Die Verantwortlichkeiten sind klar verteilt:
| Rolle | Pflichten | Beispiele |
|---|---|---|
| Hersteller | Design, Entwicklung, Konformitätsbewertung, Security-Updates für den gesamten Lebenszyklus (max. 5 Jahre) | Softwareunternehmen, IoT-Hersteller, Firmware-Entwickler |
| Importeure | Prüfung, dass Hersteller CRA-Anforderungen erfüllt, CE-Kennzeichnung vorhanden, Dokumentation verfügbar | Distributoren, die Produkte aus Drittstaaten in die EU einführen |
| Händler | Sorgfaltspflicht, dass Produkte CRA-konform sind, keine Modifikationen ohne Verantwortungsübernahme | Online-Marktplätze, Fachhändler, Systemhäuser |
Wichtig für Importeure: Wenn Sie Software oder Hardware aus den USA, China oder anderen Drittstaaten in den EU-Markt bringen, tragen Sie die volle Verantwortung dafür, dass die Produkte CRA-konform sind. Kann der Hersteller die Compliance nicht nachweisen, haften Sie.
Wer ist ausgenommen?
- Open-Source-Software, die nicht kommerziell vertrieben wird (reine Community-Projekte)
- Produkte, die bereits unter spezifischer Sektorregulierung fallen (z.B. Medizinprodukte, Luftfahrt, Automobile)
- SaaS-Lösungen, sofern sie nicht als herunterladbare Software bereitgestellt werden
Achtung: Open-Source-Komponenten in kommerziellen Produkten fallen trotzdem unter den CRA -- die Verantwortung liegt beim Hersteller des kommerziellen Produkts. Wer npm-Pakete, Python-Libraries oder andere Open-Source-Dependencies einbindet, muss deren Sicherheit gewährleisten und im Schwachstellenfall zeitnah reagieren.
Die 4 Produktkategorien
Nicht jedes Produkt wird gleich behandelt. Der CRA definiert vier Kategorien mit unterschiedlichen Anforderungen an die Konformitätsbewertung:
Default (unkritisch)
| Aspekt | Details |
|---|---|
| Bewertung | Self-Assessment durch den Hersteller |
| Beispiele | Textverarbeitung, Foto-Apps, Spiele, einfache IoT-Geräte |
| Aufwand | Moderate Dokumentation, interne Prüfung |
Important Class I
| Aspekt | Details |
|---|---|
| Bewertung | Self-Assessment ODER harmonisierte Standards anwenden |
| Beispiele | Passwort-Manager, VPN-Software, Netzwerk-Management-Tools, SIEM-Systeme, Firewalls (privat) |
| Aufwand | Höhere Dokumentationsanforderungen, ggf. Standardkonformität nachweisen |
Important Class II
| Aspekt | Details |
|---|---|
| Bewertung | Third-Party-Assessment erforderlich (durch benannte Stelle) |
| Beispiele | Betriebssysteme, Hypervisoren, Firewalls (industriell/gewerblich), Intrusion Detection/Prevention, Router und Switches für industriellen Einsatz |
| Aufwand | Externe Zertifizierung, erheblicher Zeit- und Kostenaufwand |
Critical
| Aspekt | Details |
|---|---|
| Bewertung | EU-Cybersecurity-Zertifizierung verpflichtend |
| Beispiele | Smartcards, sichere Elemente (Secure Elements), Hardware-Security-Module (HSM), Smartcard-Reader |
| Aufwand | Höchste Anforderungen, EU-Zertifizierungsschema erforderlich |
Die Klassifizierung bestimmt den Aufwand: Für die Mehrheit der Produkte (Default-Kategorie) reicht ein Self-Assessment. Aber sobald Ihr Produkt eine Sicherheitsfunktion erfüllt oder in kritischen Umgebungen eingesetzt wird, steigen die Anforderungen erheblich. Die Einstufung orientiert sich an der Funktion und dem Einsatzkontext des Produkts -- nicht an der Unternehmensgröße des Herstellers. Ein kleines Startup, das ein VPN-Tool entwickelt, unterliegt denselben Anforderungen wie ein Konzern.
Kernanforderungen aus Annex I
Annex I des CRA definiert die wesentlichen Cybersecurity-Anforderungen, die alle Produkte mit digitalen Elementen erfüllen müssen. Die wichtigsten im Überblick:
Security by Design
- Produkte müssen mit einem angemessenen Cybersecurity-Niveau auf den Markt gebracht werden
- Keine bekannten ausnutzbaren Schwachstellen bei Auslieferung
- Sichere Standardkonfiguration (Security by Default)
- Schutz vor unbefugtem Zugriff mit angemessenen Mechanismen (Authentifizierung, Identitätsmanagement)
Datenintegrität und Vertraulichkeit
- Schutz der Vertraulichkeit und Integrität gespeicherter, übermittelter und verarbeiteter Daten
- Verschlüsselung nach Stand der Technik
- Datenminimierung: Nur die Daten verarbeiten, die für die Funktion notwendig sind
Resilienz und Verfügbarkeit
- Widerstandsfähigkeit gegen Denial-of-Service-Angriffe
- Minimierung negativer Auswirkungen auf andere Geräte und Netzwerke
- Reduzierung der Angriffsfläche auf das notwendige Minimum
Schwachstellen-Management
- Dokumentiertes Verfahren zur Identifikation und Behebung von Schwachstellen
- Security-Updates für die gesamte Support-Dauer (mindestens 5 Jahre)
- Regelmäßige Tests und Reviews der Produktsicherheit
- Koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure)
- Software Bill of Materials (SBOM) erstellen und pflegen
Meldepflichten (ab September 2026)
- Aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden
- Schwere Sicherheitsvorfälle innerhalb von 72 Stunden melden
- Nutzer unverzüglich über Schwachstellen und verfügbare Patches informieren
Praxis-Tipp: Die SBOM-Anforderung wird oft unterschätzt. Für komplexe Softwareprodukte mit dutzenden oder hunderten Abhängigkeiten ist die Erstellung und Pflege einer vollständigen SBOM ein erheblicher Aufwand. Beginnen Sie jetzt mit der Tooling-Evaluierung. Tools wie CycloneDX, SPDX oder Syft können den Prozess automatisieren -- aber die Integration in bestehende Build-Pipelines braucht Zeit und Testing.
5-Schritte Compliance-Roadmap
Schritt 1: Produktinventar und Klassifizierung (sofort -- Q2 2026)
Ziel: Vollständige Sichtbarkeit über alle betroffenen Produkte.
| Aufgabe | Details | Verantwortlich |
|---|---|---|
| Produktinventar erstellen | Alle Produkte mit digitalen Elementen erfassen | Product Management |
| Kategorie zuordnen | Default, Important I/II oder Critical | Product Management + Legal |
| Lieferkette analysieren | Welche Drittkomponenten sind enthalten? | Engineering |
| SBOM-Prozess starten | Tooling evaluieren, erste SBOMs erstellen | Engineering |
| Open-Source-Audit | Alle OSS-Komponenten identifizieren und Lizenzen prüfen | Engineering + Legal |
Quick Win: Beginnen Sie mit Ihrem umsatzstärksten Produkt. Das schafft Prozesse, die sich auf andere Produkte übertragen lassen.
Schritt 2: Gap-Analyse gegen Annex I (Q2 -- Q3 2026)
Ziel: Verstehen, wo Sie stehen und was fehlt.
- Jede Anforderung aus Annex I gegen den Ist-Zustand prüfen
- Gaps dokumentieren und priorisieren
- Aufwandsschätzung pro Gap erstellen
- Budget und Ressourcen für die Umsetzung einplanen
| Anforderung | Status | Gap | Aufwand |
|---|---|---|---|
| Security by Default | Teilweise | Default-Passwörter in 2 Produktlinien | Mittel |
| Verschlüsselung | Erfüllt | -- | -- |
| SBOM | Nicht vorhanden | Vollständig aufbauen | Hoch |
| Schwachstellen-Management | Teilweise | Kein koordinierter Disclosure-Prozess | Mittel |
| Meldeprozess ENISA | Nicht vorhanden | Aufbauen | Mittel |
Schritt 3: Schwachstellen-Management und Meldeprozesse (Q3 2026 -- Sep 2026)
Ziel: Bereit für die Meldepflichten ab September 2026.
- Vulnerability Handling Policy definieren und implementieren
- Koordinierte Offenlegung (CVD) einrichten: Kontaktkanal, Prozess, Fristen
- Meldeprozess an ENISA aufsetzen und testen
- Interne Eskalationswege dokumentieren
- Nutzer-Benachrichtigungsprozess für Schwachstellen und Patches etablieren
Kritisch: Die Meldepflichten gelten ab September 2026. Das ist die erste harte Deadline. Ein aktiv ausgenutzter Zero-Day in Ihrem Produkt, den Sie nicht innerhalb von 24 Stunden melden -- das ist bereits ein Verstoß.
Schritt 4: Security by Design implementieren (Q3 2026 -- H1 2027)
Ziel: Produkte erfüllen die technischen Anforderungen aus Annex I.
- Secure Development Lifecycle (SDL) in die Entwicklungsprozesse integrieren
- Sichere Standardkonfigurationen für alle Produkte definieren
- Authentifizierungs- und Zugriffskontrollen implementieren oder verbessern
- Kryptographie nach Stand der Technik einsetzen
- Automatisierte Security-Tests in CI/CD-Pipelines integrieren
- Angriffsflächen-Analyse und -Reduzierung durchführen
Empfehlung: Integrieren Sie Security-Reviews in bestehende Sprint-Zyklen statt separate Security-Sprints zu planen. Das ist nachhaltiger und reduziert Reibung im Entwicklungsteam. Threat Modelling als Teil des Feature-Designs wird langfristig mehr Wirkung zeigen als nachträgliche Penetrationstests allein.
Schritt 5: Konformitätsbewertung und CE-Kennzeichnung (H1 -- H2 2027)
Ziel: Nachweis der CRA-Konformität und Marktzulassung.
| Produktkategorie | Bewertungsverfahren | Timeline |
|---|---|---|
| Default | Self-Assessment, technische Dokumentation | 2-4 Wochen |
| Important Class I | Self-Assessment + Standardnachweis | 1-3 Monate |
| Important Class II | Third-Party-Assessment beauftragen | 3-6 Monate |
| Critical | EU-Zertifizierung | 6-12+ Monate |
- Technische Dokumentation finalisieren (Annex VII)
- EU-Konformitätserklärung erstellen (Annex VI)
- CE-Kennzeichnung anbringen
- Bei Class II / Critical: Benannte Stelle frühzeitig kontaktieren
Warnung: Für Important Class II und Critical-Produkte sollten Sie die benannte Stelle spätestens Anfang 2027 kontaktieren. Die Kapazitäten werden begrenzt sein, wenn alle gleichzeitig eine Zertifizierung brauchen.
CRA und KI: Die Schnittstelle
Für Unternehmen, die KI-basierte Produkte entwickeln oder vertreiben, entsteht ein regulatorisches Dreieck: CRA, EU AI Act und branchenspezifische Regulierung.
Wann fallen KI-Produkte unter den CRA?
Jedes KI-Produkt, das als Software oder als Gerät mit eingebetteter Software auf den Markt gebracht wird, fällt unter den CRA. Das betrifft:
- KI-gestützte Sicherheitssoftware (Endpoint Protection, SIEM mit ML-Komponenten)
- Embedded AI in IoT-Geräten (Kameras mit Gesichtserkennung, Smart-Home-Geräte mit Sprachassistenten)
- KI-Entwicklungstools und Frameworks, die als Produkt vertrieben werden
- On-Premise KI-Lösungen, die beim Kunden installiert werden
Doppelte Compliance: CRA + EU AI Act
| Aspekt | CRA | EU AI Act | Synergie |
|---|---|---|---|
| Fokus | Cybersecurity des Produkts | Sicherheit und Grundrechte | Ergänzend |
| Risikomanagement | Schwachstellen, Angriffsfläche | Bias, Fairness, Transparenz | Integriertes Framework möglich |
| Dokumentation | Technische Dokumentation (Annex VII) | Technische Dokumentation (Art. 11) | Gemeinsame Dokumentenstruktur |
| Updates | Security-Patches verpflichtend | Modell-Monitoring | Gemeinsamer Update-Prozess |
| Bewertung | Konformitätsbewertung | Conformity Assessment | Parallele Durchführung |
Praxisempfehlung: Bauen Sie ein integriertes Compliance-Framework auf, das beide Verordnungen abdeckt. Die Dokumentationsanforderungen überschneiden sich erheblich -- wer sie getrennt behandelt, verdoppelt den Aufwand.
KI-spezifische CRA-Herausforderungen
- Modell-Updates vs. Schwachstellen-Management: Wann ist ein Modell-Update ein Security-Patch, der gemeldet werden muss?
- Adversarial Attacks: Prompt Injection und Model Manipulation sind Schwachstellen im CRA-Sinne
- Supply Chain: LLM-Anbieter wie OpenAI oder Anthropic als Teil Ihrer Produktlieferkette -- wer trägt die CRA-Verantwortung?
- SBOM für KI: Wie bilden Sie Trainingsdaten und Modellkomponenten in einer SBOM ab?
- Continuous Updates: KI-Modelle werden regelmäßig nachtrainiert oder ausgetauscht. Jedes Update kann die Konformitätsbewertung beeinflussen -- ein Aspekt, den klassische Software-Lifecycles nicht kennen.
Strafen und Durchsetzung
| Verstoß | Höchststrafe |
|---|---|
| Nichterfüllung wesentlicher Anforderungen (Annex I) | €15 Mio. oder 2,5% des weltweiten Jahresumsatzes |
| Nichterfüllung sonstiger Pflichten | €10 Mio. oder 2% des weltweiten Jahresumsatzes |
| Falsche, unvollständige oder irreführende Angaben | €5 Mio. oder 1% des weltweiten Jahresumsatzes |
Darüber hinaus: Marktüberwachungsbehörden können Produkte vom Markt nehmen lassen oder den Verkauf untersagen. Das ist in der Praxis oft schmerzhafter als die Geldstrafe -- ein Verkaufsverbot trifft das Kerngeschäft direkt.
Vergleich mit anderen Regulierungen: Die CRA-Strafen liegen unter den Höchststrafen des EU AI Act (€35 Mio. oder 7%) und der DSGVO (€20 Mio. oder 4%), aber das Risiko eines Marktausschlusses macht den CRA potenziell einschneidender. Ohne CE-Kennzeichnung darf das Produkt schlicht nicht mehr in der EU vertrieben werden.
Die häufigsten Fehler
"Das betrifft nur IoT-Hersteller"
Realität: Der CRA gilt für ALLE Produkte mit digitalen Elementen. Reine Softwareprodukte, Desktop-Anwendungen, mobile Apps und Firmware -- alles fällt darunter, sofern es auf dem EU-Markt bereitgestellt wird.
"Wir nutzen nur Open-Source-Komponenten, also sind wir nicht betroffen"
Realität: Wenn Sie Open-Source-Komponenten in ein kommerzielles Produkt integrieren, tragen SIE die volle CRA-Verantwortung für diese Komponenten. Inklusive Schwachstellen-Management und Security-Updates.
"Unser SaaS ist nicht betroffen"
Realität: Richtig, reine SaaS-Lösungen fallen nicht direkt unter den CRA. Aber: Wenn Ihr Produkt herunterladbare Komponenten hat (Desktop-Client, Mobile App, On-Premise-Modul), fallen diese Teile unter den CRA.
"CE-Kennzeichnung haben wir schon"
Realität: Die bestehende CE-Kennzeichnung deckt den CRA nicht ab. Sie brauchen eine neue Konformitätsbewertung, die spezifisch die Cybersecurity-Anforderungen des CRA adressiert.
Regulatorisches Gesamtbild
Der CRA existiert nicht isoliert. Für die meisten Unternehmen entsteht ein Geflecht aus Regulierungen, die zusammen betrachtet werden müssen:
| Regulierung | Fokus | Überschneidung mit CRA |
|---|---|---|
| EU AI Act | KI-Sicherheit und Grundrechte | Konformitätsbewertung, Dokumentation, Risikomanagement |
| NIS2 | Cybersecurity von Unternehmen | Incident Reporting, Supply Chain Security |
| CRA | Cybersecurity von Produkten | -- |
| DSGVO | Datenschutz | Datenverarbeitung in Produkten |
| Produkthaftungsrichtlinie | Haftung für fehlerhafte Produkte | Software explizit einbezogen |
Strategie: Wer NIS2-Compliance bereits aufgebaut hat, kann viele Prozesse (Incident Response, Schwachstellen-Management) für den CRA wiederverwenden. Wer ein AI Risk Assessment bereits durchführt, hat eine gute Grundlage für die CRA-Risikoanalyse.
Die drei Fragen für Ihr nächstes Board-Meeting
- Bestandsaufnahme: Welche unserer Produkte fallen unter den CRA, und in welche Kategorie (Default, Important, Critical)?
- Meldepflicht: Haben wir einen funktionsfähigen Prozess, um aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA zu melden -- ab September 2026?
- Lifecycle: Können wir für jedes Produkt Security-Updates über den gesamten Support-Zeitraum garantieren, und haben wir die SBOM-Pflicht adressiert?
Wenn Sie eine dieser Fragen nicht mit einem klaren "Ja" beantworten können, ist jetzt der richtige Zeitpunkt, die Umsetzung zu starten. Die erste Deadline liegt nur noch Monate entfernt.
Weiterführend
- CRA und Software-Sicherheit -- Technische Anforderungen für Softwareprodukte im Detail
- EU AI Act -- Klassifizierung und Compliance-Anforderungen für KI-Systeme
- NIS2 und KI-Systeme -- Überschneidungen mit Cybersecurity-Regulierung
- AI Risk Assessment -- Methodik für Risikobewertung als CRA-Grundlage