In 10 Schritten zur CRA-Konformität bis 2028

Mit dem Inkrafttreten des Cyber Resilience Act (CRA) beginnt für Hersteller digitaler Produkte ein Wettlauf mit der Zeit. Ab dem 11. Dezember 2027 dürfen nur noch Produkte mit CE-Kennzeichnung gemäß CRA in den europäischen Markt eingeführt werden. Bereits ab September 2026 greifen erste Verpflichtungen wie die 24-Stunden-Meldepflicht bei aktiv ausgenutzten Schwachstellen. Unternehmen, die bis dahin keine Compliance-Strategie entwickelt und umgesetzt haben, riskieren nicht nur Bußgelder und Marktverbot, sondern auch den Verlust von Kundenvertrauen.

Damit es nicht so weit kommt, braucht es einen strukturierten Fahrplan. Die folgenden 10 Schritte helfen Ihnen, systematisch, realistisch und mit einem klaren Blick auf Aufwand, Zuständigkeiten und Budget auf 2028 hinzuarbeiten.

• 1. Projektstruktur aufsetzen und Verantwortung klären
• 2. Produkte identifizieren und Lebenszyklus festlegen
• 3. Security-by-Design in der Produktentwicklung verankern
• 4. Schwachstellenmanagement aufbauen
• 5. Lieferkette und Open Source prüfen
• 6. Technische Dokumentation und Konformität vorbereiten
• 7. Sicherheitsvorfälle erkennen und melden
• 8. Update-Strategie anpassen: Funktion ≠ Sicherheit
• 9. Mitarbeitende schulen – und nicht nur die Entwickler
• 10. Produktstrategie anpassen und Portfolio steuern

1. Projektstruktur aufsetzen und Verantwortung klären

Die Umsetzung des Cyber Resilience Act ist kein reines IT-Sicherheitsvorhaben – sie ist ein eigenständiges Unternehmensprojekt. Das bedeutet: 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? Wer trägt die Verantwortung für Steuerung und Umsetzung?

Wie bei jedem größeren Projekt müssen nun die organisatorischen Grundlagen geschaffen werden. Dazu gehört insbesondere die Definition eines Projektteams sowie eine RACI-Matrix, die klärt, wer für welche Aufgaben verantwortlich, beteiligt oder informiert ist. Auch ein realistischer Zeit- und Budgetrahmen gehört zu den Basics dieser Phase.

Die Projektverantwortung muss nicht zwingend bei der Geschäftsleitung liegen – wohl aber deren Unterstützung ist entscheidend. Ohne die Rolle der Geschäftsführung als Sponsor lassen sich notwendige Entscheidungen und strukturelle Veränderungen nicht durchsetzen. Sie sollte als aktiver Stakeholder verstanden werden, der regelmäßig in Steering Committees einbezogen wird und die Umsetzung aktiv unterstützt.

Was konkret zu tun ist:

• 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

2. Produkte identifizieren und Lebenszyklus festlegen

Der CRA betrifft „Produkte mit digitalen Elementen“, also Hardware oder Software, die direkt oder indirekt mit einem Netzwerk verbunden werden können. In der Praxis bedeutet das: Nicht jedes Produkt eines Unternehmens ist automatisch betroffen. Gerade Hersteller mit breitem Portfolio – etwa Maschinenbauer mit vielen Produktvarianten und Baureihen – sollten nicht mit einer vollständigen Produktauflistung starten, sondern gezielt alle Produkte mit digitalen Funktionen in den Fokus nehmen.

Im nächsten Schritt lohnt es sich zu prüfen, welche Produkte technisch identisch oder zumindest sehr ähnlich aufgebaut sind. Wenn etwa alle Maschinen eines Herstellers auf der gleichen Steuerungsplattform basieren, können diese im CRA-Kontext als eine Produktfamilie betrachtet werden. Das reduziert den Analyse- und Dokumentationsaufwand erheblich und ermöglicht eine effizientere Umsetzung.

Zusätzlich ist der Lebenszyklus jedes betroffenen Produkts zu definieren. Denn die CRA-Pflichten enden nicht mit dem Inverkehrbringen – sie erstrecken sich über die gesamte Lebensdauer hinweg. Der Gesetzgeber erwartet einen Mindest-Supportzeitraum von fünf Jahren, sofern keine triftigen Gründe für eine kürzere Dauer vorliegen. Hersteller müssen frühzeitig bewerten, wie lange ihre Produkte genutzt werden, wie lange sie unterstützt werden können – und ob bestehende Komponenten, Plattformen und Prozesse dies überhaupt ermöglichen.

Was konkret zu tun ist:

