Cyber Resilience Act: Was Unternehmen jetzt wissen müssen

Definition

Der Cyber Resilience Act ist eine EU-Verordnung mit verbindlichen Cybersecurity-Anforderungen für Produkte mit digitalen Elementen, die im EU-Markt bereitgestellt werden. Er ist Produktregulierung über den Lebenszyklus und kein allgemeines Programm für interne IT-Sicherheit oder NIS2-Compliance im Unternehmen.

Einleitung

Wenn du Hardware, Software oder vernetzte Produkte in der EU verkaufst, wird der Cyber Resilience Act schnell operativ: Anforderungen, Nachweise und Verantwortlichkeiten müssen zusammenpassen. Das betrifft nicht nur Security-Teams, sondern Produktmanagement, Entwicklung, Einkauf und Legal. Wer früh strukturiert startet, spart später teure Nacharbeit an Dokumentation, Release-Prozessen und Schwachstellenhandling.

Wer betroffen ist und wie Verantwortung in der Lieferkette verteilt ist

Der CRA gilt grundsätzlich für Produkte mit digitalen Elementen, die auf dem europäischen market bereitgestellt werden, z. B. connected devices, Software-Komponenten oder mobile apps. Bestimmte Konstellationen (z. B. nicht-kommerzielle Open-Source-Software) können ausgenommen sein; daneben gibt es Rollen wie Open-source software steward.

Die Pflichten sind entlang der supply chain verteilt: Hersteller tragen den Hauptteil (sichere Entwicklung, Konformität, Schwachstellenprozesse). Importeure und Händler müssen prüfen, ob Konformität, Dokumentation und Kennzeichnung vorhanden sind und ob das Produkt legal in den EU internal market gebracht wird.

Zentrale CRA-Anforderungen über den Produktlebenszyklus

Entscheidend ist, dass Anforderungen nicht nur beim Release gelten, sondern über den life cycle inklusive definierter Support period. Typische Anforderungen und Nachweise sind:

• Security by design und Security by default, inklusive Cybersecurity risk assessment und sicherer Entwicklung.
• Vulnerability handling: Schwachstellen erfassen, fixen, kommunizieren; Vulnerability reporting und Reporting obligations über zentrale Meldewege wie die ENISA Single Reporting Platform.
• Nachweisfähigkeit: Software Bill of Materials (SBOM), technische Dokumentation, EU Declaration of Conformity (DoC) und häufig CE-Kennzeichnung; je nach Product classification (standard/important/critical, Annex III/IV) steigt der Prüfaufwand.

Der Nutzen dahinter ist klar: weniger ungeplante Hotfixes, weniger Sicherheitsvorfälle durch bekannte vulnerabilities und weniger Vertriebsbremsen, weil Kunden Nachweise fordern.

Schritt-für-Schritt-Implementierung (kompakt als Checkliste)

Eine pragmatische Umsetzung beginnt nicht mit Tooling, sondern mit Klarheit. Diese Reihenfolge funktioniert in der Praxis gut:

• Scope und Klassifizierung: Welche Produkte/Elements fallen unter den CRA, welche Annex-Kategorie, welcher Zielmarkt in der European Union?
• Gap-Assessment: Welche cybersecurity requirements sind schon erfüllt, welche fehlen? Ergebnis ist eine Compliance-Matrix mit Owners und Fristen.
• Prozesse festziehen: Secure Development, Patch- und Release-Prozess, Support period, Schwachstellen-Triage und Reporting obligations (24h/72h/final reports) als wiederholbarer Ablauf.

Mini-Beispiel für ein Startup: Ein Smart-Device-Team hat gute Code-Qualität, aber keinen SBOM-Standard und kein definiertes Meldeverfahren. Mit SBOM-Template, festem Vulnerability-Workflow und klarer DoC-Verantwortung sinkt die Zeit pro Release, weil Rückfragen von Kunden, Einkauf und Auditoren nicht jedes Mal neu beantwortet werden müssen.

Tools, Guidance, Leitfäden und Vorlagen (ohne Overkill)

Du brauchst am Anfang kein schweres framework. Hilfreich sind einfache Bausteine, die du wiederverwenden kannst:

• CRA Fast Check oder Maturity self-assessment, plus Classification finder für die erste Einordnung.
• SBOM-Generator, DoC generator und eine schlanke Vorlage für technische Doku (inklusive Änderungshistorie).
• Vulnerability Analyzer sowie ein internes Template für Schwachstellenbewertung, Fix-Entscheidung und Reporting.

Als Orientierung dienen Standards und Normen (CEN, CENELEC, ETSI) sowie Guidance von ENISA. Für deutsche Unternehmen kann ergänzend BSI-orientierte Dokumentationslogik helfen, auch wenn CRA und IT-Sicherheitskennzeichen unterschiedliche Ziele haben.

Kosten, Voraussetzungen und ROI: woran es wirklich hängt

Die größten Kosten entstehen meist nicht durch Maßnahmen selbst, sondern durch Reibung: ungeplante Security-Arbeit kurz vor Releases, Blockaden im Vertrieb und unklare Verantwortlichkeiten. Voraussetzungen für einen effizienten Start sind überschaubar: klarer Produkt-Scope, Owner pro Nachweis (SBOM, DoC, Doku) und ein realistischer Support-Plan.

Der ROI zeigt sich typischerweise in weniger Incident-Kosten, stabileren Release-Zyklen und schnellerer Deal-Progression, weil Kunden im procurement und Risk-Management Nachweise sehen wollen. Für KMU ist „gut und nachweisbar“ fast immer wirtschaftlicher als „spät und hektisch“.

Zeitplan, Fristen und nächste Schritte

Der CRA ist EU legislation mit gestaffelter Anwendung. Praktisch heißt das: Reporting-Pflichten und volle Produktanforderungen greifen nicht am selben Tag, aber wer wartet, verliert Zeit für Doku, Konformitätsbewertung und Lieferkettentest.

Die nächsten Schritte, die du diese Woche starten kannst: Produktliste erstellen, CRA-Relevanz prüfen, erste Klassifizierung dokumentieren und ein Owner-Modell für SBOM/DoC/Schwachstellenprozess festlegen.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe wird sinnvoll, wenn interne Teams die Anforderungen kennen, aber das Zusammenspiel aus Nachweisführung, Prozessbetrieb und Verantwortlichkeiten nicht neben dem Tagesgeschäft stabil hinbekommen. Typische Signale sind: SBOM und Doku sind verteilt, Vulnerability-Prozesse sind ad hoc, und niemand kann verbindlich sagen, wer innerhalb von 24h/72h berichtet.

Wenn du CRA-Readiness mit NIS2-Nachweislogik und operativer Sicherheit verbinden willst, lohnt sich ein kurzes Erstgespräch: Wir ordnen nüchtern ein, welche Lücken produktseitig sind und welche im laufenden Betrieb des Microsoft Security-Stacks liegen.