Cyber Resilience Act: Was er von Hardware fordert

Zwei Daten, und das nähere wird übersehen

Die Verordnung (EU) 2024/2847, der Cyber Resilience Act (CRA), erfasst „Produkte mit digitalen Elementen”, die auf dem EU-Markt bereitgestellt werden. Praktisch heißt das: alles mit Firmware. Bei Consumer- und Gesundheitshardware also nahezu jedes Produkt, das heute ausgeliefert wird.

In den meisten Planungsunterlagen steht ein Datum: 11. Dezember 2027. Ab dann gilt die volle Konformität, und ein nicht konformes Produkt darf nicht mehr in Verkehr gebracht werden. Danach richten sich die Roadmaps.

Zuerst kommt allerdings ein anderes: 11. September 2026, der Beginn der Meldepflichten nach Artikel 14. Es wird übersehen, weil es keine Produktentwicklungsfrist ist und deshalb in keinem Hardware-Terminplan auftaucht.

Es sollte dort auftauchen. Warum, steht unten.

Die Meldeuhr greift rückwärts

Ab dem 11. September 2026 gilt für Hersteller, die von einer aktiv ausgenutzten Schwachstelle in ihrem Produkt oder von einem schwerwiegenden Sicherheitsvorfall Kenntnis erlangen, eine gestufte Uhr:

Stufe	Frist ab Kenntnis
Frühwarnung	24 Stunden
Technische Meldung	72 Stunden
Abschlussbericht	14 Tage (ausgenutzte Schwachstelle) / 1 Monat (schwerer Vorfall)

Adressaten sind die ENISA und das zuständige nationale CSIRT.

Der Teil, den man zweimal lesen sollte: Die Meldepflicht gilt für Produkte, die bereits auf dem EU-Markt bereitgestellt wurden, einschließlich Einheiten von vor der Frist. Die Designanforderungen aus Anhang I greifen für Produkte, die ab Dezember 2027 in Verkehr gebracht werden, für ältere nur bei einer wesentlichen Veränderung. Für die Meldepflicht gibt es diese Grenze nicht.

Die praktische Frage für eine Marke im September 2026 lautet daher nicht mehr „ist mein nächstes Produkt konform”. Sie lautet:

In einem Gerät, das wir 2023 ausgeliefert haben, wird eine Schwachstelle aktiv ausgenutzt. Erfahren wir das innerhalb von 24 Stunden, und wissen wir genug über den Inhalt, um das Problem zu beschreiben?

Bei den meisten Hardwaremarken lautet die ehrliche Antwort auf die zweite Hälfte: nein. Das ist ein Problem der Fertigungsunterlagen, bevor es ein Sicherheitsproblem ist.

→ Eine weitere EU-Frist, die zur Gehäuseentscheidung wird: EU-Batterieverordnung 2027: wechselbare Akkus

Der Supportzeitraum ist eine Stücklistenentscheidung

Anhang I verlangt einen erklärten Supportzeitraum von mindestens fünf Jahren, bei kürzerer erwarteter Lebensdauer entsprechend kürzer, mit einem Enddatum, das der Käufer beim Kauf kennt. In diesem Zeitraum behandelt der Hersteller Schwachstellen und stellt Sicherheitspatches kostenlos bereit.

Lesen Sie das als Beschaffungsrestriktion, denn genau das ist es.

Läuft auf dem Funkmodul Ihres Designs ein Hersteller-SDK, das im dritten Jahr keine Sicherheitspatches mehr erhält, können Sie nichts mehr patchen, was darauf aufsetzt. Sie haben am Verkaufspunkt fünf Jahre Support erklärt und verlieren die Fähigkeit zur Einhaltung im dritten Jahr, durch eine Entscheidung aus der Bauteilauswahl.

Damit gehören zwei Fragen in die Modulqualifizierung, neben Preis, Lieferzeit und Zweitquelle:

• Wie lange liefert dieser Hersteller Sicherheitspatches für dieses Bauteil, schriftlich, und was passiert am Ende der Verfügbarkeit?
• Gibt es eine Zweitquelle mit einem Stack, auf den wir migrieren könnten, ohne die Leiterplatte neu zu entwickeln?

Beide Fragen stehen üblicherweise nicht im Stücklisten-Review. Beide gehören in dasselbe Gespräch wie das Versorgungsrisiko, denn es ist dieselbe Art von Risiko: ein Bauteil wird unverfügbar, einmal kommerziell, einmal rechtlich.

→ Wie Bauteile bewertet werden und was ein Rot bedeutet: Risikomatrix für die Bauteilversorgung

Die SBOM muss beschreiben, was wirklich drin ist

Anhang I Teil II verlangt eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.

Bei einer Webanwendung ist das eine Ausgabe des Build-Tools. Bei einem physischen Produkt ist es eine Frage der Montage, denn die Firmware gehört selten vollständig Ihnen. Ein typisches vernetztes Consumer-Gerät enthält:

