Cyber Resilience Act praktisch umsetzen
Cybersicherheit für Produkte mit digitalen Elementen über ihren gesamten Lebenszyklus organisieren und belegen.
Der Cyber Resilience Act (CRA) richtet sich an Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, und an die jeweils verantwortlichen Wirtschaftsakteure. Hersteller müssen Cybersicherheit von Planung und Entwicklung bis zur Wartung und Schwachstellenbehandlung steuern. Die Verordnung gilt seit 10. Dezember 2024; Notifizierungsvorschriften seit 11. Juni 2026, Artikel-14-Meldepflichten ab 11. September 2026 und die übrige Verordnung ab 11. Dezember 2027.
Ausgangslage
Software und vernetzte Produkte bestehen häufig aus eigenen Komponenten, Open-Source-Bibliotheken, Diensten Dritter und mehreren Release-Varianten. Ohne ein klares Produktinventar, Verantwortlichkeiten und eine gepflegte Schwachstellenroutine bleibt unklar, was ausgeliefert wurde, welchen Support ein Produkt erhält und wie auf Sicherheitslücken reagiert wird.
Der CRA verschiebt den Fokus deshalb vom punktuellen Sicherheitscheck zu einem nachweisbaren Produktlebenszyklus. Er verlangt nicht, dass jedes Team dieselben Werkzeuge einsetzt. Entscheidend ist, dass die geeigneten Cybersicherheitsanforderungen risikobasiert umgesetzt, dokumentiert und während des Supportzeitraums betrieben werden.
Fachliche Einordnung
Die Verordnung (EU) 2024/2847 ist ein horizontaler EU-Rechtsrahmen für Hardware- und Softwareprodukte mit digitalen Elementen, die im Rahmen einer gewerblichen Tätigkeit auf dem Unionsmarkt bereitgestellt werden. Erfasst sein können Endprodukte, separat bereitgestellte Komponenten und bestimmte zugehörige Ferndatenverarbeitungslösungen. Ausnahmen und die genaue Rolle – etwa Hersteller, Einführer oder Händler – sind im Einzelfall rechtlich zu prüfen.
Die Hauptpflichten treffen Hersteller, die ein Produkt unter ihrem Namen oder ihrer Marke in Verkehr bringen. Sie müssen unter anderem eine Cybersicherheitsrisikobewertung durchführen, grundlegende Anforderungen nach Anhang I berücksichtigen, technische Dokumentation erstellen und das passende Konformitätsbewertungsverfahren vor dem Inverkehrbringen durchführen. Nach erfolgreicher Bewertung folgen EU-Konformitätserklärung und CE-Kennzeichnung.
Der CRA trat am 10. Dezember 2024 in Kraft. Vorschriften zur Notifizierung von Konformitätsbewertungsstellen gelten seit 11. Juni 2026; ab 11. September 2026 gelten die Artikel-14-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Ab 11. Dezember 2027 gelten die übrigen Hauptpflichten der Verordnung. Die nicht bindende Kommissionsleitlinie vom 27. Juli 2026 erläutert unter anderem Scope, Ferndatenverarbeitung, Open Source, Supportzeiträume und das Zusammenspiel mit anderem EU-Recht.
Der CRA ergänzt NIS2, ersetzt aber keine organisationsbezogenen NIS2-Pflichten. NIS2 wird auf der Seite NIS2 praktisch umsetzen behandelt; die Cluster-Einordnung bietet Cybersecurity & Resilienz.
Was Unternehmen konkret klären müssen
- Welche Produkte, Komponenten, Versionen und zugehörigen Ferndatenverarbeitungslösungen im Prüfungsrahmen liegen.
- Welche Rolle das Unternehmen für jedes Produkt einnimmt und wer die rechtliche Einordnung verantwortet.
- Wie Cybersicherheitsrisiken während Planung, Entwicklung, Produktion, Lieferung und Wartung bewertet werden.
- Wie Schwachstellen aufgenommen, bewertet, behoben, kommuniziert und über den Supportzeitraum verfolgt werden.
- Welche technische Dokumentation, Nutzerinformationen, Konformitätsunterlagen und Betriebsnachweise verfügbar sein müssen.
Für jedes Produkt sollte der verantwortete Supportzeitraum früh festgelegt und für Nutzende klar kommuniziert werden. Nach Art. 13 ist die Behandlung von Schwachstellen grundsätzlich über mindestens fünf Jahre zu gewährleisten, sofern die erwartete Nutzungsdauer nicht kürzer ist. Die konkrete Dauer, Anwendung und Ausnahmen gehören in die rechtliche und produktbezogene Prüfung.
Artefakt-Set für den Lifecycle
- Produkt- und Versionsinventar sowie Rollenentscheidung;
- Cybersicherheitsrisikobewertung;
- SBOM oder anderer Komponentennachweis;
- Ablauf für Vulnerability-Handling und Supportzeitraum;
- technische Dokumentation und Konformitätsunterlagen.
Von der Anforderung zur Umsetzung
Cybersicherheitsrisikobewertung
Risiko: Sicherheitsanforderungen bleiben unvollständig
Organisatorische Maßnahme: Produkt-, Risiko- und Freigabeverantwortung festlegen
Technische Umsetzung: Bedrohungsmodellierung und risikobasierte Security-Tests in den Lifecycle integrieren
Möglicher Nachweis: Risikobewertung, Architektur- und Freigabeunterlagen
Sichere Entwicklung und Lieferung
Risiko: Schwachstellen oder Manipulationen gelangen in Releases
Organisatorische Maßnahme: Sicherheitsgates, Ausnahmen und Release-Verantwortung definieren
Technische Umsetzung: Geschützte Repositories und Pipelines, Prüfungen von Code und Abhängigkeiten
Möglicher Nachweis: Pipeline-Protokolle, Review- und Release-Nachweise
Schwachstellenbehandlung und Updates
Risiko: Bekannte Lücken bleiben offen
Organisatorische Maßnahme: Triage-, Korrektur-, Kommunikations- und Eskalationsprozess betreiben
Technische Umsetzung: Vulnerability-Management, Update-Verteilung und Rückverfolgbarkeit von Versionen
Möglicher Nachweis: Tickets, Advisories, Update- und Patchberichte
Technische Dokumentation und Konformität
Risiko: Bewertung ist nicht nachvollziehbar
Organisatorische Maßnahme: Dokumentationsverantwortung und Pflegeprozess bestimmen
Technische Umsetzung: Produkt-, Komponenten- und Konfigurationsinformationen versioniert verwalten
Möglicher Nachweis: Technische Dokumentation, EU-Konformitätserklärung, Nachweise zur Bewertung
Meldungen nach Art. 14
Risiko: Aktiv ausgenutzte Lücken oder schwere Vorfälle werden verspätet gemeldet
Organisatorische Maßnahme: Meldeentscheidungen, Kontakte und Eskalationsweg festlegen
Technische Umsetzung: Erkennung, Fallanlage und strukturierte Meldedaten vorbereiten
Möglicher Nachweis: Zeitstempel, Meldungen, Abschlussberichte
Eine SBOM kann die Transparenz über Komponenten und Abhängigkeiten unterstützen, ist aber kein Selbstzweck und keine automatische Konformitätsaussage. Vertiefungen bieten SBOM & Dependency Management und Secure Software Lifecycle / DevSecOps. Signaturen können die Integrität und Herkunft von Artefakten unterstützen; der CRA schreibt Code Signing jedoch nicht als eigenständige Einzelmaßnahme vor. Für die Strategie dazu siehe Code Signing / Artifact Signing.
Vorgehen mit ADIUMENTO
ADIUMENTO unterstützt Produkt-, Entwicklungs- und Security-Teams dabei, vorhandene Lieferwege, Abhängigkeiten, Schwachstellenprozesse und Nachweise zu strukturieren. Daraus können ein risikobasiertes Lifecycle-Zielbild, priorisierte Sicherheitsmaßnahmen und umsetzbare Arbeitspakete für Entwicklung, Betrieb und Dokumentation entstehen.
Die Arbeit knüpft an IT-Security & Compliance und IT-Security & Compliance an. ADIUMENTO erbringt keine Rechtsberatung, führt keine verbindliche Produktklassifizierung durch und stellt keine Konformitätsgarantie, CE-Leistung oder Zertifizierung aus.
Typische Ergebnisse
- abgegrenztes Inventar von Produkten, Versionen, Komponenten und Verantwortlichkeiten;
- Lifecycle-Zielbild für Security-Gates, Schwachstellenmanagement und Updates;
- priorisierte Roadmap für Toolchain, Dokumentation und Betrieb;
- Nachweisstruktur für Risikobewertungen, Freigaben, Updates und Meldungen;
- Arbeitsgrundlagen für die Abstimmung mit Rechtsberatung, Konformitätsbewertung und Marktüberwachung.
Grenzen und Abhängigkeiten
Ob ein konkretes Produkt im Anwendungsbereich liegt, welche Rolle ein Unternehmen einnimmt, welcher Supportzeitraum gilt und welches Konformitätsbewertungsverfahren erforderlich ist, muss rechtlich und produktbezogen bewertet werden. Technische Maßnahmen allein ersetzen diese Bewertung nicht.
Die Qualität der Nachweise hängt von vollständigen Produktinformationen, gepflegten Komponenten- und Versionsdaten, verlässlichen Lieferanteninformationen und einem tatsächlich gelebten Betriebsprozess ab. ADIUMENTO ersetzt weder Rechtsberatung noch eine notifizierte Stelle, Marktüberwachungsbehörde oder Konformitätsbewertung.
Weiterführende offizielle Quellen
- Verordnung (EU) 2024/2847 – Cyber Resilience Act – EUR-Lex
- EU-Kommission: Cyberresilienzgesetz – EU-Kommission
- EU-Kommission: CRA – Zusammenfassung – EU-Kommission
- EU-Kommission: Leitlinie zur CRA-Umsetzung vom 27. Juli 2026 – EU-Kommission
- EU-Kommission: CRA Reporting und Single Reporting Platform – EU-Kommission
Orientierung
Häufige Fragen
Ab wann müssen Hersteller nach Artikel 14 CRA melden?
Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab 11. September 2026. Die Kommission fasst Fristen von 24 Stunden für eine Frühwarnung und 72 Stunden für eine Meldung zusammen; die anwendbaren Voraussetzungen und Inhalte sollten für den Einzelfall geprüft werden.
Gilt der CRA bereits vollständig?
Nein. Die Verordnung trat am 10. Dezember 2024 in Kraft. Notifizierungsvorschriften gelten seit 11. Juni 2026, Artikel-14-Meldepflichten ab 11. September 2026; die übrigen Hauptpflichten gelten ab 11. Dezember 2027.
Ist Code Signing nach dem CRA verpflichtend?
Der CRA nennt Code Signing nicht als ausdrückliche Einzelpflicht. Eine Signatur kann in einer angemessenen Sicherheitsarchitektur die Integrität und Herkunft von Artefakten unterstützen. Welche Kontrollen geeignet sind, folgt aus der Risikobewertung, den grundlegenden Anforderungen und dem jeweiligen Produkt.
Nächster sinnvoller Schritt
Machen Sie zuerst Produktumfang, Verantwortlichkeiten, Komponenten, Supportzeiträume und aktuelle Schwachstellenprozesse transparent. IT-Security & Compliance kann Lifecycle- und Lieferketten-Readiness technisch strukturieren; es ersetzt keine rechtliche Bewertung oder Konformitätsbewertung. Der Regulatorik-Hub zeigt die weiteren Themenfelder.