Definition
EU-Verordnung zur Cybersicherheit von Produkten mit digitalen Elementen. In Kraft seit Dezember 2024, vollständige Anwendung ab 11. Dezember 2027 — ohne Übergangsfrist. Hersteller müssen Secure-by-Design, Schwachstellenmanagement über den Lebenszyklus, SBOM-Pflicht und CE-Konformitätsbewertung für Cybersicherheit nachweisen. Bußgelder bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Meldepflicht für aktiv ausgenutzte Schwachstellen an ENISA ab September 2026.
In der Praxis
Der Cyber Resilience Act ist die erste horizontale Produktsicherheits-Verordnung für Cybersicherheit — und der häufigste Fehler ist, ihn für ein IT-Thema zu halten. Wer eine Maschine, ein Steuergerät oder ein Messgerät mit Software in der EU in Verkehr bringt, ist Hersteller im Sinne der Verordnung: Das Produkt muss beim Inverkehrbringen den grundlegenden Anforderungen entsprechen (Secure by Design), es darf keine bekannten ausnutzbaren Schwachstellen enthalten, und Sicherheitsaktualisierungen müssen unverzüglich, kostenlos und — soweit technisch machbar — getrennt von Funktionsupdates bereitgestellt werden. Dazu gehören eine dokumentierte Cybersicherheits-Risikobewertung, die über den gesamten Unterstützungszeitraum aktuell gehalten wird, und eine maschinenlesbare Software-Stückliste (SBOM) — für viele Maschinenbauer mit eingebetteter Software eine völlig neue Disziplin. Zeitkritisch: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten bereits ab dem 11. September 2026, die Hauptanforderungen ab dem 11. Dezember 2027. Wer heute Produkte entwickelt, die 2027 noch verkauft werden, muss die Anforderungen jetzt in den Entwicklungsprozess ziehen.
Verwandte Begriffe
Häufige Fragen zu Cyber Resilience Act
Wir bauen Maschinen, keine Software — betrifft uns der CRA überhaupt?
Sehr wahrscheinlich ja. Der CRA gilt für Produkte mit digitalen Elementen, und dazu zählt jede Maschine mit Steuerung, Firmware oder vernetzter Komponente. Hersteller im Sinne der Verordnung ist, wer ein solches Produkt entwickelt, herstellt oder herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet — unabhängig davon, ob die Software selbst entwickelt oder zugekauft wurde. Nach Art. 13 Abs. 1 CRA muss das Produkt beim Inverkehrbringen den grundlegenden Cybersicherheitsanforderungen entsprechen; Nachweisweg ist die Konformitätsbewertung nach Art. 32 mit EU-Konformitätserklärung (Art. 28) und CE-Kennzeichnung (Art. 30). Prüfen Sie Ihr Produktportfolio jetzt: Alles mit Software, Schnittstelle oder Fernwartung gehört auf die CRA-Liste.
Welche Meldepflichten kommen auf uns zu — und ab wann gelten sie?
Die Meldepflichten des Art. 14 CRA gelten bereits ab dem 11. September 2026, also über ein Jahr vor den übrigen Hauptanforderungen (Art. 71 CRA). Gemeldet werden müssen zwei Fälle: aktiv ausgenutzte Schwachstellen im eigenen Produkt und schwerwiegende Sicherheitsvorfälle — jeweils gleichzeitig an das zuständige CSIRT und die ENISA über die einheitliche Meldeplattform. Bei beiden Fällen gilt: Frühwarnung unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung, Meldung binnen 72 Stunden. Der Abschlussbericht unterscheidet sich: bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, bei schwerwiegenden Vorfällen binnen eines Monats nach der ersten Meldung (Art. 14 Abs. 2 und 4 CRA). Sie brauchen dafür einen funktionierenden Schwachstellen-Management-Prozess — wer nicht weiß, welche Software in seinen Produkten steckt, kann nicht melden, was er nicht kennt.
Wie bauen wir praktisch eine SBOM für unsere Produkte auf?
Anhang I Nr. 1 lit. d CRA verlangt eine maschinenlesbare Software-Stückliste, die mindestens die obersten Abhängigkeiten des Produkts erfasst. Praktisch heißt das: Generieren Sie die SBOM aus dem Build-Prozess heraus, nicht per Hand — Werkzeuge dafür existieren für alle gängigen Toolchains und erzeugen Formate wie SPDX oder CycloneDX. Erfassen Sie neben eigener Software alle eingebetteten Bibliotheken, Betriebssystem-Komponenten und Open-Source-Pakete. Die SBOM ist kein einmaliges Dokument: Sie gehört ins Änderungsmanagement und wird mit jeder Produktversion neu erzeugt. Der eigentliche Nutzen zeigt sich im Betrieb: Nur mit aktueller SBOM können Sie bei jeder neu veröffentlichten Schwachstelle in Stunden statt Wochen beantworten, ob Ihre Produkte betroffen sind. Hersteller von Medizinprodukt-Software kennen die Logik bereits aus dem Umfeld der IEC 62304 — hier wird sie querschnittlich Pflicht.