In 10 Schritten zur CRA-Konformität bis Dezember 2027

Dieser Artikel wurde erstmals am 06.08.2025 veröffentlicht und am 03.09.2026 auf Basis des zu diesem Zeitpunkt bekannten Rechts- und Informationsstands aktualisiert.

Der Cyber Resilience Act (CRA) stellt Hersteller digitaler Produkte vor zwei zeitlich getrennte Aufgaben. Dieser Artikel zeigt dir in zehn Schritten, wie du Reporting ab September 2026 und Produktkonformität bis Dezember 2027 vorbereitest. Ab dem 11. September 2026 gelten die Meldepflichten aus Artikel 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.

Ab dem 11. Dezember 2027 müssen Produkte, die erstmals auf dem Unionsmarkt bereitgestellt werden, die CRA-Anforderungen erfüllen und das erforderliche Konformitätsbewertungsverfahren durchlaufen haben. Ein belastbarer Ablaufplan verbindet deshalb Track A für das Reporting mit Track B für Produktkonformität, Aufwand, Zuständigkeiten und Budget.

Organisation und Scope

Schritt 1. Projektstruktur aufsetzen und Verantwortung klären

Die Umsetzung des Cyber Resilience Act ist kein reines IT-Sicherheitsvorhaben, sondern ein eigenständiges Unternehmensprojekt. Es braucht einen klar definierten Scope, eine belastbare Zeitplanung, ein dediziertes Budget sowie benannte Rollen mit Verantwortung. Bereits in dieser ersten Phase müssen zentrale Fragen beantwortet werden: Welche Produktgruppen fallen in den Geltungsbereich, welche Unternehmensbereiche sind betroffen und wer trägt die Verantwortung für Steuerung und Umsetzung?

Wie bei jedem größeren Projekt müssen die organisatorischen Grundlagen geschaffen werden. Dazu gehört ein Projektteam sowie eine RACI-Matrix (Responsible, Accountable, Consulted, Informed), die Ausführung, Gesamtverantwortung, Beratung und Information je Aufgabe zuordnet. Auch ein realistischer Zeit- und Budgetrahmen gehört zu den Grundlagen dieser Phase.

Die Projektverantwortung muss nicht zwingend bei der Geschäftsleitung liegen, deren Unterstützung ist aber entscheidend. Ohne die Geschäftsführung als Sponsor lassen sich notwendige Entscheidungen und strukturelle Veränderungen kaum durchsetzen. Sie sollte als aktiver Stakeholder regelmäßig in Steuerungskreise einbezogen werden und die Umsetzung sichtbar unterstützen.

Daraus ergeben sich diese nächsten Schritte:

• Internen CRA-Kick-off initiieren (ggf. mit externer Unterstützung)
• Projektteam aufstellen und Rollen definieren
• RACI-Matrix erstellen
• Budget und Zeitrahmen für das CRA-Projekt festlegen
• C-Level über Scope, Zuständigkeiten und Risiken informieren

Schritt 2. Produkte identifizieren und Supportzeitraum festlegen

Der CRA-Geltungsbereich nach Artikel 2 betrifft Produkte mit digitalen Elementen, wenn ihre Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz umfasst. Das geht über Ethernet oder WLAN hinaus und schließt auch separat bereitgestellte Software- und Hardwarekomponenten ein. Zur Produktdefinition gehören außerdem Datenfernverarbeitungslösungen, wenn sie vom Hersteller oder unter seiner Verantwortung entwickelt wurden und das Produkt ohne sie eine seiner Funktionen nicht ausführen könnte.

Gemeinsame Steuerungsplattformen und ähnliche Sicherheitsarchitekturen können Risikoanalysen, Testartefakte und technische Nachweise wiederverwendbar machen. Eine Produktfamilie ist jedoch keine eigenständige CRA-Rechtskategorie. Halte deshalb nachvollziehbar fest, für welche Produkttypen und Varianten ein Nachweis tatsächlich gilt.

