CRA-Fristen 2026 und 2027: Was ansteht, was blockiert ist

Stand 30. Mai 2026: Keine notifizierte Stelle ist unter dem CRA designiert. Keine harmonisierte Norm ist im Amtsblatt der EU veröffentlicht. Die ENISA-Meldeplattform existiert noch nicht. Bis zum Beginn der Durchsetzung von Artikel 14 am 11. September 2026 bleiben etwa 3,4 Monate.

Wenn Sie Produkte mit digitalen Elementen für den EU-Markt herstellen, ist dies die tatsächliche Lage: was Sie vor September aufbauen müssen, was aktuell blockiert ist und warum die Selbstbewertung für wichtige Produkte der Klasse I heute nicht funktioniert.

Drei Blocker, die sich nicht umgehen lassen

Keine harmonisierten Normen

Artikel 32 Absatz 2 gibt Herstellern wichtiger Produkte der Klasse I drei Konformitätswege: Selbstbewertung, Drittbewertung anhand harmonisierter Normen oder gemeinsamer Spezifikationen, oder Bewertung durch eine notifizierte Stelle. Der mittlere Weg setzt harmonisierte CRA-Normen voraus. Bisher ist jedoch keine harmonisierte CRA-Norm im Amtsblatt veröffentlicht. Stand 30. Mai 2026:

• Die Seite der Kommission zu harmonisierten Normen führt keinen Eintrag zur Verordnung (EU) 2024/2847.
• Es wurden keine gemeinsamen Spezifikationen nach Artikel 27 Absatz 2 erlassen.
• Kein delegierter Rechtsakt nach Artikel 27 Absatz 9 weist ein europäisches Cybersicherheits-Zertifizierungssystem als CRA-Konformitätsvermutungsweg aus.

Wo Normen fehlen, verlangt Artikel 32 Absatz 2 Modul B+C (EU-Baumusterprüfung) oder Modul H (umfassende Qualitätssicherung). Beide erfordern eine notifizierte Stelle.

Wenn Sie also ein wichtiges Produkt der Klasse I herstellen, funktioniert die Selbstbewertung heute nicht. Die Bewertung durch eine notifizierte Stelle ist der einzige konforme Weg.

CEN-CLC/JTC 13/WG 9 entwickelt die EN 40000-Reihe:

• prEN 40000-1-1 (Vokabular): öffentliche Umfrage abgeschlossen, noch nicht in der formalen Abstimmung.
• prEN 40000-1-2 (Grundsätze): öffentliche Umfrage abgeschlossen, noch nicht in der formalen Abstimmung.
• prEN 40000-1-3 (Schwachstellenbehandlung): öffentliche Umfrage lief von Dezember 2025 bis Februar 2026, derzeit in der Kommentarauswertung.
• prEN 40000-1-4 (Allgemeine Sicherheitsanforderungen): noch in Erstellung.
• Vertikale Typ-C-Normen (Browser, VPNs, SIEM und weitere): in fortgeschrittenem Entwurfsstadium, noch nicht in der öffentlichen Umfrage.

Realistisch frühester Zitiertermin im Amtsblatt: Q4 2026. Mehrere vertikale Normen werden voraussichtlich ins Jahr 2027 rutschen.

Keine notifizierten Stellen

Kapitel IV wird am 11. Juni 2026 aktiv. Ziel der Kommission ist eine ausreichende Kapazität notifizierter Stellen bis zum 11. Dezember 2026 (Artikel 35 Absatz 2, Best-Effort-Formulierung). Stand 30. Mai 2026 erscheinen keine CRA-designierten notifizierten Stellen im Single Market Compliance Space.

Wenn Sie eine Bewertung für ein wichtiges Produkt der Klasse I vor Dezember 2027 abschließen müssen, planen Sie:

• Vorbereitung der technischen Dokumentation: 3 bis 6 Monate.
• Bewertung Modul B+C: 2 bis 4 Monate pro Produkt.
• Verfügbarkeit notifizierter Stellen: unsicher bis zur formalen Designierung nach Juni 2026.

