CRA-Produktsicherheitsakte 2026 mit ISO 27001

Ein Hersteller vernetzter Geräte ruft seine CISO Maria an einem Freitagnachmittag in eine Besprechung. Der Vertrieb hat gerade eine europäische Vertriebsvereinbarung abgeschlossen. Die Rechtsabteilung fragt, ob das Unternehmen die Konformität mit dem Cyber Resilience Act unterstützen kann. Die Entwicklung erklärt, sichere Entwicklung sei „größtenteils abgedeckt“, weil Code-Reviews, SAST und Patching vorhanden seien. Die Beschaffung sagt, Lieferanten stünden „unter NDA“. Produktteams verwalten Firmware-Abhängigkeiten in einem Tool, Cloud-API-Inventare in einem anderen und Schwachstellen-Tickets in Jira. Die Compliance-Funktion verfügt über Zertifizierungsnachweise zu ISO/IEC 27001:2022, diese sind jedoch am unternehmensweiten ISMS ausgerichtet und nicht an jedem einzelnen Produkt, das auf dem EU-Markt bereitgestellt wird.

Dann kommt die unangenehme Frage: „Wenn 2026 eine EU-Behörde, ein Kunde, eine benannte Stelle oder ein großer Distributor die Produktsicherheitsakte anfordert, können wir sie innerhalb einer Woche vorlegen?“

Für viele Softwareanbieter, Hersteller smarter Geräte und Anbieter vernetzter Dienste lautet die ehrliche Antwort: nein. Nicht, weil ihnen Sicherheitskontrollen fehlen, sondern weil ihre Nachweise zur Produktsicherheit verstreut sind. Nachweise zur sicheren Entwicklung liegen in der Entwicklung. SBOMs werden pro Build erzeugt, aber nicht gesteuert. Koordinierte Offenlegung von Schwachstellen existiert als Webseite, ist aber nicht immer mit Triage, Abhilfemaßnahmen, Sicherheitshinweisen und Überwachung nach dem Inverkehrbringen verbunden. Lieferantensicherheit ist in Beschaffungsverträgen verborgen. Vorfallmeldung gehört zum Security Operations, während Konformitätsdokumentation zur Produkt-Compliance gehört.

Der EU Cyber Resilience Act verändert das Betriebsmodell. Produktsicherheit ist nicht mehr nur eine Best Practice oder ein vertragliches Versprechen. Sie wird zu einer Nachweispflicht über den gesamten Lebenszyklus. Organisationen müssen zeigen können, wie Cybersicherheitsanforderungen in Design, Entwicklung, Freigabe, Schwachstellenbehandlung, Aktualisierungen und Überwachung nach dem Inverkehrbringen des Produkts eingebettet sind.

Genau hier wird ISO/IEC 27001:2022 wirksam, wenn sie richtig genutzt wird. Die Norm ist für sich genommen kein Produktzertifizierungsschema, aber ihre ISMS-, Risiko-, Asset-, Lieferanten-, Secure-Development-, Schwachstellen- und Vorfallkontrollen können das Rückgrat einer CRA-Produktsicherheitsakte bilden. Ziel ist nicht, ein weiteres Compliance-Silo zu schaffen. Ziel ist, Ihr bestehendes ISMS in ein Nachweissystem auf Produktebene zu überführen.

Wie Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap in Phase 2, Schritt 8, Nachweisarchitektur, formuliert:

„Nachweise sollten nicht erst am Ende des Auditzyklus gesammelt werden. Sie sollten in die Kontrolle integriert, einem Verantwortlichen zugewiesen, durch den Prozess mit einem Zeitstempel versehen und für jede Verpflichtung wiederverwendbar sein, die dieselbe Frage in anderer Sprache stellt.“

Dieser Satz beschreibt den Kern der CRA-Bereitschaft. Die Frage lautet nicht nur: „Haben wir sichere Entwicklung?“ Die Frage lautet: „Können wir sichere Entwicklung, Komponentenkenntnis, Schwachstellenbehandlung und Überwachung nach dem Inverkehrbringen für dieses Produkt, diese Version, dieses Release und diesen Markt nachweisen?“

Die CRA-Produktsicherheitsakte ist ein lebendes Nachweissystem

