Jahrelang galt eingebettete Sicherheit als „nice to have“ – etwas, das man hinzufügte, wenn Zeit und Budget es erlaubten oder wenn das Produkt genügend Reichweite erlangte, um Aufmerksamkeit zu erregen. Diese Zeit ist vorbei. Heute ist die Sicherheit von Embedded-Systemen geschäftskritisch, und Entwickler, die sie als nachrangigen Gedanken behandeln, werden Systeme neu entwerfen müssen, vermeidbare Fehler beheben oder zusehen, wie ihre Produkte in Vulnerability-Listen landen.
 
Die Messe Embedded World vermittelt diese Botschaft seit mehreren Jahren, und die Realität wird immer offensichtlicher. Wenn fast jeder Mikrocontroller, Sensorknoten, jedes Haushaltsgerät, jeder Industriecontroller, jedes Wearable und jedes Fahrzeugsystem netzwerkverbunden ist – direkt oder indirekt – dann ist die Angriffsfläche im Prinzip das gesamte Internet. Einen MCU im Feld ohne angemessene Sicherheitsmaßnahmen im Jahr 2026 auszuliefern, ist so, als hätte man 1999 einen PC mit offenem Dateizugriff und ohne Firewall ausgeliefert.

Das ist eine praktische Reaktion auf eine Branche, in der Supply-Chain-Angriffe auf Software, Firmware-Manipulation und kompromittierte IoT-Flotten zur Routine geworden sind. Von Embedded-Systemen wird nun erwartet, dass sie die gleichen Eigenschaften wie klassische IT-Systeme bieten: Vertraulichkeit, Integrität, Authentizität und Widerstandsfähigkeit. Der Unterschied ist, dass eingebettete Systeme diese Garantien unter strengen Stromvorgaben, geringem Speicherbedarf und jahrzehntelanger Lebensdauer bereitstellen müssen.

Wenn Entwickler dies nicht frühzeitig priorisieren, werden sie später deutlich mehr Aufwand für die Behebung betreiben.
 

embedded security is no longer optional
Embedded Security ist nicht mehr optional.

Das wachsende Bedrohungsmodell: Alles kommuniziert mit allem

Vor zehn Jahren war ein 8-Bit-Mikrocontroller, der irgendwelche Regelkreise ausführte, bei niemandem auf dem Cybersicherheits-Radar. Er kommunizierte wahrscheinlich nur über einen einfachen seriellen Bus und saß hinter einem Gateway. Heute kann genau diese Geräteklasse mit Folgendem kommunizieren:
 
  • Ein drahtloses IP-fähiges Modul
  • Ein Cloud-Dienst
  • Mehrere Hersteller-SDKs und Bibliotheken von Drittanbietern
  • Mobile Apps via Bluetooth LE
  • Ein Bootloader auf dem Gerät, der Updates im Feld akzeptiert

Mit anderen Worten: Das Gerät ist nicht mehr isoliert. Selbst günstige Minimal-Designs haben Wege in die Außenwelt – manchmal indirekt über andere Subsysteme.

Sobald Konnektivität ins Spiel kommt, tauchen die klassischen IT-Angriffsvektoren auf:
  • Gefälschte Firmware-Updates
  • Zugangsdaten-Diebstahl
  • Seitenkanal-Leckagen
  • Remote-Codeausführung durch manipulierte Pakete
  • Supply-Chain-Manipulation (kompromittierte Entwickler-Tools, vergiftete Bibliotheken, manipulierte Binärdateien)

Das ist keine Theorie: Industrielle IoT-Installationen, Consumer-Geräte und sogar Kfz-Steuergeräte wurden durch Firmware-Updates, Debug-Ports und unsichere Begleit-Apps kompromittiert.

Der größte Wandel: Angreifer interessiert heute nicht mehr, ob ein Gerät für sich genommen „wertvoll“ ist. Ist irgendjemand paranoid, dass ein Angreifer aus der Ferne den Geschirrspüler einschaltet? Nein, aber Botnetze, DDoS-Infrastrukturen und laterale Angriffe bedeuten, dass sogar eine smarte Glühbirne kompromittiert werden kann.

Wenn jeder Knoten ein potenzielles Einfallstor ist, dürfen Entwickler nicht mehr davon ausgehen, dass irgendein Gerät zu klein oder zu unbedeutend ist, um angegriffen zu werden.

Hardware zieht endlich nach (größtenteils)

