Der Cyber Resilience Act für vernetzte Produkte: was Hersteller jetzt tun müssen

Wenn Sie ein Produkt mit einem Chip, einem Funkmodul oder einem Software-Update-Mechanismus bauen und es in der Europäischen Union verkaufen, ist der Cyber Resilience Act kein Zukunftsthema mehr.

Die Verordnung (EU) 2024/2847 ist im Dezember 2024 in Kraft getreten. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden. Ab dem 11. Dezember 2027 gilt der Großteil der übrigen Pflichten, einschließlich der Sicherheitsanforderungen, die ein Produkt für die CE-Kennzeichnung erfüllen muss.

Ich bin kein Jurist, und dies ist keine Rechtsberatung. Aber ich arbeite seit Jahren an Embedded-Security-Produkten und sehe in vielen Teams dasselbe Muster: Die Verordnung wird als Compliance-Dokument gelesen, obwohl das meiste, was sie verlangt, eine technische Fähigkeit ist.

Was sich im September 2026 geändert hat

Die erste durchsetzbare Pflicht ist die Meldung. Erfährt ein Hersteller von einer aktiv ausgenutzten Schwachstelle in einem seiner Produkte oder von einem schwerwiegenden Sicherheitsvorfall, muss er innerhalb von 24 Stunden eine Frühwarnung über die zentrale Meldeplattform der ENISA abgeben.

Zwei Details sind wichtig.

• Die Pflicht gilt auch für Produkte, die bereits auf dem Markt sind, nicht nur für neue.
• Vierundzwanzig Stunden reichen nicht, um mit der Informationssuche zu beginnen. Sie reichen nur, um Informationen zu nutzen, die man bereits hat.

Die eigentliche Frage lautet also nicht „Kennen wir die Regel?“, sondern „Können wir in wenigen Stunden sagen, welche unserer Produkte die betroffene Komponente enthalten, welche Versionen im Feld sind und wer für die Behebung verantwortlich ist?“.

Was ab Dezember 2027 gilt

Ab Dezember 2027 gelten die grundlegenden Anforderungen des CRA vollständig. Praktisch heißt das: Produkte mit digitalen Elementen müssen über ihren gesamten Support-Zeitraum sicher konzipiert und gepflegt werden. Dazu gehören unter anderem:

• keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen;
• sichere Standardkonfigurationen;
• die Möglichkeit, Sicherheitsupdates bereitzustellen, wenn möglich getrennt von Funktionsupdates;
• Schutz von Vertraulichkeit und Integrität der Daten, auch durch Kryptografie nach dem Stand der Technik;
• ein Prozess für den Umgang mit Schwachstellen und eine Software-Stückliste (SBOM);
• ein festgelegter, den Nutzern mitgeteilter Support-Zeitraum.

Verstöße können teuer werden: Bei den grundlegenden Anforderungen reichen die Bußgelder bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Der unterschätzte Teil: wissen, was im Produkt steckt

Jede der genannten Pflichten hängt von einer Sache ab: einem genauen, aktuellen Bild davon, woraus Ihr Produkt besteht.

Nicht nur eine Liste von Softwarekomponenten. Ein Bild davon, wie sie zusammenhängen.

• Welches Firmware-Image läuft auf welcher Hardware-Revision?
• Welche Schlüssel signieren welche Updates?
• Welche Zertifikate begründen die Identität eines Geräts?
• Welche Drittbibliotheken übernehmen die Kryptografie, und in welchen Versionen?

Viele Organisationen haben diese Informationen. Sie sind nur über Entwicklungsteams, Fertigungssysteme, Lieferanten und alte Dokumentation verteilt. Das funktioniert bis zu dem Tag, an dem man 24 Stunden zum Handeln hat.

Kryptografie gehört zum „Stand der Technik“

Der CRA nennt keine konkreten Algorithmen. Er verlangt einen Schutz, der dem Stand der Technik entspricht.

Dieser Begriff hat einen Zeitplan. Das NIST hat im August 2024 seine ersten Standards für Post-Quanten-Kryptografie veröffentlicht. Die koordinierte Roadmap der Europäischen Union fordert die Mitgliedstaaten auf, die Umstellung bis Ende 2026 zu beginnen und Anwendungsfälle mit hohem Risiko bis 2030 zu schützen. Ein vernetztes Produkt, das 2028 mit zehn oder fünfzehn Jahren Support auf den Markt kommt, wird mitten in diesem Übergang leben.

Das heißt nicht, dass jedes Produkt morgen mit Post-Quanten-Algorithmen ausgeliefert werden muss. Es heißt, dass Sie wissen müssen, wo Ihre Kryptografie steckt und wie Sie sie ändern würden. Mehr dazu in Warum ich Shorium aufbaue.

Womit ich anfangen würde

Wäre ich heute für ein Portfolio vernetzter Produkte verantwortlich, würde ich vier Dinge tun, in dieser Reihenfolge.

1. Die betroffenen Produkte erfassen. Welche Produkte haben digitale Elemente, welche sind auf dem Markt, und welchen Support-Zeitraum können Sie realistisch zusagen?
2. Das Inventar aufbauen, das Sie in einer Krise brauchen. Komponenten, Versionen, Schlüssel, Zertifikate und Lieferanten, verknüpft mit den Produkten und Versionen im Feld. Eine SBOM ist der Anfang, nicht das Ende.
3. Die 24-Stunden-Meldung üben. Nehmen Sie eine echte Schwachstelle aus dem letzten Jahr und messen Sie, wie lange die Antwort dauert: betroffene Produkte, betroffene Versionen, Verantwortliche, Gegenmaßnahme.
4. Die Update-Kette prüfen. Können Sie jedem noch unterstützten Produkt ein signiertes Sicherheitsupdate liefern? Was passiert, wenn sich ein Signaturschlüssel oder ein Algorithmus ändern muss?

Keiner dieser Schritte erfordert am ersten Tag ein neues Werkzeug. Sie erfordern jemanden, der die Verantwortung für die Frage übernimmt.

Die Chance in der Pflicht

Man kann den CRA leicht als Kostenfaktor lesen. Ich sehe ihn auch als Antrieb.

Teams, die ihre Produkte klar sehen und sicher ändern können, bauen bessere Produkte. Die Verordnung legt nur das Datum fest, ab dem diese Fähigkeit nicht mehr optional ist.

Wenn Sie sich austauschen möchten, wie Ihre Organisation damit umgeht, schreiben Sie mir.