Zum Hauptinhalt springen
EU-Regulierung

EU Cyber Resilience Act (CRA): Compliance-Roadmap bis 2027

Der EU Cyber Resilience Act setzt zwei harte Fristen: Ab dem 11. September 2026 gelten Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Ab dem 11. Dezember 2027 müssen alle Produkte mit digitalen Elementen die vollen Anforderungen erfüllen. Hat Ihr Produkt digitale Elemente und externe Schnittstellen? Dann fällt es fast sicher unter den CRA.

Beratungsgespräch vereinbaren Bin ich betroffen?
Die Verordnung

Was der CRA fordert: und ab wann

Der Cyber Resilience Act ist die erste EU-Verordnung mit verbindlichen Cybersecurity-Mindestanforderungen für alle vernetzten Produkte am EU-Markt. Er gilt produkt- und branchenübergreifend.

Anwendungsbereich. Betroffen sind Produkte mit digitalen Elementen, also Hardware und Software mit Datenverbindung. Die Pflichten treffen Hersteller, aber auch Importeure und Distributoren, die solche Produkte in der EU bereitstellen.

Kernprinzipien. Security by Design: Sicherheit von der Konzeptphase an mitdenken. Security by Default: sichere Grundkonfiguration im Auslieferungszustand. Lifecycle-Verantwortung: Vulnerability Management, Update-Management und Meldepflichten über den gesamten Support-Zeitraum.

Sanktionen. Bei Verstößen gegen die wesentlichen Cybersecurity-Anforderungen drohen Bußgelder von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Die drei kritischen Daten

10. Dezember 2024: Der CRA ist in Kraft getreten.

11. September 2026: Die Meldepflichten greifen. Aktiv ausgenutzte Schwachstellen und schwere Vorfälle müssen an ENISA gemeldet werden: Frühwarnung binnen 24 Stunden, vollständige Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme. → Was Hersteller bis September 2026 aufbauen müssen

11. Dezember 2027: Volle Anwendung. Alle Anforderungen gelten für am EU-Markt platzierte Produkte, inklusive Konformitätsbewertung, CE-Kennzeichnung und technischer Dokumentation.

Cyber Resilience Act – volle Anwendung

00 Tage
00 Stunden
00 Minuten
00 Sekunden

Klicken zum Umschalten

Betroffenheit

Bin ich betroffen? Der erste Selbstcheck

Faustregel: Software mit externer Schnittstelle fällt unter den CRA. Ausgenommen sind Produkte ohne digitale Elemente, sektorspezifisch regulierte Bereiche (z.B. Medizin, Automotive) und Sonderfälle wie Open-Source ohne kommerzielle Absicht.

Standardprodukte

Der Großteil der Produkte. Selbstbewertung durch den Hersteller. Kein Dritter muss einbezogen werden.

Wichtige Produkte (Klasse I und II)

Strengere Anforderungen, teils mit Nachweis durch harmonisierte Normen oder durch eine benannte Stelle (Drittbewertung).

Kritische Produkte

Höchste Stufe. Obligatorische Zertifizierung durch eine benannte Stelle.
GAP-Analyse

Wo stehen Sie? Reifegrad in 7 Bereichen messen

Die GAP-Analyse prüft, ob Ihre Prozesse, Dokumente und Produkteigenschaften die 64 CRA-Anforderungen abdecken — in sieben Bereichen: Geltungsbereich, Governance, Risikoanalyse (TARA), Produktanforderungen aus Anhang I, Schwachstellenmanagement, Meldepflichten und Dokumentation. Jeder Prüfpunkt wird auf einer Skala von 0 (nicht vorhanden) bis 3 (vollständig, auditfähig) bewertet.

Die Auswertung zeigt den Erfüllungsgrad je Bereich und macht sichtbar, wo ein eigenes Umsetzungsprojekt nötig ist und wo Feinschliff reicht. Liegen die Bereiche TARA oder Schwachstellenmanagement unter 66 %, ist ein Beratungsgespräch der nächste sinnvolle Schritt.

Empfehlung: Die Analyse gemeinsam mit Produktmanagement, Entwicklung und Qualitätssicherung durchführen und Nachweise direkt verlinken. Quartalsweise wiederholen — so wird daraus ein Fortschrittsinstrument bis Dezember 2027.

Radar-Diagramm: CRA-Reifegrad in sieben Bereichen
Interaktiver Check

