CRA und ISO 27001 im Vergleich: Reicht das Zertifikat?

Ein Softwarehersteller hat viel in Informationssicherheit investiert. Die Entwicklung gehört zum zertifizierten Geltungsbereich, Sicherheitsanforderungen werden dokumentiert und auch der Umgang mit Schwachstellen ist geregelt. Als das Gespräch auf den Cyber Resilience Act kommt, fällt deshalb der Satz: „Wir sind doch nach ISO 27001 zertifiziert. Dann müssten unsere Produkte doch eigentlich CRA-konform sein.“

Der Gedanke liegt nahe. Schließlich beschäftigen sich sowohl ISO 27001 als auch der CRA mit sicherer Entwicklung, Risiken, Schwachstellen, Lieferanten und Sicherheitsvorfällen.

Trotzdem werden hier zwei Ebenen vermischt: Ein Unternehmen kann Informationssicherheit sehr ordentlich managen und dennoch ein Produkt auf den Markt bringen, das die konkreten Anforderungen des CRA nicht erfüllt. Das zertifizierte Managementsystem ist ein gutes Fundament. Die Produktsicherheit, technische Produktdokumentation und gesetzliche Konformitätsbewertung ersetzt es nicht.

Die kurze Antwort

ISO 27001 stellt Anforderungen an ein Informationssicherheitsmanagementsystem. Die Norm fragt also, ob eine Organisation Informationssicherheit systematisch plant, steuert, überprüft und verbessert. Dazu gehören auch Anforderungen und Maßnahmen für sichere Entwicklung.

Der Cyber Resilience Act, kurz CRA, ist dagegen unmittelbar geltendes EU-Recht. Er stellt verbindliche Cybersicherheitsanforderungen an Hardware- und Softwareprodukte mit digitalen Elementen und verpflichtet insbesondere deren Hersteller. Dabei geht es nicht nur um den Entwicklungsprozess, sondern um die Sicherheit eines konkreten Produkts während seines Lebenszyklus.

Deshalb gilt: Ein ISO 27001-Zertifikat kann viele geeignete Prozesse nachweisen. Es bescheinigt aber weder die CRA-Konformität eines Produkts noch ersetzt es dessen Konformitätsbewertung, EU-Konformitätserklärung oder CE-Kennzeichnung.

Was ist der Cyber Resilience Act?

Der CRA ist die Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Gemeint sind vereinfacht gesagt Software- oder Hardwareprodukte sowie bestimmte zugehörige Lösungen zur Datenverarbeitung aus der Ferne.

Die Verordnung soll dafür sorgen, dass solche Produkte von Anfang an angemessen sicher gestaltet, während ihrer erwarteten Nutzungszeit unterstützt und mit Sicherheitsupdates versorgt werden. Nutzer sollen außerdem verständliche Informationen über die sichere Verwendung und den Unterstützungszeitraum erhalten.

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die wesentlichen Pflichten gelten ab dem 11. Dezember 2027. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten allerdings bereits ab dem 11. September 2026. Die Europäische Kommission fasst die Fristen und Pflichten übersichtlich zusammen.

Wer muss sich nach dem CRA richten?

Im Mittelpunkt stehen Hersteller, die Produkte mit digitalen Elementen auf dem europäischen Markt bereitstellen. Das betrifft nicht nur Unternehmen mit einer eigenen Hardwarefabrik. Auch wer kommerziell Software entwickelt und unter seinem Namen auf den Markt bringt, kann Hersteller im Sinne des CRA sein.

Pflichten haben außerdem:

• Importeure, die Produkte aus Drittstaaten auf den EU-Markt bringen;
• Händler, die solche Produkte in der EU bereitstellen;
• Unternehmen, die Produkte unter eigenem Namen oder eigener Marke vertreiben;
• Unternehmen, die ein Produkt so wesentlich verändern, dass sie dadurch Herstellerpflichten übernehmen.

Dabei kann es etwa um Betriebssysteme, Apps, Router, Smart-Home-Geräte, Industriesteuerungen, Softwarebibliotheken oder andere digitale Komponenten gehen. Der CRA unterscheidet außerdem zwischen normalen, wichtigen und kritischen Produkten. Von dieser Einordnung hängt das zulässige Konformitätsbewertungsverfahren ab.

