Der CRA im Zusammenspiel mit ISO 27001, NIST SSDF und NIS2

Problem in der Praxis

Viele Organisationen verfügen bereits über ein ISMS nach ISO/IEC 27001, teils ergänzt um NIST-SSDF-Praktiken in der Entwicklung, und sind oder werden von NIS2 erfasst. Die naheliegende Annahme lautet dann: Der CRA ist abgedeckt, weil ohnehin sichere Prozesse existieren. Diese Annahme ist gefährlich, weil sie zwei verschiedene Steuerungslogiken vermengt.

Prozessrahmen fragen, ob die Organisation Sicherheit systematisch managt. Der CRA fragt, ob ein konkretes Produkt beim Inverkehrbringen bestimmte wesentliche Cybersicherheitsanforderungen erfüllt, ob es über den Lebenszyklus gepflegt wird und ob die Konformität nachgewiesen und gekennzeichnet ist. Ein Unternehmen kann ein einwandfreies ISMS betreiben und trotzdem ein Produkt ausliefern, das die CRA-Pflichten verfehlt, etwa weil keine Software Bill of Materials (SBOM) existiert, kein Unterstützungszeitraum definiert ist oder die Konformitätsbewertung fehlt.

Spätestens bei der CE-Kennzeichnung wird der Unterschied sichtbar. Ein Managementsystem-Zertifikat hängt nicht am Produkt; eine EU-Konformitätserklärung schon.

CISO-Einordnung

Die Trennlinie verläuft zwischen Prozess und Produkt sowie zwischen Managementsystem und Produktrecht.

ISO/IEC 27001 liefert das organisatorische Betriebssystem der Informationssicherheit: Risiken, Rollen, Maßnahmen, Nachweise, Verbesserung. Die Secure-Development-Themen der ISO/IEC-27000-Reihe beschreiben abstrakt das organisatorische Wie eines sicheren Entwicklungsprozesses. Diese Inhalte sind lizenzpflichtig und werden hier nur als Strukturbezug genannt, ohne Wiedergabe von Control-Nummern oder Volltexten.

NIST SSDF (SP 800-218) ist ebenfalls prozessual und beschreibt Praktiken sicherer Softwareentwicklung. Es lässt sich gut auf die CRA-Anforderungen zur Schwachstellenbehandlung nach Anhang I Teil II und auf SBOM abbilden und ist gemeinfrei (Public Domain), also frei nutzbar.

NIS2 (Richtlinie (EU) 2022/2555) verpflichtet Betreiber zu organisationsbezogenem Risikomanagement und Meldungen; sie ist eine Richtlinie und bedarf nationaler Umsetzung. Der CRA ist demgegenüber eine Verordnung und gilt unmittelbar in allen Mitgliedstaaten ohne nationales Umsetzungsgesetz.

Inhaltlich verzahnen sich die Rahmen, statt sich zu ersetzen. NIS2 verlangt vom Betreiber Lieferkettensicherheit (Art. 21); CRA-konforme Produkte liefern genau die Eigenschaften und Informationen, die der Betreiber dafür braucht. Was prozessual erprobt ist, trägt die produktrechtlichen Pflichten des CRA, ersetzt sie aber nicht.

Neu am CRA ist vor allem: produktbezogene Pflichten an das Inverkehrbringen, eine Konformitätsbewertung mit EU-Konformitätserklärung und CE-Kennzeichnung, ein definierter Unterstützungszeitraum mit Sicherheitsupdates, eine verpflichtende SBOM, gesetzliche Meldefristen für Produkt-Schwachstellen und -Vorfälle sowie Produktklassen, die die Prüfstrenge steuern. Betriebssysteme zählen zu den wichtigen Produkten der Klasse I; Firewalls sowie Intrusion-Detection-/-Prevention-Systeme (IDS/IPS) zur Klasse II. Für Klasse II ist eine Drittprüfung durch eine notifizierte Stelle verpflichtend; reine Selbstbewertung genügt dort nicht. Die genauen Produktlisten ergeben sich aus den Anhängen der Verordnung und können durch delegierte Rechtsakte präzisiert werden; sie sind im Einzelfall zu prüfen.

Umsetzungsperspektive

Sinnvoll ist, die Rahmen entlang ihrer Logik zu verknüpfen statt parallel zu führen.