Eine CRA-Produktsicherheitsakte sollte nicht als statisches PDF behandelt werden, das einmal vor der Freigabe erstellt und dann vergessen wird. Sie sollte ein strukturiertes Dossier sein, das die Sicherheitsgeschichte des Produkts vom Konzept bis zum Supportende nachvollziehbar macht.

Eine aussagekräftige Akte erläutert:

1. Was das Produkt ist und wie es bestimmungsgemäß verwendet werden soll.
2. Welche Software, Firmware, Cloud-Services und Abhängigkeiten von Drittparteien es enthält.
3. Welche Cybersicherheitsrisiken bewertet wurden.
4. Welche Sicherheitsanforderungen angewendet wurden.
5. Wie sichere Entwicklung durchgeführt wurde.
6. Wie Schwachstellen entgegengenommen, triagiert, behoben und offengelegt werden.
7. Wie sichere Aktualisierungen bereitgestellt werden.
8. Wie Lieferanten und Open-Source-Komponenten gesteuert werden.
9. Wie Vorfälle und aktiv ausgenutzte Schwachstellen eskaliert werden.
10. Wie das Produkt nach dem Inverkehrbringen überwacht wird.

Für einen CISO ist dies eine Herausforderung der ISMS-Nachweisführung. Für einen Product-Compliance-Manager ist es technische Dokumentation. Für die Entwicklung ist es DevSecOps und Release-Governance. Für Führungskräfte geht es um Marktzugang und Haftungssteuerung.

Der Fehler besteht darin, diese Themen als getrennte Arbeitsstränge zu behandeln. Das bessere Modell ist eine Nachweisakte auf Produktebene, die ISO/IEC 27001:2022- und ISO/IEC 27002:2022-Kontrollen zugeordnet ist und dieselben Nachweise bei Bedarf zusätzlich NIS2, DORA, GDPR, NIST und COBIT 2019 zuordnet.

Clarysecs Zenith Controls: The Cross-Compliance Guide beschreibt dies als Kette von Kontrolle zu Nachweis zu Auditor:

„Eine Cross-Compliance-Nachweisakte sollte jede Verpflichtung der operativen Kontrolle, dem wiederkehrenden Nachweisobjekt, dem rechenschaftspflichtigen Verantwortlichen und der Auditperspektive zuordnen, mit der sie geprüft wird.“

Genau diese Disziplin braucht die CRA-Vorbereitung. Die Produktsicherheitsakte ist nicht bloß ein Ordner. Sie ist die Übersetzungsschicht zwischen Produktentwicklung, Sicherheitsgovernance, Konformitätsbewertung und Kundenvertrauen.

Zuerst das Nachweisrückgrat für das Produkt aufbauen

Die Akte benötigt eine konsistente Struktur, bevor Teams mit dem Hochladen von Aufzeichnungen beginnen. Ohne klares Rückgrat werden Nachweise zu einer Sammlung von Screenshots, Exporten und Richtlinien-PDFs, der kein Auditor folgen kann.

Für CRA-Bereitschaftsworkshops empfiehlt Clarysec Organisationen, die bereits ein ISO/IEC 27001:2022-ISMS betreiben, typischerweise die folgende Struktur der Produktsicherheitsakte.

Diese Tabelle ersetzt keine gesetzlichen Pflichten zur technischen Dokumentation. Sie gibt dem Unternehmen ein Betriebsmodell, um diese Pflichten nachweisbar zu erfüllen.

Im Zenith Blueprint konzentriert sich Phase 1, Schritt 3 auf die Definition von Geltungsbereich und Abgrenzung. Für CRA wird dieser Schritt produktspezifisch. Definieren Sie Produktfamilie, Softwareversionen, Bereitstellungsannahmen, Benutzerrollen, vernetzte Dienste, Aktualisierungskanäle und Supportzeitraum. Wenn der ISMS-Geltungsbereich „Corporate SaaS and device management platform“ lautet, muss die CRA-Akte dennoch eine engere Frage beantworten: „Welches Produkt mit digitalen Elementen wird auf dem EU-Markt bereitgestellt, und was ist in diesem Produkt enthalten?“

Sichere Entwicklung auf Aufzeichnungen auf Produktebene abbilden