Die gute Nachricht: Die Halbleiterhersteller haben reagiert. Die meisten neuen Mikrocontroller und SoCs verfügen inzwischen über Funktionen, die früher nur High-End-Anwendungsprozessoren vorbehalten waren:
 
  • Sicherer Bootvorgang
  • Hardware Root of Trust
  • On-Chip-Schlüsselspeicher (PUFs, HSM-ähnliche Blöcke, One-Time-Programmierbereiche)
  • Isolierte Ausführungsbereiche (ARM TrustZone-M, RISC-V PMP)
  • Kryptografische Beschleuniger
  • Sabotageerkennung und aktive Shielding-Layer (bei einigen sicheren MCUs)

Die Herausforderung ist nicht mangelnde Funktionalität, sondern dass viele Teams diese Features nicht aktivieren oder nutzen. Die vier häufigsten Gründe:
 
  • Sicherheitsfunktionen erschweren die Entwicklung. Sie erfordern sorgfältige Provisionierung und Signaturprozesse, die im Standard-Board-Bring-Up nicht vorgesehen sind.
  • Dokumentation ist oft fragmentiert oder herstellerspezifisch. Secure Boot auf einem Cortex-M33 unterscheidet sich von anderen Varianten.
  • Sicherheit gilt als „Extra-Arbeit“, wenn Termine eng sind. Features werden auf „Phase zwei“ verschoben, die nie kommt.
  • Teams fehlt eine einheitliche Sicherheitsdenke. Firmware-Entwickler, Hardware-Designer, DevOps und Cloud-Entwickler betrachten Sicherheit oft als SEP („Somebody Else’s Problem“).

Das Silizium ist bereit – die Prozesse oft nicht.

Was die aktuelle Landschaft erfordert

Starke Embedded-Security basiert nicht mehr auf Einzel-Features, sondern auf Ende-zu-Ende-Vertrauen:

Eine vertrauenswürdige Hardware-Basis
  • Unveränderlicher ROM-Bootloader
  • Signierte Firmware
  • Verifizierte Update-Wege

Sichere Identitäten pro Gerät
  • Einzigartige kryptografische Schlüssel
  • Zertifikatsbasierte Authentifizierung
  • Schlüssel verlassen nie die MCU

Widerstand gegen Ausnutzung
  • Speicherschutz-Einheiten
  • Compiler-Härtung
  • Reduktion der Angriffsfläche von Firmware

Schutz von Daten im Speicher und bei Übertragung
  • On-Chip-verschlüsselter Flash
  • TLS oder vergleichbare sichere Kanäle

Ein sicherer Entwicklungs-Workflow
Lebenszyklusmanagement
Der entscheidende Punkt: Sicherheit ist kein nachträglicher Aufsatz mehr. Sie ist ein kontinuierlicher Prozess über Design, Fertigung, Deployment und Wartung hinweg.

Wo Entwickler am meisten straucheln

Branchenübergreifend – vom Hobbyprojekt bis zur Industrieinstallation – tauchen die gleichen Stolpersteine immer wieder auf:

Sichere Boot-Ketten, die nur halb umgesetzt sind

Entwickler signieren den First-Stage-Bootloader, lassen aber das Applikationsimage unsigniert. Oder sie verlassen sich auf Debug-Keys, die in der Produktion offenbleiben.

Schwache oder wiederverwendete Schlüssel

Erstaunlich viele Geräte werden immer noch ausgeliefert mit:
  • Gemeinsamen privaten Schlüsseln für ganze Produktlinien!
  • Hartkodierten Zugangsdaten
  • Symmetrischen Schlüsseln in der Firmware

Sobald einer geleakt ist, ist die ganze Flotte angreifbar.

OTA-Updates ohne Integritätsprüfung

Sogar 2026 laden manche Geräte noch Updates über HTTP ohne Signaturprüfung herunter! Das bleibt der einfachste Angriffsweg auf IoT-Geräte.

Zu viel Vertrauen in „Security by Obscurity“

Geschlossene Firmware, seltene MCUs, proprietäre Protokolle und andere Verschleierung schützen niemanden – schon gar nicht heute. Angreifer analysieren und reengineeren regelmäßig unbekannte Architekturen.

Kein Plan für langfristige Wartung

Produkte leben 10 bis 20 Jahre. Hersteller überdauern drei bis fünf Produktzyklen. Cloud-Backends kommen und gehen. Sicherheitspläne berücksichtigen das selten.

Praktische Maßnahmen, die Entwickler heute ergreifen können

