CRA und ISO 27001: Reicht das Zertifikat?

Die häufige Annahme — und warum sie trügt

Viele Unternehmen, die bereits nach ISO/IEC 27001:2022 zertifiziert sind, stellen sich dieselbe Frage: „Wir haben doch schon ein ISMS — reicht das nicht für den CRA?”

Nein. ISO 27001 reicht nicht aus. Sie hilft — aber wer glaubt, damit CRA-konform zu sein, wird bei der ersten Behördenanfrage böse überrascht. Das liegt nicht an mangelnder Qualität der Norm. Es liegt daran, dass sie eine grundlegend andere Frage beantwortet.

Was ISO 27001 abdeckt

ISO/IEC 27001:2022 ist ein organisationsweites Managementsystem für Informationssicherheit (ISMS). Es verpflichtet ein Unternehmen, Risiken systematisch zu identifizieren, zu bewerten und durch geeignete Kontrollen zu behandeln. Anhang A der Norm listet 93 Kontrollen in vier Themengebieten:

Organisatorische Kontrollen (z. B. Richtlinien, Lieferantenmanagement)
Personenbezogene Kontrollen (z. B. Schulungen, Hintergrundprüfungen)
Physische Kontrollen (z. B. Zutrittskontrolle, Geräteentsorgung)
Technologische Kontrollen (z. B. Logging, Kryptographie, sichere Entwicklung)

ISO 27001 ist damit ein Unternehmens-Standard: Er bewertet, ob das Unternehmen seine eigene Informationsumgebung sicher betreibt.

Was der CRA fordert — und wo die Unterschiede liegen

Der Cyber Resilience Act (EU-Verordnung 2024/2847) ist ein Produktstandard: Er bewertet, ob ein einzelnes Produkt mit digitalen Elementen sicher entwickelt wurde, sicher betrieben werden kann und sicher bleibt — über den gesamten Produktlebenszyklus.¹

Das ist der Punkt, den viele übersehen: ISO 27001 fragt „Ist Ihr Unternehmen sicher?” Der CRA fragt „Ist Ihr Produkt sicher?” Zwei verschiedene Fragen. Zwei verschiedene Antworten.

Die strukturelle Ähnlichkeit — beide sprechen von Risikoanalyse, Incident Management, Lieferantensicherheit — verführt dazu, beide Anforderungsrahmen zu vermischen. In der Praxis erleben wir genau das: Ein Hersteller von industriellen MQTT-Gateways tritt in einer CRA-Konformitätsprüfung mit seinem ISO-27001-Zertifikat an — und hat damit die falsche Antwort auf die falsche Frage. Genauso ein embedded-Software-Hersteller für Heizungssteuerungen, der sein ISMS vorzeigt, aber keine produktbezogene Sicherheitsdokumentation vorweisen kann. Das kann teuer werden.

Mapping-Tabelle: ISO 27001-Kontrollen ↔ CRA Anhang I

Die folgende Tabelle zeigt, welche CRA-Anforderungen aus Anhang I durch typische ISO-27001-Implementierungen (Anhang A) gestützt werden — und welche nicht:

CRA Anhang I Anforderung	ISO 27001 Anhang A (Relevanz)	Abgedeckt?
Risikobasierte Schutzmaßnahmen nach Stand der Technik	A.5.8 (Informationssicherheit in Projekten), A.8.25 (Sicherer Entwicklungslebenszyklus)	Teilweise
Secure by Default	A.8.9 (Konfigurationsmanagement)	Schwach
Schutz vor unbefugtem Zugriff (Authentifizierung, Zugangskontrolle)	A.5.15–5.18 (Zugriffssteuerung, Benutzerauthentifizierung)	Ja
Vertraulichkeit von Daten in Übertragung und Speicherung	A.8.24 (Kryptographie), A.8.20 (Netzwerksicherheit)	Ja
Integrität von Daten, Software, Konfigurationen	A.8.12 (Verhinderung von Datenlecks), A.8.16 (Überwachungsaktivitäten)	Teilweise
Minimierung der Angriffsoberfläche	A.8.8 (Management technischer Schwachstellen)	Schwach
Schutz vor Denial-of-Service-Angriffen	A.8.6 (Kapazitätsmanagement)	Schwach
Datenminimierung	Kein direktes ISO-Äquivalent (eher DSGVO-Bereich)	Nein
Schwachstellenmanagement und Sicherheitsupdates	A.8.8 (Schwachstellenmanagement)	Teilweise
SBOM — Software Bill of Materials	Kein ISO-27001-Äquivalent	Nein
CE-Kennzeichnung	Kein ISO-27001-Äquivalent	Nein
24h-Meldung aktiv ausgenutzter Schwachstellen	A.5.24–5.26 (Incident Management) — aber kein 24h-Standard	Nein
Technische Dokumentation (Anhang VII CRA)	A.5.37 (Dokumentierte Betriebsabläufe) — unvollständig	Schwach
Konformitätserklärung + EU-DoC	Kein ISO-27001-Äquivalent	Nein

Legende: Ja = inhaltlich abgedeckt / Teilweise = Ansatz vorhanden, aber CRA-spezifische Vertiefung nötig / Schwach = marginale Überlappung / Nein = kein Äquivalent in ISO 27001

Die drei größten Lücken

1. SBOM — Software Bill of Materials

CRA Anhang I Nummer 10 verpflichtet Hersteller, eine maschinenlesbare Software-Stückliste (SBOM) aller verwendeten Komponenten zu erstellen und aktuell zu halten — einschließlich Open-Source-Bibliotheken, Drittanbieter-Komponenten und deren Versionen.¹

ISO 27001 kennt keine SBOM-Anforderung. Anhang A.8.8 adressiert zwar das Management technischer Schwachstellen, fordert aber keine standardisierte Inventarliste im SBOM-Format (SPDX, CycloneDX o. ä.). Konkret bedeutet das: Ein IoT-Startup, das Sensormodule für die Industrie-4.0-Fertigung vertreibt, muss neue Werkzeuge und Prozesse einführen — unabhängig davon, wie reif sein ISMS bereits ist. Das ISMS hilft hier schlicht nicht weiter.

2. 24-Stunden-Meldepflicht für Schwachstellen

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen ihrer Produkte innerhalb von 24 Stunden an ENISA (und die zuständige nationale CSIRTs-Einheit) melden. Innerhalb von 72 Stunden folgt eine detaillierte Frühwarnung, innerhalb von 14 Tagen ein vollständiger Bericht.¹

ISO 27001 verlangt ein Incident-Management-System (Anhang A.5.24–5.26), aber keine spezifischen Fristen für externe Meldungen an Regulierungsbehörden. Das ist kein gradueller Unterschied. Das ist ein operativer. Ein Maschinenbauer, der embedded-Software für vernetzte Steuerungseinheiten liefert und noch keinen strukturierten Vulnerability-Disclosure-Prozess betreibt, muss diesen eigenständig aufbauen — bevor September 2026 die Meldepflicht scharf schaltet. Wer das auf die lange Bank schiebt, baut unter Zeitdruck.

3. CE-Kennzeichnung und EU-Konformitätserklärung

Der CRA verlangt vom Hersteller eine EU-Konformitätserklärung (DoC) sowie das Anbringen der CE-Kennzeichnung als Nachweis der Konformität (Artikel 28 und 30).¹ Dieser formale Produktnachweis — mit definiertem Inhalt nach Anhang VI — ist ein produktrechtliches Instrument ohne Entsprechung in ISO 27001.

ISO-27001-Zertifikate stellen Zertifizierungsstellen aus und belegen Unternehmenskonformität. Die CRA-CE-Kennzeichnung ist ein Produktmerkmal, das der Hersteller selbst erklärt (Selbstbewertung für die Default-Klasse) oder durch eine notifizierte Stelle bestätigen lässt. Das klingt nach bürokratischem Aufwand. Ist es auch. Aber es ist unvermeidlich.