Sprechen Sie jetzt mit Konformitätsbewertungsstellen. Die formale Mechanik öffnet erst Mitte 2026. Wer bis dahin wartet, kann seine Bewertung kaum noch vor Dezember 2027 abschließen.

Keine ENISA-Meldeplattform

Die einheitliche Meldeplattform nach Artikel 16 ist am 30. Mai 2026 nicht verfügbar. ENISA hat einen Auftragnehmer beauftragt. Die Plattform soll vor dem 11. September 2026 öffnen. Es liegen weder eine Registrierungs-URL noch herstellerorientierte Hinweise vor.

Was Sie heute tun können:

• Meldevorlagen anhand der Formatvorgaben aus Artikel 14 entwerfen: Meldungen binnen 24 Stunden und 72 Stunden, ein Schwachstellen-Abschlussbericht binnen 14 Tagen und ein Abschlussbericht zu schwerwiegenden Sicherheitsvorfällen binnen einem Monat.
• Den zuständigen CSIRT-Koordinator Ihres Mitgliedstaats identifizieren.
• Intern festlegen, wer eine 24-Stunden-Meldung an einem Wochenende oder Feiertag freigeben darf.

ENISA-SRP-Seite: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

Was vor dem 11. September 2026 stehen muss

Es bleiben etwa 3,4 Monate. Wenn diese Punkte nicht erledigt sind, sind Sie nicht mit Aufgaben im Rückstand. Sie sind mit Infrastruktur im Rückstand, und Infrastruktur baut man nicht in Wochen auf.

Produktinventar und Klassifizierung

Sie brauchen eine vollständige Liste aller Produkte mit digitalen Elementen (PDE), die Sie auf dem EU-Markt bereitstellen, mit bestätigter CRA-Klassifizierung je Produkt:

• Standardklasse: Selbstbewertung verfügbar.
• Wichtig Klasse I: Bewertung durch eine notifizierte Stelle heute erforderlich (siehe oben).
• Wichtig Klasse II: Notifizierte Stelle erforderlich. Modul B+C oder Modul H.
• Kritisch: Modul B+C oder umfassende Qualitätssicherung. Eine europäische Cybersicherheits-Zertifizierung kann zusätzlich anwendbar sein.

Klassifizierungs-Referenz: Durchführungsverordnung (EU) 2025/2392 (ABl. 1. Dezember 2025, in Kraft 21. Dezember 2025) liefert technische Beschreibungen der Produktkategorien aus Anhang III und IV. Nutzen Sie sie für Grenzfälle.

SBOM-Infrastruktur

Sie können eine aktiv ausgenutzte Schwachstelle nicht binnen 24 Stunden melden, wenn Sie nicht wissen, welche Komponenten Ihr Produkt enthält. Die SBOM-Erstellung muss vor September 2026 produktiv laufen.

• Format: CycloneDX oder SPDX. Beide werden unter dem CRA akzeptiert. Wählen Sie eines und vereinheitlichen Sie es produktübergreifend.
• Umfang: Transitive Abhängigkeiten, nicht nur direkte. Die vollständige Komponentensicht ist für die Risikoanalyse nach Anhang VII erforderlich.
• Speicherung: Versionsverwaltet, gekoppelt an Produkt-Releases. Jede SBOM muss einem konkreten Build zuordenbar sein.
• Integration: CI/CD-Pipeline. Ein einmaliger Export erfüllt die laufende Pflicht nicht.

Schwachstellenüberwachung

Die 24-Stunden-Meldefrist beginnt mit der Kenntnisnahme: hinreichende Sicherheit auf Basis einer ersten Einschätzung. Eine forensische Bestätigung ist nicht erforderlich, um die Frist auszulösen. Sie brauchen eine Überwachung, die diese erste Einschätzung liefern kann, bevor die Frist abläuft.