Nicht jedes digitale Angebot fällt automatisch unter den CRA. Es gibt Ausnahmen und Abgrenzungen, unter anderem für bestimmte Produkte, die bereits sektorspezifischen europäischen Regelungen unterliegen. Auch freie und quelloffene Software, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, wird besonders behandelt. Wer wissen möchte, ob ein konkretes Produkt erfasst ist, braucht deshalb zunächst eine belastbare Betroffenheitsprüfung – keine Bauchentscheidung anhand des Produktnamens.

Gilt der CRA auch für SaaS und Cloud-Dienste?

Gerade Softwareunternehmen fragen häufig: „Wir verkaufen gar keine Software zum Installieren. Wir betreiben nur eine SaaS-Plattform. Sind wir damit raus?“

So pauschal lässt sich das nicht beantworten.

Ein reiner Cloud-Dienst wie Software as a Service, Platform as a Service oder Infrastructure as a Service fällt grundsätzlich nicht allein deshalb unter den CRA, weil dabei Software verwendet wird. Solche Dienste werden an anderer Stelle des europäischen Cybersicherheitsrechts behandelt.

Der CRA erfasst aber auch eine Lösung zur Datenverarbeitung aus der Ferne, wenn sie vom Hersteller oder unter seiner Verantwortung entwickelt wurde und ein Produkt ohne diese Verarbeitung eine seiner Funktionen nicht erfüllen könnte.

Ein einfaches Beispiel: Ein vernetztes Gerät benötigt zwingend die vom Hersteller betriebene Cloud, damit eine wesentliche Produktfunktion funktioniert. Dann kann die Remote-Datenverarbeitung Teil des Produkts mit digitalen Elementen sein. Eine beliebige, unabhängig nutzbare SaaS-Anwendung ist dagegen nicht automatisch dasselbe.

Entscheidend sind daher nicht die Werbebegriffe „Cloud“ oder „SaaS“, sondern konkrete Fragen:

• Was wird auf dem europäischen Markt bereitgestellt?
• Welche Funktionen gehören zum Produkt?
• Kann das Produkt diese Funktionen ohne die entfernte Datenverarbeitung erfüllen?
• Wer hat die Software beziehungsweise Cloud-Komponente entwickelt?
• Unter wessen Verantwortung wird sie angeboten und gepflegt?

Gerade Mischmodelle sollten Unternehmen sorgfältig prüfen. Ein Satz wie „Wir sind SaaS, also gilt der CRA für uns nicht“ ist als Betroffenheitsanalyse etwas dünn.

Was regelt ISO 27001?

ISO 27001 ist eine internationale Norm für Informationssicherheitsmanagementsysteme. Sie betrachtet die Organisation, ihren Kontext, ihre Risiken, Verantwortlichkeiten, Prozesse und Maßnahmen. Eine Zertifizierungsstelle kann prüfen, ob das ISMS innerhalb des festgelegten Geltungsbereichs die Normanforderungen erfüllt.

Die Norm enthält durchaus relevante Vorgaben für entwickelnde Unternehmen. Insbesondere die Anforderungen A.8.25 bis A.8.32 behandeln Themen wie den sicheren Entwicklungslebenszyklus, Sicherheitsanforderungen an Anwendungen, sichere Architektur, sichere Codierung, Sicherheitstests, ausgelagerte Entwicklung, die Trennung von Entwicklungs-, Test- und Produktionsumgebungen sowie Änderungsmanagement.

Wie man diese Anforderungen praktisch in die Entwicklung bringt, erklären wir ausführlicher im Artikel Softwareentwicklung: So bauen Sie Sicherheit in den Code ein. Auch der Schutz von Sourcecode ist ein wichtiger Teil dieser organisatorischen und technischen Grundlage.

Aber: ISO 27001 zertifiziert ein Managementsystem, also schlussendlich ein Unternehmen. Sie erklärt nicht jedes Produkt eines zertifizierten Unternehmens automatisch für sicher.

Wo überschneiden sich CRA und ISO 27001?

Die Schnittmenge ist groß genug, dass ein vorhandenes ISMS die CRA-Umsetzung erheblich erleichtern kann.

Risikobasiertes Vorgehen

