CRA-Umsetzungs-Roadmap für Hersteller und CISO

Problem in der Praxis

Viele Hersteller behandeln den CRA als spätere Pflichtübung und unterschätzen die Vorlaufzeit. Drei Muster wiederholen sich. Erstens fehlt ein belastbares Produktinventar: Niemand kann verlässlich sagen, welche Produkte, Varianten und Firmware-Stände in den Anwendungsbereich fallen und wer dafür Hersteller im Sinne der Verordnung ist. Zweitens wird die Produktklasse zu spät bestimmt, sodass eine eventuell verpflichtende Drittprüfung den Marktstart blockiert. Drittens werden SBOM, PSIRT und Unterstützungszeitraum als Detailthemen weggeschoben, obwohl sie das Fundament der Lebenszykluspflichten bilden. Sichtbar wird die Lücke erst, wenn der Einkauf eines Kunden die EU-Konformitätserklärung verlangt oder eine erste Schwachstellenmeldung über einen Kanal eintrifft, der niemandem zugeordnet ist.

CISO-Einordnung

Der CRA ist produktbezogen und damit von organisationsbezogenen Rahmen wie NIS2 abzugrenzen. NIS2 adressiert das Risikomanagement eines Betreibers, der CRA die Eigenschaften und Lebenszykluspflichten eines Produkts beim Hersteller. Die Roadmap muss deshalb zwei oft getrennte Welten zusammenführen: Produktsicherheit als Engineering-Thema und Konformität als regulatorisches Thema. Sie ordnet sich entlang weniger Bausteine, die aufeinander aufbauen:

• Scope und Produktinventar: betroffene Produkte und eigene Akteursrolle (Hersteller, Bevollmächtigter, Importeur, Händler).
• Klassifizierung: Standardprodukt, wichtiges Produkt nach Anhang III (Klasse I oder II) oder kritisches Produkt nach Anhang IV.
• Gap-Analyse gegen die wesentlichen Anforderungen (Anhang I, Teil I Produkteigenschaften, Teil II Schwachstellenbehandlung).
• Dauerfunktionen: SBOM als Datengrundlage, PSIRT als organisatorischer Kern für Schwachstellenbehandlung und Meldung.
• Konformitätsbewertung und Nachweisbasis: technische Dokumentation (Anhang VII), Nutzerinformationen (Anhang II), EU-Konformitätserklärung und CE-Kennzeichnung.

Diese Bausteine sind kein einmaliger Durchlauf, sondern ein Regelkreis je Produktlinie.

Umsetzungsperspektive

Eine praktikable Roadmap richtet sich an den gestaffelten Terminen aus.

Phase 1 (Inventar und Scope, sofort): Produktportfolio erfassen, Anwendungsbereich je Produkt klären, eigene Akteursrolle festlegen. Wer ein Produkt wesentlich verändert, kann selbst als Hersteller gelten. Ergebnis ist ein priorisiertes Produktregister.

Phase 2 (Klassifizierung): Jedes Produkt anhand der Original-Anhänge einordnen, weil die Klasse das Bewertungsverfahren steuert. Betriebssysteme zählen zu den wichtigen Produkten der Klasse I; Firewalls sowie Intrusion-Detection- und -Prevention-Systeme (IDS/IPS) zur Klasse II. Bei Klasse I ist eine Selbstbewertung nur zulässig, wenn einschlägige harmonisierte Normen, gemeinsame Spezifikationen oder ein passendes Zertifizierungsschema vollständig angewendet werden, sonst ist eine Drittprüfung durch eine notifizierte Stelle nötig. Bei Klasse II ist die Drittprüfung grundsätzlich verpflichtend. Standardprodukte kommen in der Regel mit Selbstbewertung (interne Kontrolle, Modul A) aus.

Phase 3 (Gap-Analyse): Den Ist-Zustand je Produkt gegen Anhang I bewerten, also Security-by-Design und -by-Default, Auslieferung ohne bekannte ausnutzbare Schwachstellen, sichere Standardkonfiguration und sichere Update-Mechanismen sowie die Lebenszykluspflichten zur Schwachstellenbehandlung. Aus den Lücken entsteht ein Maßnahmenplan mit Ownern und Terminen.

Phase 4 (Dauerfunktionen): SBOM automatisiert aus der Build-Pipeline erzeugen und versioniert mitführen; eine PSIRT-Funktion mit erreichbarer Kontaktstelle, Coordinated-Vulnerability-Disclosure-Policy (CVD) und definierten Reaktionszeiten verankern; den Unterstützungszeitraum je Produktlinie festlegen und ausweisen. Als Orientierung gilt in der Regel mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist; der Einzelfall ist an der Verordnung zu prüfen.

Phase 5 (Konformitätsbewertung mit Vorlauf): Die Vorschriften zur Notifizierung der Konformitätsbewertungsstellen (Kapitel IV) gelten ab dem 11. Juni 2026; erst danach baut sich die Landschaft notifizierter Stellen auf. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle greifen ab dem 11. September 2026; bis dahin müssen die Meldewege (24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht an ENISA und das nationale CSIRT) eingeübt sein. Die volle Anwendung inklusive Konformitätsbewertung und CE-Kennzeichnung gilt ab dem 11. Dezember 2027.

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen grundsätzlich erst bei einer wesentlichen Änderung unter die vollen Pflichten; die Meldepflichten wirken jedoch auch für bereits bereitgestellte Produkte. Als nationale Orientierungshilfe kann die BSI TR-03183 dienen (Teil 1 allgemeine Anforderungen, Teil 2 SBOM, Teil 3 Umgang mit Schwachstellen); sie ist frei zugänglich, aber nicht rechtsverbindlich und ohne Konformitätsvermutung. Versionsstand vor Nutzung prüfen.