• Abonnieren Sie NVD, OSV und einschlägige Hersteller-Advisories für Ihren Komponenten-Stack.
• Automatisieren Sie das Scannen gegen Ihre SBOM-Komponenten.
• Dokumentieren Sie Ihren internen Eskalationspfad und testen Sie ihn End-to-End.
• Entwerfen Sie Meldevorlagen jetzt, bevor die ENISA-Plattform startet.

Checkliste vor September 2026

PRODUKTINVENTAR (zuerst: die Klassifizierung steuert Ihren Konformitätsweg):
[ ] Vollständige Liste der in der EU verkauften PDE mit bestätigter CRA-Klassifizierung pro Produkt
[ ] Wichtige Produkte Klasse I: Konformitätsbewertungsstelle jetzt einbinden: die Designierung
    notifizierter Stellen öffnet erst im Juni 2026; späteres Warten reißt den Dezember 2027.
[ ] Supportzeitraum gemäß erwarteter Produktlebensdauer angegeben (Art. 13 Abs. 8)

SBOM (hier starten: speist Überwachung, technische Dokumentation und 24-Stunden-Meldung):
[ ] SBOM-Erstellung in CI/CD-Pipeline integriert: ein einmaliger Export reicht nicht
[ ] Format vereinheitlicht: CycloneDX oder SPDX
[ ] Abdeckung transitiver Abhängigkeiten verifiziert: nur direkte reichen nicht
[ ] SBOMs versionsverwaltet und an konkrete Produkt-Releases gekoppelt

SCHWACHSTELLENÜBERWACHUNG (muss vor dem 11. September live sein):
[ ] Überwachung aktiv für alle Produkte: NVD, OSV, Hersteller-Advisories
[ ] Automatisiertes Scannen gegen SBOM läuft
[ ] Interner Eskalationspfad dokumentiert und End-to-End getestet
[ ] 24/7-Abdeckung bestätigt, einschließlich Feiertags- und Wochenend-Eskalation

MELDEVORBEREITUNG (ENISA-Plattform noch nicht live: alles andere jetzt vorbereiten):
[ ] Vorlagen für 24 Stunden, 72 Stunden, 14-Tage-Schwachstelle und Ein-Monats-Vorfall gegen Art. 14 entworfen
[ ] CSIRT-Koordinator des Mitgliedstaats identifiziert
[ ] Person mit Befugnis zur Auslösung einer 24-Stunden-Meldung benannt und rund um die Uhr erreichbar

DOKUMENTATION:
[ ] Technische Dokumentation gegen Anhang VII geprüft
[ ] Lückenanalyse abgeschlossen
[ ] Risikoanalyse läuft

Artikel 14: Was die Meldung ab 11. September 2026 verlangt

Ab dem 11. September 2026 müssen Sie aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gleichzeitig an zwei Stellen melden: an den zuständigen CSIRT-Koordinator Ihres Mitgliedstaats und an ENISA über die einheitliche Meldeplattform (Artikel 16).

KMU-Ausnahme: Artikel 64 Absatz 10 Buchstabe a befreit Kleinstunternehmen und kleine Unternehmen von Bußgeldern für die Nichteinhaltung der Fristanforderungen aus Artikel 14 Absatz 2 Buchstabe a und Artikel 14 Absatz 4 Buchstabe a. Die Befreiung gilt nur für die Fristen. Die Meldepflicht selbst bleibt bestehen.

Was „aktiv ausgenutzt" bedeutet

Artikel 14 Absatz 2 Buchstabe a greift, wenn glaubwürdige Hinweise vorliegen, dass ein Bedrohungsakteur die Schwachstelle in einem System ohne Erlaubnis des Eigentümers genutzt hat. Indikatoren sind:

• Bestätigte Angriffe in freier Wildbahn.
• Ausnutzung in Threat-Intelligence-Feeds gemeldet oder von Sicherheitsforschern berichtet.
• Erkennung in Honeypots mit Hinweisen auf aktiven Einsatz.

