„Wir sind ISO 27001 zertifiziert, damit ist der CRA für uns abgehakt." Dieser Satz fällt in Gesprächen mit größeren Herstellern erstaunlich oft, gerade dort, wo viel Geld und Mühe in die Zertifizierung geflossen ist. Die Hoffnung ist nachvollziehbar. Sie ist trotzdem falsch, und zwar aus einem strukturellen Grund: Die beiden Regelwerke schauen auf unterschiedliche Gegenstände.
Was bedeutet ISO 27001 und was prüft sie?
ISO 27001 ist der internationale Standard für Informationssicherheits-Managementsysteme (ISMS). Zertifiziert wird die Organisation: ihre Risikoanalyse, ihre Sicherheitsprozesse, ihre Verantwortlichkeiten, ihre kontinuierliche Verbesserung. Der Auditor prüft, ob das Unternehmen Informationssicherheit systematisch managt.
Was der Auditor nicht prüft: ob ein konkretes Produkt sicher entworfen wurde, welche Softwarekomponenten darin stecken, ob es über seinen Lebenszyklus Sicherheitsupdates erhält. Ein Unternehmen mit vorbildlichem ISMS kann ein Produkt mit veralteter Verschlüsselung und ungepflegten Open-Source-Komponenten ausliefern, ohne dass das Zertifikat davon berührt wird.
Der Cyber Resilience Act setzt genau dort an. Er folgt dem New Legislative Framework (NLF), dem EU-Rechtsrahmen für Produktsicherheit, und reguliert das einzelne Produkt mit digitalen Elementen: Security by Design, also von Anfang an im Entwicklungsprozess verankerte Sicherheit, Schwachstellenmanagement über den Lebenszyklus, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung. Einen Überblick gibt unsere CRA-Zusammenfassung.
Warum der Kurzschluss „Zertifikat = Compliance" gefährlich ist
Wer die ISO-Zertifizierung als CRA-Nachweis einplant, übersieht mindestens vier Anforderungsblöcke, die ein ISMS-Audit nicht liefert:
- Konformitätsbewertung pro Produkt: Der CRA verlangt für jedes Produktmodell ein Konformitätsbewertungsverfahren, abgeschlossen mit EU-Konformitätserklärung und CE-Kennzeichnung. Je nach Produktkategorie, etwa bei wichtigen Produkten der Klasse I oder II, gelten dafür unterschiedliche Verfahren. Details dazu im Artikel zur CE-Kennzeichnung unter dem CRA.
- SBOM je Produkt: Der CRA fordert eine SBOM (Software Bill of Materials), also ein vollständiges Verzeichnis aller Softwarekomponenten, als Teil der technischen Dokumentation. ISO 27001 kennt diese Anforderung nicht. Wie Sie SBOMs aufbauen, zeigt der SBOM-Guide.
- Support-Zeitraum mit kostenlosen Sicherheitsupdates: Hersteller müssen für jedes in Verkehr gebrachte Produkt (also jedes erstmals auf dem EU-Markt bereitgestellte Produkt) über den festgelegten Support-Zeitraum Sicherheitsupdates bereitstellen. Das ist eine Produktpflicht, kein Organisationsprozess.
- Meldepflichten in Stunden statt Auditzyklen: Aktiv ausgenutzte Schwachstellen müssen ab dem 11. September 2026 binnen 24 Stunden über die Single Reporting Platform der ENISA gemeldet werden. Ein ISMS-Audit findet einmal im Jahr statt. Die CRA-Frist läuft in Stunden.
Ein Beispiel: Der CISO eines Konzerns hinterlegt im CRA-Projektplan das ISO-Zertifikat als Nachweis für die Produktlinie. Nach dem Stichtag fragt ein Großkunde im Lieferantenaudit nach der SBOM für Modell X und dem definierten Support-Zeitraum. Beides steht auf keinem ISMS-Zertifikat der Welt.
Mythos vs. Fakt
Mythos: Eine ISO-27001-Zertifizierung deckt die Anforderungen des Cyber Resilience Act ab.
Fakt: ISO 27001 zertifiziert das Managementsystem der Organisation. Der CRA reguliert das einzelne Produkt. Konformitätsbewertung, CE-Kennzeichnung, SBOM, Support-Zeitraum und die 24-Stunden-Meldepflicht lassen sich durch kein ISMS-Zertifikat ersetzen. Ein gelebtes ISMS ist aber ein starkes Fundament für den CRA-Aufbau.
Konkrete Konsequenzen für Ihr CRA-Projekt
1. Führen Sie ein strukturiertes Gap-Assessment durch. Legen Sie die CRA-Anforderungen neben Ihre ISMS-Prozesse und markieren Sie drei Kategorien: bereits abgedeckt (etwa Risikomanagement-Methodik), anpassbar (etwa Incident-Response als Basis für den Meldeprozess) und neu (etwa SBOM, Konformitätsbewertung, Support-Zeitraum). So wird aus dem diffusen „CRA-Projekt" eine konkrete Arbeitsliste.
2. Nutzen Sie Ihre ISO-Strukturen als Beschleuniger. Ihr Vorteil gegenüber Unternehmen ohne ISMS ist real: Sie haben Verantwortlichkeiten, Dokumentationsdisziplin und einen Incident-Prozess. Erweitern Sie den Incident-Prozess um den CRA-Meldeweg mit seinen Fristenstufen, statt parallel etwas Neues zu bauen. Dieselbe Logik gilt für Lieferantenmanagement und Risikobewertung.
3. Behandeln Sie die Produktebene als eigenes Arbeitspaket. Alles, was pro Produkt anfällt, braucht eigene Verantwortliche, meistens näher an Entwicklung und Produktmanagement als an der Informationssicherheit: SBOM je Produktlinie, Security-by-Design-Nachweise, Konformitätsbewertung, Update-Prozesse. Der häufigste Fehler ist, diese Aufgaben der ISMS-Organisation zuzuschieben, die dafür weder Werkzeuge noch Produktnähe hat.
Was bedeutet das für Ihre CRA-Roadmap?
Am 11. September 2026 treten die Meldepflichten in Kraft. Ihr ISMS-Incident-Prozess ist die beste Ausgangsbasis für den Meldeweg, muss aber um die CRA-Fristen und die ENISA-Meldung erweitert werden.
Am 11. Dezember 2027 folgt die volle CRA-Anwendbarkeit. Ab dann braucht jedes neu in Verkehr gebrachte Produkt die vollständige Konformität inklusive CE-Kennzeichnung.
Wie Sie beide Stichtage in eine realistische Planung übersetzen, zeigt die CRA Compliance-Roadmap 2026/2027. Was bei Nichteinhaltung droht, steht im Artikel zu CRA-Bußgeldern und Sanktionen.
Häufig gestellte Fragen
Bringt mir ISO 27001 für den CRA gar nichts? Doch, einiges. Risikomanagement, Incident-Prozesse, Dokumentationsdisziplin und Auditerfahrung verkürzen den CRA-Aufbau erheblich. Nur ersetzt das ISMS die produktbezogenen Pflichten nicht.
Gibt es eine Zertifizierung, die eine CRA-Konformitätsvermutung erzeugt? Der CRA arbeitet mit harmonisierten Normen: Produkte, die nach ihnen entwickelt und bewertet werden, profitieren von einer Konformitätsvermutung. Diese Normen entstehen derzeit bei den europäischen Normungsorganisationen. ISO 27001 gehört nicht dazu, da sie die Organisation und nicht das Produkt betrifft.
Wir sind zusätzlich IEC 62443 zertifiziert. Reicht die Kombination? Die Kombination ist stark, aber auch IEC 62443 erzeugt derzeit keine automatische CRA-Konformität. Warum das so ist, behandle ich in einem eigenen Beitrag dieser Serie.
Muss ich mein ISMS für den CRA erweitern? Formal nein, praktisch ja. Es ist sinnvoll, die CRA-Prozesse (Meldewege, Schwachstellenmanagement, Update-Auslieferung) in die bestehende Prozesslandschaft zu integrieren, statt eine Parallelorganisation aufzubauen.
Wer im Unternehmen sollte den CRA verantworten, CISO oder Produktbereich? Beide, mit klarer Aufgabenteilung. Die Meldewege und das Monitoring liegen oft gut beim CISO, die produktbezogenen Pflichten (SBOM, Konformitätsbewertung, Updates) gehören in Entwicklung und Produktmanagement. Entscheidend ist, dass die Schnittstelle definiert ist.
Fazit
ISO 27001 ist ein Qualitätsausweis für Ihre Organisation und ein echtes Fundament für den CRA-Aufbau. Ein CRA-Nachweis ist sie nicht. Die produktbezogenen Pflichten, von der SBOM über die Konformitätsbewertung bis zur 24-Stunden-Meldung, entstehen nur durch eigene Arbeit auf Produktebene.
Eine strukturierte CRA-Roadmap, unterstützt von einer Plattform wie Kunnus, hilft dabei, die Lücken zwischen ISMS und Produktpflichten systematisch abzuarbeiten, bevor der Stichtag aus der Theorie in die Praxis kippt. Den Einstieg bietet unser kostenloser CRA-Compliance-Check.
Jeden Freitag räume ich hier mit einem CRA-Mythos auf.