Embedded Security im Feld: Schwachstellen und Altgeräte

Nach der Auslieferung entscheidet der Update-Weg, ob ein Gerät sicher bleibt. Was Gerätehersteller über Jahre im Feld leisten müssen.

Verfasst von Philipp Knaack, MSc | CTO, Danube Dynamics
ca. 18 Minuten Lesezeit

Am 30. August 2026 begann Hoymiles, ein Sicherheitsupdate für ältere Mikro-Wechselrichter zu verteilen. Vorausgegangen war eine Veröffentlichung des Chaos Computer Club vom Juli: Die Geräte nahmen Firmware-Updates per Funk ohne Authentisierung an und gaben auf eine undokumentierte Rundruf-Anfrage ihre Seriennummer preis, die zugleich als Zugangsschlüssel diente (CCC). Das Update schließt die Lücke und hat trotzdem einen Preis: Danach funktionieren laut Hersteller offene Gateway-Alternativen wie OpenDTU nicht mehr (Hoymiles). Offen blieb laut Borns IT-Blog, wie Geräte ohne Anbindung an ein Hoymiles-Gateway (DTU) das Update überhaupt bekommen (Borns IT-Blog).

Der Fall zeigt, worum es nach der Auslieferung geht. Ein Fix nützt nur, wenn er sicher ins Gerät kommt, auch Jahre nach dem Verkauf, und wenn der Hersteller weiß, welche Geräte ihn brauchen. Seit dem 11. September 2026 kommt eine Frist dazu: Aktiv ausgenutzte Schwachstellen sind nach dem Cyber Resilience Act (CRA) binnen 24 Stunden zu melden.

Das Wichtigste in Kürze:

Schlüssel und Zertifikate müssen sich im Feld tauschen und sperren lassen, unabhängig von ihrer Gültigkeitsdauer. Die Voraussetzungen dafür, Reserve-Schlüsselplätze, Sperrmöglichkeiten und ein aktualisierbarer Bootloader, werden bei der Hardware-Auslegung geschaffen.
Offene Software ist nicht unsicherer als proprietäre, Schwachstellen beheben kann aber nur, wer seine Komponenten kennt.
Von Tausenden CVE-Meldungen betreffen nur wenige das eigene Gerät. Welche, zeigen eine Software-Stückliste (SBOM) je Firmware-Stand und der Abgleich mit dem tatsächlich kompilierten Code.
Bestandsgeräte lassen sich nicht immer vollständig absichern; dann wird das Restrisiko dokumentiert und aktiv verkleinert.
Seit dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden, auch für Geräte, die bereits in Verkehr gebracht wurden.

Wie bleiben Schlüssel und Zertifikate über die Laufzeit eines Geräts gültig?

Nur, wenn Tausch, Sperrung und Ablauf schon in Hardware und Bootloader vorgesehen sind. Im Feld lässt sich ein Schlüssel nur so wechseln, wie Schlüsselplätze, Sperr-Fuses und der Update-Weg es erlauben. Wie Schlüssel erzeugt und in der Fertigung eingebracht werden, behandelt Teil 1. Hier geht es um die Jahre danach: Tausch, Sperrung, Ablauf und Geräte, die lange offline waren.

Schlüssel über die Laufzeit tauschen, sperren und erneuern

Tauschen

Beim Tausch gibt es zwei Ebenen.

Anker in den Fuses
Der Anker in den Fuses lässt sich nur wechseln, wenn der SoC mehrere Schlüsselplätze und Sperr-Fuses vorsieht: Ist ein Schlüssel kompromittiert, wird er gesperrt, ein vorab hinterlegter übernimmt. Details stehen im Referenzhandbuch des Controllers.

Schlüssel unterhalb des Ankers
Signierschlüssel und Zertifikate unterhalb des Ankers lassen sich per signiertem Update tauschen, sofern der Bootloader das unterstützt, signiert mit einem Schlüssel, dem das Gerät noch vertraut.

Fuses lassen sich setzen, aber nie überschreiben. Beliebig oft tauschbar sind Schlüssel deshalb nur, wenn sie nicht direkt in den Fuses liegen:

