Der EU Cyber Resilience Act (CRA): Alles, was du 2026 wissen musst
🇬🇧 Read in English~11 min read
devopssecuritycomplianceeu-regulationcyber-resilience-actsupply-chainiotopen-source
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Traditionelle Service Meshes wie Istio oder Linkerd sind zu langsam für Multi-Hop-Requests. Eine aktuelle Studie zeigt, wie eBPF Echtzeit-Zugriffskontrolle auf Kernel-Ebene ermöglicht – mit 10x weniger Latency.
Das Wichtigste zuerst: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) macht Cybersicherheit zur gesetzlichen Pflicht für fast jedes Produkt mit digitalen Elementen, das in der EU verkauft wird – Hardware wie Software gleichermaßen. Er ist am 10. Dezember 2024 in Kraft getreten, die Hauptpflichten greifen am 11. Dezember 2027, und die Melde- und Berichtspflichten starten schon am 11. September 2026. Wenn du Software oder vernetzte Hardware für den EU-Markt entwickelst, verkaufst oder integrierst, betrifft dich dieses Gesetz – samt Geldstrafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Umsatzes, je nachdem, was höher ist.
⚡ Kernidee: Bisher war „Security by Design" eine Best Practice. Mit dem CRA ist sie eine rechtliche Pflicht. Nach Ablauf der Übergangsfrist darfst du kein unsicheres Produkt mehr auf den EU-Markt bringen – und du bringst kein Produkt auf den Markt, sondern einen Lebenszyklus inklusive Updates, Schwachstellen-Management und Incident-Meldungen.
Der CRA ist eine horizontale EU-Verordnung (gilt unmittelbar in allen Mitgliedstaaten, keine nationale Umsetzung nötig), die verbindliche Cybersicherheitsanforderungen an Hersteller, Importeure und Händler von Produkten mit digitalen Elementen stellt – also jede Hardware oder Software, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Verbindung zu einem Gerät oder einem Netzwerk einschließt.
Er ist die „Produkt-Hälfte" der EU-Cybersicherheitsstrategie. Die Schwester-Richtlinie NIS2 (EU) 2022/2555 reguliert die Betreiber (Unternehmen, die kritische und wichtige Dienste betreiben); der CRA reguliert die Produkte selbst. Zusammen bilden sie die Antwort der EU auf eine Angriffsfläche, die mit jedem vernetzten Gerät wächst.
Warum jetzt? Die Kommission beziffert die Kosten von Ransomware, IoT-Botnetzen und Supply-Chain-Angriffen für die EU-Wirtschaft auf Milliarden pro Jahr. Die meisten vernetzten Produkte kommen heute mit unsicheren Standardeinstellungen, ohne Updatepfad und ohne koordinierte Offenlegung von Schwachstellen. Der CRA verschiebt die Verantwortung: Es ist nicht mehr die Aufgabe der Nutzer, sicher zu bleiben – der Hersteller muss über den gesamten Lebenszyklus eine Sorgfaltspflicht tragen.
| Datum | Was passiert |
|---|---|
| 23. Okt. 2024 | Verordnung (EU) 2024/2847 angenommen |
| 10. Dez. 2024 | Inkrafttreten (20 Tage nach Veröffentlichung im Amtsblatt) |
| 11. Juni 2026 | Kapitel IV gilt: benannte Stellen, Marktüberwachung, Durchsetzungs-Infrastruktur |
| 11. Sep. 2026 | Meldepflichten (Art. 14) gelten – aktiv ausgenutzte Schwachstellen & schwerwiegende Vorfälle |
| 27. Juli 2026 | Kommission veröffentlicht praktischen Umsetzungsleitfaden |
| 11. Dez. 2027 | Hauptpflichten gelten: wesentliche Anforderungen (Anhang I), Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation, EU-Konformitätserklärung |
Selbst wenn sich „der CRA" nach einem 2027-Thema anhört: Die Meldepflicht ist ab heute (Stand August 2026) nur noch gut ein Jahr entfernt – und die Infrastruktur (benannte Stellen, nationale Behörden) wird gerade aufgebaut. Schon jetzt sind Prüfungen und Konformitätskontrollen gegen den Anforderungsrahmen möglich.
Der CRA wendet sich an Wirtschaftsakteure:
Wichtig: Der CRA erfasst auch Software-Updates – ein Update auszuliefern ist ein Inverkehrbringen. Eine SaaS-Lösung, die du nur selbst betreibst, ist kein „auf den Markt gebrachtes Produkt"; eine On-Premise-Anwendung, Firmware oder ein vertriebenes und monetarisiertes Tool dagegen sehr wohl.
Auslöser des Anwendungsbereichs: Das Produkt muss auf dem Markt bereitgestellt werden – also im Rahmen einer kommerziellen Tätigkeit für den Vertrieb oder die Nutzung geliefert werden (Art. 3 Abs. 22). Genau dieser Satz hält nicht-kommerzielle Open-Source-Software aus den meisten Pflichten heraus.
Alle erfassten Produkte müssen die wesentlichen Anforderungen aus Anhang I erfüllen, in zwei Teilen:
Die SBOM verdient für DevOps-Leser besonderes Gewicht: Du brauchst eine maschinenlesbare Inventarliste aller Komponenten deiner Software – dieselbe Disziplin, die gute Supply-Chain-Sicherheit ohnehin schon verlangt (z. B. für Dependency-Scans).
Produkte werden nach cybersicherheitsrelevanter Bedeutung eingeteilt. Die Konformitätsbewertung (wie du Compliance nachweist) hängt von der Klasse ab:
| Kategorie | Typische Beispiele | Bewertungsweg | Drittpartei? |
|---|---|---|---|
| Standard (~90 % der Produkte) | Apps, die meiste Software, viele Verbrauchergeräte | Selbstbewertung (interne Kontrolle, Modul A) | Nein |
| Wichtig – Klasse I (Anhang III) | Betriebssysteme, VPNs, Passwortmanager, Browser, Router, Smart-Home-Sicherheit, SIEM, Identitäts-/Zugriffsmanagement | Selbstbewertung bei vollständiger Anwendung harmonisierter Normen; sonst EU-Baumusterprüfung (Modul B+C) oder umfassende Qualitätssicherung (Modul H) | Nur ohne/bei teilweisen harmonisierten Normen |
| Wichtig – Klasse II (Anhang III) | Firewalls, IDS/IPS, manipulationssichere Mikroprozessoren/-controller, Hypervisoren, Container-Runtimes | Drittparteien-Bewertung immer | Ja |
| Kritisch (Anhang IV) | Hardware-Sicherheitsboxen, Smart-Meter-Gateways, Smartcards / Secure Elements | EU-Cybersicherheits-Zertifizierung (auf Basis des Cyber Security Act), von der Kommission festgelegt | Ja |
Für die Standard-Kategorie – die große Mehrheit der Software – ist der CRA vergleichsweise mild: ein internes Kontrollverfahren, ein dokumentierter Sicherheitsprozess und die technische Akte. Das ist Absicht: Die EU will Startups nicht für ein Mobile Game in Drittparteien-Audits ertränken. Aber „Selbstbewertung" heißt nicht „keine Arbeit": Die Dokumentation muss existieren, wahrheitsgemäß sein und späterer Marktüberwachung standhalten (die jederzeit Unterlagen anfordern und Kontrollen durchführen kann).
Das musst du vorweisen:
Ein Hersteller, der von einem der folgenden Fälle Kenntnis erlangt, muss über die zentrale Meldeplattform an den koordinierenden CSIRT und an die ENISA melden (Art. 14):
Aktiv ausgenutzte Schwachstellen (im Produkt):
Schwerwiegende Vorfälle mit Auswirkung auf die Sicherheit des Produkts:
Die Fristen laufen ab dem Moment, in dem der Hersteller „Kenntnis erlangt" – Erkennungs- und Eskalationsprozesse müssen also vor Beginn der Pflicht existieren. Anbieter, die Produkte an Unternehmen in NIS2-Sektoren verkaufen, werden Überschneidungen mit den NIS2-Meldeketten feststellen; die zentrale Plattform soll Doppelmeldungen reduzieren.
Das Verhältnis zu Freier und Open-Source-Software (FOSS) war der umstrittenste Punkt während der Ausarbeitung. Der erzielte Kompromiss dreht sich bewusst um Monetarisierung:
Praktische Lesart für Maintainer: Hobby-Projekte und Community-Software: raus. Consulting-Produkt, das du verkaufst: rein. Du verkaufst zur Tarnung ein T-Shirt: immer noch rein – kommerzielle Absicht wird nach Substanz beurteilt, nicht nach Etiketten.
Hersteller müssen einen Support-Zeitraum festlegen, der der erwarteten Nutzungsdauer des Produkts entspricht (Nutzererwartungen, Produktart, Lebensdauer der Komponenten). Regeln:
„Einmal entwickelt, fertig" ist vorbei: Nach 2027 ist das Inverkehrbringen auf dem EU-Markt ein Bekenntnis zur Wartung.
Die Mitgliedstaaten legen den Bußgeldrahmen fest, die Verordnung deckelt ihn (Art. 64):
| Verstoß | Maximales Bußgeld |
|---|---|
| Verstoß gegen die wesentlichen Anforderungen, Konformitätsbewertung, CE-/Rückverfolgbarkeits-Pflichten | 15.000.000 Euro oder 2,5 % des weltweiten Jahresumsatzes (je nachdem, was höher ist) |
| Verstoß gegen Melde-, Support-, Dokumentations- oder weitere gelistete Pflichten | 10.000.000 Euro oder 2 % |
| Unrichtige/irreführende/unvollständige Angaben gegenüber benannten Stellen oder Marktüberwachung | 5.000.000 Euro oder 1 % |
Verwaltungsstrafen gelten nicht für nicht-kommerzielle Open-Source-Entwickler (Art. 64 Abs. 10). Darüber hinaus können Marktüberwachungsbehörden Produkte zurücknehmen oder zurückrufen und die Behebung von Abweichungen anordnen.
Wenn du ein Produkt für den EU-Markt herstellst (oder planst):
Open-Source-Maintainer & Stiftungen: Dokumentiere, dass dein Projekt nicht-kommerziell ist (oder übernimm bewusst die Steward-Rolle), veröffentliche eine CVD-/SECURITY.md, wenn du monetarisierst, und behalte – wie alle – die SBOM-Denkweise.
Unternehmen, die Produkte kaufen: Nutze den CRA als Hebel im Einkauf – fordere CE-gekennzeichnete, CRA-konforme Produkte, die SBOM und das Support-Zeitraum-Versprechen. Ab 2027 gehört das auch zu deiner Compliance-Story unter NIS2 und Vertragsrecht.
Zuletzt aktualisiert: 27. August 2026.