CRA-Checkliste: 12 Schritte zur Umsetzung

Die Umsetzung des Cyber Resilience Act lässt sich in zwei Phasen gliedern: Bis zum 11. September 2026 brauchen Sie Meldefähigkeit – Produktinventar, Kontaktstelle und ein Runbook für 24 h/72 h. Bis zum 11. Dezember 2027 bauen Sie die Nachweise auf: Risikobewertung, SBOM, sichere Standardkonfiguration, Update-Prozess, technische Dokumentation und Konformitätserklärung.

Die folgenden 12 Schritte sind nach Dringlichkeit sortiert. Sie ersetzen keine rechtliche Prüfung Ihres Einzelfalls, geben aber eine belastbare Reihenfolge vor.

Phase 1: bis 11. September 2026

1. Produktinventar: Alle Produkte mit digitalen Elementen, die Sie in der EU bereitstellen – inklusive Versionen, die noch bei Kunden laufen. Die Meldepflicht gilt auch für Bestandsprodukte.
2. Rollen klären: Für jedes Produkt festhalten, wer Hersteller ist. Agenturen finden dazu Szenarien in CRA für Agenturen.
3. Kontaktstelle einrichten: Eine feste Adresse für Schwachstellenmeldungen veröffentlichen (z. B. security.txt) und eine Richtlinie zur koordinierten Offenlegung.
4. Runbook und Bereitschaft: Wer erkennt, wer bewertet, wer meldet innerhalb von 24 h und 72 h? Vertretungen und Vorlagen festlegen – Details in CRA-Meldepflicht.

Phase 2: bis 11. Dezember 2027

1. Produktkategorie bestimmen: Standard, wichtig (Klasse I/II) oder kritisch – siehe CRA-Produktkategorien. Bei Bedarf früh eine benannte Stelle ansprechen.
2. Cybersicherheits-Risikobewertung: Dokumentiert, pro Produkt, und bei Änderungen aktualisiert (Art. 13).
3. SBOM: Maschinenlesbar, je Release, automatisiert – Anleitung in SBOM erstellen.
4. Sorgfalt bei Komponenten Dritter: Open-Source- und Zukaufkomponenten prüfen und überwachen – siehe CRA und Open Source.
5. Secure by default und Annex I Teil I: Sichere Standardkonfiguration, Zugriffsschutz, Datenminimierung, reduzierte Angriffsfläche, Protokollierung.
6. Supportzeitraum und Update-Prozess: Supportzeitraum festlegen (in der Regel mindestens fünf Jahre), sichere und möglichst automatische Sicherheitsupdates.
7. Technische Dokumentation (Annex VII): Produktbeschreibung, Design und Entwicklung, Risikobewertung, Schwachstellenbehandlung, angewandte Normen, Testberichte, Supportzeitraum.
8. Konformitätsbewertung, EU-Konformitätserklärung, CE: Verfahren nach Kategorie durchführen, Erklärung ausstellen, CE-Kennzeichen anbringen, Nutzerinformationen nach Annex II bereitstellen.

Was in die Nutzerinformation gehört

Annex II verlangt unter anderem: Name und Kontakt des Herstellers, die Kontaktstelle für Schwachstellen, den Zweck des Produkts, bekannte Risiken, wo die SBOM zugänglich ist (falls der Hersteller sie bereitstellt), das Enddatum des Supportzeitraums und Hinweise zur sicheren Installation und Nutzung. Das Supportende muss beim Kauf klar erkennbar sein.

Vorlage

Eine strukturierte Fassung dieser Checkliste mit Verantwortlichen, Status und Nachweisfeldern finden Sie auf unserer Seite CRA-Checkliste. Nutzen Sie sie als Arbeitsliste für Ihr Produktteam.

Häufige Lücken

• Nur das aktuelle Release im Blick: Die Meldepflicht betrifft auch ältere Versionen im Feld.
• SBOM ohne Prozess: Eine einmalige Liste hilft im Ernstfall nicht.
• Kein Supportende kommuniziert: Ohne festgelegten Zeitraum lassen sich weder Kosten planen noch Annex II erfüllen.
• Dokumentation am Ende: Nachweise lassen sich schwer rekonstruieren. Sammeln Sie sie während der Entwicklung.
• Warten auf Normen: Die harmonisierten Normen sind in Arbeit, die Pflichten gelten trotzdem.

Wer macht was? Rollen im Unternehmen

In kleinen Unternehmen liegen mehrere Rollen bei einer Person. Wichtig ist, dass jeder Schritt einen namentlich Verantwortlichen hat.

Ein realistischer Fahrplan

Für einen Mittelständler mit wenigen Produkten hat sich eine Abfolge in Quartalen bewährt: Im ersten Schritt die Meldefähigkeit herstellen, danach SBOM und Komponentenprüfung automatisieren, dann die Risikobewertung je Produkt erstellen und zuletzt die technische Dokumentation zusammenführen. Klasse-II-Produkte sollten vorgezogen werden, weil die externe Prüfung zusätzliche Zeit braucht.

Beispiel: Softwarehaus mit drei Produkten

Ein Softwarehaus mit einem Desktop-Produkt, einer mobilen App und einer Server-Komponente startet mit einem gemeinsamen Runbook und einer gemeinsamen Kontaktstelle für alle drei Produkte. SBOM-Erzeugung und Schwachstellenabgleich werden in allen Pipelines gleich aufgesetzt. Risikobewertungen und Supportzeiträume werden dagegen je Produkt festgelegt, weil sich Nutzung und Lebensdauer unterscheiden.

Beispiel: Agentur mit Kundenportfolio

Eine Agentur arbeitet die Checkliste zweimal ab: einmal für eigene Produkte, einmal als Service-Liste für Kunden. Für Kundenprojekte konzentriert sie sich auf die Schritte, die sie technisch liefern kann – SBOM, Updates, Komponentenprüfung – und übergibt die Nachweise an den Hersteller.

So nutzen Sie die Checkliste im Team

Die Checkliste entfaltet ihren Wert erst, wenn sie regelmäßig gepflegt wird. Bewährt hat sich ein kurzer, fester Termin alle zwei Wochen, in dem das Team Status, Blocker und nächste Schritte je Produkt durchgeht. Jeder abgeschlossene Schritt bekommt einen Nachweis: ein Dokument, ein Pipeline-Log, eine SBOM-Datei oder ein Protokoll.

• Status: offen, in Arbeit, abgeschlossen – mit Datum.
• Nachweis: Link auf das konkrete Artefakt, nicht nur ein Häkchen.
• Nächste Überprüfung: Risikobewertung und SBOM veralten; legen Sie fest, wann sie erneut geprüft werden.

So entsteht die technische Dokumentation nebenbei, statt am Ende unter Zeitdruck zusammengesucht zu werden.

Mit Nuowei abarbeiten

Nuowei (Beta, Launch November 2026) bildet diese Schritte als Arbeitsliste je Produkt ab und verknüpft sie mit automatisch gesammelten Nachweisen aus Repository und Pipeline. Tragen Sie sich auf die Warteliste ein.