Das Herzstück der Produktsicherheitsakte sind Nachweise für Security by Design. ISO/IEC 27001:2022 stellt das Governance-System bereit. ISO/IEC 27002:2022 liefert Umsetzungshinweise durch Kontrollen wie A.8.25 Secure Development Life Cycle, A.8.27 Sichere Systemarchitektur und Engineering-Grundsätze, A.8.28 Sichere Programmierung und A.8.29 Sicherheitsprüfung in Entwicklung und Abnahme.

Die entscheidende Veränderung liegt im Übergang von allgemeinen Aussagen zur sicheren Entwicklung zu release-spezifischen Aufzeichnungen. „Wir führen Code-Reviews durch“ reicht nicht aus. Die Akte sollte zeigen, welches Release geprüft wurde, welche Risiken berücksichtigt wurden, welche Sicherheitstests bestanden wurden, welche Schwachstellen akzeptiert oder behoben wurden und wer das Release freigegeben hat.

Clarysecs Enterprise-Richtlinie für sichere Softwareentwicklung ist darauf ausgelegt, diesen Prüfpfad durchzusetzen. In Klausel 6.1, Anforderungen an den sicheren Entwicklungslebenszyklus, heißt es:

„Für jedes Produkt- oder Service-Release sind vor der Produktivbereitstellung dokumentierte Nachweise zu Sicherheitsanforderungen, Designprüfung, sicheren Programmieraktivitäten, Sicherheitsprüfung, Entscheidungen zur Schwachstellenbehebung und Release-Freigabe aufzubewahren.“

Diese Klausel ist für CRA nützlich, weil sie sichere Entwicklung in ein wiederholbares Nachweismuster überführt. Ein Auditor muss nicht ableiten, dass sichere Entwicklung stattgefunden hat. Er kann die Release-Aufzeichnung prüfen.

Für ein smartes Thermostat, ein medizinisches IoT-Gerät, einen industriellen Sensor oder ein SaaS-verbundenes Produkt sollten die Nachweise zur sicheren Entwicklung Folgendes umfassen:

• Produktsicherheitsanforderungen, die identifizierten Risiken zugeordnet sind.
• Bedrohungsmodell oder Analyse von Missbrauchsszenarien für das Produkt und die vernetzten Dienste.
• Architekturprüfung einschließlich Vertrauensgrenzen und externer Schnittstellen.
• Standard für sichere Programmierung und Nachweis der Bestätigung oder Schulung durch Entwickler.
• SAST, DAST, Software Composition Analysis, Secrets-Scanning und Firmware-Analyse, soweit anwendbar.
• Abhilfetickets für risikobehaftete Feststellungen.
• Aufzeichnungen zur Risikoakzeptanz mit fachlicher und sicherheitsbezogener Freigabe.
• Release-Gate-Checkliste, die zeigt, dass Sicherheitskriterien erfüllt wurden.
• Nachweise zu kryptografischer Signatur und Integrität von Aktualisierungen.
• Annahmen zum Supportzeitraum und zum End of Life.

Weitere Standards stärken die Methode. ISO/IEC 27005 unterstützt den risikobasierten Ansatz hinter diesen Aufzeichnungen. ISO/IEC 27017 ist nützlich, wenn Cloud-Services Teil des Produktökosystems sind. ISO/IEC 27035 unterstützt den Umgang mit Informationssicherheitsvorfällen. ISO/IEC 29147 und ISO/IEC 30111 sind insbesondere für Schwachstellenoffenlegung und Schwachstellenbehandlung relevant. ISO/IEC 27036 unterstützt Lieferantensicherheit, was relevant ist, wenn das Produkt ausgelagerte Software, eingebettete Module, verwaltete Cloud-Services oder Drittanbieter-Bibliotheken enthält.

In Zenith Controls werden CRA-Nachweise zur sicheren Entwicklung typischerweise Kontrollthemen aus ISO/IEC 27002:2022 zugeordnet, etwa Informationssicherheit im Projektmanagement, Secure Development Life Cycle, sichere Programmierung, Sicherheitsprüfung, Änderungsmanagement und Management technischer Schwachstellen. Der Leitfaden verknüpft diese außerdem mit Asset-Inventar und Lieferantenkontrollen, weil kein Prozess für sichere Entwicklung vollständig ist, wenn die Organisation die ausgelieferten Komponenten nicht identifizieren kann.

