Cyber Resilience Act Artikel 13 und 14: Warum ein ISMS für Produkte mit digitalen Elementen nicht ausreicht

Der Cyber Resilience Act verpflichtet Hersteller von Hard- und Software zu Security by Design, kontinuierlichem Schwachstellenmanagement und Meldepflichten bei aktiv ausgenutzten Sicherheitslücken. Was viele Unternehmen unterschätzen: Diese Pflichten erstrecken sich über den gesamten Produktlebenszyklus — und erfordern Nachweise, die ein ISMS allein nicht liefert.

Ein ISMS strukturiert die interne Governance. Der CRA fordert darüber hinaus produktbezogene Cybersicherheitsanforderungen ab dem Design, Meldung aktiv ausgenutzter Schwachstellen innerhalb von 24 Stunden (Artikel 14), Software-Stücklisten (SBOM), CE-Kennzeichnung und fortlaufende Sicherheitsupdates während des gesamten Support-Zeitraums (Artikel 13).

Sprungmarken:

Artikel 14: Meldepflichten für Hersteller
Artikel 13: Pflichten der Hersteller
Lieferkette: Pflichten für Importeure und Händler

Warum ein ISMS seit dem Cyber Resilience Act nicht mehr ausreicht

Die Verordnung (EU) 2024/2847 — der Cyber Resilience Act (CRA) — trat am 10. Dezember 2024 in Kraft und wird ab dem 11. Dezember 2027 vollständig anwendbar. Die Meldepflichten nach Artikel 14 gelten bereits ab dem 11. September 2026.

Der CRA ist die erste EU-weite Verordnung, die verbindliche Mindestanforderungen an die Cybersicherheit von Produkten mit digitalen Elementen festlegt — unabhängig davon, ob es sich um günstige Consumer-Produkte oder hochwertige B2B-Software handelt.

Der entscheidende Unterschied zu NIS2, DORA oder der DSGVO: Der CRA ist produktzentriert, nicht organisationszentriert. Während ein ISMS die Sicherheit einer Organisation strukturiert, verlangt der CRA Sicherheit auf Produktebene — vom Design über die Entwicklung bis zur gesamten Lebensdauer des Produkts.

Wo ein ISMS zum CRA beiträgt — Organisatorische Grundlage

Ein gutes ISMS liefert die strukturelle Basis für viele CRA-Anforderungen:

Risikomanagement-Prozesse für die Bewertung von Cybersicherheitsrisiken
Dokumentierte Prozesse für Schwachstellenmanagement
Incident-Response-Verfahren als Grundlage für die Meldepflichten
Konfigurationsmanagement und Change-Control-Prozesse

Anhang I des CRA verlangt, dass Produkte „so konzipiert, entwickelt und hergestellt werden, dass sie unter Berücksichtigung der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten". Das klingt nach ISMS — und ein ISMS kann hier tatsächlich als Grundlage dienen.

Doch der CRA geht an entscheidenden Stellen weiter: Er verlangt produktspezifische Nachweise, Meldepflichten mit sehr kurzen Fristen und eine CE-Kennzeichnung, die die Konformität mit den Cybersicherheitsanforderungen bestätigt.

Wo der CRA über ein ISMS hinausgeht

Artikel 14: Meldepflichten für Hersteller

Der CRA führt ein dreistufiges Melderegime für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle ein.

Frühwarnung (24 Stunden)

Der Hersteller muss jede ihm bekannt gewordene aktiv ausgenutzte Schwachstelle unverzüglich und jedenfalls binnen 24 Stunden dem zuständigen CSIRT und der ENISA melden.

Die Meldung erfolgt über die von ENISA betriebene Single Reporting Platform (SRP) an das CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat.

Inhalt der Frühwarnung nach Artikel 14 Abs. 2 lit. a:

Element	Beschreibung
Zeitpunkt	Unverzüglich, jedenfalls binnen 24 Stunden nach Kenntnisnahme
Betroffene Mitgliedstaaten	Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde
Art der Schwachstelle	Erste Einordnung der Sicherheitslücke

Vollständige Meldung (72 Stunden)

Binnen 72 Stunden nach Kenntnisnahme muss eine vollständige Schwachstellenmeldung erfolgen, sofern die Informationen nicht bereits in der Frühwarnung enthalten waren.

Inhalt der vollständigen Meldung nach Artikel 14 Abs. 2 lit. b:

