
Stand: 2026-10-09
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) kennt keine Größenausnahme. Wer ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt - ob Hardware mit Software-Komponente, Embedded-Gerät oder reine Software - unterliegt grundsätzlich denselben Anforderungen wie ein Großkonzern. Der Unterschied liegt im Zeitplan, in der Prioritätensetzung und im verfügbaren Budget. Dieser Artikel liefert einen priorisierten Fahrplan, der genau dort ansetzt.
Gilt der CRA überhaupt für mein Unternehmen?
Ob der CRA gilt, hängt von der Art des Produkts ab; die Unternehmensgröße spielt keine Rolle. Betroffen sind Hersteller, Einführer (Importeure) und Händler von Produkten mit digitalen Elementen, die eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk aufweisen - und die auf dem EU-Markt bereitgestellt werden. Das gilt auch für kostenlose Software, die im Rahmen einer gewerblichen Tätigkeit bereitgestellt wird, und für Produkte, die unter eigenem Namen vermarktet werden, aber von Dritten entwickelt wurden.
Ausnahmen gelten für Produkte, die bereits durch sektorspezifische EU-Rechtsakte gleichwertig geregelt sind, etwa Medizinprodukte (MDR/IVDR), Kraftfahrzeuge (Kfz-Typgenehmigung), nach der Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte oder Schiffsausrüstung. Für mittelständische Software- und Hardware-Hersteller außerhalb dieser Sektoren greifen diese Ausnahmen nicht. Den systematischen Selbstcheck bietet unser interaktiver Betroffenheits-Check; eine ausführliche Erklärung der Rollen und Abgrenzungen findet sich im Artikel Cyber Resilience Act - bin ich betroffen?