• Prozess als Fundament: Der sichere Entwicklungslebenszyklus aus ISO/IEC 27001 und NIST SSDF liefert das organisatorische Wie. Auf dieser Basis werden die produktbezogenen CRA-Anforderungen konkretisiert, nicht von Grund auf neu erfunden.
• Produktpflichten verankern: Was der CRA produktspezifisch fordert, gehört ins Produkt und seine Dokumentation. Dazu zählen Security-by-Design und Security-by-Default nach Anhang I Teil I, die Schwachstellenbehandlung über den Lebenszyklus nach Anhang I Teil II mit SBOM und Coordinated Vulnerability Disclosure (CVD), die technische Dokumentation, die Konformitätsbewertung und die CE-Kennzeichnung.
• Dauerhafte Funktion etablieren: Für CVD, Kontaktstelle und Update-Verteilung über den Unterstützungszeitraum etablieren Hersteller typischerweise ein Product Security Incident Response Team (PSIRT). Der Unterstützungszeitraum orientiert sich an der erwarteten Nutzungsdauer; als Richtwert nennt der Regelungsrahmen in der Regel mindestens fünf Jahre.
• Meldewege sauber trennen: Der CRA verlangt vom Hersteller gestaffelte Meldungen aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle an das zuständige nationale CSIRT und ENISA, mit Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und Abschlussbericht bei Schwachstellen binnen 14 Tagen, bei schwerwiegenden Vorfällen binnen eines Monats. Diese produktbezogenen Meldungen sind von den organisationsbezogenen NIS2-Meldungen des Betreibers zu unterscheiden.
• Harmonisierte Normen beobachten: Die IEC-62443-Reihe (insbesondere 62443-4-1 und 62443-4-2) gilt als wichtiger Kandidat für harmonisierte Normen mit Vermutungswirkung. Die Selbstbewertung bei Klasse-I-Produkten ist möglich, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein geeignetes europäisches Cybersicherheits-Zertifizierungsschema vollständig angewendet werden; harmonisierte Normen sind dabei nur einer dieser Wege. Ihr Stand ist laufend und vor verbindlicher Nutzung zu prüfen.

Als frei zugängliche Orientierungshilfe zum CRA dient die BSI TR-03183; sie ist nicht rechtsverbindlich und entfaltet keine Vermutungswirkung. Der Versionsstand ist vor Nutzung zu prüfen.

Typische Fehler

1. Das ISO-27001-Zertifikat wird als CRA-Nachweis missverstanden, obwohl es keine Vermutungswirkung für die Produktkonformität erzeugt.
2. Prozessreife wird mit Produktkonformität gleichgesetzt; ein gutes ISMS deckt das Inverkehrbringen nicht automatisch ab.
3. CRA- und NIS2-Meldepflichten werden vermischt, statt produkt- und organisationsbezogene Wege getrennt zu führen.
4. SBOM, Unterstützungszeitraum und Konformitätsbewertung werden als Entwicklungsdetail behandelt statt als rechtliche Produktpflicht.
5. Die Produktklasse wird nicht bestimmt, sodass die nötige Prüfstrenge (etwa Drittprüfung bei Klasse II) zu spät erkannt wird.
6. Harmonisierte Normen werden als gegeben angenommen, obwohl ihr Stand und ihre Vermutungswirkung noch zu prüfen sind.

Risiken und Trade-offs

Der erste Trade-off liegt zwischen Integration und Trennschärfe. Werden CRA-, ISO-, NIST- und NIS2-Aktivitäten zu eng verschmolzen, entsteht der Eindruck, ein Rahmen erledige den anderen; das führt zu Lücken bei genau den Pflichten, die nur der CRA kennt. Werden sie zu getrennt geführt, entstehen doppelte Strukturen, doppelte Nachweise und Reibung zwischen ISMS und Produktentwicklung.

Ein zweiter Trade-off betrifft die Konformitätsstrategie. Die Wahl zwischen Selbstbewertung und Drittprüfung hängt von der Produktklasse und davon ab, ob harmonisierte Normen, gemeinsame Spezifikationen oder ein geeignetes europäisches Zertifizierungsschema verfügbar sind und vollständig angewendet werden. Auf noch nicht finale Normen zu setzen, schafft Planungsrisiko; diese Wege zu ignorieren, verschenkt den möglichen Zugang zur Selbstbewertung bei Klasse I.