Die SBOM als regulierten Produktnachweis behandeln

Die Software Bill of Materials wird häufig als technisches Artefakt behandelt. Für CRA-Bereitschaft sollte sie als Produktnachweis behandelt werden.

Eine aussagekräftige SBOM zeigt, welche Komponenten im Produkt enthalten sind, welche Versionen verwendet werden, woher sie stammen, welche Lizenzen gelten, welche Schwachstellen sie betreffen und welche Releases sie enthalten. Bei Firmware- und Embedded-Produkten kann dies Betriebssystempakete, Bootloader, Bibliotheken, Treiber, Container, Drittmodule und cloudseitige Abhängigkeiten umfassen, die für den Produktbetrieb erforderlich sind.

Das Problem besteht darin, dass viele Organisationen SBOMs erzeugen, sie aber nicht steuern. Eine Build-Pipeline kann eine SPDX- oder CycloneDX-Datei erzeugen, aber niemand validiert die Vollständigkeit. Sicherheitswerkzeuge können Schwachstellen melden, aber die Ergebnisse sind nicht mit Produktversionen verknüpft. Die Beschaffung kann einen Lieferanten freigeben, aber dessen Komponentenliste wird nicht mit dem freigegebenen Produkt abgeglichen.

Clarysecs Enterprise-Richtlinie zum Asset-Management adressiert diese Governance-Lücke in Klausel 5.2, Informations- und zugehöriges Asset-Inventar:

„Informations-Assets und zugehörige Technologiekomponenten sind zu identifizieren, einem Verantwortlichen zuzuweisen, soweit anwendbar zu klassifizieren und in einem Inventar zu pflegen, das Risikobeurteilung, Schwachstellenmanagement, Änderungskontrolle und Auditnachweise unterstützt.“

Für CRA wird diese Klausel produktspezifisch. Die SBOM ist Teil des Inventars zugehöriger Technologiekomponenten. Sie benötigt einen Verantwortlichen, eine Aufbewahrungsregel, einen Validierungsprozess und eine Verbindung zum Schwachstellenmanagement.

Eine praktikable Nachweisregel für SBOMs ist einfach: Jede freigegebene Produktversion muss über ein freigegebenes Komponenteninventar verfügen, das dem Release-Artefakt zugeordnet werden kann. Wenn die Organisation die SBOM nicht mit dem exakten Firmware-Image, Anwendungspaket, Container-Digest oder SaaS-Release verbinden kann, ist die SBOM ein schwacher Nachweis.

Wenn mehr als zwei Zeilen fehlschlagen, liegt das Problem in der Regel nicht beim SBOM-Werkzeug. Es liegt in der Governance. Die Produktsicherheitsakte sollte eine Korrekturmaßnahme im ISMS erfassen, weil eine Schwäche bei CRA-Nachweisen auch ein Problem der Kontrollwirksamkeit nach ISO/IEC 27001:2022 ist.

CVD mit Schwachstellenbehandlung und Release-Governance verbinden

Koordinierte Offenlegung von Schwachstellen ist einer der sichtbarsten Bereiche der CRA-Bereitschaft, weil externe Sicherheitsforscher, Kunden und Behörden ihn direkt testen können. Die Veröffentlichung einer Seite zur Schwachstellenoffenlegung oder einer security.txt-Datei ist nützlich, aber sie ist nur die Eingangstür. Die Produktsicherheitsakte muss belegen, dass die nachgelagerten Prozesse funktionieren.

Ein belastbarer CVD- und Schwachstellenbehandlungs-Nachweisbestand sollte Folgendes umfassen:

• Öffentlicher Offenlegungskanal und Einreichungsanweisungen.
• Verfahren zur Bestätigung gegenüber Sicherheitsforschern.
• Triage-Kriterien einschließlich Bewertung von Schweregrad und Ausnutzbarkeit.
• Analyse der Produktauswirkungen.
• Verantwortlichkeit für Abhilfe und Zieltermine.
• Vorlagen für Kundenhinweise und Kommunikation zu Aktualisierungen.
• Nachweise für sichere Patch-Entwicklung und -Prüfung.
• Aufzeichnungen über koordinierte Veröffentlichung, soweit anwendbar.
• Lessons Learned und wiederkehrende Trendanalyse zu Schwachstellen.