entweder verschlüsselt im Flash, mit einem gerätespezifischen Geheimwert aus den Fuses als Wurzel (bei NXP etwa „CAAM Blob“),
oder in einem Secure Element oder TPM.

Sperren

Schwieriger als der Tausch ist das Sperren, also einen kompromittierten Schlüssel oder ein gestohlenes Zertifikat für ungültig zu erklären, bevor es abläuft. In der IT übernehmen das Online-Sperrlisten. Für die Prüfung braucht das Gerät Zugang zu dem Server, der die Sperrinformationen bereitstellt (Sperrliste oder OCSP-Dienst), und eine verlässliche Uhrzeit, beides fehlt etwa in der Produktionshalle ohne Internet. Ein solches Gerät erfährt von einer Sperrung nur über ein signiertes Update seiner Vertrauensliste, notfalls per USB-Stick.

Auf Ebene des Ankers wird über Sperr-Fuses gesperrt. Sie sind wie die Anti-Rollback-Zähler, die das Zurückspielen alter Firmware verhindern, irreversibel und nur in begrenzter Zahl vorhanden.

Erneuern

Dass Zertifikate ablaufen, ist gewollt: Ohne Ablaufdatum bliebe ein gestohlenes Zertifikat unbegrenzt nutzbar, solange es niemand aktiv sperrt. Was ein abgelaufenes Zertifikat anrichtet, hängt davon ab, wofür es verwendet wird.

Beim Start
Beim Start prüfen Geräte das Ablaufdatum meist nicht, weil eine vertrauenswürdige Uhr fehlt. Auf x86-Industrie-PCs zeigt sich trotzdem, was Ablauf bedeutet: Die Microsoft UEFI CA 2011, mit der Bootloader von Drittanbietern signiert sind, lief am 27. Juni 2026 ab; die Geräte starten weiter, bekommen aber keine neuen Schutzmaßnahmen für den frühen Start mehr, etwa aktualisierte Sperrlisten für unsichere Bootloader (Microsoft).

Beim Client-Zertifikat
Kritisch ist Ablauf beim mTLS-Client-Zertifikat, mit dem sich das Gerät am Server ausweist. Abgelaufen heißt keine Verbindung und keine Updates, Stillstand ohne jeden Angriff.

Nach langer Offline-Zeit
Und ein Gerät, das lange offline war und den Zertifikatswechsel verpasst hat, braucht einen definierten Weg zu einem gültigen Zertifikat.

Ist Open Source unsicherer als proprietäre Software?

Nein, und geschlossener Code ist auch nicht automatisch sicherer. Offenheit ist ein Sicherheitsvorteil für den, der sie nutzt: Wer weiß, was verbaut ist, kann prüfen, selbst patchen und hängt nicht am Zeitplan eines Herstellers. Voraussetzung ist in beiden Welten dieselbe: die eigenen Komponenten zu kennen und ihre Herkunft zu kontrollieren.

Vier Fälle, die man kennen sollte

Ripple20 (2020): 19 Schwachstellen im proprietären TCP/IP-Stack des Herstellers Treck, erste Version um 1997. Viele Hersteller wussten nicht, dass sie ihn über Zulieferer verbaut hatten (Wikipedia).

Amnesia:33 (2020): 33 Schwachstellen in vier offenen TCP/IP-Stacks, laut Forescout bei über 150 Herstellern (Forescout); für einige gab es laut TechTarget nie einen offiziellen Patch (TechTarget).

xz-utils (2024): Ein Angreifer baute über zwei Jahre Vertrauen als Maintainer des Kompressionsprojekts auf. Die Hintertür steckte nur im veröffentlichten Quellarchiv (Release-Tarball). Gefunden wurde sie vor den stabilen Releases der großen Distributionen, weil einem Entwickler verzögerte SSH-Anmeldungen auffielen und er den Code prüfen konnte, mit einer Portion Glück (oss-security).

Miasma (2026): Schadpakete im npm-Ökosystem mit gültigen Signaturen und Herkunftsnachweisen (Golem, kes). Eine Signatur belegt die Herkunft, nicht die Harmlosigkeit; Embedded-Teams trifft das über Build-Pipelines, Entwicklerrechner und Web-Oberflächen auf dem Gerät.