Drittens besteht ein zeitliches Risiko. Die Meldepflichten gelten bereits ab dem 11.09.2026, die Vollanwendung der übrigen Pflichten ab dem 11.12.2027. Wer die produktbezogenen Fähigkeiten erst zur Vollanwendung aufbaut, verfehlt die früher greifenden Meldepflichten.

Entscheidungspunkte

• Welche eigenen Produkte fallen voraussichtlich in den CRA-Anwendungsbereich, und in welche Produktklasse (Standard, Klasse I, Klasse II, kritisch) sind sie einzuordnen?
• Wo nutzt die Organisation den vorhandenen sicheren Entwicklungsprozess aus ISO/IEC 27001 und NIST SSDF als Basis, und welche produktbezogenen CRA-Pflichten müssen ergänzt werden?
• Wie werden CRA-Produktmeldungen und NIS2-Betreibermeldungen organisatorisch sauber getrennt und zugleich abgestimmt?
• Setzt die Konformitätsstrategie auf Selbstbewertung (gestützt auf harmonisierte Normen, gemeinsame Spezifikationen oder ein geeignetes EU-Zertifizierungsschema) oder auf Drittprüfung, und wie wird der noch zu prüfende Normstand berücksichtigt?
• Sind SBOM, Unterstützungszeitraum, PSIRT-Funktion und Meldefähigkeit rechtzeitig vor dem 11.09.2026 und dem 11.12.2027 aufgebaut?

Praktische Empfehlungen

1. Behandeln Sie ISO/IEC 27001 und NIST SSDF als prozessuales Fundament und den CRA als darauf aufsetzende, produktrechtliche Pflichtenschicht, nicht als Dublette.
2. Erstellen Sie ein bewusst grobes Mapping, das prozessuale Fähigkeiten den CRA-Produktpflichten zuordnet und die CRA-spezifischen Lücken sichtbar macht. Verzichten Sie dabei auf ISO-Control-Nummern und auf normersetzende Pflichtenlisten.
3. Bestimmen Sie je Produkt frühzeitig die Produktklasse, da sie die Prüfstrenge und den möglichen Weg zur Selbstbewertung (über harmonisierte Normen, gemeinsame Spezifikationen oder ein geeignetes EU-Zertifizierungsschema) steuert.
4. Verzahnen Sie CRA und NIS2 über gemeinsame Komponenten-, Schwachstellen- und Lieferantendaten, halten Sie die getrennten Meldewege aber strikt auseinander.
5. Bauen Sie SBOM, Unterstützungszeitraum, PSIRT und Meldefähigkeit termingerecht zu den gestaffelten CRA-Fristen auf und testen Sie den Meldeprozess gegen die 24/72-Stunden-Logik.
6. Verfolgen Sie den Stand harmonisierter Normen (insbesondere IEC 62443) und die BSI TR-03183 als Orientierung, ohne sie als rechtsverbindlich zu behandeln.

Relevante Normreferenzen

• Cyber Resilience Act, Verordnung (EU) 2024/2847: maßgeblicher Rechtsakt für Produkte mit digitalen Elementen; unmittelbar in allen Mitgliedstaaten geltend, Vollanwendung ab 11.12.2027, Meldepflichten ab 11.09.2026. Für verbindliche Pflichten, Produktklassen und Fristen ist der Verordnungstext einschließlich Anhänge maßgeblich.
• ISO/IEC 27001: organisatorischer Bezugsrahmen für das prozessorientierte ISMS und den sicheren Entwicklungslebenszyklus (Referenz, keine Wiedergabe von Inhalten oder Control-Nummern).
• NIST SP 800-218 (Secure Software Development Framework, SSDF): prozessuale Referenz für sichere Softwareentwicklung und SBOM (Public Domain).
• NIS2, Richtlinie (EU) 2022/2555: organisationsbezogene Cybersicherheits- und Lieferkettenpflichten der Betreiber (Art. 21); komplementär zum produktbezogenen CRA, getrennte Meldewege; als Richtlinie national umzusetzen.
• IEC 62443 (insbesondere 62443-4-1 und 62443-4-2): Referenz für sicheren Produktentwicklungsprozess und Komponentenanforderungen; wichtiger Kandidat für harmonisierte Normen, Stand zu prüfen.
• BSI TR-03183 (Cyber-Resilienz-Anforderungen an Hersteller und Produkte): frei zugängliche Orientierungshilfe zum CRA, nicht rechtsverbindlich und ohne Vermutungswirkung; Versionsstand vor Nutzung prüfen.