Clarysecs Enterprise-Richtlinie zum Schwachstellenmanagement legt in Klausel 6.3, Eingang, Triage und Behebung von Schwachstellen, fest:

„Gemeldete Schwachstellen sind zu protokollieren, hinsichtlich betroffener Assets und Produkte zu bewerten, nach Risiko und Ausnutzbarkeit zu priorisieren, einem rechenschaftspflichtigen Verantwortlichen zuzuweisen und über Behebung, Verifikation, Kommunikation und Abschluss nachzuverfolgen.“

Diese Klausel verbindet CVD mit SBOM, Asset-Inventar, Engineering-Tickets, Release-Management und Überwachung nach dem Inverkehrbringen. Sie ist außerdem die Klausel, die Auditoren naheliegend prüfen werden: Zeigen Sie die Eingangsaufzeichnung, zeigen Sie die betroffenen Produkte, zeigen Sie die Triage, zeigen Sie die Korrektur, zeigen Sie die Kundenkommunikation, zeigen Sie den Abschluss.

Ihre bestehende Richtlinie zum Management von Informationssicherheitsvorfällen sollte ebenfalls erweitert werden, um Produktschwachstellen abzudecken, die zu Vorfällen werden oder eine externe Benachrichtigung erfordern. ISO/IEC 27002:2022 A.5.24 behandelt Planung und Vorbereitung des Vorfallmanagements, A.5.25 behandelt Beurteilung und Entscheidung zu Informationssicherheitsereignissen, A.5.26 behandelt die Reaktion auf Informationssicherheitsvorfälle, und A.5.27 behandelt das Lernen aus Informationssicherheitsvorfällen.

In Zenith Controls wird Schwachstellenmanagement sowohl präventiv als auch korrektiv behandelt. Die präventive Seite umfasst Inventar, sichere Entwicklung, Lieferantenüberwachung und sichere Konfiguration. Die korrektive Seite umfasst Erkennung, Triage, Patching, Kommunikation und Vorfalleskalation. Diese Unterscheidung ist wichtig, weil die Schwachstellenbehandlung nach dem Inverkehrbringen Teil der Produktlebenszykluspflicht ist und kein nachträglicher Zusatz.

Lieferantennachweise sind die verborgene Schwachstelle

Die Produktsicherheitsakte wird häufig dort am stärksten hinterfragt, wo der Hersteller von Dritten abhängig ist. Dazu zählen eingebettete Module, ausgelagerte Firmware-Entwicklung, White-Label-Komponenten, Cloud-Hosting, mobile SDKs, Zahlungsdienste, kryptografische Bibliotheken und Managed-Support-Anbieter.

Das häufige Fehlermuster ist vertragliche Abstraktion. Der Hersteller sagt: „Dafür ist unser Lieferant verantwortlich.“ Unter einer Prüfung der Produktsicherheit reicht das nicht aus. Die Organisation muss zeigen, dass Lieferantenrisiken identifiziert, Sicherheitsanforderungen kommuniziert, Nachweise gesammelt, Schwachstellen koordiniert und Änderungen kontrolliert werden.

Clarysecs Enterprise-Richtlinie zur Lieferanten- und Drittparteiensicherheit legt in Klausel 7.1, Anforderungen an die Lieferantensicherheit, fest:

„Lieferanten, die Informationssysteme, Produkte oder Dienstleistungen entwickeln, betreiben, verarbeiten, unterstützen oder wesentlich beeinflussen, sind risikobasiert zu bewerten und müssen Sicherheitsanforderungen unterliegen, die Zugriff, Schwachstellenmanagement, Vorfallbenachrichtigung, Unterbeauftragung, Kontinuität und Bereitstellung von Nachweisen abdecken.“

Für CRA ist die Formulierung „Produkte wesentlich beeinflussen“ entscheidend. Wenn eine Lieferantenkomponente eine Schwachstelle einführen, Aktualisierungen stören, Kundendaten offenlegen oder die Geräteintegrität kompromittieren kann, gehört sie in die Produktsicherheitsakte.