Was das für die eigene Software heißt

Aus diesen Fällen folgt keine Angst vor Open Source, wohl aber Arbeit an der eigenen Lieferkette:

Inventur für beide Welten.
Die Software-Stückliste (SBOM) umfasst auch proprietäre Binärteile, Firmware-Blobs und das Board Support Package des Herstellers (BSP). Yocto 6.0 erzeugt sie standardmäßig in SPDX 3 und bringt sbom-cve-check mit (Yocto Project); für MCU-Firmware gilt die Inventur genauso.

Proprietäre Komponenten.
SBOM anfordern, Supportende und Patchzeiten vertraglich festhalten, bei kritischen Teilen eine Quellcode-Hinterlegung vereinbaren.

Offene Komponenten.
Wartungszustand prüfen, Versionen und Hashes festschreiben, aus Quellen bauen, Quellen spiegeln, neue Versionen nicht am ersten Tag übernehmen.

Der Build als Angriffsfläche.
Build-Server und Signierschlüssel gehören in dieselbe Bedrohungsanalyse wie das Gerät.

Kernel und BSP vom SoC-Hersteller sind ein Sonderfall. Sie sind offen, machen aber ähnlich abhängig wie proprietäre Software, wenn sie dem Mainline-Kernel über Jahre hinterherlaufen. Der CRA verpflichtet Hersteller zu Sorgfalt bei zugekauften Komponenten, ausdrücklich auch bei Open Source [1], und dazu, gefundene Schwachstellen an den Maintainer zu melden [2]. Eine Einschätzung, noch kein Befund: Das dürfte Druck auf die Pflege von Hersteller-BSPs erzeugen, weil Verantwortung dorthin wandert, wo der Code entsteht. Die Pflege der Komponenten läuft über den ganzen Lebenszyklus, und die SBOM ist die Grundlage für alles, was nach der Auslieferung kommt.

Wie erkennt man, welche neuen Schwachstellen das eigene Gerät betreffen?

Nur wer weiß, was im Gerät steckt, kann neue Schwachstellen bewerten und kontrolliert beheben. Die Menge der Meldungen macht einen Filter nötig: erst die Komponenten je Firmware-Stand, dann nur der tatsächlich kompilierte Code und die aktivierten Funktionen. Ob eine verbleibende Schwachstelle aktiv ausgenutzt wird, entscheidet über die Dringlichkeit. Behoben wird die Lücke in der Entwicklung, im Code oder in der Konfiguration. Ins Feld kommt der Fix dann als signiertes Software-Update.

Aus tausenden Meldungen die wenigen herausfiltern, die zählen

Allein für den Linux-Kernel zählt linuxcvetracker.com 5.681 CVEs im Jahr 2025 (linuxcvetracker.com, abgerufen am 24.09.2026). Ob eine davon das eigene System betrifft, kann laut Kernel-Dokumentation nur der Hersteller beurteilen, weil das CVE-Team weder Anwendungsfall noch Konfiguration kennt (kernel.org). Die US-Schwachstellendatenbank NVD ergänzt seit dem 15. April 2026 zudem nicht mehr alle CVEs um Schweregrad und betroffene Produkte (NIST).

Praktikabel ist ein Filter in drei Stufen.

Die SBOM je Firmware-Stand, also eine Software-Stückliste für jede ausgelieferte Firmware-Version, zeigt Komponenten und Versionen.
Der Abgleich gegen den kompilierten Code und die aktive Konfiguration trennt das Relevante vom Rest, VEX-Aussagen halten fest, warum ein Gerät nicht betroffen ist.
Zuletzt zählt die aktive Ausnutzung. Hinweise liefern der Katalog aktiv ausgenutzter Schwachstellen (KEV) der US-Behörde CISA (CISA), Meldungen von CERTs und Herstellern und die Telemetrie der eigenen Flotte.

Updates laufen über dieselbe Kette wie der Start

Ein Fix muss so ins Feld kommen, wie die Firmware beim Start geprüft wird: signiert, mit Rückfall auf den vorherigen Stand, über einen authentisierten Weg. Wie das für ganze Flotten aussieht, beschreibt das Whitepaper zum Fleet Management. Heikel ist der Bootloader selbst, laut Fachberichten das riskanteste Update im Feld, weil vielen Produkten ein redundanter Bootloader fehlt (techveda). Wer das nicht vorsieht, kann Fixes wie die für die Signaturprüfung in U-Boot (Teil 1) nicht ausrollen.

