Ein mittelständischer Anbieter industrieller Steuerungssoftware verkauft seine Produkte EU-weit, hat aber kein produktbezogenes Schwachstellenmanagement, kein SBOM und keinen dokumentierten Update-Prozess über die Lebensdauer hinweg. Ab Dezember 2027 reicht das nicht mehr für die CE-Kennzeichnung — und ohne CE-Kennzeichnung darf das Produkt im EU-Binnenmarkt nicht verkauft werden. Die Vorbereitungszeit für ein vollständiges Produktsicherheits-Programm beträgt für die meisten Hersteller mindestens 18 Monate.
Der Cyber Resilience Act ist die erste horizontale EU-Verordnung, die Cybersicherheitsanforderungen an Produkte mit digitalen Elementen stellt. Sie verlagert die Verantwortung von der Endkundin auf den Hersteller und macht Cybersicherheit zur CE-relevanten Produkteigenschaft — vergleichbar mit elektrischer Sicherheit oder elektromagnetischer Verträglichkeit.
Wer ist betroffen?
Praktisch jeder, der Hardware mit Netzwerkfähigkeit oder Software in der EU vertreibt. Der CRA folgt dem klassischen Produktrecht-Modell mit klar abgegrenzten Wirtschaftsakteuren:
- Hersteller — tragen die volle Konformitätsverantwortung. Auch wer nur sein Logo auf ein OEM-Produkt klebt, gilt als Hersteller.
- Bevollmächtigte — von Drittstaaten-Herstellern benannte Vertreter in der EU.
- Importeure — bringen Produkte aus Drittstaaten in den EU-Markt und müssen prüfen, ob die Konformitätsbewertung vorliegt.
- Händler — müssen die Sorgfaltspflicht walten lassen und nicht-konforme Produkte aus dem Verkehr nehmen.
Drei Risikoklassen bestimmen die Konformitätsbewertung:
- Standardprodukte (~90 % aller Produkte) — Selbstbewertung durch den Hersteller.
- Wichtige Produkte Klasse I — z. B. Identitätsmanagement-Systeme, Browser, VPN-Software, Netzwerkmanagement-Tools — Selbstbewertung mit verschärften Anforderungen oder Drittstellenbewertung.
- Wichtige Produkte Klasse II — z. B. Hypervisoren, Firewalls, Tamper-Resistant-Microprocessors — verpflichtende Drittstellenbewertung.
- Kritische Produkte — z. B. Hardware Security Modules, Smart-Meter-Gateways, Smartcards — Pflicht zur europäischen Cybersicherheitszertifizierung.
Was verlangt das Gesetz?
Der CRA stellt Anforderungen an das Produkt selbst und an die Prozesse über den gesamten Lebenszyklus. Die wesentlichen Punkte:
- Sicherheit by Design (Anhang I, Teil I) — Produkte werden ohne bekannte ausnutzbare Schwachstellen ausgeliefert, mit sicheren Standardkonfigurationen, Mechanismen zur Authentifizierung, Vertraulichkeit und Integrität, sowie Protokollierung sicherheitsrelevanter Ereignisse.
- Schwachstellenbehandlung (Anhang I, Teil II) — koordinierter Offenlegungsprozess (CVD), Pflicht zu kostenlosen Sicherheitsupdates über die erwartete Produktlebensdauer (mindestens fünf Jahre, häufig länger), SBOM in maschinenlesbarem Format.
- Konformitätsbewertung (Art. 32) — je nach Risikoklasse Selbstbewertung oder Beteiligung einer benannten Stelle. Ergebnis: EU-Konformitätserklärung und CE-Kennzeichnung.
- Technische Dokumentation (Anhang VII) — Risikoanalyse, Architektur, eingesetzte Komponenten, Testberichte, Schwachstellenmanagement-Prozess. Aufbewahrung mindestens zehn Jahre.
- Meldepflichten (Art. 14) — aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden (Frühwarnung), 72 Stunden (Vorfallsmeldung) und einem Monat (Abschlussbericht) an ENISA und die zuständige nationale CSIRT.
- Kennzeichnungspflichten — CE-Kennzeichnung, Benutzerinformationen mit Sicherheitshinweisen, klare Kommunikation der unterstützten Sicherheitsupdate-Periode am Verkaufsort.
In der Praxis
SBOM-Pflicht ernst nehmen — auch für Eigenentwicklungen. Ohne maschinenlesbares Software-Stückverzeichnis lässt sich keine sinnvolle Schwachstellenbewertung führen. CycloneDX und SPDX sind die etablierten Formate. Wer mit einem Produkt im Markt ist, braucht das SBOM als laufend gepflegtes Artefakt, nicht als einmalige Anlage zur Konformitätsbewertung.
Coordinated Vulnerability Disclosure (CVD) operationalisieren. Eine security.txt auf der Website, ein klarer Eingangskanal (z. B. PGP-verschlüsseltes Postfach), definierte Reaktionszeiten und ein interner Eskalationspfad sind die Mindestausstattung. Wer Schwachstellenmeldungen ignoriert oder klagt, verstößt gegen den CRA-Geist und riskiert Reputationsschaden.
Update-Pflicht in die Produktkalkulation einrechnen. Sicherheitsupdates über fünf bis zehn Jahre kosten Geld — Backports, Test, Verteilung, Kundeninformation. Wer das nicht in die Total Cost of Ownership einrechnet, gerät in eine wirtschaftliche Klemme, sobald die Produkte im Feld sind.
Mapping zu ISO 27001
Der CRA ergänzt das ISMS um eine produktbezogene Sicht. Viele ISO-27001-Kontrollen lassen sich direkt auf den CRA-Lebenszyklus mappen, vor allem im Bereich sichere Entwicklung und Schwachstellenmanagement.
Direkt relevante Kontrollen:
- A.5.7 — Bedrohungsinformationen: Grundlage für die Schwachstellenbewertung im Produkt.
- A.5.8 — Informationssicherheit im Projektmanagement: Sicherheitsanforderungen ab Projektbeginn.
- A.5.21 — Verwaltung der Informationssicherheit in der IKT-Lieferkette: Voraussetzung für ein belastbares SBOM.
- A.5.24 — Planung der Informationssicherheitsvorfallreaktion: Voraussetzung für die 24-Stunden-Meldung.
- A.5.37 — Dokumentierte Betriebsabläufe: Update- und Patch-Prozesse über den Lebenszyklus.
- A.6.3 — Informationssicherheitsbewusstsein: sichere Entwicklungspraktiken im Team.
- A.8.8 — Handhabung technischer Schwachstellen: Kerndisziplin für CRA-Compliance.
- A.8.9 — Konfigurationsmanagement: sichere Standardkonfiguration als CRA-Pflicht.
- A.8.25 — Sicherer Entwicklungslebenszyklus: Brückenpunkt zu Anhang I Teil I CRA.
- A.8.26 — Sicherheitsanforderungen für Anwendungen: funktionale und nicht-funktionale Sicherheitsanforderungen.
- A.8.27 — Sichere Systemarchitektur und Engineering-Prinzipien: Security-by-Design-Nachweis.
- A.8.28 — Sichere Programmierung: Code-Qualität als Voraussetzung schwachstellenarmer Produkte.
- A.8.29 — Sicherheitstests in Entwicklung und Abnahme: Pflichtbestandteil der Konformitätsbewertung.
- A.8.30 — Outgesourcte Entwicklung: Verantwortung bleibt beim Hersteller, auch bei externer Entwicklung.
Typische Audit-Befunde
- Kein gepflegtes SBOM — entweder gar nicht vorhanden oder einmalig erstellt und seither nicht aktualisiert. Dependency-Updates sind nicht nachvollziehbar.
- Update-Periode nicht kommuniziert — am Verkaufsort und in der Dokumentation fehlt die Aussage zur unterstützten Sicherheitsupdate-Dauer.
- Schwachstellenmeldungen ohne Prozess — Mails an
info@werden nicht bearbeitet, kein zentraler Eingangskanal, keine Triage. - Konformitätsbewertung wurde gemacht, aber nie aktualisiert — bei größeren Produktänderungen muss neu bewertet werden, das wird häufig übersehen.
- Lieferkettentransparenz fehlt — Open-Source-Komponenten und Drittanbieter-Bibliotheken sind nicht inventarisiert, kritische Schwachstellen werden zu spät erkannt.
- Risikoklasse falsch eingeschätzt — Selbstbewertung obwohl das Produkt eigentlich in Klasse I oder II fällt; bei Kontrolle führt das direkt zur Vertriebsuntersagung.
Quellen
- Verordnung (EU) 2024/2847 (EUR-Lex) — amtliche EU-Fassung in allen Sprachen
- CRA-Seite der Europäischen Kommission — FAQ, Leitfäden und Implementierungsplan
- ENISA-Materialien zum CRA — technische Standards und Leitlinien
- BSI-Informationen zum CRA — nationale Umsetzung und Marktüberwachung
- CycloneDX und SPDX — etablierte SBOM-Formate