Praxisorientierte Einordnung zu Cyber Resilience Act: Der Umsetzungsfahrplan für Hersteller digitaler Produkte: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Cyber Resilience Act aufbauen.
Der Cyber Resilience Act verändert Produktsicherheit von einer freiwilligen Qualitätsdisziplin zu einer verbindlichen Voraussetzung für viele Produkte mit digitalen Elementen im europäischen Markt. Hersteller müssen Cybersicherheit über Planung, Entwicklung, Auslieferung und Support beherrschen, Risiken dokumentieren, Schwachstellen während des Unterstützungszeitraums behandeln und die Konformität nachweisen. Wer erst kurz vor der vollständigen Anwendung im Dezember 2027 mit der Umsetzung beginnt, wird vor allem an fehlenden Produktdaten, gewachsenen Entwicklungsprozessen und unklaren Lieferketten scheitern.
Ein tragfähiger Umsetzungsfahrplan beginnt deshalb nicht mit einer langen Kontrollliste. Zuerst werden Produktportfolio, wirtschaftliche Rolle und Übergangsfristen geklärt. Danach entstehen wiederverwendbare Prozesse für Risikobewertung, sichere Entwicklung, Komponentensteuerung, Vulnerability Handling und technische Dokumentation. Dieser Leitfaden ordnet die Arbeit in acht aufeinander aufbauende Pakete.
1. Betroffenheit auf Produktebene bestimmen
Der CRA gilt grundsätzlich für Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden und deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz einschließt. Diese Definition erfasst nicht nur klassische Hardware. Auch eigenständige Software, eingebettete Komponenten und bestimmte zugehörige Fernverarbeitungslösungen können in den Scope fallen.
Unternehmen sollten daher ein CRA-Produktregister aufbauen. Für jede Produktfamilie werden Zweck, digitale Bestandteile, Verbindungsarten, Zielmarkt, Lebenszyklus, Varianten und verantwortliche Gesellschaft dokumentiert. Danach ist zu prüfen, ob eine Ausnahme oder ein vorrangiger sektoraler Rechtsrahmen greift. Produkte, die bereits unter spezifischen unionsrechtlichen Anforderungen mit gleichwertigem Schutzniveau stehen, dürfen nicht pauschal doppelt eingeordnet werden.
Besonders wichtig ist die wirtschaftliche Rolle. Hersteller tragen andere Pflichten als Importeure oder Händler. Wer ein Produkt unter eigenem Namen oder eigener Marke anbietet oder wesentlich verändert, kann rechtlich zum Hersteller werden. Eine Einkaufsbezeichnung wie „OEM-Produkt“ beantwortet diese Frage nicht. Das Register sollte deshalb pro Vertriebskonstellation festhalten, wer konstruiert, wer die Konformität erklärt, wer das CE-Zeichen anbringt und wer Schwachstellenmeldungen bearbeitet.
2. Produktklassifizierung und Konformitätsweg festlegen
Die meisten Produkte können über interne Konformitätskontrolle bewertet werden, sofern die gesetzlichen Voraussetzungen erfüllt sind. Für wichtige Produkte der Klassen I und II sowie kritische Produkte gelten abhängig von Kategorie, angewandten harmonisierten Standards oder europäischen Zertifizierungsschemata strengere Wege. Eine falsche Klassifizierung kann die gesamte Markteinführungsplanung gefährden.
Produktmanagement, Recht, Entwicklung und Qualität sollten deshalb für jede Produktfamilie ein begründetes Klassifizierungsblatt erstellen. Es enthält Funktionsbeschreibung, relevante Kategorie, mögliche kritische Funktionen, vorgesehene Bewertungsmodule und offene Annahmen. Die technische Beschreibung wichtiger und kritischer Produktkategorien sowie aktuelle Leitlinien der Kommission sind dabei zu berücksichtigen.
Wenn eine externe Konformitätsbewertungsstelle erforderlich sein könnte, sollte die Kapazität früh angefragt werden. Prüfungen lassen sich nicht sinnvoll auf den letzten Monat vor Markteinführung verschieben. Architektur, Nachweisformate und Teststrategie sollten vor der Designfreigabe abgestimmt sein, damit spätere Feststellungen nicht zu grundlegenden Produktänderungen führen.
3. CRA-Governance in den Produktlebenszyklus einbauen
Der CRA ist kein isoliertes Security-Projekt. Produktstrategie entscheidet über Supportdauer, Entwicklung über Architektur, Einkauf über Komponenten, Support über Schwachstellen und Qualität über Freigaben. Ohne verbindliche Entscheidungsrechte bleiben Anforderungen zwischen den Funktionen liegen.
Für jede Produktfamilie sollte ein verantwortlicher Product Security Owner benannt werden. Er koordiniert, ersetzt aber nicht die Verantwortung der Fachbereiche. Ein bereichsübergreifendes Gremium entscheidet über Risikoakzeptanz, Freigabe trotz offener Schwachstellen, wesentliche Produktänderungen und Eskalationen. Die Geschäftsleitung erhält regelmäßig Informationen über Portfolioabdeckung, kritische Abweichungen und Meldereife.
In bestehende Quality Gates werden konkrete Security-Ergebnisse eingebaut: Scope und Risikokontext vor Architekturstart, Threat Model vor Designfreigabe, Testnachweise vor Release, vollständige technische Dokumentation vor Konformitätserklärung und Supportbereitschaft vor Markteinführung. Ein Gate darf nicht nur das Vorhandensein eines Dokuments prüfen, sondern die Bearbeitung wesentlicher Risiken.
4. Cybersecurity-Risikobewertung pro Produkt etablieren
Die Risikobewertung begleitet das Produkt über seinen Lebenszyklus. Sie beginnt mit bestimmungsgemäßer und vernünftigerweise vorhersehbarer Verwendung. Dazu gehören typische Fehlkonfigurationen, erreichbare Schnittstellen, Benutzerrollen, Einsatzumgebungen und Abhängigkeiten von Backend- oder Cloud-Diensten. Erst daraus entstehen relevante Bedrohungsszenarien.
Ein gutes Threat Model beschreibt schützenswerte Funktionen und Daten, Vertrauensgrenzen, Angreiferzugänge und mögliche Auswirkungen. Bei einer vernetzten Industriesteuerung sind andere Folgen relevant als bei einer mobilen App: Manipulation kann physische Prozesse, Verfügbarkeit oder Sicherheit betreffen. Risiken werden technischen und organisatorischen Maßnahmen zugeordnet und verbleibende Risiken begründet.
Die Bewertung ist kein einmaliges Entwicklungsdokument. Neue Schwachstellen, geänderte Komponenten, zusätzliche Cloud-Funktionen oder veränderte Bedrohungen können sie beeinflussen. Definierte Auslöser sorgen dafür, dass sie bei Release, wesentlicher Änderung, Sicherheitsvorfall und periodischer Überprüfung aktualisiert wird.
5. Secure Development mit prüfbaren Ergebnissen verankern
Secure by Design muss in den normalen Entwicklungsablauf integriert werden. Anforderungen werden aus Risikobewertung und wesentlichen CRA-Anforderungen abgeleitet. Architekturentscheidungen berücksichtigen sichere Standardkonfiguration, geringstmögliche Privilegien, Schutz von Vertraulichkeit, Integrität und Verfügbarkeit, Begrenzung von Angriffsflächen sowie sichere Update- und Wiederherstellungsmechanismen.
Die konkrete Teststrategie richtet sich nach Produkt und Risiko. Dazu können Codeanalyse, Abhängigkeitsprüfung, Secret Detection, Fuzzing, Penetrationstest, Missbrauchstests und Prüfung kryptografischer Funktionen gehören. Entscheidend ist die Rückverfolgbarkeit: Welches Risiko wird durch welchen Test adressiert, welches Ergebnis wurde erzielt und wie wurden Abweichungen behandelt?
Freigabekriterien müssen den Auslieferungszustand berücksichtigen. Unsichere Standardpasswörter, nicht benötigte offene Dienste oder deaktivierte Updateprüfung dürfen nicht durch Installationshinweise kompensiert werden, wenn sichere Defaults technisch möglich sind. Benutzerinformationen sollen verständlich erklären, wie das Produkt sicher installiert, betrieben, aktualisiert und außer Betrieb genommen wird.
6. Software-Lieferkette und Komponenten beherrschen
Moderne Produkte bestehen zu erheblichen Teilen aus Open-Source- und Drittanbieterkomponenten. Hersteller benötigen deshalb Transparenz über Version, Herkunft, Lizenz, Einsatzort und bekannte Schwachstellen. Eine Software Bill of Materials kann diese Sicht unterstützen, ist aber nur ein Artefakt. Ohne Prozess für Bewertung und Aktualisierung bleibt sie eine statische Liste.
Der Einkauf sollte Security-Anforderungen an kommerzielle Komponenten und Entwicklungsdienstleister vertraglich verankern. Dazu gehören Schwachstellenmeldungen, Bereitstellung von Fixes, Supportzeitraum, Nachweise zu sicherer Entwicklung und Informationen über Unterlieferanten. Bei Open Source braucht es Zuständigkeiten für Auswahl, Pflege, Monitoring und gegebenenfalls eigene Fehlerbehebung.
Ein Komponentenereignis muss produktbezogen beantwortet werden können: Welche ausgelieferten Versionen enthalten die Komponente? Ist die verwundbare Funktion erreichbar? Welche Konfigurationen sind betroffen? Gibt es eine Kompensation? Welche Kunden müssen informiert werden? Diese Abfragen sollten vor dem ersten kritischen Ereignis getestet sein.
7. Vulnerability Handling und Meldefähigkeit aufbauen
Hersteller müssen Schwachstellen während des Unterstützungszeitraums wirksam behandeln. Dazu gehören ein erreichbarer Meldekanal, eine Coordinated Vulnerability Disclosure Policy, Triage, technische Analyse, Priorisierung, Behebung, Veröffentlichung von Sicherheitshinweisen und sichere Verteilung von Updates. Externe Forschende benötigen klare Angaben, welche Informationen erwartet werden und wie das Unternehmen reagiert.
Ab 11. September 2026 gelten die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. ENISA stellt dafür die Single Reporting Platform bereit. Die gesetzlichen Fristen sind kurz und erfordern gestufte Meldungen. Organisationen müssen deshalb erkennen können, wann eine Schwachstelle als aktiv ausgenutzt gilt, wer die Entscheidung trifft und welche Informationen innerhalb der ersten Frist verfügbar sein müssen.
Ein Melde-Playbook sollte Produktteam, Product Security, Recht, Datenschutz, Kommunikation und Geschäftsleitung verbinden. Es enthält Kriterien, Rufbereitschaft, Freigaben, Kontaktstellen und Vorlagen. Tabletop-Übungen mit einem realistischen Komponentenfall zeigen, ob die Organisation innerhalb der Fristen handlungsfähig ist.
8. Technische Dokumentation und Konformität abschließen
Die technische Dokumentation muss die Bewertung der Konformität ermöglichen. Sie sollte Produktbeschreibung, bestimmungsgemäße Verwendung, Architektur, Risikobewertung, angewandte Anforderungen, Design- und Entwicklungsinformationen, Prüfungen, Vulnerability-Handling und relevante Standards nachvollziehbar verbinden. Eine Sammlung unverbundener Entwicklungsdokumente genügt diesem Zweck nicht.
Für wiederkehrende Produktvarianten empfiehlt sich ein modulares Nachweismodell. Gemeinsame Plattformbestandteile werden zentral dokumentiert; produktspezifische Abweichungen und Einsatzkontexte bleiben erkennbar. Versionierung ist entscheidend, damit später nachvollzogen werden kann, welche Nachweise zu welcher ausgelieferten Version gehörten.
Vor der Markteinführung wird der gewählte Konformitätsweg abgeschlossen, die EU-Konformitätserklärung erstellt und die CE-Kennzeichnung angebracht. Zugleich müssen Supportkanal, Updateinfrastruktur, Sicherheitsinformationen und interne Produktakten betriebsbereit sein. Konformität endet nicht mit dem Release: Änderungen, Schwachstellen und Marktbeobachtung können neue Bewertungen auslösen.
Ein realistischer Zeitplan bis zur vollständigen Anwendung
Phase 1 – Transparenz: Produktregister, Rollen, Scope und Klassifizierung erstellen. Bestehende Entwicklungs- und Vulnerability-Prozesse gegen die CRA-Anforderungen bewerten.
Phase 2 – Pilot: Eine repräsentative Produktfamilie auswählen und Risikobewertung, Secure-Development-Gates, Komponentensteuerung und technische Dokumentation vollständig durchlaufen. Lücken im Prozess werden am realen Produkt sichtbar.
Phase 3 – Meldefähigkeit: Vor September 2026 Meldekriterien, Single-Reporting-Platform-Zugang, Rufbereitschaft und Übungen abschließen. Bestehende Produkte im Markt in die Meldeprozesse einbeziehen.
Phase 4 – Skalierung: Vorlagen und Werkzeuge auf weitere Produktfamilien übertragen, ohne individuelle Risikobewertung zu ersetzen. Lieferanten und Entwicklungspartner vertraglich sowie operativ einbinden.
Phase 5 – Konformitätsreife: Produktakten intern auditieren, erforderliche externe Bewertungen terminieren, Abweichungen schließen und Freigabeverfahren für Markteinführungen ab Dezember 2027 stabil betreiben.
Steuerungskennzahlen mit Aussagekraft
- Anteil des Portfolios mit bestätigtem CRA-Scope und begründeter Klassifizierung.
- Anteil aktiver Produkte mit aktuellem Threat Model und zugeordneten Security-Tests.
- Zeit von Eingang einer Schwachstellenmeldung bis Triage, Entscheidung und verfügbarer Abhilfe.
- Anteil ausgelieferter Versionen mit nachvollziehbarer Komponenten- und Nachweisbasis.
- Anzahl überfälliger kritischer Abweichungen vor Produktfreigaben.
- Ergebnis regelmäßiger Melde- und Vulnerability-Handling-Übungen.
Die Kennzahlen sollten Entscheidungen auslösen. Eine hohe Zahl gefundener Schwachstellen kann bei verbesserter Testtiefe positiv sein; entscheidend sind Exposition, Bearbeitungszeit und verbleibendes Risiko. Reine Aktivitätszahlen wie durchgeführte Scans sagen wenig über Konformitätsreife aus.
Fazit: CRA-Reife entsteht im Produktprozess
Hersteller erreichen CRA-Konformität nicht durch ein spätes Dokumentationsprojekt. Sie entsteht, wenn Produktentscheidungen, Entwicklung, Lieferkette, Schwachstellenbehandlung und Nachweise als zusammenhängender Lebenszyklus funktionieren. Ein produktbezogenes Register, klare Rollen und ein repräsentativer Pilot schaffen dafür die schnellste belastbare Grundlage. Wer die Meldefähigkeit separat priorisiert und anschließend kontrolliert skaliert, reduziert regulatorisches Risiko und verbessert zugleich die tatsächliche Produktsicherheit.
BlackMount unterstützt Hersteller bei Scope, Gap-Analyse, Secure-Development-Prozessen und der Vorbereitung belastbarer CRA-Nachweise. Mehr dazu finden Sie unter Cyber Resilience Act Beratung.