Den Supportzeitraum legt der Hersteller nach der erwarteten Nutzungsdauer fest.
Laut CRA beträgt er mindestens fünf Jahre, es sei denn, das Produkt wird erwartbar kürzer genutzt [3]. Seit dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden [4], auch für Geräte, die vor der vollen Geltung des CRA in Verkehr gebracht wurden [5]. Wer SBOM und Bewertungsprozess hat, hat die Grundlage, um fristgerecht zu entscheiden. Damit ist auch das Supportende ein Glied der Kette, das geplant werden muss: Termin, Information der Betreiber, Nachfolgegeneration.

Lassen sich Geräte, die schon im Feld sind, nachträglich absichern?

Manchmal ja, manchmal teilweise, manchmal nicht. Gemeint sind Geräte, die ohne die Kette aus Abb. 1 gebaut wurden, und solche kurz vor dem Supportende. Wie weit es geht, hängt vom verbauten Controller ab: ob sein Boot-ROM Signaturen prüft, ob die Fuses frei sind, ob es einen Schlüsselspeicher gibt und ob sich der Bootloader aktualisieren lässt. Wo die Hardware es nicht hergibt, wird das Restrisiko dokumentiert und aktiv verkleinert, bis eine Nachfolgegeneration mit Vertrauensanker kommt.

Erst die Bestandsaufnahme, dann die Maßnahme

Nachrüstbar

Nachrüstbar ist ein Gerät, wenn der Controller Secure Boot kann und die Fuses noch unbeschrieben sind und sich aus der Firmware heraus beschreiben lassen, etwa über einen Fuse-Controller im SoC. Dann lässt sich die Chain of Trust per Update aktivieren, irreversibel, mit Brick-Risiko und nur mit einem Ablauf, der vorher an echten Geräten getestet wurde.

Teilweise nachrüstbar

Teilweise nachrüstbar ist es ohne Hardware-Anker. Dann bleiben signierte Updates, ein verifiziertes Root-Dateisystem, abgeschaltete Dienste, Zugangsdaten je Gerät und ein Fernzugriff, den das Gerät selbst aufbaut. Ein Zusatzmodul über eine vorhandene Schnittstelle ist möglich, im Feld aber ein Serviceeinsatz je Gerät; ob sich das rechnet, hängt von Stückzahl, Zugänglichkeit und Schutzbedarf ab. Auch ein reines Software-Update hat seinen Preis. Das zeigt der Hoymiles-Fall vom Anfang: Ein Update kann Funktionen beenden, auf die sich Betreiber verlassen haben, und erreicht nicht jedes Gerät.

Nicht nachrüstbar heißt:

Restrisiko schriftlich festhalten, mit dem Betreiber kompensierende Maßnahmen vereinbaren (Segmentierung, Monitoring, physischer Schutz), Betreiber informieren und Supportende sowie Nachfolgegeneration planen, mit Vertrauensanker im Prozessor oder extern. Eine harte Grenze zeigt Fusée Gelée: Einen Fehler im Boot-ROM behebt kein Update, beim Tegra X1 half laut BleepingComputer nur neue Hardware (BleepingComputer). Das Restrisiko aus dem ersten Schritt ist an dieser Stelle eine dokumentierte Entscheidung und keine Überraschung mehr.

Fazit

Nach der Auslieferung wird Security zur Betriebsaufgabe. Zertifikate müssen rechtzeitig erneuert und Schlüssel getauscht werden, und laufend kommen Schwachstellen in Komponenten hinzu, die man nicht selbst geschrieben hat. Technisch ist die Liste überschaubar:

Eine SBOM je Firmware-Stand und ein Ablauf, der neue CVEs bewertet.
Updates inklusive Bootloader über dieselbe geprüfte Kette.
Zertifikate, die sich rechtzeitig erneuern lassen, auch auf Geräten, die lange offline waren.
Und ein Supportende, das der Hersteller festlegt und den Betreibern frühzeitig mitteilt.