Sowohl ISO 27001 als auch der CRA verlangen, dass Sicherheit auf Risiken basiert, bzw. darauf, dass Risiken erkannt, bewertet und priorisiert abgestellt werden. Hersteller müssen nach dem CRA eine produktspezifische Cybersicherheitsrisikobewertung durchführen und bei Planung, Entwicklung, Herstellung, Bereitstellung und Wartung berücksichtigen.

Ein bestehender ISMS-Risikoprozess liefert dafür Methode, Rollen und Dokumentationslogik. Die Unternehmensrisikotabelle allein reicht aber nicht: Der CRA verlangt die Betrachtung des jeweiligen Produkts und seines vorgesehenen Einsatzes.

Sichere Entwicklung

Bei Sicherheitsanforderungen, Architektur, Codierung, Tests und Änderungen liegen die beiden Regelwerke nah beieinander. Wer die Entwicklungsmaßnahmen aus Anhang A tatsächlich lebt, hat für den CRA wesentlich mehr in der Hand als ein Unternehmen, das Sicherheit erst kurz vor der Freigabe entdeckt.

Schwachstellenmanagement

ISO 27001 A.8.8 verlangt den Umgang mit technischen Schwachstellen. Der CRA macht daraus zusätzlich eine Herstellerpflicht für konkrete Produkte und deren Komponenten. Hersteller müssen Schwachstellen identifizieren, dokumentieren, beheben und während des Unterstützungszeitraums Sicherheitsupdates bereitstellen.

Grundlagen dazu finden Sie in unseren Artikeln Schwachstellen managen und CWE, CVE und CVSS: Was ist der Unterschied?.

Lieferanten und Komponenten

Moderne Produkte bestehen selten vollständig aus selbst geschriebenem Code. Bibliotheken, Open-Source-Komponenten, Betriebssysteme, Chips und externe Entwicklungsleistungen gehören zur Lieferkette. ISO 27001 liefert Prozesse für Lieferantenbeziehungen und ausgelagerte Entwicklung. Der CRA verlangt zusätzlich produktbezogene Kenntnis über Komponenten und Schwachstellen.

Warum ein Vertrag allein noch keine sichere Lieferkette erzeugt, zeigt unser Artikel über sichere Lieferanten.

Vorfälle, Protokollierung und Reaktion

Ein funktionierendes ISMS sollte Sicherheitsereignisse erkennen, bewerten und behandeln können. Dazu braucht es passende Prozesse sowie Logging und Monitoring. Der CRA ergänzt diese internen Abläufe um produktspezifische Meldepflichten. Unser Beitrag zum Informationssicherheitsvorfall-Management erläutert die betriebliche Grundlage.

CRA und ISO 27001 im direkten Vergleich

Welche Produktanforderungen kennt ISO 27001 nicht?

Hier liegt der entscheidende Unterschied. ISO 27001 hilft dabei, einen Entwicklungsprozess zu organisieren. Der CRA verlangt darüber hinaus bestimmte Eigenschaften und Nachweise für das konkrete Produkt.

Nach Anhang I des CRA müssen Produkte abhängig vom Risiko unter anderem so entworfen, entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau bieten. Dazu gehören beispielsweise:

• Bereitstellung ohne bekannte ausnutzbare Schwachstellen;
• sichere Grundeinstellungen;
• Schutz vor unbefugtem Zugriff;
• angemessener Schutz von Vertraulichkeit, Integrität und Verfügbarkeit;
• Begrenzung von Datenverarbeitung und Angriffsflächen auf das notwendige Maß;
• Schutz wesentlicher Funktionen, auch bei Störungen;
• Verringerung der Auswirkungen von Sicherheitsvorfällen;
• geeignete Protokollierungs- und Überwachungsmöglichkeiten;
• sichere und rechtzeitige Updates.

Hinzu kommen Anforderungen an die Schwachstellenbehandlung. Hersteller müssen unter anderem Produktkomponenten und Schwachstellen dokumentieren, eine Software Bill of Materials (SBOM) in einem üblichen maschinenlesbaren Format erstellen, Schwachstellen prüfen und beheben sowie eine Regelung zur koordinierten Offenlegung von Schwachstellen vorhalten.

Das alles kann durch ein ISMS unterstützt werden. ISO 27001 fordert aber nicht allgemein für jedes Produkt eine CRA-konforme SBOM, einen festgelegten Unterstützungszeitraum oder eine EU-Konformitätserklärung.