Der Supportzeitraum nach Artikel 13 Absatz 8 CRA entspricht der erwarteten Produktlebensdauer oder fünf Jahren ab dem Inverkehrbringen, je nachdem, welcher Zeitraum kürzer ist. Er darf nur unter fünf Jahren liegen, wenn die erwartete Nutzungsdauer des Produkts ebenfalls kürzer ist. Bei Maschinen und Anlagen kann eine längere Unterstützung sinnvoll oder vertraglich erforderlich sein, sie folgt aber nicht allein aus dieser gesetzlichen Mindestregel.

Daraus ergeben sich diese nächsten Schritte:

• Produkte mit digitalen Elementen und zugehörige Datenfernverarbeitungslösungen identifizieren und in den Scope aufnehmen
• Technische Gemeinsamkeiten und Plattformansätze erkennen (z. B. gemeinsame Steuerung, Firmware, Kommunikation)
• Produkte der Default-Kategorie, Important Products der Klasse I oder II und Critical Products nach Anhang IV einordnen
• Eigene Rolle als Hersteller, Importeur oder Händler klären
• Geltungsbereich wiederverwendeter Nachweise für Produkttypen und Varianten dokumentieren
• Erwartete Nutzungsdauer und vorgesehenen Supportzeitraum pro Produkt oder Variante definieren
• Updatepolitik dokumentieren (z. B. Art, Häufigkeit und Verteilung von Sicherheitsupdates)
• Interne Prozesse und Ressourcen für langfristigen Support planen
• Kundenkommunikation vorbereiten: Supportzeiträume und End-of-Support klar kommunizieren

Entwicklung und Lieferkette

Schritt 3. Security by Design in der Produktentwicklung verankern

Der CRA verlangt nach Artikel 13 und Anhang I, dass Cybersicherheit nicht nachträglich aufgesetzt, sondern von Beginn an in den Entwicklungsprozess integriert wird. Dieses Prinzip wird als Security by Design bezeichnet. Hersteller müssen nachweisen, dass sie bereits bei Konzeption, Entwicklung und Produktion eines Produkts potenzielle Risiken identifizieren und angemessene Schutzmaßnahmen ergreifen.

Das betrifft sowohl technische Aspekte wie Zugriffskontrolle, Datenintegrität, Authentifizierungsmechanismen oder Protokollierung als auch organisatorische Anforderungen wie Entwicklungsvorgaben und Prüfprozesse. Ziel ist es, Produkte so zu gestalten, dass sie auch in komplexen Nutzungskontexten widerstandsfähig gegenüber gängigen Angriffsszenarien sind.

Eine gründliche Risikoanalyse pro Produkt und nachvollziehbar abgegrenzter Variante ist dabei der Einstiegspunkt. Sie bildet die Basis für angemessene technische und organisatorische Maßnahmen und ist gleichzeitig zwingender Bestandteil der technischen Dokumentation.

Daraus ergeben sich diese nächsten Schritte:

• Sicherheitsanforderungen pro Produkt systematisch erfassen und dokumentieren
• Risikoanalyse durchführen: Bedrohungen beispielsweise mit STRIDE oder im TARA-Prozess erfassen und ihre Risiken nach einem nachvollziehbaren Verfahren wie ISO 27005 bewerten
• Schutzmaßnahmen auf Architekturebene einplanen (z. B. Zugriffskontrollen, Logging, Verschlüsselung)
• Umsetzung in den Entwicklungsprozess integrieren (Security-Reviews, sichere Coding-Guidelines etc.)
• Ergebnisse und Maßnahmen in der technischen Dokumentation erfassen

Schritt 4. Schwachstellenmanagement aufbauen

Ein zentrales Element des CRA-Anhangs I Teil II ist ein durchgängiges Schwachstellenmanagement über den Supportzeitraum eines Produkts. Hersteller müssen sicherstellen, dass Schwachstellen frühzeitig erkannt, bewertet, priorisiert und behandelt werden. Das gilt sowohl für selbst entwickelte Softwarekomponenten als auch für Drittanbieter-Code und Open Source.