Der Entwurf der Kommissionsleitlinie (Ares(2026)2319816, 3. März 2026) verwendet „glaubwürdige Hinweise auf aktive Ausnutzung" als Maßstab, der unter einer forensischen Bestätigung liegt.

Phase-2-Bereitschaftscheckliste

MELDEINFRASTRUKTUR (vor dem 11. September 2026):
[ ] Meldevorlagen vorbereitet: Formate für 24 Stunden, 72 Stunden, 14-Tage-Schwachstelle und Ein-Monats-Vorfall
[ ] CSIRT-Koordinator des Mitgliedstaats identifiziert: er ist neben ENISA Ihre primäre
    Meldestelle
[ ] 24/7-Eskalationspfad bestätigt, einschließlich Feiertagsabdeckung und Backup-Kontakten
[ ] Rechtsprüfung der Pflichten aus Art. 14 abgeschlossen

SCHWACHSTELLENMANAGEMENT:
[ ] Aktive Überwachung für alle Produkte einsatzbereit
[ ] CVE/NVD-Integration live
[ ] Vorlagen für Kundenmeldungen bereit

TEAM-BEREITSCHAFT:
[ ] Sicherheitsteam zu den Pflichten aus Artikel 14 und der vierstufigen Frist geschult
[ ] Eskalationspfad ans Management dokumentiert
[ ] Rechtsabteilung zu den Meldepflichten gebrieft
[ ] Kommunikationsteam auf öffentliche Bekanntmachungen vorbereitet

Vollständige Konformität bis 11. Dezember 2027

Grundlegende Cybersicherheitsanforderungen (Anhang I)

Jedes konforme PDE muss diese Anforderungen erfüllen:

Security by Design

• Sicherheitsniveau angemessen zu den Risiken des Produkts (Anhang I, Teil I, §1).
• Schutz gegen unbefugten Zugriff.
• Vertraulichkeit, Integrität und Verfügbarkeit von Daten und wesentlichen Funktionen.
• Minimale Angriffsfläche, sichere Voreinstellungen, keine fest kodierten Zugangsdaten.

Schwachstellenmanagement

• Dokumentierter Prozess zur Identifikation und Behebung von Schwachstellen.
• Zeitnahe, kostenlose Sicherheitsupdates während des Supportzeitraums.
• Politik zur koordinierten Offenlegung von Schwachstellen (Art. 13 Abs. 6).

Update-Fähigkeit

• Sicherer, zuverlässiger Update-Mechanismus.
• Möglichkeit, Sicherheitsupdates von Funktionsupdates zu trennen.

Technische Dokumentation (Anhang VII)

Supportzeitraum: zwei getrennte Pflichten

Der CRA legt zwei eigenständige Pflichten zu Sicherheitsupdates fest.

Artikel 13 Absatz 8: Sie müssen Sicherheitsupdates für mindestens fünf Jahre ab Inverkehrbringen des Produkts bereitstellen, oder für die erwartete Lebensdauer, falls diese kürzer ist. Fünf Jahre sind die Untergrenze, nicht die Vorgabe. Ein Produkt mit zehn Jahren erwarteter Lebensdauer braucht eine zehnjährige Supportzusage.

Artikel 13 Absatz 9: Jedes von Ihnen ausgelieferte Sicherheitsupdate muss mindestens zehn Jahre ab Veröffentlichung oder bis zum Ende des Supportzeitraums zum Download verfügbar bleiben, je nachdem, welcher Zeitraum länger ist.

Beide Pflichten sind unabhängig. Ein im vierten Jahr eines fünfjährigen Supportzeitraums veröffentlichtes Update muss bis zum 14. Jahr nach Veröffentlichung herunterladbar bleiben. Wenn Sie alte Update-Pakete löschen oder Verteilinfrastruktur auslaufen lassen, verletzen Sie Artikel 13 Absatz 9, selbst wenn Sie planmäßig neue Updates ausliefern. Planen Sie Speicher- und Verteilinfrastruktur für die lange Strecke, bevor Sie Ihr erstes Update unter dem CRA ausliefern.