• Nur Produkte mit digitalen Elementen identifizieren und in den Scope aufnehmen
• Technische Gemeinsamkeiten und Plattformansätze erkennen (z. B. gemeinsame Steuerung, Firmware, Kommunikation)
• Erste grobe Zuordnung zu CRA-Kategorien (Standardprodukt, Klasse I, Klasse II) vornehmen
• Unternehmensrollen klären: Treten Sie als Hersteller, Importeur oder Händler auf?
• Erwartete Lebensdauer und vorgesehener Supportzeitraum pro Produktfamilie 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

3. Security-by-Design in der Produktentwicklung verankern

Der CRA verlangt, dass Cybersicherheit nicht nachträglich aufgesetzt, sondern von Beginn an in den Entwicklungsprozess integriert wird. Landläufig ist diese Forderung als „Security by Design“ bekannt. Hersteller müssen nachweisen, dass sie bereits bei der 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 oder Produktfamilie ist dabei der Einstiegspunkt. Sie bildet die Basis für angemessene technische und organisatorische Maßnahmen und ist gleichzeitig zwingender Bestandteil der technischen Dokumentation.

Was konkret zu tun ist:

• Sicherheitsanforderungen pro Produkt systematisch erfassen und dokumentieren
• Risikoanalyse durchführen (z. B. mit STRIDE, DREAD, TARA oder ISO 27005)
• 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

4. Schwachstellenmanagement aufbauen

Ein zentrales Element des CRA ist ein durchgängiges Schwachstellenmanagement über die gesamte Lebensdauer eines Produkts hinweg. 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 ist nicht nur gefordert, sondern wird auch in der technischen Dokumentation und bei Audits überprüft. Unternehmen sollten daher ein zentrales Vorgehen etablieren, das vom CVE-Scanning über die Klassifizierung bis zur Verteilung von Patches reicht. Auch die Offenlegung gegenüber Nutzern und die Meldung an ENISA spielt dabei eine Rolle.

Was konkret zu tun ist:

• 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

5. Lieferkette und Open Source prüfen

Viele Sicherheitsrisiken entstehen nicht in der eigenen Entwicklung, sondern durch zugekaufte Komponenten, vor allem durch Open Source. Der CRA verlangt, dass Hersteller auch für diese Drittkomponenten Verantwortung übernehmen. Wer Bibliotheken, Frameworks oder Hardware anderer Anbieter einsetzt, muss sicherstellen, dass diese sicher betrieben und regelmäßig überprüft werden.

Ein entscheidender Hebel ist dabei die Einführung einer Software Bill of Materials (SBOM), also einer vollständigen Aufstellung aller Softwarekomponenten inkl. Herkunft, Lizenz und Versionsstand. Diese SBOM dient als Grundlage für Schwachstellenanalysen und Compliance-Prüfungen. Sie kann im Fall eines Vorfalls schnell Auskunft darüber geben, ob ein betroffenes Modul im Produkt enthalten ist.

Was konkret zu tun ist:

• Für jedes betroffene Produkt eine SBOM 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
• Vertragliche Anforderungen an Lieferanten anpassen, um Sicherheits- und Updatepflichten abzusichern
• Externe Lieferanten auditieren

6. Technische Dokumentation und Konformität vorbereiten

Die technische Dokumentation ist das Rückgrat des Nachweises, dass ein Produkt den Anforderungen des CRA entspricht. Sie muss nicht nur bei der erstmaligen Konformitätsbewertung vollständig und aktuell vorliegen, sondern über die gesamte Lebensdauer des Produkts gepflegt werden.

Die Dokumentation umfasst unter anderem: Risikobewertung, Sicherheitsmaßnahmen, Updatepolitik, Informationen zur Lieferkette, Beschreibung der Entwicklungsprozesse, Schwachstellenmanagement sowie – falls vorhanden – die Ergebnisse externer Prüfungen. Für höher klassifizierte Produkte (Klasse I/II) kann zudem eine Konformitätsbewertung durch eine benannte Stelle erforderlich sein.

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

Was konkret zu tun ist:

• 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 benannten Stellen aufnehmen, wenn eine externe Konformitätsbewertung erforderlich ist

7. Sicherheitsvorfälle erkennen und melden

Ab dem 17. Januar 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen sowie sicherheitsrelevante Vorfälle mit erheblicher Wirkung innerhalb von 24 Stunden an ENISA (über das europäische Meldesystem) sowie an nationale Behörden melden. Diese Pflicht gilt unabhängig von der Frage, ob der Hersteller die Schwachstelle selbst verschuldet hat.