CRA GAP-Analyse: Kostenloser Online-Check

17 Fragen · 7 Bereiche · Radar-Diagramm · Kein Login

Lieber in die Tiefe? 75 Prüfpunkte als Excel-Vorlage
Zum interaktiven Check
Roadmap

Was bis 2026 und 2027 zu tun ist

Sofort: bis September 2026

  • Vulnerability-Disclosure-Prozess etablieren.
  • Incident-Response-Prozess mit belastbarem 24-Stunden-Meldepfad aufsetzen.
  • Kontakte zu ENISA und den nationalen CSIRTs klären.
  • Verantwortlichkeiten benennen, etwa einen Product Security Officer.

Mittelfristig: bis Dezember 2027

  • Cyber-Risikobewertung / TARA für alle CRA-relevanten Produkte.
  • Security-Anforderungen fest in die Engineering-Prozesse integrieren.
  • SBOM (Software Bill of Materials) für jedes Produkt führen.
  • Vulnerability Management über den gesamten Lifecycle.
  • Lifecycle-Pflege: Updates, Patches und eine klare End-of-Support-Strategie.
  • Konformitätsbewertung und CE-Kennzeichnung mit Cybersecurity-Bezug.

Zwei dieser Bausteine reichen tief in Nachbarthemen hinein. Die TARA gehört methodisch zur Cybersecurity. → Cyber Security Und die durchgängige Nachverfolgbarkeit von Anforderungen ist Pflicht, sobald Sie Security-Anforderungen über Tools hinweg belegen müssen. → Requirements Traceability

Excel-Template

CRA-Risikoanalyse: Mit Excel-Vorlage starten

Das itemis SECURE Excel-Template unterstützt den vollständigen TARA-Prozess: Assets, Damage Scenarios, Threat Catalog, Attack Steps, Controls bis zu Threat Scenarios und Risks. AFL, IL und RL werden automatisch berechnet. Die Ergebnisse lassen sich direkt in itemis SECURE importieren.

Excel · XLSX · Kostenlos

Im Artikel: Wie man mit dem Template arbeitet
Template herunterladen
Verantwortung

Wer haftet? Die Kette der Verantwortung

Der CRA verteilt die Pflichten entlang der gesamten Lieferkette. Jedes Glied kann bei Nichteinhaltung zur Verantwortung gezogen werden.

Hersteller

Die primäre Verantwortung liegt hier. Sie müssen die Cyber-Risikobewertung (TARA) durchführen, das Produkt nachweislich sicher gestalten und die technische Dokumentation über den gesamten Lebenszyklus pflegen.

Importeure

Sie prüfen, dass der Hersteller alle CRA-Pflichten erfüllt hat: CE-Kennzeichnung, Dokumentation, Konformitätsbewertung. Importeure übernehmen damit eine direkte Haftung.

Distributoren

Sie müssen sicherstellen, dass das Produkt eine gültige CE-Kennzeichnung trägt und alle erforderlichen Anweisungen beiliegen, bevor es an den Endkunden verkauft wird.
CRAIG

CRAIG — die europäische CRA-Community

CRAIG ist eine gemeinnützige ASBL nach belgischem Recht, gegründet am 18. März 2026 in Dortmund beim itemis PODIUM. Die Mission: die CRA-Umsetzung demokratisieren, besonders für KMU mit begrenzten Ressourcen.

CRAIG schlägt die Brücke zwischen Recht und Technik. Komplexe Verordnungstexte werden in umsetzbare Schritte übersetzt. Das passiert auf zwei Wegen: über Local Chapters als persönliches Netzwerk vor Ort (erste Standorte Böblingen und Stuttgart, weitere im Aufbau) und über Online-Tools wie den Betroffenheits-Check, eine Wissensdatenbank und Vorlagen.

Mitmachen kann jede betroffene Organisation. Für Einzelpersonen ist die Mitgliedschaft kostenlos, wer will, kann ein eigenes Chapter gründen.

Das Gründerteam: Dirk Leopold (Chairman), Tim Scherer, Michael Happ, Janine Funke, Hauke Petersen, Max Schubert und Michael Jesse.

itemis ist strategischer Sponsor und unterstützt aktiv das europaweite Netzwerk für die CRA-Umsetzung.

→ CRAIG-Website · Gründungsveranstaltung beim itemis PODIUM

Die CRAIG-Gründer beim itemis PODIUM in Dortmund
Häufige Missverständnisse