Checkliste Dezember 2027

PRODUKT-COMPLIANCE:
[ ] Alle Produkte erfüllen die Anforderungen aus Anhang I: Security by Design, Schwachstellenmanagement
    und Update-Fähigkeit
[ ] Konformitätsbewertungen abgeschlossen: Verfahren mit notifizierter Stelle für wichtige Produkte
    Klasse I und Klasse II beendet
[ ] CE-Kennzeichnung angebracht
[ ] EU-Konformitätserklärung gemäß Art. 28 erstellt

TECHNISCHE DOKUMENTATION (Anhang VII):
[ ] Risikoanalyse abgeschlossen und dokumentiert
[ ] SBOM aktuell und validiert
[ ] Konformitätsnachweise strukturiert und zugänglich
[ ] Supportzeitraum gemäß erwarteter Produktlebensdauer nach Art. 13 Abs. 8 angegeben

LIEFERKETTE:
[ ] Einführer und Händler über ihre CRA-Pflichten informiert
[ ] Kundenseitige Dokumentation aktualisiert

LAUFEND:
[ ] Art. 13 Abs. 8: Sicherheitsupdate-Prozess aktiv über die volle Dauer des Supportzeitraums
[ ] Art. 13 Abs. 9: Verteilinfrastruktur für Update-Verfügbarkeit eingerichtet: zehn Jahre
    ab Veröffentlichungsdatum
[ ] Schwachstellenüberwachung aktiv und getestet
[ ] Vorfallsreaktion mindestens vierteljährlich geübt

Leitlinien der Kommission: Entwurf März 2026

Die Kommission hat am 3. März 2026 einen Mitteilungsentwurf (Ares(2026)2319816) mit rund 70 Seiten veröffentlicht. Die Stakeholder-Konsultation endete am 31. März 2026. Das Dokument ist nicht final. Endgültige Sprachfassungen stehen aus. Eine vollständige Aufschlüsselung finden Sie in unserem Leitfaden zur Kommissionsleitlinie.

Wichtige Festlegungen mit Bezug zu Ihrem Zeitplan:

RDPS-Test für SaaS-Anwendungsbereich: Software zur Datenfernverarbeitung fällt nur dann in den CRA-Anwendungsbereich, wenn sie drei Bedingungen erfüllt. Die Software führt eine Datenfernverarbeitung durch. Diese Verarbeitung ist für die Kernfunktion des Produkts erforderlich. Und der Hersteller kontrolliert die Datenfernverarbeitung. SaaS, das diesen Test nicht besteht, ist außerhalb des Anwendungsbereichs.

Bestandsprodukte: Eine Rekonstruktion historischer Dokumentation ist nicht erforderlich. Sie brauchen eine aktuelle Risikoanalyse. Produktfamilien dürfen für Zwecke der Risikoanalyse gruppiert werden.

Software-Updates: Ein Update gilt nicht als „wesentliche Änderung", die eine neue Konformitätsbewertung auslöst, es sei denn, es führt neue Bedrohungsvektoren ein oder ändert den Verwendungszweck des Produkts. Die Leitlinie liefert einen Test mit vier Fragen.

24-Stunden-Frist: Beginnt mit der Kenntnisnahme. Hinreichende Sicherheit auf Basis einer ersten Einschätzung genügt. Eine forensische Bestätigung ist nicht erforderlich.

Untergrenze des Supportzeitraums: Fünf Jahre sind ein Minimum, keine Vorgabe. Der Supportzeitraum muss die erwartete Lebensdauer des Produkts widerspiegeln.

Open Source: Die Veröffentlichung von Quellcode stellt kein Inverkehrbringen dar. Beitragende, die das Release eines fertigen Produkts nicht kontrollieren, sind unter dem CRA keine Hersteller.