• die für dieses Produkt geschriebene Anwendungsfirmware
• ein Hersteller-SDK, das mit dem Funkmodul kam
• einen Protokollstack (Bluetooth, WLAN, Thread), ausgeliefert als Binärblob
• ein Echtzeitbetriebssystem
• Open-Source-Bibliotheken, die eines der genannten Teile mitbringt

Der Marke gehört üblicherweise der erste Punkt, in den Rest hat sie keinen Einblick, weil dieser über das Werk und dessen Modullieferanten kam. Eine belastbare SBOM zusammenzustellen heißt, im Werk zu fragen und das Werk seine Lieferanten fragen zu lassen.

Während der Entwicklung ist diese Anfrage weit günstiger als nach einem Vorfall. Sie erfahren dabei außerdem, ob Ihr Modulhersteller Ihnen sagt, was in seinem Binärblob steckt, und das ist eine Information, die man vor dem Design-In haben möchte.

Sicher voreingestellt, und überhaupt aktualisierbar

Zwei weitere Anforderungen aus Anhang I landen auf sehr frühen Hardwareentscheidungen.

Sicher voreingestellt heißt: Das Produkt wird mit sicherer Konfiguration ausgeliefert, ohne gemeinsame Standardpasswörter, ohne unnötige Dienste oder offene Ports, mit minimierter Angriffsfläche. Das sind Firmware-Voreinstellungen, und die setzt meist derjenige, der die Firmware schreibt. Ist das Ihr Auftragsfertiger, liegt die Umsetzung bei ihm und die Spezifikation bei Ihnen.

Kostenlose Sicherheitsupdates über den Supportzeitraum setzen voraus, dass das Produkt Updates überhaupt empfangen kann. Ob es das kann, ist keine Softwarefrage:

• Flash-Budget. Ein Zwei-Partitionen-Schema für sichere Over-the-Air-Updates verdoppelt den Firmware-Bedarf ungefähr. Fällt das erst nach dem Stücklisten-Freeze auf, bleiben nur Speicherwechsel oder Verzicht auf OTA.
• Konnektivität. Ein Gerät ohne Weg ins Internet lässt sich nur im Feld oder über eine Companion-App aktualisieren, beides mit Abschlussquoten weit unter dem, was eine Fünfjahrespflicht unterstellt.
• Energie. Ein Update, das bei niedrigem Akkustand läuft und das Gerät unbrauchbar macht, ist schlechter als kein Update. Also braucht die Updatelogik eine Energieschwelle, und die braucht eine Ladezustandsmessung.

Nichts davon lässt sich günstig nachrüsten. Alles davon wird im Engineering-Review entschieden, vor dem Werkzeugbau.

→ Die Prüfung, in der solche Restriktionen auftauchen: DFX-Risikoprüfung vor dem Werkzeugbau

Was sich im Projekt konkret ändert

Für ein Produkt, das jetzt in die Entwicklung geht und in die EU verkauft werden soll, ändern sich drei Dinge:

1. Die Modulqualifizierung bekommt eine Frage zur Patch-Laufzeit. Lassen Sie sich die Sicherheitszusage des Herstellers schriftlich geben, und werten Sie „das veröffentlichen wir nicht” als die Antwort, die es ist.
2. Die SBOM wird zur Lieferleistung. Nennen Sie sie im Entwicklungsvertrag neben Zeichnungen und Prüfberichten, damit sie mit dem Produkt kommt statt unter einer 24-Stunden-Uhr rekonstruiert zu werden.
3. Aktualisierbarkeit wird vor dem Werkzeugbau spezifiziert. Flash-Reserve, Partitionsschema und Updateweg sind in der Konzeptphase billig zu entscheiden und teuer nachzurüsten, sobald das Gehäuse existiert.

Für Produkte, die bereits am Markt sind, ist die kurzfristige Frage enger und dringender: Können Sie herausfinden, was darin steckt, und wie schnell?

Hinweis zum Anwendungsbereich

Dies ist eine Lesart veröffentlichter Rechtstexte und keine Rechtsberatung; die Umsetzungsdetails des CRA werden weiterhin über Normen und Leitlinien ergänzt. Klären Sie mit qualifizierter rechtlicher Beratung, wie er auf Ihre Produktklasse und Ihre Märkte wirkt, bevor Sie einen Plan darauf aufbauen. Gesichert genug für die Konstruktion ist die Richtung: Sicherheitssupport ist eine erklärte, datierte Zusage geworden, und die Entscheidungen, die sie möglich oder unmöglich machen, fallen in der Hardware, und zwar früh.

→ Die Details auf Leiterplattenebene, vom Schaltplan bis zur SMT-Linie: Auftragsfertigung für Consumer Electronics