Die zwei harten Fristen - und warum die erste drängt
Für den Mittelstand gibt es zwei Daten, die den gesamten Umsetzungsplan strukturieren:
- 11. September 2026: Die Melde- und Berichtspflichten des CRA (Art. 14) sind seitdem anwendbar. Seit diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung und unverzüglich, spätestens nach 72 Stunden als Meldung anzeigen. Ein Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist, bei schwerwiegenden Vorfällen innerhalb eines Monats nach der 72-Stunden-Meldung. Die Anzeige erfolgt über die Single Reporting Platform (SRP) der ENISA an das zuständige CSIRT.
- 11. Dezember 2027: Alle übrigen Produktanforderungen werden vollständig anwendbar: Security-by-Design, Schwachstellen-Handling über den gesamten Supportzeitraum, SBOM, technische Dokumentation, CE-Kennzeichnung und EU-Konformitätserklärung.
Für operative Entscheidungen drängt die erste Frist mehr: Sie gilt seit dem 11. September 2026. Praktisch braucht es dafür funktionierende Meldewege; eine abgeschlossene Produktzertifizierung ist keine Voraussetzung. Mehr dazu im Artikel CRA Meldepflicht seit 11. September 2026: 24h/72h/14-Tage erklärt.
Minimum Viable CRA Compliance: Prioritäten für knappes Budget
Wenn Ressourcen begrenzt sind, kommt es auf die Reihenfolge an. Nicht alle CRA-Pflichten werden gleichzeitig wirksam, und nicht alle haben dasselbe Bußgeldrisiko. Der folgende Fahrplan orientiert sich an Fristdringlichkeit und Implementierungsaufwand.
Phase 1 (sofort, Pflicht seit September 2026): Meldeprozesse aufbauen
Dies ist die dringlichste Maßnahme. Ein Product Security Incident Response Team (PSIRT) muss nicht zwingend eine eigene Abteilung sein - aber es braucht eine benannte verantwortliche Person, einen dokumentierten Eskalationspfad und die technische Fähigkeit, eine qualifizierte Frühwarnung unverzüglich, spätestens innerhalb von 24 Stunden abzusetzen. Konkret bedeutet das:
- Interne Meldekette definieren: Wer entscheidet, ob eine Schwachstelle „aktiv ausgenutzt“ oder ein Vorfall „schwerwiegend“ ist?
- Kontakt zur ENISA Single Reporting Platform (SRP) vorbereiten - Registrierung und Meldeformat prüfen
- Vorlage für 24h-Frühwarnung, 72h-Meldung und Abschlussbericht erstellen
- Monitoring-Grundlage sichern: Gibt es eine Vulnerability-Datenbank-Anbindung (NVD, OSV), um bekannte Schwachstellen in eigenen Produktkomponenten früh zu erkennen und auf aktive Ausnutzung zu prüfen?
Hinweis: Gemeldet wird über die Single Reporting Platform, die ENISA nach Art. 16 CRA einrichtet und betreibt. Hersteller sollten die ENISA-Website auf das Zugangsverfahren und das genaue Meldeformat beobachten. Detailinfos zur Meldepflicht.
Phase 2 (parallel, bis Dezember 2027): SBOM aufbauen
Eine Software Bill of Materials (SBOM) ist eine unverzichtbare Grundlage für weitere CRA-Pflichten: Ohne zu wissen, welche Drittkomponenten in einem Produkt stecken, ist weder schnelles Schwachstellen-Reporting noch koordiniertes Vulnerability Handling möglich.
Für KMU empfiehlt sich ein gestuftes Vorgehen:
- Sofortmaßnahme: SBOM für das umsatzstärkste oder risikoreichste Produkt erstellen - im Format CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 (BSI TR-03183-2)
- Tooling: Open-Source-Werkzeuge wie Syft oder cdxgen erzeugen SBOMs im Build; Dependency-Track gleicht sie laufend gegen Schwachstellendatenbanken ab
- Aufbewahrungspflicht beachten: Die technische Dokumentation einschließlich der SBOM ist mindestens 10 Jahre nach dem Inverkehrbringen oder für den Supportzeitraum des Produkts vorzuhalten - je nachdem, welcher Zeitraum länger ist
Einen detaillierten technischen Überblick zu Formaten, Werkzeugen und der Aufbewahrungspflicht bietet der Artikel SBOM-Anforderungen im CRA. Mit unserem SBOM-Check können Sie eine SBOM (CycloneDX/SPDX) oder ein Lockfile automatisch auf bekannte Schwachstellen prüfen lassen.
Phase 3 (bis Dezember 2027): Produktklasse bestimmen und Konformitätsbewertung planen
Der CRA unterscheidet vier Stufen mit unterschiedlichen Anforderungen an die Konformitätsbewertung:
| Produktkategorie | Konformitätsbewertung | Typische Beispiele |
|---|---|---|
| Standard | Selbstbewertung (Modul A) | Mobile Apps und Computerspiele ohne Kernfunktion einer Produktkategorie aus Anhang III oder IV |
| Wichtig, Klasse I (Anhang III) | Selbstbewertung (Modul A) bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas (mindestens Stufe „mittel“); sonst notifizierte Stelle (Modul B+C oder H) | Passwortmanager, VPN, Browser, PKI-Software, SIEM |
| Wichtig, Klasse II (Anhang III) | Immer Drittprüfung: Modul B+C oder H mit notifizierter Stelle oder, sofern verfügbar, europäisches Cybersicherheitszertifikat mindestens der Stufe „mittel“ | Firewalls, Hypervisoren, manipulationssichere Mikroprozessoren |
| Kritisch (Anhang IV) | Vorgeschriebenes europäisches Cybersicherheitszertifikat (Art. 8 Abs. 1), sonst wie Klasse II (Art. 32 Abs. 4) | Smartcards, Secure Elements, Smart-Meter-Gateways |
Für Produkte der Klasse I besteht eine wichtige Entlastungsmöglichkeit: Werden harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) vollständig angewandt, genügt die Selbstbewertung nach Modul A - ohne externe Prüfstelle. Andernfalls ist Modul B+C oder H mit einer notifizierten Stelle vorgeschrieben. Diese Normen werden unter dem Normungsauftrag M/606 von CEN, CENELEC und ETSI erarbeitet. KMU mit Produkten der Klasse I sollten ihren Stand verfolgen, denn davon hängt ab, ob die Selbstbewertung nach Modul A möglich ist.
Die genaue Einordnung konkreter Produkte ist teils auslegungsbedürftig und hängt von der Durchführungsverordnung (EU) 2025/2392 ab. Alle Klassenangaben in diesem Artikel sind schematisch; die Einstufung Ihres Produkts sollte fachlich begleitet werden. Mehr dazu im Artikel CRA-Produktklassen: Standard, Klasse I/II und kritisch.
Wovon der Aufwand abhängt
Der Aufwand für die erstmalige Umsetzung hängt vor allem von der Produktkomplexität, vom Ausgangszustand der Sicherheitsprozesse und von der Produktklasse ab. Wer die Produktklasse früh klärt, erkennt rechtzeitig, ob eine Drittprüfung nötig wird.
Erleichterungen für Kleinst- und Kleinunternehmen - und was sie nicht abdecken
Kleinst- und Kleinunternehmen bestimmt der CRA nach der Empfehlung 2003/361/EG (Kleinstunternehmen: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme; kleine Unternehmen: weniger als 50 Beschäftigte und höchstens 10 Millionen Euro). Für Kleinst- und Kleinunternehmen gibt es punktuelle Erleichterungen, etwa die Möglichkeit, die technische Dokumentation in einem vereinfachten Format vorzulegen, dessen Formular die Kommission festlegt (Art. 33 Abs. 5), und eine Ausnahme bei Geldbußen für die versäumte 24-Stunden-Frühwarnung (Art. 64 Abs. 10), deren Reichweite eine Auslegungsfrage ist. Die Meldepflicht selbst gilt unabhängig von der Unternehmensgröße. Vom CRA ausgenommen sind diese Unternehmen damit nicht, auch die technischen Produktanforderungen gelten für sie. Für Hersteller in dieser Größenklasse ist der pragmatische Ansatz besonders wichtig: Priorität auf Meldeprozesse und SBOM, Selbstbewertung wo immer zulässig, harmonisierte Normen sobald verfügbar.
Ein möglicher Zeitplan auf einen Blick
- Sofort (Q4 2026): Betroffenheit prüfen, Produktklasse vorab einschätzen, PSIRT-Verantwortung benennen, Meldekette dokumentieren, SRP-Registrierung vorbereiten
- Q4 2026 bis Q2 2027: SBOM für Kernprodukte aufbauen, Dependency-Track oder vergleichbares Tooling einführen, technische Dokumentation beginnen
- Q3 bis Q4 2027: Konformitätsbewertung abschließen (Selbstbewertung oder notifizierte Stelle), CE-Kennzeichnung anbringen, EU-Konformitätserklärung ausstellen
Einen vollständigen Überblick über alle CRA-Pflichten bietet die CRA-Pillar-Seite. Wenn Sie unsicher sind, ob und wie Ihr Produkt betroffen ist, starten Sie mit dem Betroffenheits-Check oder vereinbaren Sie direkt ein unverbindliches Erstgespräch.
Häufige Fragen
Gilt der Cyber Resilience Act auch für kleine Unternehmen?+
Was ist die wichtigste CRA-Pflicht, die KMU zuerst umsetzen sollten?+
Muss ich für mein Produkt eine notifizierte Stelle einschalten?+
Was ist eine SBOM und warum ist sie für den CRA so wichtig?+
Wovon hängt der Aufwand der CRA-Umsetzung ab?+
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act) - EUR-Lex
- Durchführungsverordnung (EU) 2025/2392 (Kategoriebeschreibungen Anhang III/IV)
- Europäische Kommission - Cyber Resilience Act (Themenseite)
- Europäische Kommission - Meldepflichten nach dem CRA
- Europäische Kommission - Konformitätsbewertung nach dem CRA
- Europäische Kommission - Zusammenfassung des Cyber Resilience Act
- ENISA - Einheitliche Meldeplattform (Single Reporting Platform)
Diese Inhalte dienen der allgemeinen technischen und organisatorischen Information zum Cyber Resilience Act (Verordnung (EU) 2024/2847) und stellen keine Rechtsberatung dar (keine Rechtsdienstleistung i.S.d. RDG).