Sicherheit ist nur dann abschreckend, wenn sie auf einmal umgesetzt werden muss. Der beste Ansatz: Von Anfang an direkt in den Designprozess integrieren, statt sie nachträglich draufzusetzen.

Mit einer Hardware Root of Trust beginnen

Falls der MCU oder SoC Secure Boot unterstützt, aktivieren Sie dies am ersten Tag. Bauen Sie Ihren Firmware-Signier- und Provisionierungs-Workflow früh auf – noch bevor Sie die erste Zeile Anwendungs-Code schreiben. So vermeiden Sie das „Wir sichern das später“-Syndrom.

Gerätespezifische Schlüssel, keine gemeinsamen Geheimnisse

Moderne MCUs haben Hardware-Schlüsselspeicher genau dafür. Provisionieren Sie eindeutige Zugangsdaten während der Fertigung oder beim ersten Start, idealerweise direkt im Gerät erzeugt.

Die Firmware-Angriffsfläche reduzieren

Deaktivieren Sie ungenutzte Peripherie, Kommunikations-Stacks und Debug-Schnittstellen. Minimieren Sie Fremdcode. Jeder nicht genutzte Treiber ist ein potenzieller Angriffsweg.

Authentifizierte Updates erzwingen

Updates sollten immer sowohl Transport-Sicherheit (TLS, DTLS etc.) als auch kryptografische Signaturprüfung des Images verlangen.

Bedrohungen früh modellieren

Keine 50-seitige Beratung – nur ein strukturiertes 30-minütiges Gespräch:
 
  • Was kann ein Angreifer sehen?
  • Was kann er kontrollieren?
  • Worauf hätte er physischen Zugriff?
  • Was passiert, wenn er das bekommt?

So entdecken Sie Designfehler, bevor sie zu Architekturproblemen werden.

Ihren Sicherheitsplan dokumentieren

Wenn Ihr Team nicht klar benennen kann, wie Schlüssel gespeichert, Updates authentifiziert und die Boot-Kette gesichert wird, dann haben Sie kein sicheres Gerät – nur ein glückliches, vorerst.

Warum frühe Sicherheit Zeit (und Geld) spart

Sicherheit wird oft als teure Verzögerung gesehen. In Wirklichkeit sind „penny-wise and pound-foolish“-Implementierungen teuer – unsichere Systeme sind nämlich viel kostenintensiver:
 
  • Rückrufe wegen kompromittierter Firmware
  • Notfall-Patches unter Zeitdruck
  • Kundenverlust nach Vorfällen
  • Regulatorische Probleme (vor allem in Medizin, Industrie oder Consumer-IoT)
  • Verkürzte Produktlebensdauer, weil wichtige Fixes später unmöglich sind

Eine kleine Investition in sichere Provisionierung und Architektur am Anfang des Entwicklungszyklus erspart Jahre an Nachbesserung und Krisenbewältigung.

Der weitere Vorteil: Sichere Geräte bleiben länger nutzbar. Wenn Hardware ihrer Firmware und Update-Pipeline vertrauen kann, können Sie Features, Patches oder ganz neue Workflows auch Jahre nach dem Launch ausrollen.

Die neue Verantwortung des Embedded-Entwicklers

Die Veränderung ist klar: Jedes Gerät mit Firmware ist jetzt ein sicherheitsrelevantes System. Entwickler bauen Vertrauen auf – nicht nur Funktionalität. Ob Sie mit winzigen Cortex-M0+-Teilen, leistungsstarken Linux-SoCs oder neuen RISC-V-Plattformen arbeiten, die Erwartungen sind die gleichen.

Community, Markt und immer öfter auch Gesetzgeber erwarten sicheres Verhalten als Standard.

Das ist der Rahmen für unser Embedded-World-Special 2026. Die Messe spiegelt einen Branchenwandel wider: von „Security als Zusatz“ zu „Security als Infrastruktur“. Die Zeiten, in denen MCUs als isolierte Steuerblöcke betrachtet wurden, sind vorbei. Sie sind Knoten in einem globalen System – und ihre Sicherheitslage zählt weit über ihre unmittelbare Funktion hinaus.

Sichern Sie Ihre Zukunft

Embedded Security ist nicht so aufregend wie neue KI-Beschleuniger oder Ultra-Low-Power-Funks, aber sie entscheidet darüber, ob Ihr Produkt in freier Wildbahn bestehen kann, vertrauenswürdig bleibt und nicht Teil des nächsten großen IoT-Vorfalls wird.

Wer heute Embedded-Systeme baut, für den ist Sicherheit Teil des Jobs – nicht mehr optional.