Element	Beschreibung
Allgemeine Informationen	Art der Schwachstelle und betroffene Produkte
Technische Details	Beschreibung der Schwachstelle und ihrer Auswirkungen
Schweregrad	Einschätzung der Kritikalität
Ergriffene Maßnahmen	Bereits umgesetzte Gegenmaßnahmen
Empfehlungen für Nutzer	Mögliche Maßnahmen zur Risikominderung

Abschlussbericht

Situation	Frist
Aktiv ausgenutzte Schwachstelle	Spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme
Schwerwiegender Sicherheitsvorfall	Spätestens 1 Monat nach der 72-Stunden-Meldung

Der Abschlussbericht muss eine Ursachenanalyse, ergriffene Korrekturmaßnahmen und präventive Maßnahmen enthalten.

Information der Nutzer

Nach Artikel 14 Abs. 8 muss der Hersteller nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls die betroffenen Nutzer informieren — über die Schwachstelle, den Vorfall und gegebenenfalls über Maßnahmen zur Risikominderung.

Falls der Hersteller die Nutzer nicht rechtzeitig informiert, kann das zuständige CSIRT diese Information selbst veröffentlichen.

Artikel 13: Pflichten der Hersteller

Der CRA etabliert umfassende Pflichten für Hersteller über den gesamten Produktlebenszyklus.

Security by Design und Default (Artikel 13 Abs. 1)

Hersteller müssen sicherstellen, dass Produkte mit digitalen Elementen in Übereinstimmung mit den wesentlichen Cybersicherheitsanforderungen aus Anhang I Teil I konzipiert, entwickelt und hergestellt werden:

Anforderung	Beschreibung
Angemessenes Schutzniveau	Produkte müssen ein dem Risiko angemessenes Cybersicherheitsniveau gewährleisten
Keine bekannten Schwachstellen	Produkte dürfen nicht mit bekannten ausnutzbaren Schwachstellen ausgeliefert werden
Sichere Standardkonfiguration	Produkte müssen mit sicheren Standardeinstellungen bereitgestellt werden
Schutz vor unbefugtem Zugriff	Authentifizierung, Identitäts- und Zugriffskontrollmechanismen
Schutz der Vertraulichkeit	Verschlüsselung ruhender und übertragener Daten
Schutz der Integrität	Schutz vor unbefugter Manipulation von Daten und Funktionen
Schutz der Verfügbarkeit	Widerstandsfähigkeit gegen Denial-of-Service-Angriffe
Minimierung der Angriffsfläche	Reduktion externer Schnittstellen auf das Notwendige

Software Bill of Materials (SBOM)

Anhang I Teil II verlangt, dass Hersteller Schwachstellen und Komponenten ihrer Produkte identifizieren und dokumentieren — einschließlich einer Software-Stückliste (SBOM) in einem gebräuchlichen und maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten abdeckt.

Der SBOM muss nicht veröffentlicht werden, muss aber den Marktüberwachungsbehörden auf Anfrage bereitgestellt werden können.

Warum SBOM-Pflichten faktisch ab September 2026 gelten:

Die SBOM-Anforderung wird formal erst am 11. Dezember 2027 durchsetzbar. Doch die Meldepflichten gelten bereits ab dem 11. September 2026. Ohne SBOM und Schwachstellen-Monitoring kann ein Hersteller nicht wissen, ob eine neu bekannt gewordene Schwachstelle sein Produkt betrifft — und die 24-Stunden-Frist verstreicht.

Support-Zeitraum und Sicherheitsupdates (Artikel 13 Abs. 8)

Hersteller müssen einen Support-Zeitraum festlegen, während dessen sie Sicherheitsupdates bereitstellen. Dieser Zeitraum muss:

Mindestens 5 Jahre betragen (oder kürzer, wenn die erwartete Nutzungsdauer kürzer ist)
Den Nutzern vor dem Kauf mitgeteilt werden
Kostenlose Sicherheitsupdates umfassen

Technische Dokumentation (Artikel 13 und Anhang VII)

Hersteller müssen eine technische Dokumentation erstellen und 10 Jahre nach Inverkehrbringen oder während des Support-Zeitraums (je nachdem, welcher Zeitraum länger ist) aufbewahren:

Dokument	Beschreibung
Produktbeschreibung	Konzeption, Design und Entwicklung
Cybersicherheits-Risikobewertung	Bewertung der Risiken nach Artikel 13 Abs. 2
SBOM	Software-Stückliste der Komponenten
Konformitätsbewertung	Nachweis der Einhaltung der Anforderungen
EU-Konformitätserklärung	Erklärung des Herstellers

Warum die Sorgfaltspflicht kein One-Off ist

