Cyber Resilience Act: Compliance-Roadmap für Hersteller und Importeure

€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

Für Ihre Planung: Die Meldepflichten gelten seit dem 11. September 2026 (Art. 71 Abs. 2 CRA). Sie setzen funktionsfähige Prozesse für Schwachstellen-Management und Incident Response voraus. Wer diese Prozesse noch nicht hat, ist bereits heute im Verzug. Bis zur vollständigen Geltung am 11. Dezember 2027 bleibt nur ein gutes Jahr.

Wer ist betroffen?

Der CRA richtet sich an die gesamte Lieferkette digitaler Produkte. Die Verantwortlichkeiten sind klar verteilt:

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)

Important Class I

Important Class II

Critical

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 (seit 11. September 2026)

• Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die Single Reporting Platform der ENISA melden. Die Meldung geht gleichzeitig an das koordinierende CSIRT (in Deutschland CERT-Bund beim BSI) und an die ENISA
• Fristen nach Art. 14 CRA: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur (Schwachstellen) bzw. einen Monat nach der 72-Stunden-Meldung (Vorfälle)
• 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.

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

Schritt 3: Schwachstellen-Management und Meldeprozesse (sofort, Pflicht seit Sep 2026)

Ziel: Die seit dem 11. September 2026 geltenden Meldepflichten zuverlässig erfüllen.

• Vulnerability Handling Policy definieren und implementieren
• Koordinierte Offenlegung (CVD) einrichten: Kontaktkanal, Prozess, Fristen
• Meldeprozess über die Single Reporting Platform aufsetzen und testen: Zugang einrichten, Zuständigkeiten für Frühwarnung (24 h), Meldung (72 h) und Abschlussbericht festlegen
• Interne Eskalationswege dokumentieren
• Nutzer-Benachrichtigungsprozess für Schwachstellen und Patches etablieren

Kritisch: Die Meldepflichten gelten seit dem 11. September 2026. Die erste harte Deadline ist damit verstrichen. Ein aktiv ausgenutzter Zero-Day in Ihrem Produkt, für den Sie nicht innerhalb von 24 Stunden eine Frühwarnung abgeben, ist bereits heute ein Verstoß. In Deutschland sitzen das koordinierende CSIRT (CERT-Bund) und die CRA-Marktüberwachung beide im BSI.

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.

• 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

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

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:

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

1. Bestandsaufnahme: Welche unserer Produkte fallen unter den CRA, und in welche Kategorie (Default, Important, Critical)?
2. Meldepflicht: Haben wir einen funktionsfähigen Prozess, um aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden über die Single Reporting Platform an CERT-Bund und ENISA zu melden? Die Pflicht gilt seit dem 11. September 2026.
3. 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 ist bereits verstrichen, die zweite folgt im Dezember 2027.

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