Drei Annahmen, die am Stichtag teuer werden

Viele Hersteller haben den falschen Termin im Kopf, oder unterschätzen, wen die Meldepflicht wirklich trifft. Die drei häufigsten Denkfehler.

„Der CRA betrifft uns erst 2027."

Die volle Anwendbarkeit kommt am 11. Dezember 2027. Die Meldepflicht aus Artikel 14 steht jedoch fünfzehn Monate früher: am 11. September 2026.

„Betroffen sind nur neue Produkte."

Artikel 69 Absatz 3 dehnt die Meldepflicht auf alle Produkte mit digitalen Elementen aus, die vor dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wurden. Das Baujahr spielt keine Rolle.

„Eine Meldung an ENISA genügt."

Die Frühwarnung muss gleichzeitig ENISA und das nationale CSIRT erreichen. Eine Meldung an nur eine der beiden Stellen erfüllt Artikel 14 nicht.
itemis SECURE

Wie itemis SECURE und CRAIG die Umsetzung beschleunigen

Die Rollen sind klar getrennt. CRAIG liefert Community, Wissen und Netzwerk. itemis SECURE ist die Plattform für die technische Umsetzung: modellbasierte TARA, Risk Assessment und Lifecycle-Pflege.

Das Zusammenspiel: Die Community klärt das WAS, SECURE liefert das WIE. In itemis SECURE führen AI Assistants durch die TARA-Erstellung, statt dass jedes Team bei null im Tabellenblatt anfängt. Das Ergebnis ist ein lebendes Risikomodell, das sich aktualisiert, wenn neue Schwachstellen auftauchen, kein PDF, das nach drei Monaten veraltet ist.

Transparenzhinweis: CRAIG ist gemeinnützig und herstellerneutral. itemis SECURE ist unser kommerzielles Produkt. Wir trennen das offen.

→ itemis SECURE: Cyber Resilience Act

das Cybersecurity-Engineering-Werkzeug

TARA, Bedrohungsmodellierung, Attack Trees, Vulnerability Management: mit nativem Support für ISO/SAE 21434 und den EU Cyber Resilience Act. KI-gestützte Automatisierung reduziert den TARA-Aufwand um bis zu 80 % bei vollem Human-in-the-Loop. Im Einsatz unter anderem bei OEMs, Tier-1-Zulieferern und Medizintechnik-Herstellern.
Mehr zu itemis SECURE
itemis SECURE Screenshot
Unser Angebot

itemis begleitet Sie auf dem gesamten Weg

Jede Phase ist ein eigenständiger Einstieg. Die Lifecycle-Integration steht von Anfang an zur Verfügung, nicht erst am Ende.

01 Understand

CRA Readiness Assessment

  • GAP-Analyse gegen CRA und IEC 62443
  • Produktklassifizierung: Standard, Klasse I oder II
  • Priorisierter Maßnahmenplan mit Fristenbezug

2–5 Tage vom Kick-off bis zum Ergebnis

02 Engineer

Security Engineering

  • TARA mit itemis SECURE
  • Secure Development Lifecycle
  • Prozessaufbau nach IEC 62443‑4‑1

Security-Anforderungen mit Traceability

03 Operate

Lifecycle Operations

  • SBOM-Generierung und -Pflege
  • CVE-Monitoring und VEX-Prozess
  • Vulnerability Management im Support-Zeitraum

Patch-Dokumentation und Nachweis

04 Automate

Compliance Automation

  • Lifecycle-Integration in die Toolchain
  • Automatisch erzeugte Audit-Evidenzen
  • Traceability vom Risiko bis zum Test

Eine Quelle der Wahrheit für alle Nachweise

Unsere Experten
Dirk Leopold

Head of Compliance Intelligence · itemis AG

Alle Artikel →
Dirk Leopold schlägt die Brücke zwischen komplexen Engineering-Anforderungen und Cybersicherheitsstandards in Automotive und Industrial IoT. Als treibende Kraft hinter itemis SECURE verfügt er über Expertise in der Bedrohungsanalyse und Risikobewertung (TARA) sowie in „Security by Design"-Methodiken. Als Redner zeigt er, wie Standards wie die ISO/SAE 21434 und der Cyber Resilience Act (CRA) die Zukunft vernetzter Produkte beeinflussen. Er ist Mitbegründer und President von CRAIG, einer Online-Community zur Einführung des CRA in Europa.
Jens Bühl

