Mit dem Cyber Resilience Act (Verordnung (EU) 2024/2847) vollzieht die Europäische Union einen Paradigmenwechsel für alle Produkte mit digitalen Elementen: Erstmals haften Hersteller, Softwarehäuser und Betreiber vernetzter B2B-Systeme für grundlegende Cybersicherheit über den gesamten Lebenszyklus. Wer kommerzielle Software, SaaS-Konnektoren, IoT-Lösungen oder mobile Apps im EU-Binnenmarkt anbietet, muss verpflichtende Software-Stücklisten (SBOM), automatisierte Schwachstellenanalysen und strikte 24-Stunden-Meldepflichten an das BSI und die ENISA nachweisen — inklusive CE-Kennzeichnung. Dieser Leitfaden liefert IT-Leitern, CTOs und Entwicklungsteams im Mittelstand einen praxiserprobten Fahrplan zur Compliance vor Ablauf der Übergangsfristen.
Dieser Artikel ist ein vertiefender Fachbeitrag aus unserem Content-Cluster. Entdecken Sie die vollständige Übersicht auf unserer Hauptseite: IT-Sicherheit & Compliance →
- Produkthaftung & CE-Kennzeichnung: Hersteller und Entwickler vernetzter Software haften künftig für grundlegende Cybersicherheit über den gesamten Lebenszyklus (in der Regel mindestens 5 Jahre) und müssen eine formelle CE-Kennzeichnung nachweisen.
- Maschinenlesbare SBOM-Pflicht: Jedes Release erfordert eine automatisierte Software-Stückliste (CycloneDX oder SPDX) in der CI/CD-Pipeline zur lückenlosen Transparenz aller Open-Source- und Drittanbieter-Abhängigkeiten.
- 24-Stunden-Frühwarnsystem: Aktiv ausgenutzte Sicherheitslücken müssen ab Juni 2026 innerhalb von 24 Stunden verbindlich an das BSI und die ENISA gemeldet werden — bei Zuwiderhandlung drohen empfindliche Bußgelder von bis zu 15 Millionen Euro.
Die europäische Gesetzgebung im Bereich digitaler Technologien hat in den vergangenen Jahren rasant an Verbindlichkeit gewonnen. Während die DSGVO den Schutz personenbezogener Daten reguliert, der EU AI Act vertrauenswürdige künstliche Intelligenz einfordert und die NIS-2-Richtlinie die Widerstandsfähigkeit kritischer und wichtiger Betreiber festschreibt, schließt der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) die gravierendste regulatorische Lücke: die Haftungs- und Sicherheitsstandards der eigentlichen Software- und Hardwareprodukte selbst.
Bislang konnten Software-Entwickler und Hardware-Hersteller ihre Produkte weitgehend nach dem Prinzip „Ship first, patch later“ auf den Markt bringen. Vertragliche Haftungsausschlüsse und allgemeine Geschäftsbedingungen (AGB) federten das Risiko für Sicherheitslücken in Open-Source-Bibliotheken oder veralteten Frameworks weitgehend ab. Mit dem CRA ist dieses Zeitalter unwiderruflich beendet: Wer Produkte mit digitalen Elementen gewerblich im europäischen Wirtschaftsraum in Verkehr bringt, muss ab sofort nachweisen, dass das Produkt bereits ab Werk sicher konzipiert ist (Security by Design), frei von bekannten Schwachstellen ausgeliefert wird und über den gesamten Lebenszyklus mit kostenlosen Sicherheitsupdates versorgt wird.
Für den deutschen Mittelstand — vom spezialisierten Maschinenbauer mit vernetzter Steuerung über den SaaS-Anbieter für Logistik bis hin zum Web- und App-Entwicklungsdienstleister — bedeutet das CRA-Regelwerk eine tiefgreifende Umstellung des gesamten Software-Lebenszyklus (SDLC).
CRA im Überblick: Wesentliche Rahmendaten
- Gesetzesstatus: Verordnung (EU) 2024/2847, am 20. November 2024 im EU-Amtsblatt veröffentlicht, in Kraft getreten am 10. Dezember 2024.
- Geltungsbereich: Alle direkt oder indirekt vernetzten Hard- und Softwareprodukte (Produkte mit digitalen Elementen), die im EU-Binnenmarkt bereitgestellt werden.
- Meldepflichten: Greifen bereits ab dem 11. Juni 2026 (24h-Frist für aktiv ausgenutzte Schwachstellen an BSI und ENISA).
- Vollständige Produktanforderungen & CE-Kennzeichnung: Verbindlich ab dem 11. Dezember 2027.
- Strafrahmen: Bußgelder bis zu 15.000.000 € oder 2,5 % des weltweiten Jahresumsatzes, Untersagung des Vertriebs und Produktrückrufe.
1. Geltungsbereich: Wer fällt unter den Cyber Resilience Act?
Der Anwendungsbereich des CRA ist bewusst horizontal und technologieunabhängig formuliert. Artikel 2 definiert die Zielgruppe als alle „Produkte mit digitalen Elementen“ (PDE), deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.
Reine Softwareprodukte
Betriebssysteme, Desktop-Applikationen, B2B-Fachsoftware, Mobile Apps, Middleware, ERP-Konnektoren, Datenbanken und kommerzielle SaaS-On-Premise-Bundles.
Vernetzte Hardware (IoT & OT)
Smarte Sensoren, industrielle Steuerungen (SPS/PLC), Edge-Gateways, Robotikkomponenten, Router, Netzwerkkameras und vernetzte medizinische Peripheriegeräte.
Softwarekomponenten & Bibliotheken
Kommerziell vertriebene SDKs, Frameworks, Integrationsmodule und APIs, die für den Einbau in Drittprodukte bestimmt sind.
Open Source (Abgrenzung)
Reine gemeinnützige Open-Source-Projekte ohne kommerzielle Gegenleistung sind ausgenommen. Sobald Open Source jedoch monetarisiert oder in kommerzielle Produkte integriert wird, haftet der Inverkehrbringer.
Die Risikoklassen des CRA: Standard, Wichtig und Kritisch
Der CRA unterteilt digitale Produkte in vier Sicherheitsstufen, aus denen sich das konkrete Konformitätsbewertungsverfahren ableitet:
Reguläre B2B- & Consumer-Software
- Standard-B2B-Webanwendungen, CMS-Plattformen & ERP-Plugins
- Bildbearbeitungssoftware, CRM-Module & mobile Business-Apps
- Keine systemkritischen Sicherheitsfunktionen im OS oder Netzwerk
Wichtige Sicherheitsprodukte
- Identitäts- und Zugriffsmanagement (IAM) & Passwortmanager
- Antiviren- und Endpoint-Detection-and-Response (EDR)-Software
- VPN-Router, Netzwerkschnittstellen & physische Controller
Kritische System-Infrastruktur
- Firewalls, Intrusion-Detection- & Prevention-Systeme (IDS/IPS)
- Hypervisoren, Container-Laufzeitumgebungen & OS-Kernel
- Smart-Meter-Gateways & industrielle SPS-Steuerungen (OT/KRITIS)
Höchste Sicherheitsrelevanz
- Hardware-Sicherheitsmodule (HSM) & Smart-Cards
- Biometrische Lesegeräte & hardwarebasierte Krypto-Tokens
- Hochsicherheits-Gateways für Betreiber kritischer Infrastrukturen
Das Sanktions- und Bußgeldregime des CRA
Verstöße gegen den Cyber Resilience Act werden von den nationalen Marktaufsichtsbehörden mit drastischen Sanktionen geahndet:
Wesentliche Pflichtverletzungen (Art. 13/14)
Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen, fehlerhafte Konformitätsbewertung oder Inverkehrbringen ohne CE-Kennzeichnung:
bis zu 15.000.000 €oder bis zu 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres.
Meldepflichtverletzungen (Art. 14)
Versäumnis oder Verzögerung der verpflichtenden 24-Stunden-Frühwarnung aktiv ausgenutzter Schwachstellen an CSIRT und ENISA:
bis zu 10.000.000 €oder bis zu 2,0 % des weltweiten Jahresumsatzes.
2. Die 6 Kernpflichten für Software-Hersteller und Entwickler
Um ein digitales Produkt rechtskonform mit dem CE-Kennzeichen zu versehen und im EU-Binnenmarkt vertreiben zu dürfen, müssen Hersteller sechs wesentliche Pflichtenfelder nachweisbar implementieren:
Security by Design & by Default
Sicherheit muss integraler Bestandteil der Konzeptions- und Architekturphase sein. Systeme müssen standardmäßig in der sichersten Konfiguration ausgeliefert werden (keine Standard-Passwörter, unnötige Ports geschlossen, Verschlüsselung im Ruhezustand und bei der Übertragung).
Software Bill of Materials (SBOM)
Für jedes Produkt muss eine lückenlose, maschinenlesbare Komponentenliste geführt werden, die sämtliche verwendeten Open-Source-Bibliotheken, Fremd-Module und deren Versionen dokumentiert.
Schwachstellen-Management über die Nutzungsdauer
Hersteller müssen über den gesamten erwarteten Produktlebenszyklus (mindestens jedoch für die Dauer der Support-Zusage, in der Regel 5 Jahre) kontinuierlich auf bekannt werdende Schwachstellen (CVEs) prüfen und zeitnah unentgeltliche Sicherheitsupdates bereitstellen.
Strikte 24-Stunden-Meldepflicht
Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen innerhalb von 24 Stunden nach Kenntniserlangung über die zentrale CSIRT-Plattform an das BSI und die ENISA gemeldet werden.
Transparente Nutzerinformation & Dokumentation
Bereitstellung klar verständlicher Sicherheitsrichtlinien, Anleitungen zur sicheren Konfiguration, End-of-Life-Support-Daten und Kontaktstellen zur koordinierten Offenlegung von Sicherheitslücken (Coordinated Vulnerability Disclosure via security.txt).
EU-Konformitätserklärung & CE-Kennzeichnung
Erstellung der technischen Dokumentation gemäß Anhang VII, Unterzeichnung der EU-Konformitätserklärung und Anbringung des CE-Siegels auf dem Produkt, der Verpackung oder in den Begleitdokumenten.
3. Software Bill of Materials (SBOM): Der technische Standard
Die Forderung nach einer Software Bill of Materials (SBOM) ist das Herzstück der technischen CRA-Vorgaben. In modernen Softwareprojekten stammen 70 bis 90 Prozent der Codebasis aus Open-Source-Bibliotheken, npm-Paketen, Python-Wheels oder Go-Modulen. Sicherheitsvorfälle wie Log4Shell oder Angriffe auf die Software-Lieferkette (XZ-Utils-Backdoor) haben gezeigt, dass Unternehmen oft tagelang recherchieren mussten, in welchen eigenen Produkten eine verwundbare Bibliothek verbaut war.
Der CRA verlangt, dass jede Software Bill of Materials drei fundamentale Kernanforderungen erfüllt:
Standardisierte Formate wie CycloneDX (JSON/XML) oder SPDX ermöglichen den automatisierten Austausch entlang der gesamten B2B-Lieferkette.
Wird bei jedem Build und Release dynamisch in der CI/CD-Pipeline generiert, um veraltete statische Dokumentationsstände zuverlässig auszuschließen.
Direkte Anbindung an die Common Vulnerabilities and Exposures (CVE)- und NVD-Datenbanken für automatisierte Schwachstellen-Scans in Echtzeit.
Beispiel: Automatisierte SBOM-Generierung in einer CI/CD-Pipeline
Moderne Entwicklungsteams binden SBOM-Generatoren wie syft (von Anchore) oder @cyclonedx/cyclonedx-npm direkt in ihre GitHub Actions oder GitLab CI Pipelines ein:
# .github/workflows/cra-sbom-check.yml
name: "CRA Compliance: SBOM & Vulnerability Scan"
on:
push:
branches: [ "main", "release/*" ]
schedule:
# Täglicher Scan auf neu veröffentlichte CVEs in bestehenden Releases
- cron: '0 4 * * *'
jobs:
sbom-and-security-audit:
runs-on: ubuntu-latest
steps:
- name: Checkout Source Code
uses: actions/checkout@v4
- name: Setup Node.js Environment
uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install Production Dependencies
run: npm ci --omit=dev
- name: Generate CycloneDX SBOM (JSON Format)
run: |
npx @cyclonedx/cyclonedx-npm --output-file dist/sbom.cdx.json \
--output-format JSON \
--spec-version 1.5 \
--validate
- name: Scan SBOM against National Vulnerability Database (NVD) via Grype
uses: anchore/scan-action@v3
with:
sbom: "dist/sbom.cdx.json"
fail-build: true
severity-cutoff: high
output-format: sarif
- name: Archive SBOM Artifact for CRA Technical Documentation
uses: actions/upload-artifact@v4
with:
name: release-sbom-cyclonedx
path: dist/sbom.cdx.json
retention-days: 1825 # 5 Jahre Aufbewahrungspflicht gemäß CRABest Practice: Die 5-Jahre-Aufbewahrungspflicht
Gemäß Artikel 13 Absatz 8 des CRA müssen Hersteller die technische Dokumentation einschließlich der jeweiligen SBOM für einen Zeitraum von mindestens 10 Jahren bzw. über die gesamte festgelegte Support-Dauer (mindestens 5 Jahre nach Inverkehrbringen) aufbewahren und den Marktaufsichtsbehörden (in Deutschland der Bundesnetzagentur und dem BSI) auf Verlangen digital vorlegen können.
4. Die 24-Stunden-Meldepflicht: Ablauf & Eskalationsstufen
Die gravierendste operative Hürde für viele Entwicklungsabteilungen ist die Frist zur Meldung aktiv ausgenutzter Sicherheitslücken. Während bisherige Richtlinien oft Fristen von 72 Stunden (DSGVO) vorsahen, setzt der CRA auf ein mehrstufiges, extrem eng getaktetes Warnsystem:
Meldung an das zuständige nationale CSIRT (in Deutschland: BSI) und die europäische Cybersicherheitsagentur ENISA über die zentrale Meldeplattform. Die Frühwarnung muss angeben, ob die Schwachstelle bereits aktiv im Feld ausgenutzt wird und ob grenzüberschreitende Auswirkungen zu befürchten sind.
Präzisierung des Vorfalls: Technische Beschreibung der Schwachstelle, betroffene Software-Versionen, Risikobewertung (CVSS-Score) sowie bereits eingeleitete Sofortmaßnahmen (Workarounds, temporäre Deaktivierung betroffener Module).
Detaillierter Abschlussbericht an die Behörden mit Ursachenanalyse (Root Cause Analysis), Dokumentation des bereitgestellten Sicherheitsupdates und Nachweis über die Information der betroffenen B2B-Kunden und Anwender.
5. Synergien & Abgrenzung: CRA vs. NIS-2
In der Praxis herrscht im Mittelstand häufig Verwirrung über das Zusammenspiel von CRA und NIS-2. Beide Regulierungen stammen aus der europäischen Cybersicherheitsstrategie, verfolgen jedoch komplementäre Ansätze:
| Kriterium | NIS-2 (Richtlinie 2022/2555) | Cyber Resilience Act (CRA 2024/2847) |
|---|---|---|
| Regulierungstyp | EU-Richtlinie (muss in nationales Recht überführt werden, z. B. NIS-2-UmsuCG) | EU-Verordnung (gilt unmittelbar und einheitlich in allen 27 EU-Staaten) |
| Fokus | Betreiber von Infrastrukturen & Unternehmen (Entitätssicherheit) | Hersteller & Entwickler von Hard- und Software (Produktsicherheit) |
| Ziel | Schutz von Unternehmensprozessen, Netzwerken und Lieferketten | Sicherstellung inhärenter Sicherheit und Patchbarkeit digitaler Produkte |
| Nachweis | Risikoanalysen, Audits, Information Security Management Systems (ISO 27001) | Technische Dokumentation, SBOM, Konformitätsbewertung, CE-Kennzeichen |
| Haftung | Persönliche Geschäftsleiterhaftung der Organe | Hersteller- und Inverkehrbringerhaftung, Marktrückrufe, Verkaufsstopps |
Die Schnittstelle für Softwarehäuser
Wer als B2B-Softwarehersteller Kunden beliefert, die unter NIS-2 fallen (z. B. Stadtwerke, Kliniken, Industrieunternehmen oder Logistiker), gerät über die Lieferkettenanforderungen von NIS-2 automatisch unter Druck: Diese Kunden dürfen künftig nur noch Produkte beschaffen, die nachweislich CRA-konform sind und transparente SBOMs bereitstellen. Der CRA wird damit zum zwingenden Markteintrittskriterium im B2B-Vertrieb.
6. Der 5-Stufen-Fahrplan zur CRA-Compliance für KMU
Um den personellen und finanziellen Aufwand im Rahmen zu halten, sollten Entwicklungs- und IT-Verantwortliche das strukturierte Vorgehen anhand einer verbindlichen Roadmap umsetzen:
-
1. Produkt- und Komponenten-Inventur (Scoping)
Erfassen Sie alle kommerziell vertriebenen Softwarepakete, Embedded-Lösungen, Kundenportale und mobilen Anwendungen. Klären Sie für jedes Produkt die Einstufung: Fällt es unter die Standard-Kategorie (Selbsterklärung nach Modul A) oder unter Anhang III (Wichtige Produkte Klasse I/II mit Pflicht zu harmonisierten Normen oder benannten Prüfstellen)?
-
2. Etablierung eines automatisierten SBOM-Prozesses
Integrieren Sie automatisierte SBOM-Tools (wie CycloneDX, Syft oder Trivy) fest in Ihre Build- und CI/CD-Pipelines. Stellen Sie sicher, dass für jeden Release-Kandidaten automatisch ein unveränderliches, maschinenlesbares SBOM-Artefakt erzeugt, versioniert und im Compliance-Archiv abgelegt wird.
-
3. Kontinuierliches Schwachstellen-Scanning & Patch-SLAs
Führen Sie kontinuierliche automatisierte Scans gegen bekannte Schwachstellendatenbanken (NVD, GitHub Advisory Database) durch. Definieren Sie interne Service Level Agreements (SLAs): Kritische Schwachstellen (CVSS ≥ 9.0) müssen innerhalb definierter Fristen (z. B. 48 bis 72 Stunden) durch getestete Hotfixes behoben werden können.
-
4. Coordinated Vulnerability Disclosure (CVD) & Security.txt
Richten Sie einen standardisierten, sicheren Meldeweg für externe Sicherheitsforscher ein. Veröffentlichen Sie unter
/.well-known/security.txteine verschlüsselte Kontaktmöglichkeit (PGP-Key) und eine transparente Richtlinie zum koordinierten Umgang mit Sicherheitsmeldungen. -
5. Erstellung der Technischen Dokumentation & CE-Erklärung
Erstellen Sie für jedes Produkt die technische Dokumentation nach Anhang VII des CRA: Architekturbeschreibung, Bedrohungsmodellierung (Threat Model), Nachweis über angewandte Sicherheitsstandards, Testberichte (Penetrationstests, Code-Audits) und die formell unterzeichnete EU-Konformitätserklärung.
Quick-Check: Ihr Weg zur CRA-Compliance
7. Fazit: Vom regulatorischen Zwang zum Wettbewerbsvorteil
Der Cyber Resilience Act mag auf den ersten Blick wie ein weiteres bürokratisches EU-Monstrum wirken. Bei genauerer Betrachtung erzwingt er jedoch schlichtweg professionelles Software-Engineering nach modernem State of the Art:
- Wer saubere DevSecOps-Pipelines pflegt, automatisiert testet und seine Abhängigkeiten kennt, hat mehr als die Hälfte der CRA-Anforderungen bereits erfüllt.
- Wer jetzt die Weichen stellt, vermeidet den hektischen Engpass vor den Fristen im Juni 2026 und Dezember 2027.
- Im B2B-Vertrieb wird das CRA-konforme CE-Siegel und die lückenlose SBOM-Bereitstellung zum entscheidenden Verkaufsargument gegenüber Mitbewerbern, die ihre Sicherheitsarchitektur nicht nachweisen können.
Primärquellen & Weiterführende Dokumentation
- Europäische Union: Verordnung (EU) 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), Amtsblatt der Europäischen Union, L-Serie, 20.11.2024.
- BSI (Bundesamt für Sicherheit in der Informationstechnik): Technische Richtlinie TR-03183 — Cyber-Resilienz-Anforderungen an Software- und Hardwareprodukte, BSI Bonn.
- ENISA (European Union Agency for Cybersecurity): Guidelines on Coordinated Vulnerability Disclosure and Software Supply Chain Security, Lissabon/Athen.
- CycloneDX Standard: OWASP CycloneDX Software Bill of Materials (SBOM) Specification v1.5 / v1.6, OWASP Foundation.
Unsere Expertise vor Ort
Wir sind Ihr digitaler Partner – regional verankert und überregional erfolgreich.
Haben Sie eine Vision?
Lassen Sie uns gemeinsam prüfen, wie wir Ihre Idee zum Fliegen bringen.
Jetzt kostenloses Strategiegespräch buchenErweitertes Fachglossar
Software Bill of Materials (SBOM)
Ein strukturierter, maschinenlesbarer Komponenten-Inventarbericht einer Software, der alle direkten und transitiven Open-Source-Abhängigkeiten, Lizenzen und Versionsstände abbildet (z. B. nach CycloneDX oder SPDX).
Cyber Resilience Act (CRA)
Die EU-Verordnung 2024/2847 zur Festlegung horizontaler Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, die Hersteller zur Absicherung über den gesamten Lebenszyklus und zur CE-Kennzeichnung verpflichtet.
Security by Design
Ein Entwicklungsansatz, bei dem Sicherheitsaspekte wie Zugriffskontrollen, Verschlüsselung, Least-Privilege-Prinzipien und Schwachstellenprüfungen von Beginn der Architekturphase an integriert werden.
Vulnerability Disclosure Policy
Ein öffentlich dokumentierter Prozess, der externen Sicherheitsforschern und Nutzern einen sicheren und koordinierten Kanal zur Meldung entdeckter Sicherheitslücken bietet (z. B. security.txt).