Typische Fehler

1. Der Programmstart wird verschoben, obwohl der Aufbau Jahre Vorlauf braucht.
2. Das Produktinventar bleibt unvollständig, sodass betroffene Produkte oder die eigene Herstellerrolle übersehen werden.
3. Die Klassifizierung erfolgt spät, und eine verpflichtende Drittprüfung wird erst kurz vor dem Marktstart erkannt.
4. SBOM und PSIRT werden als optionale Technikthemen behandelt statt als tragende Dauerfunktionen.
5. Die technische Dokumentation wird nachträglich erzeugt statt entwicklungsbegleitend gepflegt.
6. Die Meldewege werden nicht geübt, sodass die 24-/72-Stunden-Fristen im Ernstfall nicht eingehalten werden.

Risiken und Trade-offs

Die Roadmap balanciert Geschwindigkeit gegen Belastbarkeit: Eine zu schlanke Umsetzung erreicht Stichtage formal, liefert aber keine prüfbaren Nachweise; eine zu schwere bindet Kapazität, die im Engineering für die eigentliche Sicherheit fehlt. Bei der Klassifizierung erzeugt eine zu konservative Einstufung unnötigen Prüfaufwand, eine zu optimistische führt zu nicht konformen Produkten am Markt mit aufsichtsrechtlichen Folgen. Die Wahl zwischen Selbstbewertung und Drittprüfung wägt Geschwindigkeit und Haftung gegen externe Bestätigung ab. Beim Unterstützungszeitraum steht kurzfristige Kostenersparnis gegen Markterwartung und Nutzungsdauer. Werkzeuge für SBOM-Erzeugung oder Schwachstellen-Scanning unterstützen den Prozess, ersetzen aber weder die PSIRT-Verantwortung noch die Triage-Entscheidungen.

Entscheidungspunkte

• Welche Produkte fallen in den Anwendungsbereich, und in welcher Akteursrolle handeln wir je Produkt?
• In welche Produktklasse fällt jedes Produkt nach Anhang III beziehungsweise IV, und wer verantwortet diese Einstufung?
• Ist je Produkt eine Selbstbewertung zulässig, oder ist eine notifizierte Stelle erforderlich?
• Welche harmonisierten Normen oder Spezifikationen ziehen wir heran, um eine Konformitätsvermutung zu nutzen?
• Wie und bis wann entstehen SBOM, PSIRT, CVD-Policy und Unterstützungszeitraum je Produktlinie?
• Welche Vorlaufzeit braucht eine notifizierte Stelle im Verhältnis zum geplanten Marktstart?

Praktische Empfehlungen

1. Starten Sie sofort mit einem priorisierten Produktinventar und klären Sie je Produkt Anwendungsbereich und Akteursrolle.
2. Klassifizieren Sie frühzeitig anhand der Original-Anhänge und dokumentieren Sie die Begründung nachvollziehbar.
3. Führen Sie eine Gap-Analyse gegen die wesentlichen Anforderungen (Anhang I) und leiten Sie einen Maßnahmenplan mit Ownern und Terminen ab.
4. Bauen Sie SBOM (automatisiert aus der Pipeline) und PSIRT (Kontaktstelle, CVD-Policy, Reaktionszeiten) als Dauerfunktionen, nicht als Projekt.
5. Pflegen Sie die technische Dokumentation entwicklungsbegleitend und legen Sie den Unterstützungszeitraum bewusst und transparent fest.
6. Sichern Sie die Kapazität notifizierter Stellen, bevor der Marktzeitplan steht, und üben Sie die Meldewege vor dem 11. September 2026.

Relevante Normreferenzen

• Cyber Resilience Act, Verordnung (EU) 2024/2847: maßgeblicher Rechtsrahmen; wesentliche Anforderungen (Anhang I), technische Dokumentation (Anhang VII), Nutzerinformationen (Anhang II), Produktklassen (Anhang III/IV), Konformitätsbewertung, CE-Kennzeichnung und gestaffelte Anwendungstermine; unmittelbar geltend, frei zitierbar mit Quellenangabe.
• IEC 62443 (Reihe, insbesondere 62443-4-1): fachliche Referenz für sicheren Produktentwicklungsprozess und Komponentenanforderungen; Kandidat für harmonisierte Normen, ohne dass eine Listung vorweggenommen wird.
• NIST SSDF (SP 800-218): prozessuale Referenz für sichere Softwareentwicklung, Schwachstellenbehandlung und SBOM (Public Domain).
• ISO/IEC 27001: organisatorische Referenz für den sicheren Entwicklungs- und Schwachstellenprozess (nur allgemeiner Strukturbezug, keine Control-Nummern).
• BSI TR-03183: nationale Orientierungs- und Umsetzungshilfe zum CRA; nicht rechtsverbindlich, keine Konformitätsvermutung.