Product Owner · itemis AG

Alle Artikel →
Jens Bühl ist Product Owner bei itemis und ist seit 2019 auf Cyber-Security-Engineering sowie modellbasierte Bedrohungs- und Risikoanalysen spezialisiert. Er engagiert sich aktiv für die Standardisierung des openXSAM-Austauschformats in der Automotive Security Research Group (ASRG). Sein Fokus liegt auf der Automatisierung von Security-Prozessen und der Absicherung komplexer cyber-physischer Systeme nach ISO/SAE 21434 und IEC 62443.
Jetzt starten

CRA-Readiness-Assessment buchen

Jetzt Termin mit Dirk Leopold und Jens Bühl vereinbaren.

Beratungsgespräch vereinbaren
Häufige Fragen

Häufige Fragen zum EU Cyber Resilience Act

Löst jede bekannte Schwachstelle die 24-Stunden-Meldepflicht aus?
Nein. Artikel 14 verlangt die Meldung nur bei einer aktiv ausgenutzten Schwachstelle: also einer, bei der die Prüfung mit hinreichender Sicherheit auf eine tatsächliche Ausnutzung deutet. Eine bloß bekannte oder theoretisch mögliche Schwachstelle ohne Hinweise auf Ausnutzung startet die Uhr nicht.
Wann beginnt die 24-Stunden-Frist?
Sie beginnt, sobald der Hersteller nach einer ersten Prüfung mit hinreichender Sicherheit annehmen kann, dass eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Vorfall vorliegt. Die CRA-Leitlinien der Kommission stellen klar, dass die Erstprüfung nicht verschleppt werden darf, um den Fristbeginn hinauszuzögern.
Reicht eine Meldung an ENISA, oder muss ich auch das CSIRT informieren?
Beide Stellen müssen die Meldung parallel erhalten: ENISA und das nationale CSIRT, das in Ihrem Mitgliedstaat unter NIS2 als Koordinator benannt ist. Eine Meldung allein an ENISA erfüllt die Pflicht aus Artikel 14 nicht.
Gilt die Meldepflicht im September 2026 auch für Produkte, die schon im Markt sind?
Ja. Artikel 69 Absatz 3 CRA dehnt die Meldepflicht auf Produkte mit digitalen Elementen aus, die vor dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wurden. Es ist die einzige Regelung des CRA, die Bestandsprodukte auf diese Weise erfasst.
Wer haftet für Schwachstellen in zugekauften oder Open-Source-Komponenten?
Der Hersteller, der das Produkt in Verkehr bringt. Die Meldepflicht knüpft am fertigen Produkt an, nicht an der Herkunft des einzelnen Codebausteins. Schwachstellen in Komponenten Dritter gehören damit in die eigene Schwachstellenbehandlung.
Was ist ein schwerwiegender Cybersicherheitsvorfall im Sinne des CRA?
Ein Vorfall, der die Sicherheit des Produkts mit digitalen Elementen beeinträchtigt. Schweregrad und Relevanz bemessen sich nach Faktoren wie dem Umfang der Auswirkungen, der Zahl betroffener Nutzer und möglichen Folgen für den Betrieb.
Welche Bußgelder drohen bei einem Verstoß gegen die Meldepflicht?
Nach Artikel 64 Absatz 2 bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für Kleinstunternehmen und kleine Unternehmen entfallen Bußgelder wegen einer versäumten 24-Stunden-Frühwarnung. Von der Meldepflicht selbst befreit das niemanden.
Was ist eine CVD-Policy?
Ein veröffentlichter Prozess, über den Sicherheitsforscher, Kunden und andere Stellen Schwachstellen in Ihren Produkten melden können. Nach Anhang I Teil II CRA müssen Hersteller eine CVD-Policy mit einem benannten zentralen Ansprechpartner pflegen und den Austausch über mögliche Schwachstellen aktiv fördern.
Was ist der Unterschied zwischen CRA und NIS2?
NIS2 adressiert die Cybersicherheit von Unternehmenseinheiten und kritischen Infrastrukturen. Der CRA regelt die Sicherheit der Produkte selbst. Ein CRA-konformes Produkt hilft NIS2-pflichtigen Betreibern, ihre eigenen Anforderungen zu erfüllen. Beide Gesetze greifen aber an unterschiedlichen Stellen.
Fachwissen

Insights zum Cyber Resilience Act

Alle Insights zum Cyber Resilience Act