Ein strukturierter Prozess zur Schwachstellenbehandlung umfasst Erkennung, Bewertung, Behebung, Kommunikation und Coordinated Vulnerability Disclosure. Die Meldepflichten aus Artikel 14 bilden einen eigenen, fristgebundenen Prozess und werden in Schritt 7 konkretisiert. Bei Maschinen und Anlagen sollte der Prozess trotzdem auf lange Betriebszeiten vorbereitet sein, wenn vertragliche Zusagen, Sicherheitsrisiken oder das Geschäftsmodell dies erfordern.

Daraus ergeben sich diese nächsten Schritte:

• Verfahren zur Schwachstellenbehandlung definieren (inkl. Bewertung, Priorisierung, Behebung)
• Automatisierte Tools für CVE-Scanning und Dependency-Checks einsetzen
• Zuständigkeiten für Schwachstellenmanagement organisatorisch verankern
• Offenlegungs- und Meldeprozesse (z. B. Coordinated Vulnerability Disclosure) aufsetzen
• Ergebnisse und Prozesse in der technischen Dokumentation abbilden und dokumentieren

Schritt 5. Lieferkette und Open Source prüfen

Viele Sicherheitsrisiken entstehen nicht in der eigenen Entwicklung, sondern durch zugekaufte Komponenten, vor allem durch Open Source. Nach Artikel 13 CRA müssen Hersteller bei integrierten Drittkomponenten die erforderliche Sorgfalt walten lassen, damit diese die Cybersicherheit des Gesamtprodukts nicht beeinträchtigen. Wer Bibliotheken, Frameworks oder Hardware anderer Anbieter einsetzt, muss sie deshalb risikobasiert bewerten und überwachen.

Ein entscheidender Hebel ist eine Software Bill of Materials (SBOM), also eine maschinenlesbare Software-Stückliste. Das CRA-Minimum in Anhang I Teil II umfasst ein gängiges maschinenlesbares Format und mindestens die direkten Abhängigkeiten auf oberster Ebene. Eine vollständige transitive SBOM mit eindeutigen Komponentenkennungen, Versionen und Lieferanteninformationen ist eine sinnvolle weitergehende Umsetzung. Lizenzinformationen können für Open-Source- und License-Compliance wichtig sein, gehören aber nicht zum gesetzlichen CRA-Minimum.

Bei integrierten Drittkomponenten ist risikobasierte Sorgfalt erforderlich, damit sie die Cybersicherheit des Gesamtprodukts nicht beeinträchtigen. Lieferantenbewertungen, vertragliche Anforderungen, SBOMs, Zertifikate oder Audits sind mögliche Nachweise und keine pauschal vorgeschriebene Auditpflicht. Für SBOMs bietet die BSI TR-03183-2 in Version 2.1.0 eine weitergehende technische Orientierung, einschließlich einer Zuordnungsempfehlung zu SPDX und CycloneDX.

Daraus ergeben sich diese nächsten Schritte:

• Für jedes betroffene Produkt mindestens eine maschinenlesbare SBOM mit direkten Abhängigkeiten erstellen und pflegen
• Automatisierte Tools zur Erkennung von Schwachstellen und Lizenzrisiken in Drittsoftware einsetzen
• Prozesse zur Prüfung und Freigabe von Komponenten (insbesondere Open Source) etablieren
• Risikobasierte Sorgfaltspflichten für Lieferanten festlegen und angemessene Nachweise einfordern
• Vertragliche Anforderungen an Lieferanten anpassen, wenn dies für Sicherheits- und Updatepflichten erforderlich ist

Nachweise und Reporting

Schritt 6. Technische Dokumentation und Konformität vorbereiten

Die technische Dokumentation ist das Rückgrat des Nachweises, dass ein Produkt den Anforderungen des CRA entspricht. Nach Artikel 31 CRA muss sie bei der erstmaligen Konformitätsbewertung vollständig und aktuell vorliegen und anschließend soweit angemessen, mindestens aber während des Supportzeitraums, aktualisiert werden. Du musst sie mindestens zehn Jahre nach dem Inverkehrbringen oder während des Supportzeitraums aufbewahren, je nachdem, welcher Zeitraum länger ist.

