Der EU Cyber Resilience Act (CRA): Alles, was du 2026 wissen musst

Der EU Cyber Resilience Act (CRA): Alles, was du 2026 wissen musst

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.

---

Was ist der CRA?

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.

---

Die Timeline (das ist für die Planung entscheidend)

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.

---

Wen betrifft der CRA?

Der CRA wendet sich an Wirtschaftsakteure:

• Hersteller – die Person, die das Produkt unter ihrem Namen oder ihrer Marke auf den Markt bringt. Dazu gehören auch reine Software-Produkte, die in der EU vertrieben werden.
• Importeure – in der EU ansässige Unternehmen, die Produkte von außerhalb der EU auf den Markt bringen.
• Händler – alle in der Lieferkette, die ein Produkt in der EU verfügbar machen.
• Bevollmächtigte – in der EU ansässige Stellen, die von Nicht-EU-Herstellern mandatiert sind.
• „Open-Source-Software-Stewards" – Stiftungen/komerzielle Unterstützer, die ein FOSS-Projekt systematisch fördern (siehe Abschnitt Open Source).

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.

Was ausdrücklich ausgenommen ist

• Medizinprodukte (MDR, IVDR), Luftfahrt (Verordnung 2018/1139), Fahrzeuge (Verordnung 2019/2144), Schiffsausrüstung
• Produkte für nationale Sicherheit / Verteidigung / Verschlusssachen
• Ersatzteile in identischer Spezifikation vom Originalhersteller
• Produkte, die ausschließlich für den eigenen Gebrauch entwickelt wurden (intern, nicht auf den Markt gebracht)

---

Die Kernpflichten

Alle erfassten Produkte müssen die wesentlichen Anforderungen aus Anhang I erfüllen, in zwei Teilen:

Teil I – „Security by Design"-Eigenschaften des Produkts

• Sicherheit über den gesamten Lebenszyklus: Risikobewertung, sichere Standardeinstellungen, minimale Angriffsfläche
• Schutz von Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Funktionen (auch vor unbefugtem Zugriff)
• Authentifizierung, Identitäts- und Zugriffskontroll-Management; Kontrolle des Zugriffs von Software-/Hardware-Komponenten
• Datensicherheit: Verschlüsselung, Integritätsprüfungen, sicheres Löschen
• Begrenzung der Angriffsfläche (Least Privilege, minimale Schnittstellen)
• Automatisiertes und manuelles Incident-Handling (erkennen, protokollieren, melden, alarmieren)
• Transparenz und Benutzerfreundlichkeit: sichere Einrichtung, Konfiguration und Überwachung; sicherheitsrelevante Informationen in klarer Sprache

Teil II – Schwachstellen-Management (die Sorgfaltspflicht des Herstellers)

• Schwachstellen erfassen und dokumentieren, u. a. über eine Software-Stückliste (SBOM)
• Schwachstellen beheben, auch durch Sicherheitsupdates, kostenlos, während des Support-Zeitraums
• Keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen
• Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD) mit Ansprechpartner für Forschende
• Sicherheitsupdates getrennt von Feature-Updates, soweit technisch machbar – und standardmäßig aktiviert (Opt-out möglich)
• Update-Mechanismen, die Sicherheit und Funktionalität trennen und das Produkt nicht beschädigen
• Weitergabe von Schwachstellen-Informationen (ggf. aggregiert) an nachgelagerte Hersteller

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).

---

Konformitätsbewertung – in welcher „Klasse" ist dein Produkt?

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:

• Risikobewertung + technische Dokumentation (aufbewahrt für 10 Jahre nach Inverkehrbringen bzw. bis zum Ende des Support-Zeitraums – je nachdem, was länger ist)
• EU-Konformitätserklärung (Anhang V)
• CE-Kennzeichnung am Produkt (durch den Hersteller)
• Bevollmächtigter in der EU (für Nicht-EU-Hersteller)
• Rückverfolgbarkeits-Infos zur Erreichbarkeit von Herstellern/Importeuren (10 Jahre nach Kauf)

---

Meldepflichten (ab 11. September 2026)

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):

• 24 Stunden → Frühwarnung (welche Mitgliedstaaten betroffen sind)
• 72 Stunden → Schwachstellen-Meldung (Art der Schwachstelle, Ausnutzung, Gegenmaßnahmen)
• ≤ 14 Tage nach Verfügbarkeit eines Fixes → Abschlussbericht (Schwere, Auswirkungen, ggf. Angreifer, das Update)

Schwerwiegende Vorfälle mit Auswirkung auf die Sicherheit des Produkts:

• 24 Stunden → Frühwarnung
• 72 Stunden → Vorfall-Meldung (Art, erste Bewertung, Gegenmaßnahmen)
• innerhalb eines Monats → Abschlussbericht (detaillierte Beschreibung, Ursache, ergriffene Maßnahmen)

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.

---

Open Source und der CRA – der Teil, über den alle streiten

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:

• Der CRA gilt für Wirtschaftsakteure nur bei Produkten, die im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt werden (Art. 3 Abs. 22 i. V. m. Erwägungsgrund 18).
• Nicht-kommerzielle FOSS – auch Projekte, die Spenden ohne Gewinnabsicht annehmen, Herstellerfinanzierung erhalten oder regelmäßige Releases veröffentlichen – ist nicht „auf dem Markt bereitgestellt". Einzelne Beitragende sind ausdrücklich ausgenommen.
• Allein die Finanzierung oder Mitarbeit an einem FOSS-Projekt macht dich nicht zum CRA-Hersteller dafür (Erwägungsgrund 18).
• Monetarisierte FOSS ist im Anwendungsbereich: Wenn du deine Software verkaufst oder über kostenpflichtige Support-/Commercial-Dienste hinaus ein Geschäftsmodell hast, oder über eine Plattform monetarisierst – bist du Hersteller wie jeder andere Anbieter.
• Gemeinnützige Entwicklungsorganisationen gelten nicht als kommerziell tätig, wenn alle Einnahmen nach Kosten in die gemeinnützigen Ziele fließen.
• Open-Source-Software-Stewards (Stiftungen, kommerzielle Unterstützer, die ein FOSS-Produkt für kommerzielle Nutzung systematisch fördern) unterliegen einem abgespeckten Regime: Hauptsächlich Schwachstellen-Management und Meldepflichten, nicht die volle Konformitätsmaschinerie.
• Wiederverkäufer von Open Source haben im Wesentlichen nur Händlerpflichten.

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.

---

Support-Zeiträume

Hersteller müssen einen Support-Zeitraum festlegen, der der erwarteten Nutzungsdauer des Produkts entspricht (Nutzererwartungen, Produktart, Lebensdauer der Komponenten). Regeln:

• Mindestens 5 Jahre (bzw. die erwartete Nutzungsdauer, wenn kürzer)
• Während des Support-Zeitraums veröffentlichte Sicherheitsupdates müssen mindestens 10 Jahre nach Veröffentlichung verfügbar bleiben (bzw. für den Rest des Support-Zeitraums, je nachdem, was länger ist)
• Die Kommission kann per delegiertem Rechtsakt Mindest-Supportzeiträume für bestimmte Kategorien anheben

„Einmal entwickelt, fertig" ist vorbei: Nach 2027 ist das Inverkehrbringen auf dem EU-Markt ein Bekenntnis zur Wartung.

---

Strafen

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.

---

Was du jetzt tun solltest (Checkliste)

Wenn du ein Produkt für den EU-Markt herstellst (oder planst):

1. Bestimme deine Rolle – Hersteller, Importeur, Händler oder ggf. „Steward". Halte sie mit deinem Rechtsberater fest.
2. Erstelle die Cybersicherheits-Risikobewertung noch heute; ordne sie den Anforderungen aus Anhang I Teil I zu. Sie ist auch dein Design-Blueprint.
3. Baue eine SBOM und eine Bestandsliste von Abhängigkeiten/Komponenten jetzt auf – nachrüsten ist später schmerzhaft.
4. Richte Schwachstellen-Management ein: Ansprechpartner, CVD-Richtlinie, Triage-Prozess, Fix-Release-Pipeline. Das sollte mit deinem Incident-Management verzahnt sein.
5. Klassifiziere deine Konformitätsklasse ehrlich. Bei Klasse I/II: benannte Stelle organisieren (es sind erst wenige benannt – frühe Bewegung sichert Termine).
6. Bereite die technische Akte vor: Risikobewertung, Design/Architektur, Testergebnisse, Rückverfolgbarkeit – 10 Jahre Aufbewahrung.
7. Plane die Meldungen ab 11. Sep. 2026: Die interne Eskalation muss einen „Kenntnis-Zeitstempel" schneller als 24 Stunden erzeugen.
8. Veröffentliche ein Support-Zeitraum-Versprechen samt Update- und Verfügbarkeitsbedingungen.
9. Bei Produkten in NIS2-Sektoren CRA- und NIS2-Meldungen harmonisieren, damit du keine doppelte Arbeit hast.
10. Beobachte die Normen: harmonisierte Normen und der Leitfaden der Kommission vom 27. Juli 2026 liefern das „Wie".

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.

---

Wie der CRA zu anderen EU-Regeln passt

• NIS2: reguliert Betreiber wesentlicher/wichtiger Dienste (Meldung schwerwiegender Vorfälle, Supply-Chain-Sicherheit). CRA-Produkte stecken oft in NIS2-Organisationen – die zentrale Meldeplattform reduziert Reibung.
• Delegierte Rechtsakte der RED (Funkanlagen-Richtlinie): Cybersicherheit für internetfähige Funkgeräte gilt seit 1. Aug. 2025 für neue Geräte – der CRA wird diese Überschneidung für solche Produkte weitgehend ablösen.
• AI Act / Maschinenverordnung / GPSR: separate, aber überlappende Produktsicherheitsregime; der CRA erkennt Synergien ausdrücklich an, wo sektorale Regeln dieselben Risiken bereits abdecken.

Ressourcen

• Rechtstext: Verordnung (EU) 2024/2847 auf EUR-Lex (CELEX 32024R2847)
• Kommission: Cyber-Resilience-Act-Seite + praktischer Leitfaden (veröffentlicht am 27. Juli 2026)
• ENISA: zentrale Meldeplattform für Schwachstellen-/Vorfallmeldungen
• Dieser Artikel gibt den Stand der Verordnung vom August 2026 wieder – prüfe delegierte Rechtsakte und harmonisierte Normen regelmäßig, sie entwickeln sich schnell.

Zuletzt aktualisiert: 27. August 2026.