Dieselbe Richtlinie kann auch die vertragliche SBOM-Anforderung unterstützen. Klausel 7.3 lautet:

„Für alle Softwarekomponenten, Bibliotheken oder Betriebssysteme von Drittparteien, die in unternehmenseigene Produkte mit digitalen Elementen integriert werden sollen, muss der Lieferant auf Anfrage eine maschinenlesbare Software Bill of Materials (SBOM) in einem Standardformat wie SPDX oder CycloneDX bereitstellen. Diese Anforderung muss in alle Beschaffungs- und Lieferantenverträge aufgenommen werden.“

Ein starker Lieferantennachweisbestand sollte eine Klassifizierung der Lieferanten nach Produktauswirkung, Sicherheitsanforderungen in Verträgen, Nachweise zur sicheren Entwicklung von Lieferanten für kritische Komponenten, Verpflichtungen der Lieferanten zur Schwachstellenoffenlegung, SBOMs oder Komponentenerklärungen soweit möglich, Patch-Support- und End-of-Life-Zeitpläne, Aufzeichnungen periodischer Überprüfungen sowie Eskalationswege für von Lieferanten stammende Schwachstellen umfassen.

ISO/IEC 27002:2022 A.5.19, A.5.20 und A.5.21 liefern die zentralen Kontrollthemen für Lieferanten. ISO/IEC 27036 vertieft die Sicherheit von Lieferantenbeziehungen. Aus Cross-Compliance-Sicht betont NIS2 Lieferkette und Schwachstellenbehandlung. DORA betont IKT-Drittparteienrisiken für Finanzunternehmen. GDPR wird relevant, wenn das Produkt oder seine Cloud-Services personenbezogene Daten verarbeiten. COBIT 2019 rahmt Lieferanten-Governance als Thema der Unternehmensführung für Technologie, nicht nur als Thema des Security Operations.

Überwachung nach dem Inverkehrbringen überführt Nachweise in den Betrieb

Die reifsten Produktsicherheitsorganisationen denken über die Freigabe hinaus. Sie fragen: „Woran erkennen wir, dass dieses Produkt im Feld risikobehaftet geworden ist?“

Überwachung nach dem Inverkehrbringen sollte Signale aus Schwachstellen-Feeds, Exploit-Informationen, Kundensupport, Telemetrie, Bug-Bounty- oder Sicherheitsforscher-Meldungen, Lieferantenbenachrichtigungen, Cloud-Logs, Vorfallsaufzeichnungen und Leistungsdaten aus dem Feld erfassen. Sie sollte außerdem eine periodische Überprüfung des Produktrisikos einschließen, wenn sich Bedrohungsbedingungen ändern.

Clarysecs Enterprise-Richtlinie zur Protokollierung und Überwachung legt in Klausel 5.4, Sicherheitsüberwachung und Überprüfung, fest:

„Sicherheitsrelevante Ereignisse sind so zu erfassen, zu überprüfen, zu eskalieren und aufzubewahren, dass zeitnahe Erkennung, Untersuchung, Incident Response, Berichterstattung zur Einhaltung und kontinuierliche Verbesserung unterstützt werden.“

Für vernetzte Produkte muss dies sorgfältig ausgelegt werden. Überwachung muss Datenschutz, Datenminimierung und rechtliche Beschränkungen beachten, insbesondere wenn Telemetrie personenbezogene Daten oder betriebliche Kundendaten enthält. Eine Zuordnung zu GDPR ist wichtig. Produktsicherheitsteams sollten mit Datenschutzteams festlegen, welche Telemetrie für Sicherheitszwecke erforderlich ist, wie sie minimiert wird, wie lange sie aufbewahrt wird und wie Kunden informiert werden.

Nachweise zur Überwachung nach dem Inverkehrbringen sollten einen Überwachungsplan für Produktsicherheit, Quellen für Schwachstelleninformationen, Eingangskanäle für Kundenmeldungen, Benachrichtigungskanäle von Lieferanten, den Umfang der Telemetrie- oder Logprüfung, Protokolle periodischer Produktrisikoprüfungen, Nachverfolgung der Patch-Adoption, Analyse von Sicherheitsvorfalltrends und Beiträge zur Managementbewertung umfassen.