Offizielle Ankündigung: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act

Sanktionen

Artikel 64 Absatz 2 der Verordnung (EU) 2024/2847 setzt die oberste Sanktionsstufe auf 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist, für:

• Verstöße gegen die grundlegenden Cybersicherheitsanforderungen aus Anhang I und die Pflichten aus Artikel 13.
• Nichterfüllung der Pflichten aus Artikel 14 (Meldung von Schwachstellen und Sicherheitsvorfällen).

Beide Verstöße liegen in derselben Sanktionsstufe. Es gibt keine niedrigere Stufe für Meldeverstöße.

Artikel 64 Absatz 3 (10 Mio. EUR oder 2 %) deckt eine separate Pflichtenliste ab: Artikel 18 bis 23, 28, 30 bis 33, 39, 41, 47, 49 und 53. Diese betreffen primär Pflichten von Einführern, Händlern und notifizierten Stellen. Artikel 14 steht nicht in dieser Liste.

KMU-Ausnahme: Artikel 64 Absatz 10 Buchstabe a befreit Kleinstunternehmen und kleine Unternehmen von Bußgeldern für die spezifischen Fristanforderungen aus Artikel 14 Absatz 2 Buchstabe a und Artikel 14 Absatz 4 Buchstabe a. Die Befreiung gilt nur für die Fristen, nicht für den Inhalt der Meldepflicht.

Branchenspezifische Hinweise

Unterhaltungselektronik

Die SBOM-Automatisierung ist die wertvollste Frühinvestition. Sie speist direkt die Schwachstellenüberwachung und die Erstellung der technischen Dokumentation. Konsumprodukte haben typischerweise komplexe Lieferketten mit mehreren Komponentenherstellern.

Firmware-Updates über große Gerätepopulationen hinweg zu steuern, erfordert OTA-Infrastruktur. Ein im dritten Lebensjahr eines Produkts ausgeliefertes Update muss zehn Jahre ab Veröffentlichung herunterladbar bleiben (Artikel 13 Absatz 9). Planen Sie Ihre Verteilinfrastruktur jetzt, nicht zum Zeitpunkt der Auslieferung.

Software-Anbieter

Die Schwachstellenmeldung ist die operativ anspruchsvollste Pflicht für Software-Produkte. Die Entdeckungsraten sind höher, und Abhängigkeiten in transitiver Tiefe in modernen Stacks zu verfolgen, ist nicht trivial. Integrieren Sie die SBOM-Erstellung in Ihre bestehenden CI/CD-Pipelines. Das speist direkt die Überwachung und den Reaktions-Workflow.

Industrieausrüstung

Lange Produktlebenszyklen (10 bis 20 Jahre) treffen direkt auf den Mindest-Supportzeitraum von fünf Jahren (Artikel 13 Absatz 8) und die zehnjährige Pflicht zur Update-Verfügbarkeit pro Veröffentlichung (Artikel 13 Absatz 9). Ein Produkt mit 20 Jahren erwarteter Lebensdauer braucht möglicherweise eine 20-jährige Supportzusage.

Industrieprodukte fallen häufig in wichtig Klasse I oder Klasse II, was heute eine Bewertung durch eine notifizierte Stelle bedeutet. Sprechen Sie jetzt mit Konformitätsbewertungsstellen. Das formale Designierungsverfahren öffnet nach Juni 2026, und die Kapazität bleibt mindestens bis Dezember 2026 knapp.

IoT-Geräte

Die Beseitigung von Standard-Zugangsdaten ist eine harte Anforderung (Anhang I, Teil I, §2 Buchst. e). Gehen Sie sie zuerst an. Sie ist ein klarer Verstoß gegen Anhang I und im Vergleich zu Architekturänderungen relativ eingegrenzt zu beheben. Sichere Update-Mechanismen für ressourcenbeschränkte Geräte sind aufwendiger. Beginnen Sie mit den Zugangsdaten, danach folgen die Updates.