Die Dokumentation umfasst unter anderem Risikobewertung, Sicherheitsmaßnahmen, Updatepolitik, Informationen zur Lieferkette, Beschreibung der Entwicklungsprozesse, Schwachstellenmanagement sowie gegebenenfalls Ergebnisse externer Prüfungen. Welches Konformitätsbewertungsverfahren gilt, hängt von der Produktkategorie und den verfügbaren Nachweisen ab. Für Important Products der Klasse I und Klasse II gelten unterschiedliche Wege, wie unser Artikel über harmonisierte Standards erläutert.

Um spätere Nacharbeiten zu vermeiden, sollten Unternehmen frühzeitig mit der Strukturierung und Pflege der Dokumentation beginnen und klare Verantwortlichkeiten dafür definieren.

Daraus ergeben sich diese nächsten Schritte:

• Struktur und Inhalte der technischen Dokumentation gemäß CRA-Anforderungen definieren
• Bestehende Informationen (z. B. aus ISO 27001, MDR, Maschinenrichtlinie) integrieren und konsolidieren
• Verantwortlichkeiten und Ablagestrukturen intern festlegen
• Kontakt zu einer benannten Stelle aufnehmen, wenn das geltende Konformitätsbewertungsverfahren es erfordert

Schritt 7. Sicherheitsvorfälle erkennen und melden

Ab dem 11. September 2026 gelten die Meldepflichten aus Artikel 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts. Unverzüglich und spätestens 24 Stunden nach Kenntniserlangung ist eine Early Warning abzugeben. Unverzüglich und spätestens 72 Stunden nach Kenntniserlangung folgt die Meldung mit den verfügbaren Informationen. Für aktiv ausgenutzte Schwachstellen ist ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme fällig. Für schwerwiegende Sicherheitsvorfälle folgt der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung.

Die Meldung erfolgt über die CRA Single Reporting Platform von ENISA. Hersteller wählen dort den zuständigen CSIRT-Koordinator aus; die Plattform stellt die Meldung zugleich ENISA zur Verfügung und unterstützt die Weiterleitung. Viele Unternehmen haben bislang keine etablierte Meldekette, weil Support oder Service Vorfälle auffangen, bevor sie Security oder Compliance erreichen.

Daraus ergeben sich diese nächsten Schritte:

• Prozesse zur Erkennung und Behandlung von Sicherheitsvorfällen aufsetzen
• Interne Meldeketten definieren (z. B. IT → CISO → Management)
• Registrierung, Fristen und Datenfelder der ENISA Single Reporting Platform vorbereiten
• Support-, Service- und Vertriebsmitarbeitende sensibilisieren und schulen
• Dokumentation aller Sicherheitsvorfälle und Reaktionen im Rahmen der technischen Unterlagen sicherstellen

Betrieb und Portfolio

Schritt 8. Update-Strategie anpassen und Funktion von Sicherheit trennen

Nach Anhang I Teil II CRA müssen erkannte Sicherheitslücken unverzüglich durch Sicherheitsupdates behoben werden. Sicherheitsupdates sind grundsätzlich kostenlos bereitzustellen. Update-Mechanismen müssen eine sichere Verteilung ermöglichen und, soweit anwendbar, automatische Sicherheitsupdates unterstützen. Sicherheitsupdates müssen, soweit technisch machbar, getrennt von Funktionsupdates bereitgestellt werden. Bei Industrieanlagen kann die technische Umsetzbarkeit auch von Wartungsfenstern, Sicherheitsfreigaben und Auswirkungen auf den Betrieb abhängen.

Für viele Hersteller bedeutet das eine Überarbeitung der bestehenden Update-Strategie. Es braucht klare Prozesse und technische Mechanismen, um Sicherheitsupdates gezielt und möglichst unabhängig vom Funktionsumfang auszurollen. Das betrifft insbesondere Build-, Test- und Release-Prozesse sowie die entsprechende Dokumentation.

Daraus ergeben sich diese nächsten Schritte:

• Bestehende Update-Strategie analysieren und anpassen
• Trennung von Funktions- und Sicherheitsupdates technisch und organisatorisch umsetzen, soweit dies technisch machbar ist
• Automatische Sicherheitsupdates soweit anwendbar unterstützen
• Release- und Testprozesse auf neue Anforderungen ausrichten
• DevOps-Pipeline um Security-Gates erweitern
• Änderungen in technischer Dokumentation und Kundenkommunikation festhalten