Im Zenith Blueprint konzentriert sich Phase 5, Schritt 30 auf kontinuierliche Verbesserung und Bereitschaft für Überwachungsaudits. Für CRA wird die Produktsicherheitsakte an dieser Stelle zu einer lebenden Akte. Jedes Produkt-Release, jede Schwachstelle, jede Lieferantenänderung und jedes Feldsignal sollte den Nachweisbestand aktualisieren.

Eine Nachweisakte, viele Compliance-Fragen

Eine gut konzipierte CRA-Produktsicherheitsakte reduziert Doppelarbeit, weil dieselben Nachweise mehrere Compliance-Fragen beantworten. Die Sprache ändert sich, die Kontrollrealität ist jedoch häufig ähnlich.

Zenith Controls ist für diese Wiederverwendung ausgelegt. Es ordnet Kontrollthemen aus ISO/IEC 27002:2022 Attributen wie präventivem, detektivem und korrektivem Kontrollzweck, Cybersicherheitskonzepten, operativen Fähigkeiten und Sicherheitseigenschaften zu. Für CRA hilft dies einem CISO zu erklären, warum ein einzelnes Nachweisobjekt, etwa eine Sicherheitsprüfung eines Releases, sichere Entwicklung, Risikobehandlung, Änderungskontrolle, Schwachstellenmanagement und Auditbereitschaft unterstützt.

Auf unterschiedliche Auditorperspektiven vorbereiten

Eine CRA-Produktsicherheitsakte kann durch einen ISO-Auditor, ein internes Auditteam, ein Customer-Assurance-Team, einen Prüfer der Produktkonformität, eine Aufsichtsbehörde, einen NIST-basierten Bewerter oder einen ISACA-geschulten COBIT-Auditor hinterfragt werden. Alle stellen ähnliche Fragen, aber aus unterschiedlicher Perspektive.

Dieselbe Schwachstelle wird unterschiedlich sichtbar. Wenn SBOMs erzeugt, aber nicht aufbewahrt werden, sieht der ISO-Auditor ein Problem der Aufzeichnungssteuerung und der operativen Kontrolle. Der NIST-Bewerter sieht eine Schwäche im Asset- und Schwachstellenmanagement. Der COBIT-Auditor sieht schwache Governance über Informations-Assets. Der Produktprüfer sieht unzureichende technische Dokumentation.

Ein 30-Schritte-Fahrplan, angepasst an CRA-Bereitschaft

Der Zenith Blueprint verhindert, dass Compliance-Teams direkt in die Dokumentensammlung springen. Für CRA wird der 30-Schritte-Fahrplan zu einem Nachweisprogramm für Produktsicherheit.

Phase 1 beginnt mit der Zuordnung von Verpflichtungen und Geltungsbereich. Identifizieren Sie, welche Produkte, Versionen, Komponenten, Cloud-Services und Supportprozesse im Geltungsbereich liegen. Bestätigen Sie bestimmungsgemäße Nutzung, Benutzerkategorien, Märkte und den Zeitraum für Sicherheitsunterstützung.

Phase 2 baut die Nachweisarchitektur auf. Definieren Sie den Index der Produktsicherheitsakte, Nachweisverantwortliche, Aufbewahrungsanforderungen, Repository-Struktur und Genehmigungs-Workflow. Richten Sie dies an Engineering-Systemen aus, statt manuelle Uploads zu erzwingen.

Phase 3 setzt operative Kontrollen um. Sichere Entwicklung, SBOM-Erzeugung, Schwachstellenbehandlung, Lieferantennachweise, Release-Gates, sichere Aktualisierungen und Vorfalleskalation müssen als reale Prozesse funktionieren.

Phase 4 testet die Auditbereitschaft. Wählen Sie ein Produkt-Release aus und führen Sie ein Mock-Audit durch. Kann das Team die SBOM abrufen? Kann es Sicherheitsprüfungen nachweisen? Kann es zeigen, wie eine Schwachstelle triagiert wurde? Kann es Lieferantennachweise mit Produktkomponenten verbinden?

Phase 5 verankert Überwachung und Verbesserung. Überwachung nach dem Inverkehrbringen, Trendanalyse zu Schwachstellen, Lieferantenüberprüfungen und Beiträge zur Managementbewertung halten die Akte aktuell.

