Praxisorientierte Einordnung zu CRA-Readiness-Check: Welche Nachweise Produktteams jetzt vorbereiten müssen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Cyber Resilience Act aufbauen.
Ein CRA-Readiness-Check sollte nicht fragen, ob ein Unternehmen „Security macht“, sondern ob es die Sicherheit eines konkreten Produkts nachvollziehbar belegen kann. Genau an dieser Stelle zeigen sich typische Lücken: Das Produktteam kennt Risiken, aber die Entscheidung ist nicht dokumentiert. Ein Scanner findet Komponenten, aber niemand kann sie einer ausgelieferten Version zuordnen. Support behebt Schwachstellen, ohne dass Fristen und Kundenkommunikation reproduzierbar sind.
Die folgende Prüfung ist als Nachweischeck für eine Produktfamilie aufgebaut. Sie führt von Scope und Klassifizierung über Risikobewertung und Entwicklung bis zu Auslieferung und Vulnerability Handling. Jeder Prüfpunkt nennt nicht nur eine erwartete Aktivität, sondern ein überprüfbares Ergebnis. So entsteht kein abstrakter Reifegrad, sondern eine belastbare Liste der Unterlagen und Prozesse, die bis zur Konformitätsbewertung fehlen.
So führen Sie den Readiness-Check durch
Wählen Sie eine reale, aktuell vertriebene Produktfamilie und eine konkrete Version. Beteiligen Sie Produktmanagement, Entwicklung, Product Security, Qualität, Recht, Support und Einkauf. Ein Workshop allein reicht nicht: Aussagen werden anschließend anhand von Systemen, Tickets, Repositories, Verträgen und freigegebenen Dokumenten stichprobenartig verifiziert.
Bewerten Sie jeden Punkt in vier Zuständen: belegt, wenn ein aktueller und zum Produkt passender Nachweis vorliegt; teilweise belegt, wenn Prozess oder Unterlage existiert, aber Scope oder Wirksamkeit unklar sind; nicht belegt, wenn nur mündliche Praxis besteht; und nicht anwendbar, wenn eine dokumentierte Begründung vorliegt. „Wir machen das normalerweise“ zählt nicht als Nachweis.
Zu jeder Lücke gehören Risiko, Verantwortlicher, Zieltermin und Abhängigkeit. Dringlichkeit ergibt sich nicht nur aus dem Dokumentationsaufwand. Ein fehlender Meldeprozess vor dem 11. September 2026 ist zeitkritischer als eine kosmetische Vereinheitlichung bereits funktionsfähiger Vorlagen.
Prüfbereich A: Produkt-Scope und wirtschaftliche Rolle
- Produktbeschreibung: Existiert eine eindeutige Beschreibung von Hardware, Software, eingebetteten Komponenten und relevanter Fernverarbeitung?
- Verbindung: Ist dokumentiert, welche direkte oder indirekte Datenverbindung bestimmungsgemäß oder vernünftigerweise vorhersehbar ist?
- Marktbereitstellung: Ist klar, in welcher Gesellschaft und unter welchem Namen das Produkt im EU-Markt bereitgestellt wird?
- Rolle: Ist pro Vertriebskonstellation begründet, ob das Unternehmen Hersteller, Bevollmächtigter, Importeur oder Händler ist?
- Ausnahmen: Wurden mögliche Ausschlüsse oder vorrangige sektorale Rechtsakte anhand des konkreten Produkts geprüft?
- Varianten: Sind White-Label-, OEM-, kundenspezifische und Cloud-Varianten im Scope berücksichtigt?
Erwarteter Nachweis ist ein freigegebenes Scope- und Rollenblatt mit Produktverantwortlichem, Rechtsgrundlage, Version und offenen Annahmen. Eine unternehmensweite Präsentation ohne Zuordnung zu Produktvarianten ist nicht ausreichend.
Prüfbereich B: Klassifizierung und Konformitätsstrategie
- Kategorie: Ist geprüft, ob das Produkt als wichtiges Produkt der Klasse I oder II oder als kritisches Produkt einzuordnen ist?
- Begründung: Verweist die Klassifizierung auf tatsächliche Funktionen und nicht nur auf den Marketingnamen?
- Bewertungsweg: Ist festgelegt, welches Konformitätsbewertungsverfahren vorgesehen ist?
- Standards: Wird beobachtet, welche harmonisierten Standards und europäischen Zertifizierungsschemata anwendbar werden?
- Externe Stelle: Ist bei möglicher Drittprüfung geklärt, wann eine notifizierte Stelle eingebunden werden muss?
Als Nachweis dient ein genehmigter Entscheidungsvermerk. Weil sich technische Beschreibungen und Leitlinien weiterentwickeln können, benötigt er einen Eigentümer und ein Wiedervorlagedatum. Ein einmaliger Rechtsvermerk ohne Pflegeprozess veraltet zu schnell.
Prüfbereich C: Cybersecurity-Risikobewertung
- Verwendungskontext: Sind bestimmungsgemäße und vorhersehbare Nutzung, Benutzergruppen und Einsatzumgebungen beschrieben?
- Schutzwerte: Sind schützenswerte Funktionen, Daten, Credentials und Schnittstellen identifiziert?
- Vertrauensgrenzen: Zeigt ein Architekturmodell interne und externe Datenflüsse sowie Backend-Abhängigkeiten?
- Bedrohungen: Wurden realistische Missbrauchs- und Angriffsszenarien bewertet?
- Auswirkungen: Berücksichtigt die Bewertung neben Daten auch Verfügbarkeit, Sicherheit und mögliche physische Folgen?
- Maßnahmen: Ist jedes wesentliche Risiko konkreten Design-, Test- oder Betriebsmaßnahmen zugeordnet?
- Restrisiko: Sind Annahme, Begründung und Genehmigung verbleibender Risiken nachvollziehbar?
- Aktualisierung: Gibt es Auslöser für Neubewertung bei Release, Änderung, Schwachstelle oder Vorfall?
Erwartet wird keine universelle Methodik, sondern eine konsistente Produktakte. Threat Model, Risikoregister, Architektur und Security-Anforderungen müssen dieselbe Produktversion beschreiben. Widersprüchliche Versionsstände sind ein häufiges Warnsignal.
Prüfbereich D: Security-Anforderungen und sichere Defaults
- Ableitung: Lassen sich Security-Anforderungen auf CRA-Anforderungen und Produktrisiken zurückführen?
- Authentisierung: Sind Identitäten, Rollen, privilegierte Funktionen und Schutz gegen unbefugten Zugriff definiert?
- Angriffsfläche: Werden nicht benötigte Dienste, Schnittstellen und Funktionen im Auslieferungszustand deaktiviert?
- Sichere Konfiguration: Vermeidet das Produkt bekannte Standardzugänge und erzwingt notwendige Erstkonfiguration?
- Daten- und Integritätsschutz: Sind relevante Daten bei Speicherung und Übertragung angemessen geschützt?
- Protokollierung: Erzeugt das Produkt sicherheitsrelevante, verständliche und zeitlich zuordenbare Ereignisse?
- Updatefähigkeit: Können Updates authentisch, integritätsgeschützt und fehlertolerant eingespielt werden?
- Wiederherstellung: Existiert ein sicherer Weg aus fehlgeschlagenem Update oder beschädigter Konfiguration?
Als Nachweise eignen sich versionierte Anforderungen, Architekturentscheidungen, Akzeptanzkriterien und Tests. Ein allgemeiner Coding-Standard beweist nicht, dass das konkrete Produkt mit sicheren Defaults ausgeliefert wird.
Prüfbereich E: Entwicklungs- und Testprozess
- Security Gates: Sind prüfbare Security-Ergebnisse in Planung, Design, Implementierung und Release verankert?
- Codeänderungen: Werden Reviews, Schutz der Repositories und Trennung kritischer Freigaben nachvollziehbar umgesetzt?
- Automatisierte Prüfungen: Sind SAST, Dependency Scanning, Secret Detection oder vergleichbare Verfahren passend integriert?
- Dynamische Tests: Werden Schnittstellen, Authentisierung, Rechte und Fehlerszenarien am laufenden Produkt geprüft?
- Unabhängige Prüfung: Ist risikobasiert festgelegt, wann Penetrationstest oder externe Expertise erforderlich sind?
- Testabdeckung: Ordnet die Teststrategie Risiken und Security-Anforderungen konkreten Prüffällen zu?
- Abweichungen: Haben offene Findings Schweregrad, Verantwortlichen, Frist und dokumentierte Freigabe?
- Reproduzierbarer Build: Kann nachvollzogen werden, aus welchen Quellen und Abhängigkeiten eine Version erstellt wurde?
Eine Liste verwendeter Werkzeuge ist kein Wirksamkeitsnachweis. Stichproben sollten zeigen, ob ein kritischer Fund tatsächlich den Release blockiert oder nur in einem Dashboard verbleibt.
Prüfbereich F: Komponenten und Lieferkette
- Inventar: Sind Drittanbieter- und Open-Source-Komponenten je ausgelieferter Version bekannt?
- Herkunft: Werden Bezugsquelle, Integrität und Freigabe neuer Komponenten kontrolliert?
- SBOM: Kann eine maschinenlesbare Komponentenliste erzeugt und einem Release zugeordnet werden?
- Monitoring: Werden neue Schwachstellen für eingesetzte Versionen kontinuierlich bewertet?
- Erreichbarkeit: Prüft die Triage, ob eine verwundbare Funktion im Produkt tatsächlich nutzbar ist?
- Verträge: Fordern Lieferanten rechtzeitige Sicherheitsinformationen, Fixes und Supportzusagen?
- Supportende: Sind Risiken nicht mehr gepflegter Komponenten vor Produktfreigabe sichtbar?
Erwartet wird eine Verbindung aus SBOM, Komponentenfreigabe, Monitoring und Produktzuordnung. Eine aktuelle SBOM ohne Kenntnis der installierten Kundenstände beantwortet einen kritischen Vorfall nur teilweise.
Prüfbereich G: Vulnerability Handling und Meldungen
- Meldekanal: Gibt es einen öffentlich erreichbaren und überwachten Kontakt für Schwachstellenmeldungen?
- CVD-Policy: Sind Scope, erwartete Angaben, sichere Kommunikation und Reaktionsablauf beschrieben?
- Triage: Werden Eingang, Reproduzierbarkeit, Schweregrad, Ausnutzung und betroffene Versionen strukturiert bewertet?
- Behebung: Existieren Zielzeiten und ein kontrollierter Prozess für Fix, Test und Veröffentlichung?
- Kundeninformation: Enthalten Advisories betroffene Versionen, Risiko, Abhilfe und sichere Updateanleitung?
- CRA-Kriterien: Sind aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle rechtlich-operativ definiert?
- Single Reporting Platform: Sind Zugang, Vertretung und sichere Bedienung der ENISA-Plattform vorbereitet?
- Fristen: Funktioniert die Eskalation auch nachts, am Wochenende und bei unvollständigen Informationen?
- Übung: Wurde ein meldepflichtiger Fall mit Produktteam, Recht und Kommunikation praktisch durchgespielt?
Der stärkste Nachweis ist eine dokumentierte Übung mit Zeitstempeln, Entscheidungen und Verbesserungsmaßnahmen. Eine Prozessbeschreibung ohne erreichbare Rufbereitschaft ist vor September 2026 nicht ausreichend.
Prüfbereich H: Benutzerinformationen, Support und Lebenszyklus
- Sichere Installation: Erhalten Nutzer konkrete Anforderungen an Konfiguration, Umgebung und Zugangsschutz?
- Updateinformation: Ist verständlich, wie Updates bezogen, verifiziert und eingespielt werden?
- Supportzeitraum: Ist die Dauer der Sicherheitsunterstützung festgelegt, begründet und kommuniziert?
- Kontakt: Wissen Kunden, wo sie Sicherheitsmeldungen und Supportinformationen finden?
- Außerbetriebnahme: Gibt es Hinweise zum sicheren Löschen, Trennen und Ersetzen des Produkts?
- Altversionen: Ist bekannt, welche Versionen im Markt sind und wie Nutzer bei kritischen Risiken erreicht werden?
Prüfbereich I: Technische Dokumentation und Freigabe
- Produktakte: Sind Beschreibung, Architektur, Risiken, Anforderungen, Tests und Vulnerability-Prozess zusammengeführt?
- Versionierung: Ist eindeutig, welche Nachweise zu welcher Hardware-, Software- und Cloud-Version gehören?
- Konformität: Sind Bewertungsmodul, anwendbare Standards und gegebenenfalls externe Prüfung geplant?
- Erklärung und CE: Sind Verantwortliche und Freigabeschritte für EU-Konformitätserklärung und Kennzeichnung festgelegt?
- Aufbewahrung: Werden Unterlagen geschützt, auffindbar und über den erforderlichen Zeitraum verfügbar gehalten?
- Änderungsbewertung: Prüft ein Prozess, ob Änderungen neue Risiken oder eine erneute Bewertung auslösen?
Aus dem Ergebnis einen belastbaren Maßnahmenplan machen
Sortieren Sie Lücken nicht nur nach Anzahl. Bilden Sie vier Arbeitsstränge: gesetzliche Fristen und Meldereife, produktbezogene Hochrisikolücken, skalierbare Prozessgrundlagen und dokumentarische Nacharbeiten. Ein fehlender sicherer Updateweg verdient eine andere Eskalation als ein unvollständiger Querverweis in einer bereits belastbaren Produktakte.
Für jede Maßnahme wird definiert, welcher Nachweis am Ende vorliegen muss. „SBOM-Prozess verbessern“ ist zu vage. Besser: „Für Release 4.2 kann innerhalb von vier Stunden eine vollständige, versionierte SBOM erzeugt und eine konkrete Komponente bis zu betroffenen Kundenständen verfolgt werden.“ So lässt sich Abschluss objektiv prüfen.
Nach zwölf bis sechzehn Wochen sollte dieselbe Produktfamilie erneut vollständig geprüft werden. Erst wenn der Nachweisfluss an einem realen Produkt funktioniert, werden Vorlagen und Werkzeuge auf das Portfolio ausgerollt. Diese Reihenfolge verhindert, dass ein unpraktischer Zentralprozess skaliert wird.
Fazit: Readiness zeigt sich am konkreten Produktnachweis
CRA-Reife ist keine Selbsteinschätzung der Organisation. Sie zeigt sich daran, ob Scope, Risiken, sichere Entwicklung, Komponenten, Tests, Support und Schwachstellenbehandlung für eine reale Produktversion nachvollziehbar verbunden sind. Ein evidenzbasierter Readiness-Check macht Lücken früh sichtbar und liefert zugleich die Struktur für eine prüffähige technische Dokumentation.
BlackMount führt CRA-Readiness-Assessments produktbezogen durch und übersetzt Feststellungen in priorisierte Umsetzungspläne. Weitere Informationen finden Sie unter Cyber Resilience Act Beratung.