Viele Unternehmen haben jedoch bislang keine etablierten Prozesse zur strukturierten Sicherheitsvorfallbehandlung oder die Vorfälle erreichen die IT gar nicht, weil sie vom Support-Team abgefangen werden. Deshalb braucht es technische und organisatorische Maßnahmen, um Vorfälle frühzeitig zu erkennen, sauber zu dokumentieren und strukturiert weiterzugeben.

Was konkret zu tun ist:

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

8. Update-Strategie anpassen: Funktion ≠ Sicherheit

Der CRA schreibt vor, dass Sicherheitsupdates und Funktionsupdates getrennt behandelt und bereitgestellt werden müssen. Nutzer dürfen nicht gezwungen werden, neue Funktionen zu akzeptieren, nur um Sicherheitslücken zu schließen. Gleichzeitig müssen Sicherheitsupdates auch ohne manuelle Nutzerinteraktion möglich sein – idealerweise automatisch.

Für viele Hersteller bedeutet das: Ihre bestehende Update-Strategie muss grundlegend überarbeitet werden. Es braucht klare Prozesse und technische Mechanismen, um Sicherheitsupdates gezielt und unabhängig vom Funktionsumfang auszurollen. Dies betrifft insbesondere die Trennung im Build-, Test- und Release-Prozess sowie die entsprechende Dokumentation.

Was konkret zu tun ist:

• Bestehende Update-Strategie analysieren und anpassen
• Trennung von Funktions- und Sicherheitsupdates technisch und organisatorisch umsetzen
• Automatische Sicherheitsupdates inkl Opt-Out ermöglichen (sofern technisch vertretbar)
• Release- und Testprozesse auf neue Anforderungen ausrichten
• DevOps-Pipeline um Security-Gates erweitern
• Änderungen in technischer Dokumentation und Kundenkommunikation festhalten

9. Mitarbeitende schulen – und nicht nur die 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?

Was konkret zu tun ist:

• 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)

10. Produktstrategie anpassen und Portfolio steuern

Der CRA bringt nicht nur technische Anforderungen, sondern auch unternehmerische Entscheidungen mit sich. Spätestens 2027 dürfen nur noch CRA-konforme Produkte in Verkehr gebracht werden- Das bedeutet, dass bestehende Produkte entweder nachgerüstet oder vom Markt genommen werden.

Hersteller sollten deshalb ihr Portfolio frühzeitig überprüfen: Welche Produkte bleiben langfristig im Programm? Welche lassen sich mit vertretbarem Aufwand anpassen? Und welche laufen planmäßig aus? Auch Produktneuentwicklungen müssen frühzeitig CRA-Anforderungen berücksichtigen, idealerweise bereits ab Projektstart und unter Nutzung un Einhaltung der jetzt vorliegenden technischen Dokumentation. Ein „CRA-Gate“ in der Entwicklungs- oder Release-Phase kann helfen, zu überprüfen, ob alle Anforderungen erfüllt sind, bevor ein Produkt in den Markt geht.

Was konkret zu tun ist:

• Bestehende Produktlinien und Roadmaps im Hinblick auf CRA-Fitness analysieren
• Entscheidungen treffen: Nachrüsten, abkündigen oder ersetzen?
• Neue Produkte ab 2025/26 mit CRA-Anforderungen planen und entwickeln
• Interne Freigabeprozesse um ein CRA-Konformitätskriterium erweitern

Fazit: Der CRA ist kein Sprint aber der Startschuss ist jetzt

Die Anforderungen des Cyber Resilience Act wirken auf den ersten Blick überwältigend, lassen sich aber systematisch und praxisnah in den Griff bekommen. Wer heute beginnt, legt die Grundlagen für sichere Produkte, belastbare Prozesse und langfristige Marktzulassung. Es ist auch klar, dass CRA-Compliance ist kein einmaliger Kraftakt sondern ein strukturiertes Programm ist, das sich durch Produktentwicklung, Lieferkette, Support und Organisation zieht. Wer das früh erkennt, schafft sich Zeit für Planung, Priorisierung und Umsetzungsqualität und vermeidet hektische Nachbesserungen kurz vor Fristende.

Der entscheidende Erfolgsfaktor dabei ist, Regeln nicht blind abzuarbeiten, sondern ein eigenes, tragfähiges Umsetzungskonzept mit klaren Verantwortlichkeiten, pragmatischen Lösungen und basierend auf einer ehrlichen Analyse des Status quo zu entwickeln. Wer 2025 mit Struktur plant, hat 2026 produktionsreife Prozesse, 2027 auditfähige Produkte und ist 2028 wettbewerbsfähig.

Sie möchten schneller loslegen? Unser CRA-Workshop hilft Ihnen beim Einstieg – kompakt, praxisnah und mit einem klaren Fahrplan. Gerne begleiten wir Sie auch bei der weiteren Umsetzung.