Dieser Sprint legt die Realität meist schnell offen. Organisationen scheitern selten, weil ihnen alle Kontrollen fehlen. Sie scheitern, weil Kontrollen auf Produktebene nicht verbunden sind.

Häufige Lücken bei der CRA-Bereitschaft vor 2026

Bei Softwareanbietern, Geräteherstellern und Anbietern vernetzter Dienste wiederholen sich die Lücken.

Erstens ist der ISMS-Geltungsbereich zu unternehmenszentriert. Er deckt die Organisation ab, aber nicht genügend Details des Produktlebenszyklus. Die Abhilfe besteht darin, produktbezogene Anhänge und Nachweisakten zu erstellen.

Zweitens existieren SBOMs, sind aber nicht vertrauenswürdig. Sie werden durch Werkzeuge erzeugt, aber nicht überprüft, freigegeben, aufbewahrt oder mit Schwachstellenentscheidungen verbunden. Die Abhilfe ist SBOM-Governance, nicht nur SBOM-Erzeugung.

Drittens ist CVD öffentlich sichtbar, aber operativ nicht ausgereift. Meldungen gehen ein, aber Triage-Kriterien, Reaktionsziele, Freigaben von Sicherheitshinweisen und Abschlussnachweise sind uneinheitlich. Die Abhilfe besteht darin, CVD mit Schwachstellenmanagement, Vorfallmanagement und Release-Management zu integrieren.

Viertens sind Lieferantennachweise zu oberflächlich. Kritische Lieferanten sind kommerziell freigegeben, aber nicht hinsichtlich ihrer Auswirkungen auf die Produktsicherheit bewertet. Die Abhilfe ist eine Lieferantenklassifizierung nach Produktrisiko und verpflichtende Nachweise für kritische Komponenten.

Fünftens ist Überwachung nach dem Inverkehrbringen reaktiv. Teams reagieren auf dringende Schwachstellen, führen aber keine periodischen Produktrisikoprüfungen durch. Die Abhilfe ist eine geplante Sicherheitsüberprüfung nach dem Inverkehrbringen, die mit der Managementberichterstattung verknüpft ist.

Sechstens sind Auditnachweise zu manuell. Compliance-Teams jagen Screenshots hinterher. Die Abhilfe ist Evidence by Design, bei dem Engineering-Systeme, Ticketing-Workflows und Repositories als maßgebliche Quellen genutzt werden.

Bauen Sie die Nachweisakte auf, bevor der Termin sie für Sie erzwingt

Der Cyber Resilience Act begünstigt Organisationen, die Produktsicherheit als operative Disziplin nachweisen können. Er schafft Risiken für Organisationen, die Nachweise als Compliance-Übung in letzter Minute behandeln.

Beginnen Sie mit einem Produkt. Bauen Sie eine Produktsicherheitsakte auf. Ordnen Sie sie ISO/IEC 27001:2022 und ISO/IEC 27002:2022 zu. Fügen Sie Nachweise zur sicheren Entwicklung, SBOM, CVD-Aufzeichnungen, Lieferantensicherheit und Überwachung nach dem Inverkehrbringen hinzu. Führen Sie eine Auditsimulation durch, bevor es jemand Externes für Sie tut.

Clarysec kann Sie auf diesem Weg beschleunigen – mit dem Zenith Blueprint, Zenith Controls, der Enterprise-Richtlinie für sichere Softwareentwicklung, der Richtlinie zum Schwachstellenmanagement, der Richtlinie zum Asset-Management, der Richtlinie zur Lieferanten- und Drittparteiensicherheit, der Richtlinie zur Protokollierung und Überwachung und der Richtlinie zum Management von Informationssicherheitsvorfällen.

Ihre wichtigste CRA-2026-Frage lautet nicht: „Haben wir Sicherheitskontrollen?“

Sie lautet: „Können wir Produktsicherheit nachweisen – Release für Release, Komponente für Komponente, Schwachstelle für Schwachstelle, nachdem das Produkt bereits im Markt ist?“

Bauen Sie die Nachweisakte jetzt auf, verbinden Sie sie mit Ihrem ISMS und machen Sie jedes künftige Produkt-Release von Anfang an auditbereit.