Der CRA macht daraus Pflichten mit Fristen: einen festgelegten Supportzeitraum und seit dem 11. September 2026 die Meldung aktiv ausgenutzter Schwachstellen binnen 24 Stunden, auch für Geräte, die bereits in Verkehr gebracht wurden. Wo die Hardware keinen Vertrauensanker hergibt, bleibt oft nur, das Restrisiko zu dokumentieren und zu verkleinern, bis die nächste Generation kommt. Was dafür vor der Hardware-Freigabe entschieden sein muss, zeigt Teil 1.

Ein Fix ist nur so viel wert wie der Weg, auf dem er ins Gerät kommt.

Lässt sich Secure Boot nachrüsten, auch auf Mikrocontrollern?

Nur, wenn der verbaute Prozessor oder Mikrocontroller ein Boot-ROM mit Signaturprüfung und unveränderlichen Speicher für den Vertrauensanker mitbringt und die Fuses noch frei sind und sich im Feld beschreiben lassen. Dann lässt sich die Kette per Update aktivieren, irreversibel und nur mit getestetem Ablauf. Fehlen diese Funktionen, bleiben signierte Updates und Härtung als Teilmaßnahmen, der Rest ist ein dokumentiertes Restrisiko bis zur nächsten Gerätegeneration.

Wie lange muss ein Hersteller nach dem CRA Sicherheitsupdates liefern?

Für den Supportzeitraum, den der Hersteller selbst festlegt. Er muss der erwarteten Nutzungsdauer des Produkts entsprechen und beträgt mindestens fünf Jahre, es sei denn, das Produkt wird erwartbar kürzer genutzt [1]. In dieser Zeit sind Schwachstellen zu behandeln und Sicherheitsupdates bereitzustellen. Betreiber sollten das Supportende früh kennen, damit sie Ersatz planen können. Diese Antwort ersetzt keine Rechtsberatung.

[1] VO (EU) 2024/2847, Art. 13 Abs. 8. [4] VO (EU) 2024/2847, Art. 14 Abs. 1 und 2. [5] VO (EU) 2024/2847, Art. 69 Abs. 3. EUR-Lex

Was muss ein Hersteller nach dem CRA binnen 24 Stunden melden?

Seit dem 11. September 2026 jede aktiv ausgenutzte Schwachstelle in seinem Produkt, als Frühwarnung über die zentrale Meldeplattform an das zuständige CSIRT und an ENISA. Binnen 72 Stunden folgt die eigentliche Meldung, spätestens 14 Tage nach Verfügbarkeit einer Korrektur der Abschlussbericht [1]. Das gilt auch für Geräte, die vor der vollen Geltung des CRA in Verkehr gebracht wurden [2]. Diese Antwort ersetzt keine Rechtsberatung.

[1] VO (EU) 2024/2847, Art. 14 Abs. 1 und 2. [2] VO (EU) 2024/2847, Art. 69 Abs. 3. EUR-Lex

Wie erkennt ein Hersteller, ob eine neue Schwachstelle sein Gerät betrifft?

Über einen Filter in drei Stufen. Die SBOM je Firmware-Stand zeigt, welche Komponenten in welcher Version verbaut sind. Der Abgleich mit dem tatsächlich kompilierten Code und der aktiven Konfiguration trennt das Relevante vom Rest, VEX-Aussagen halten fest, warum ein Gerät nicht betroffen ist. Zuletzt zählt, ob die Schwachstelle aktiv ausgenutzt wird, etwa laut KEV-Katalog der US-Behörde CISA.

Muss die SBOM auch proprietäre Komponenten und Firmware-Blobs enthalten?

Für eine belastbare Bewertung ja. Schwachstellen stecken auch in zugekauften Binärteilen, Firmware-Blobs und im Board Support Package des SoC-Herstellers; Ripple20 lag in einem proprietären TCP/IP-Stack, den viele Hersteller über Zulieferer verbaut hatten, ohne es zu wissen. Für solche Komponenten fordert man die SBOM beim Lieferanten an und hält Supportende und Patchzeiten vertraglich fest.

Embedded Security im Feld:
Management von Schwachstellen, Updates und Bestandsgeräten