Was ISO 27001 tatsächlich bringt

Trotz dieser Lücken ist ISO 27001 keine verlorene Investition — im Gegenteil:

Risikoanalyse-Reife: Ein bestehendes ISMS beschleunigt die produktbezogene Risikoanalyse nach CRA erheblich, weil Methodik und Dokumentationskultur bereits vorhanden sind.
Entwicklungssicherheit (A.8.25–8.31): ISO 27001:2022 deckt sichere Softwareentwicklung breiter ab als die Vorgängerversion — das zahlt direkt auf Anhang I ein.
Lieferantenmanagement (A.5.19–5.22): Die CRA-Anforderungen zur Lieferkettensicherheit (Artikel 13 Absatz 5) bereiten ISO-27001-Lieferantenkontrollen gut vor.
Incident Management: Der ISO-27001-Prozess bildet die organisatorische Grundlage, auf der Hersteller einen CRA-konformen Vulnerability-Disclosure-Prozess aufbauen können.
Nachweis gegenüber Kunden: Viele Kunden und Ausschreibungsverfahren akzeptieren ISO 27001 als Teil des Sicherheitsnachweises — das bleibt unverändert.

Was viele CRA-Berater nicht sagen: Der Wert von ISO 27001 liegt im CRA-Kontext vor allem in der Prozessreife — nicht im Zertifikat selbst. Ein Unternehmen, das sauber dokumentiert und Risiken strukturiert bewertet, hat einen echten Vorsprung. Aber nur beim Aufbau. Nicht beim Abschluss.

Fazit: Gute Basis, kein Ersatz

ISO 27001 und CRA verfolgen unterschiedliche Ziele. ISO 27001 zertifiziert das Sicherheitsmanagement des Unternehmens, der CRA reguliert die Sicherheit des Produkts. Eine ISO-27001-Zertifizierung hilft bei der CRA-Umsetzung — sie ersetzt sie nicht.

Der Abstand zwischen beiden Welten ist für Hersteller physischer Produkte mit digitalen Elementen — Industrie-4.0-Komponenten, vernetzte Maschinen, Smart-Building-Gateways — größer als für reine Software-Anbieter. Wer Hardware produziert, muss CE-Kennzeichnung, technische Dokumentation und SBOM vollständig neu aufbauen. ISO 27001 hilft dabei kaum.

Konkrete Maßnahmen, die ISO-27001-zertifizierte Unternehmen zusätzlich benötigen:

Produkt-spezifische Risikoanalyse nach Anhang I CRA
SBOM-Prozess einrichten (SPDX oder CycloneDX)
Vulnerability-Disclosure-Prozess mit 24h/72h/14-Tage-Fristen aufbauen
Technische Dokumentation nach CRA Anhang VII erstellen
CE-Kennzeichnungsprozess und EU-Konformitätserklärung implementieren
Klassifizierung des Produkts nach CRA Anhang III/IV prüfen

Welche Klasse Ihr Produkt hat und welche Pflichten konkret gelten, erfahren Sie über den kostenlosen CRA-Check. Für eine umfassende Einschätzung aller Hersteller-Pflichten lesen Sie CRA-Pflichten für Hersteller.

Wenn Sie ein strukturiertes Dokumentationspaket für Ihre CRA-Compliance benötigen, erfahren Sie mehr unter Evidence Pack — CRA-Dokumentation.

Quellen

EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act), Anhang I, Artikel 13, Artikel 28, Artikel 30, Artikel 64: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
ISO/IEC 27001:2022 — Informationssicherheits-Managementsysteme — Anforderungen. International Organization for Standardization: https://www.iso.org/standard/27001
ISO/IEC 27002:2022 — Leitfaden für Maßnahmen der Informationssicherheit (Anhang A Kontrollen): https://www.iso.org/standard/75652.html
ENISA — Cyber Resilience Act — Hintergrund und Leitfäden: https://www.enisa.europa.eu/topics/cyber-resilience-act
BSI — Cyber Resilience Act: Anforderungen und Umsetzung: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/