Sorgfaltspflicht bei Komponenten Dritter (Artikel 13 Abs. 5)

Hersteller müssen bei der Integration von Komponenten Dritter — einschließlich Open-Source-Software — Due Diligence ausüben, um sicherzustellen, dass diese Komponenten die Cybersicherheit des Produkts nicht gefährden.

Meldung von Schwachstellen in Komponenten (Artikel 13 Abs. 6)

Wenn ein Hersteller eine Schwachstelle in einer Komponente identifiziert, muss er diese dem Hersteller oder Maintainer der Komponente melden und die Schwachstelle gemäß den Anforderungen beheben.

Wesentliche Änderungen (Artikel 3 Nr. 31)

Eine wesentliche Änderung ist jede Änderung eines Produkts nach Inverkehrbringen, die:

Die Konformität mit den Cybersicherheitsanforderungen beeinflussen kann, oder
Eine Änderung des Verwendungszwecks darstellt

Bei einer wesentlichen Änderung wird der Ändernde zum Hersteller für das betroffene Produkt oder den betroffenen Teil — mit allen Pflichten aus Artikel 13 und 14.

Lieferkette: Pflichten für Importeure und Händler

Der CRA etabliert eine Kette der Verantwortlichkeit entlang der gesamten Lieferkette.

Pflichten der Importeure (Artikel 19)

Importeure dürfen nur Produkte in Verkehr bringen, die den Cybersicherheitsanforderungen entsprechen. Vor dem Inverkehrbringen müssen sie sicherstellen:

Prüfpflicht	Beschreibung
Konformitätsbewertung	Der Hersteller hat die erforderlichen Verfahren durchgeführt
Technische Dokumentation	Der Hersteller hat die Dokumentation erstellt
CE-Kennzeichnung	Das Produkt trägt die CE-Kennzeichnung
EU-Konformitätserklärung	Dem Produkt liegt die Erklärung bei
Benutzerinformationen	Informationen und Anleitungen liegen in verständlicher Sprache bei

Importeure müssen die EU-Konformitätserklärung und technische Dokumentation 10 Jahre aufbewahren und auf Anfrage den Marktüberwachungsbehörden vorlegen.

Pflichten der Händler (Artikel 20)

Händler müssen vor der Bereitstellung auf dem Markt überprüfen:

Das Produkt trägt die CE-Kennzeichnung
Hersteller und Importeur haben ihre Pflichten erfüllt
Alle erforderlichen Dokumente liegen vor

Wird ein Importeur oder Händler selbst zum Hersteller (durch Vermarktung unter eigenem Namen oder wesentliche Änderung), treffen ihn alle Pflichten aus Artikel 13 und 14.

Meldung von Schwachstellen durch Importeure und Händler

Importeure und Händler, die Kenntnis von einer Schwachstelle erlangen, müssen den Hersteller unverzüglich informieren. Bei Hinweisen auf Nicht-Konformität dürfen sie das Produkt nicht (weiter) auf dem Markt bereitstellen.

Sanktionen (Artikel 64)

Der CRA sieht ein dreistufiges Bußgeldsystem vor:

Verstoß	Bußgeld	Rechtsgrundlage
Wesentliche Cybersicherheitsanforderungen (Anhang I) und Herstellerpflichten (Art. 13, 14)	Bis 15 Mio. Euro oder 2,5% Jahresumsatz	Art. 64 Abs. 2
Sonstige Pflichten (Art. 18–23, 28, 30–33, 39, 41, 47, 49, 53)	Bis 10 Mio. Euro oder 2% Jahresumsatz	Art. 64 Abs. 3
Falsche oder unvollständige Angaben gegenüber Behörden	Bis 5 Mio. Euro oder 1% Jahresumsatz	Art. 64 Abs. 4

Maßgeblich ist jeweils der höhere Betrag.

Ausnahmen:

Kleinstunternehmen und kleine Unternehmen sind von Bußgeldern für die Nichteinhaltung der 24-Stunden-Frist nach Artikel 14 ausgenommen
Open-Source-Software-Stewards sind von sämtlichen Bußgeldern nach dem CRA ausgenommen

Zusätzliche Maßnahmen der Marktüberwachungsbehörden:

Neben Bußgeldern können Behörden Produkte vom Markt nehmen, Rückrufe anordnen oder das Inverkehrbringen untersagen — EU-weit.

ISMS und Trust Center: Zwei Perspektiven auf die Compliance