Support endet nicht beim Verkauf

Der CRA verschiebt den Blick deutlich über den Tag der Markteinführung hinaus. Hersteller müssen festlegen, wie lange ein Produkt unterstützt wird, und während dieses Zeitraums Schwachstellen wirksam behandeln.

Der Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre. Wird das Produkt voraussichtlich weniger als fünf Jahre genutzt, kann er dieser kürzeren erwarteten Nutzungsdauer entsprechen. Ist eine längere Nutzung vernünftigerweise zu erwarten, kann auch ein längerer Zeitraum erforderlich sein.

Produktmanagement, Entwicklung und Geschäftsführung müssen sich deshalb festlegen: Wie lange wird das Produkt voraussichtlich genutzt? Welche Komponenten müssen ebenso lange unterstützt werden? Wie werden Sicherheitsupdates erzeugt, getestet, verteilt und kommuniziert?

ISO 27001 kann den Änderungs-, Lieferanten- und Schwachstellenprozess liefern. Die konkrete Supportzusage für das Produkt kommt aus dem CRA.

Welche Meldepflichten bringt der CRA?

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken.

Die CRA-Meldelogik der Europäischen Kommission sieht insbesondere vor:

• eine Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden;
• eine vollständige Meldung innerhalb von 72 Stunden;
• bei aktiv ausgenutzten Schwachstellen einen Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist;
• bei schwerwiegenden Vorfällen einen Abschlussbericht innerhalb eines Monats nach der vollständigen Meldung.

Gemeldet wird über die zentrale CRA Single Reporting Platform. Ein ISO 27001-Vorfallprozess kann Erkennung, Bewertung, Zuständigkeiten und Eskalation vorbereiten. Die gesetzlichen Kriterien, Empfänger, Inhalte und Fristen muss das Unternehmen trotzdem ausdrücklich ergänzen.

Wie wird die CRA-Konformität geprüft?

Vor der Markteinführung muss der Hersteller bewerten und dokumentieren, ob das Produkt und die eigenen Schwachstellenprozesse die wesentlichen CRA-Anforderungen erfüllen. Danach erstellt er die EU-Konformitätserklärung und bringt das CE-Zeichen an.

Wie stark eine unabhängige Stelle beteiligt werden muss, hängt von der Produktkategorie ab:

• Bei den meisten normalen Produkten ist eine interne Konformitätsbewertung durch den Hersteller zulässig.
• Bei wichtigen Produkten der Klasse I ist die Selbstbewertung nur unter bestimmten Voraussetzungen möglich, etwa bei vollständiger Anwendung geeigneter harmonisierter Standards. Anderenfalls ist eine notifizierte Stelle einzubeziehen.
• Bei wichtigen Produkten der Klasse II und kritischen Produkten ist grundsätzlich eine Bewertung durch eine notifizierte Stelle oder – soweit vorgesehen und anwendbar – ein europäisches Cybersicherheitszertifizierungssystem erforderlich.

Die Europäische Kommission erläutert die CRA-Konformitätsbewertung und die jeweiligen Produktkategorien ausführlicher.

Nach der Markteinführung endet die Kontrolle nicht. Marktüberwachungsbehörden können Unterlagen anfordern, Produkte prüfen und bei Nichtkonformität Korrekturen, Einschränkungen, Rücknahmen oder Rückrufe verlangen. Bei Verstößen sind außerdem erhebliche Bußgelder möglich.

Ein ISO 27001-Zertifizierungsauditor hat einen anderen Auftrag. Er prüft das Managementsystem im vereinbarten Geltungsbereich – nicht die gesetzliche Konformität und CE-Kennzeichnung sämtlicher Produkte.

Reicht ein ISO 27001-Zertifikat für den CRA aus?

Nein.

Ein passender Zertifikats-Geltungsbereich und umgesetzte Entwicklungsmaßnahmen können wertvolle Nachweise liefern. Das Zertifikat beantwortet aber nicht:

• ob das konkrete Produkt unter den CRA fällt und wie es klassifiziert ist;
• ob seine Produktanforderungen erfüllt sind;
• ob Produktrisikoanalyse, SBOM und technische Dokumentation vollständig sind;
• ob Unterstützungszeitraum und Meldeprozesse stimmen;
• ob Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung korrekt sind.