Schritt 9. Mitarbeitende schulen, nicht nur Entwickler

Der CRA betrifft nicht nur die technische Umsetzung, sondern verändert auch die Rollen und Verantwortlichkeiten im Unternehmen. Deshalb ist es entscheidend, alle betroffenen Mitarbeitenden frühzeitig zu sensibilisieren, insbesondere in Entwicklung, Einkauf, Produktmanagement, Service und Vertrieb.

Die Schulungsinhalte sollten sich nicht auf technische Details beschränken, sondern praxisnah erklären, was sich im Tagesgeschäft ändert: Welche Anforderungen gelten für die Produktentwicklung? Welche Informationen müssen dokumentiert werden? Was ist bei Lieferanten zu beachten? Wie reagiert man auf Sicherheitsvorfälle?

Daraus ergeben sich diese nächsten Schritte:

• Zielgruppenspezifische Schulungen konzipieren und durchführen
• Schulungsnachweise dokumentieren und regelmäßig auffrischen
• Schulungsformate wählen, die in den Arbeitsalltag passen (z. B. kurze Online-Module, Onboarding-Elemente, Lunch & Learn)

Schritt 10. Produktstrategie anpassen und Portfolio steuern

Der CRA bringt nicht nur technische Anforderungen, sondern auch unternehmerische Entscheidungen mit sich. Produkte, die nach Artikel 69 Absatz 2 CRA vor dem 11. Dezember 2027 bereits in Verkehr gebracht wurden, müssen nicht allein wegen dieses Stichtags nachgerüstet oder vom Markt genommen werden. Für sie gelten die CRA-Anforderungen grundsätzlich erst, wenn sie ab diesem Zeitpunkt wesentlich geändert werden. Eine wichtige Ausnahme sind die Meldepflichten aus Artikel 14, die auch für bereits auf dem Markt befindliche Produkte gelten.

Anders liegt der Fall bei einem älteren Produkttyp, von dem nach dem 11. Dezember 2027 neue Einheiten erstmals auf den Unionsmarkt gebracht werden. Diese Einheiten müssen CRA-konform sein. Hersteller sollten ihr Portfolio deshalb danach unterscheiden, welche konkreten Einheiten bereits im Markt sind, welche neuen Einheiten geplant sind und welche Änderungen als wesentlich einzustufen sein könnten. Ein CRA-Gate in Entwicklung oder Release hilft, Anforderungen vor dem Inverkehrbringen nachvollziehbar zu prüfen.

Daraus ergeben sich diese nächsten Schritte:

• Bereits in Verkehr gebrachte Einheiten von künftig neu in Verkehr gebrachten Einheiten unterscheiden
• Produktänderungen auf ihre mögliche Wesentlichkeit prüfen und dokumentieren
• Neue Einheiten, die ab dem 11. Dezember 2027 erstmals in Verkehr gebracht werden, CRA-konform planen und entwickeln
• Interne Freigabeprozesse um ein CRA-Konformitätskriterium erweitern

Was ein belastbarer CRA-Fahrplan leistet

CRA-Compliance ist kein einmaliger Kraftakt, sondern ein Programm über Produktentwicklung, Lieferkette, Support und Organisation. Track A verlangt bis zum 11. September 2026 einen einsatzfähigen Meldeprozess. Track B führt bis zum 11. Dezember 2027 zu konformen Produkten, belastbaren Nachweisen und einer tragfähigen Supportstrategie.

Ein gutes Umsetzungskonzept macht Verantwortlichkeiten, Prioritäten und Nachweise pro Produkt sichtbar. So lassen sich Reporting, Security Engineering und Portfolioentscheidungen rechtzeitig steuern, statt sie kurz vor einer Frist unter Druck nachzuholen.

Für einen strukturierten Einstieg hilft unser CRA-Workshop.

Wie bereitest du Reporting und Produktkonformität in deinem Unternehmen gemeinsam vor? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.