Der CRA schafft eine neue Dimension der Produkthaftung für Cybersicherheit. Ein ISMS bleibt unverzichtbar für die organisatorische Steuerung — aber die produktbezogenen Anforderungen des CRA erfordern zusätzliche Strukturen.

Die zwei Richtungen eines Trust Centers

Als Hersteller / Verkäufer (Outbound):

Wer Produkte mit digitalen Elementen in der EU verkauft, muss Kunden und Behörden umfangreiche Nachweise bereitstellen. Ein Trust Center bündelt diese Dokumentation an einem professionellen Ort:

Dokument	Zweck	CRA-Bezug
EU-Konformitätserklärung	Nachweis der Einhaltung der Anforderungen	Art. 13 Abs. 20
CE-Kennzeichnung	Konformitätskennzeichnung	Art. 30
SBOM (auf Anfrage)	Transparenz über Komponenten	Anhang I Teil II
Technische Dokumentation	Nachweis der Konformität	Anhang VII
Support-Zeitraum und Update-Policy	Information für Nutzer	Art. 13 Abs. 8
Vulnerability Disclosure Policy	Prozess für Schwachstellenmeldungen	Anhang I Teil II
Zertifizierungen (ISO 27001, IEC 62443)	Unterstützender Nachweis	Art. 27
Penetrationstest-Berichte	Unabhängige Prüfung	Anhang I Teil II

Als Käufer / Integrator (Inbound):

Wer Produkte mit digitalen Elementen in eigene Produkte integriert, wird nach Artikel 13 Abs. 5 zur Due Diligence verpflichtet. Ein Trust Center unterstützt:

Sammlung und Pflege von Herstellernachweisen und SBOMs
Überwachung von Sicherheitsupdates und bekannten Schwachstellen
Dokumentation der Sorgfaltspflicht bei der Komponentenauswahl
Nachweis der Lieferketten-Compliance für eigene Kunden

Die doppelte Perspektive

Viele B2B-Unternehmen sind gleichzeitig Käufer (integrieren Komponenten Dritter) und Hersteller (verkaufen eigene Produkte). Ein Trust Center adressiert beide Rollen:

Inbound: Nachweis der Due Diligence bei der Integration von Drittkomponenten
Outbound: Bereitstellung aller erforderlichen Nachweise für eigene Kunden und Behörden

Ohne ein Trust Center läuft diese Dokumentation über E-Mail, individuelle Anfragen und manuelle Prozesse — unvereinbar mit den kurzen Fristen des CRA und der Komplexität moderner Software-Lieferketten. Mit einem Trust Center wird aus reaktiver Dokumentensuche ein funktionierendes System.

Der kritische Zeitplan

Datum	Pflicht
10. Dezember 2024	CRA in Kraft getreten
11. Juni 2026	Benannte Stellen (Notified Bodies) für Konformitätsbewertung zugelassen
11. September 2026	Meldepflichten nach Artikel 14 gelten — auch für bereits auf dem Markt befindliche Produkte
11. Dezember 2027	Vollständige Anwendung aller CRA-Anforderungen

Die Meldepflichten ab September 2026 sind der kritische Meilenstein: Wer bis dahin kein SBOM-basiertes Schwachstellen-Monitoring und keine Incident-Response-Prozesse implementiert hat, kann die 24-Stunden-Frist nicht einhalten.

Wer Governance und Kommunikation verbindet, ist gut aufgestellt: Ein ISMS für die interne Steuerung, ein Trust Center für die externe Kommunikation — in beide Richtungen der Lieferkette. So wird aus Compliance-Aufwand ein funktionierendes System und aus Dokumentation echte Cyber-Resilienz.

Quellen

Verordnung (EU) 2024/2847 (Cyber Resilience Act) – Volltext – Amtsblatt der Europäischen Union. Der vollständige Text des Cyber Resilience Act.
European Commission – Cyber Resilience Act Summary – Zusammenfassung der wichtigsten Bestimmungen.
European Commission – CRA Reporting Obligations – Details zu den Meldepflichten und der Single Reporting Platform.
BSI – Cyber Resilience Act – Informationen und Leitfäden des BSI.
european-cyber-resilience-act.com – Article 13 – Pflichten der Hersteller.
european-cyber-resilience-act.com – Article 14 – Meldepflichten.
european-cyber-resilience-act.com – Article 64 – Sanktionen.
ENISA – CRA Requirements Standards Mapping – Zuordnung der CRA-Anforderungen zu bestehenden Standards.

Cyber Resilience Act Artikel 13 und 14: Warum ein ISMS nicht ausreicht