Der Cyber Resilience Act ist eine EU-Verordnung, die erstmals verbindliche Cybersicherheitsanforderungen f\u00fcr nahezu alle Produkte mit digitalen Elementen festlegt \u2013 von vernetzter Hardware bis zu reiner Software. Seit dem 11. September 2026 m\u00fcssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorf\u00e4lle innerhalb von 24 Stunden melden, alle \u00fcbrigen Pflichten greifen ab dem 11. Dezember 2027. Damit r\u00fcckt eine Frage in den Mittelpunkt, die bisher oft als rein technisches Detail galt: Wie weisen Hersteller nach, dass ihre Software, ihre Ger\u00e4te und ihre Updates tats\u00e4chlich von ihnen stammen und unver\u00e4ndert beim Nutzer ankommen?<\/p>\n
Das Wichtigste in K\u00fcrze<\/strong><\/p>\n Der Cyber Resilience Act ist die Verordnung (EU) 2024\/2847 vom 23. Oktober 2024. Er legt Cybersicherheitsanforderungen f\u00fcr Produkte mit digitalen Elementen fest, also f\u00fcr Hardware und Software, die sich direkt oder indirekt mit einem Ger\u00e4t oder Netzwerk verbinden kann. Dazu geh\u00f6ren etwa Router, Smart-Home-Ger\u00e4te, Industriesteuerungen, Firmware und Anwendungssoftware.<\/p>\n Das Ziel des EU Cyber Resilience Act ist, dass Produkte bereits bei ihrer Entwicklung sicher gestaltet werden und \u00fcber ihre gesamte Nutzungsdauer mit Sicherheitsupdates versorgt bleiben. Ob ein Produkt die Anforderungen erf\u00fcllt, weist der Hersteller k\u00fcnftig \u00fcber die CE-Kennzeichnung nach. Der vollst\u00e4ndige Verordnungstext<\/a> liegt auf EUR-Lex auch in deutscher Sprache vor; eine Zusammenfassung des Cyber Resilience Act<\/a> hat die EU-Kommission ver\u00f6ffentlicht.<\/p>\n Der CRA richtet sich an alle, die Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen. Das betrifft vernetzte Ger\u00e4te ebenso wie reine Software: Auch Anwendungen, die unabh\u00e4ngig von einer bestimmten Hardware vertrieben werden, fallen unter den Cyber Resilience Act. Die meisten Pflichten treffen die Hersteller; Importeure und H\u00e4ndler m\u00fcssen pr\u00fcfen, ob die Produkte, die sie verkaufen, die Anforderungen erf\u00fcllen.<\/p>\n Die Verordnung unterscheidet zwischen Standardprodukten, wichtigen Produkten der Klassen I und II sowie kritischen Produkten. F\u00fcr die meisten Produkte k\u00f6nnen Hersteller die Konformit\u00e4t selbst bewerten, f\u00fcr wichtige und kritische Produkte gelten strengere Verfahren bis hin zur Pr\u00fcfung durch eine unabh\u00e4ngige Stelle. Ausgenommen sind Produkte, f\u00fcr die bereits eigene Sicherheitsregeln bestehen, etwa Medizinprodukte oder Kraftfahrzeuge. Reine Cloud-Dienste ohne zugeh\u00f6riges Produkt fallen in der Regel nicht unter den CRA; f\u00fcr sie ist vor allem NIS2 ma\u00dfgeblich.<\/p>\n Bei Open-Source-Software kommt es darauf an, wie sie bereitgestellt wird. Wer freie Software ohne Gesch\u00e4ftst\u00e4tigkeit ver\u00f6ffentlicht, bringt sie im Sinne der Verordnung nicht in Verkehr. Organisationen, die Open-Source-Projekte dauerhaft f\u00fcr die kommerzielle Nutzung unterst\u00fctzen, gelten dagegen als sogenannte Open-Source-Software-Stewards; f\u00fcr sie sieht die Verordnung ein eigenes, leichteres Pflichtenprogramm vor.<\/p>\n Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten, seine Pflichten greifen aber schrittweise:<\/p>\n F\u00fcr Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gelten die Anforderungen nur dann, wenn sie danach wesentlich ver\u00e4ndert werden. Die Meldepflicht ist davon ausdr\u00fccklich ausgenommen.<\/p>\n Seit dem 11. September 2026 m\u00fcssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten und schwerwiegende Sicherheitsvorf\u00e4lle melden, die sich auf die Sicherheit eines Produkts auswirken. Die Meldung erfolgt in drei Stufen:<\/p>\n Die Meldungen gehen \u00fcber eine zentrale Plattform der EU-Agentur f\u00fcr Cybersicherheit ENISA an ENISA und an das zust\u00e4ndige nationale CSIRT, in Deutschland an das BSI<\/a>. Zus\u00e4tzlich m\u00fcssen Hersteller die betroffenen Nutzer \u00fcber die Schwachstelle und m\u00f6gliche Gegenma\u00dfnahmen informieren.<\/p>\n Besonders folgenreich ist der Anwendungsbereich: Nach Artikel 69 Absatz 3 gilt die Meldepflicht auch f\u00fcr Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Wer heute ein Produkt verkauft, das seit Jahren auf dem Markt ist, muss eine aktiv ausgenutzte Schwachstelle darin also schon jetzt melden.<\/p>\n Die grundlegenden Sicherheitsanforderungen stehen in Anhang I der Verordnung und gelten ab dem 11. Dezember 2027. Produkte d\u00fcrfen bei ihrer Bereitstellung keine bekannten ausnutzbaren Schwachstellen enthalten, m\u00fcssen mit einer sicheren Standardkonfiguration ausgeliefert werden und w\u00e4hrend eines Unterst\u00fctzungszeitraums Sicherheitsupdates erhalten. Dieser Zeitraum betr\u00e4gt in der Regel mindestens f\u00fcnf Jahre, sofern die erwartete Nutzungsdauer nicht k\u00fcrzer ist.<\/p>\n Hinter diesen Anforderungen steht ein Gedanke, der sich durch die gesamte Verordnung zieht: Ein Produkt ist nur so sicher wie der Weg, auf dem Software und Updates zu ihm gelangen. Der CRA verlangt deshalb, dass die Integrit\u00e4t von Software gesch\u00fctzt und Sicherheitsupdates sicher bereitgestellt werden. Ein bestimmtes technisches Verfahren schreibt er daf\u00fcr nicht vor, und auch Code Signing nennt er nicht ausdr\u00fccklich. In der Praxis setzen Hersteller aber an drei Stellen an.<\/p>\n Nutzer und Systeme m\u00fcssen erkennen k\u00f6nnen, ob eine Software oder ein Update tats\u00e4chlich vom Hersteller stammt und unterwegs nicht ver\u00e4ndert wurde. Genau das leistet eine digitale Signatur mit einem Code-Signing-Zertifikat<\/a>: Sie belegt die Herkunft einer Software und macht jede nachtr\u00e4gliche Ver\u00e4nderung sichtbar. Code Signing ist damit zwar keine Pflicht aus der Verordnung, aber eines der etablierten Mittel, mit denen Hersteller die Anforderungen an Integrit\u00e4t und sichere Updates erf\u00fcllen und nachweisen k\u00f6nnen.<\/p>\n Viele Entwicklungsteams verankern Code Signing in ihrer Softwareentwicklung<\/a> als festen Schritt vor jeder Ver\u00f6ffentlichung. Wer die Signatur automatisiert in Build- und Release-Abl\u00e4ufe einbindet<\/a>, stellt zudem sicher, dass kein Update unsigniert ausgeliefert wird. Das wird umso wichtiger, als Code-Signing-Zertifikate seit dem 1. M\u00e4rz 2026 nur noch h\u00f6chstens 460 Tage g\u00fcltig<\/a> sein d\u00fcrfen und damit h\u00e4ufiger erneuert werden m\u00fcssen.<\/p>\n Bei vernetzten Produkten reicht es nicht, nur die Software zu signieren. Jedes Ger\u00e4t muss sich gegen\u00fcber Servern und anderen Ger\u00e4ten eindeutig ausweisen k\u00f6nnen, und es darf nur Firmware-Updates annehmen, die nachweislich vom Hersteller stammen. Beides l\u00e4sst sich mit Ger\u00e4tezertifikaten<\/a> umsetzen, die jedem Ger\u00e4t eine eigene digitale Identit\u00e4t geben.<\/p>\n Bei Tausenden oder Millionen von Ger\u00e4ten ist das allerdings nur mit einer Infrastruktur zu bew\u00e4ltigen, die Zertifikate automatisiert ausstellt, erneuert und bei Bedarf widerruft. Solche PKI-L\u00f6sungen f\u00fcr IoT-Ger\u00e4te<\/a> verwalten Ger\u00e4teidentit\u00e4ten \u00fcber den gesamten Lebenszyklus und passen damit zum Unterst\u00fctzungszeitraum, den der CRA verlangt.<\/p>\n Kaum ein Produkt besteht ausschlie\u00dflich aus eigenem Code. Bibliotheken, Open-Source-Komponenten und zugekaufte Module machen oft den gr\u00f6\u00dferen Teil aus. Der CRA stellt klar, dass der Hersteller auch f\u00fcr diese Bestandteile verantwortlich ist: Er muss Schwachstellen darin erkennen, dokumentieren und beheben. Das gilt ausdr\u00fccklich auch f\u00fcr freie Software, die in ein kommerzielles Produkt eingebunden wird. Zur Dokumentation geh\u00f6rt eine Software-St\u00fcckliste, die Software Bill of Materials (SBOM)<\/a>.<\/p>\n Dass diese Verantwortung keine Formalie ist, zeigen Angriffe auf die Software-Lieferkette<\/a>, bei denen Schadcode \u00fcber vertrauensw\u00fcrdige Komponenten in Produkte gelangt. Umso wichtiger ist es, bekannte Sicherheitsl\u00fccken schnell zu schlie\u00dfen<\/a>, auch in Bestandteilen, die nicht aus der eigenen Entwicklung stammen. Signierte Komponenten und Updates machen dabei sichtbar, ob ein Bestandteil auf dem Weg durch die Lieferkette manipuliert wurde.<\/p>\n Bei Verst\u00f6\u00dfen gegen die Sicherheitsanforderungen oder gegen die Pflichten der Hersteller einschlie\u00dflich der Meldepflicht drohen Bu\u00dfgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag h\u00f6her ist. F\u00fcr Verst\u00f6\u00dfe gegen weitere Pflichten, etwa die von Importeuren und H\u00e4ndlern, liegt die Obergrenze bei 10 Millionen Euro oder 2 Prozent, f\u00fcr falsche oder irref\u00fchrende Angaben gegen\u00fcber Beh\u00f6rden bei 5 Millionen Euro oder 1 Prozent. Zus\u00e4tzlich k\u00f6nnen Markt\u00fcberwachungsbeh\u00f6rden anordnen, dass nicht konforme Produkte vom Markt genommen oder zur\u00fcckgerufen werden.<\/p>\n F\u00fcr Kleinst- und Kleinunternehmen sieht die Verordnung eine Erleichterung vor: Vers\u00e4umen sie die 24-Stunden-Frist f\u00fcr die Fr\u00fchwarnung, wird daf\u00fcr kein Bu\u00dfgeld verh\u00e4ngt. Die \u00fcbrigen Meldefristen gelten f\u00fcr sie jedoch uneingeschr\u00e4nkt.<\/p>\n Der Cyber Resilience Act regelt die Sicherheit von Produkten, unabh\u00e4ngig davon, wer sie herstellt. NIS2 regelt dagegen die Sicherheit von Einrichtungen in bestimmten Sektoren. Als Richtlinie musste sie erst in nationales Recht \u00fcbertragen werden; die NIS2-Umsetzung in Deutschland<\/a> erfolgte durch ein eigenes Gesetz. Ein Unternehmen kann von beiden zugleich betroffen sein: als Hersteller eines Produkts vom CRA und als Betreiber wichtiger Dienste von NIS2. Gemeinsam mit eIDAS und DORA geh\u00f6ren beide Regelwerke zur europ\u00e4ischen Cyber-Regulierung<\/a>, mit der die EU die digitale Sicherheit auf mehreren Ebenen st\u00e4rkt.<\/p>\n Mit dem CRA wird Cybersicherheit von einer freiwilligen Qualit\u00e4tsfrage zu einer Voraussetzung f\u00fcr den Marktzugang. Am unmittelbarsten wirkt die Meldepflicht: Eine Fr\u00fchwarnung innerhalb von 24 Stunden setzt voraus, dass Schwachstellen rechtzeitig bekannt werden und dass klar ist, wer im Unternehmen \u00fcber eine Meldung entscheidet. Da die Pflicht auch Bestandsprodukte umfasst, betrifft sie das gesamte Portfolio.<\/p>\n Bis Dezember 2027 r\u00fccken zudem die Lieferkette und die Auslieferung in den Mittelpunkt. Wer Komponenten von Dritten einsetzt, muss deren Schwachstellen kennen und beheben k\u00f6nnen. Und wer \u00fcber Jahre hinweg Sicherheitsupdates liefert, muss \u00fcber diesen gesamten Zeitraum belegen k\u00f6nnen, dass jedes Update unver\u00e4ndert vom Hersteller stammt. Signatur und Ger\u00e4teidentit\u00e4t werden damit von einer technischen Einzelentscheidung zu einem Baustein der Produktverantwortung.<\/p>\n Einen kompakten Einstieg in Geltungsbereich, Meldepflichten und Fristen bietet die halbt\u00e4gige Online-Schulung zum EU Cyber Resilience Act<\/a> von PSW TRAINING. Sie richtet sich an Gesch\u00e4ftsf\u00fchrung, IT-Leitung und Informationssicherheit sowie an Verantwortliche f\u00fcr Compliance und Produktsicherheit.<\/p>\n Der Cyber Resilience Act macht Cybersicherheit zur Pflicht f\u00fcr nahezu alle Produkte mit digitalen Elementen, die in der EU verkauft werden. Die Meldepflicht gilt bereits und erfasst auch Produkte, die l\u00e4ngst auf dem Markt sind. Bis Dezember 2027 bleibt Zeit, Entwicklung, Lieferkette und Auslieferung so aufzustellen, dass jedes Produkt und jedes Update nachweisbar vom Hersteller stammt \u2013 mit signierter Software, eindeutigen Ger\u00e4teidentit\u00e4ten und einem klaren Blick auf die Komponenten, die aus fremden Quellen kommen.<\/p>\n\n
Was ist der Cyber Resilience Act?<\/h2>\n
F\u00fcr wen gilt der Cyber Resilience Act?<\/h2>\n
Die Fristen des Cyber Resilience Act<\/h2>\n
\n
Die Meldepflicht seit dem 11. September 2026<\/h2>\n
\n
Integrit\u00e4t, Signatur und Lieferkette: Was der CRA f\u00fcr die Software-Auslieferung bedeutet<\/h2>\n
Software und Updates: die Rolle von Code Signing<\/h3>\n
Vernetzte Ger\u00e4te: Identit\u00e4t und Firmware absichern<\/h3>\n
Die Lieferkette: Verantwortung f\u00fcr fremde Komponenten<\/h3>\n
Sanktionen bei Verst\u00f6\u00dfen<\/h2>\n
Cyber Resilience Act und NIS2: der Unterschied<\/h2>\n
Was die Verordnung f\u00fcr Hersteller bedeutet<\/h2>\n
Der Weg bis Dezember 2027<\/h2>\n