Das Zertifikat zeigt, dass der Hersteller ein geprüftes Managementsystem betreibt. Es ist kein CE-Zeichen und kein Produktzertifikat.

Ist der CRA eher mit Common Criteria vergleichbar?

In einer Hinsicht ja: Die Common Criteria beziehungsweise ISO/IEC 15408 betrachten die Sicherheit konkreter IT-Produkte. Sie liegen damit gedanklich näher am Produktfokus des CRA als eine reine Managementsystemzertifizierung.

Das europäische EUCC-Schema basiert auf den Common Criteria und ermöglicht die Zertifizierung von ICT-Produkten wie Hardware, Software und Komponenten. Dabei werden definierte Sicherheitsfunktions- und Vertrauenswürdigkeitsanforderungen bewertet. ENISA beschreibt das EUCC-Schema als produktbezogene Cybersicherheitszertifizierung.

Trotzdem sind Common Criteria, EUCC und CRA nicht dasselbe. Eine Common-Criteria- oder EUCC-Zertifizierung erfüllt nicht automatisch sämtliche Hersteller-, Dokumentations-, Melde-, Support- und Marktpflichten des CRA. Europäische Cybersicherheitszertifizierungssysteme können nur unter den im CRA und durch die Kommission festgelegten Voraussetzungen für die Konformitätsbewertung genutzt werden.

Zugespitzt lässt sich der Unterschied so zusammenfassen:

ISO 27001 fragt, ob der Hersteller Informationssicherheit systematisch beherrscht.

Common Criteria fragen, welche Sicherheitseigenschaften ein Produkt nachweisbar besitzt.

Der CRA verlangt, dass der Hersteller ein gesetzeskonformes Produkt auf den europäischen Markt bringt und es anschließend sicher betreut.

So nutzen Sie Ihr ISMS für die CRA-Umsetzung

Ein zertifiziertes Unternehmen sollte für den CRA keine zweite Sicherheitsorganisation neben dem ISMS aufbauen. Sinnvoller ist eine produktspezifische Erweiterung:

1. Produkte und Rollen erfassen

Klären Sie, welche Produkte, Komponenten und Remote-Datenverarbeitungen erfasst sind und ob Sie Hersteller, Importeur oder Händler sind.

2. Produkte klassifizieren

Prüfen Sie, ob es sich um ein normales, wichtiges oder kritisches Produkt handelt und welches Konformitätsbewertungsverfahren daraus folgt.

3. ISMS-Prozesse zuordnen

Nutzen Sie vorhandene Prozesse für Entwicklung, Risiken, Schwachstellen, Vorfälle, Lieferanten, Änderungen und Dokumentenlenkung.

4. Produktlücken bestimmen

Ergänzen Sie Produktrisikoanalyse, wesentliche Produkteigenschaften, SBOM, technische Dokumentation, Unterstützungszeitraum, Meldelogik und Konformitätsunterlagen.

5. Nachweise je Produkt aufbauen

Ein ISMS-Prozess kann für viele Produkte gemeinsam gelten. Risikobewertung, Testergebnisse, Komponentenübersicht und Konformität müssen trotzdem für das konkrete Produkt nachvollziehbar sein.

6. Nicht bis 2027 warten

Produkte, die Ende 2027 auf den Markt kommen sollen, werden heute entwickelt. Wer erst kurz vor der Markteinführung über Architektur, Komponenten, Updatefähigkeit und Nachweisdokumentation nachdenkt, wird einen erheblichen Teil der Entwicklung rückwärts dokumentieren oder nacharbeiten müssen.

Interesse geweckt?

Sie entwickeln Hardware oder Software und möchten wissen, wie viel Ihrer CRA-Vorbereitung bereits im ISMS steckt? Oder Sie wollen Ihre ISO 27001-Prozesse so erweitern, dass daraus belastbare Produktnachweise entstehen?

Dann sprechen Sie mit uns. Wir helfen Ihnen dabei, die Schnittmenge sinnvoll zu nutzen, Produktlücken sichtbar zu machen und Informationssicherheitsmanagement und Produktsicherheit nicht in zwei widersprüchlichen Welten zu organisieren.

Sie möchten das Thema in Ihrem Unternehmen sauber und pragmatisch angehen? Sprechen Sie mit uns.