Wie schützt man IoT-Geräte vor Cyberangriffen?

IoT-Geräte sind attraktive Angriffsziele: Sie verarbeiten sensible Daten, sind oft dauerhaft vernetzt und laufen in Umgebungen, in denen Sicherheitsupdates selten oder gar nicht eingespielt werden. Für Teams, die ein IoT-Gerät entwickeln lassen oder ein eingebettetes System zur Serienreife bringen wollen, ist Cybersicherheit kein optionales Feature, sondern ein Designparameter mit direkten Auswirkungen auf Zertifizierung, Haftung und Marktfähigkeit. Die Entscheidungen, die in der frühen Entwicklungsphase getroffen werden, bestimmen, ob ein Gerät nach dem Markteintritt vertretbar sicher betrieben werden kann oder nicht.

Dieser Artikel richtet sich an CTOs, Produktmanager und Ingenieurteams, die konkrete Sicherheitsentscheidungen für IoT- und Embedded-Produkte treffen müssen. Die Abschnitte folgen dem Produktlebenszyklus: von der Angriffsflächenanalyse über Hardware- und Firmware-Design bis hin zu regulatorischen Anforderungen und dem Betrieb nach dem Launch.

Table of Contents

Typische Angriffsvektoren bei IoT-Geräten

Die häufigsten Einstiegspunkte für Angreifer sind physische Debug-Schnittstellen, ungeschützte Firmware-Update-Mechanismen und schwache oder hartcodierte Zugangsdaten. JTAG- und UART-Ports, die im Prototyp für Debugging aktiviert wurden und im Seriengerät nie deaktiviert wurden, ermöglichen direkten Speicherzugriff ohne jede Authentifizierung. Das ist kein theoretisches Risiko: Angreifer mit physischem Gerätezugang extrahieren Firmware-Images routinemäßig über diese Schnittstellen und analysieren sie auf Klartext-Credentials oder proprietäre Protokolle.

Drahtlose Kommunikationsstacks sind ein zweiter kritischer Angriffsvektor. BLE-Geräte, die Pairing ohne Authentifizierung erlauben, oder MQTT-Broker ohne TLS-Verschlüsselung sind in der Praxis häufiger anzutreffen als erwartet, weil Entwickler im Prototypstadium Verbindungsprobleme durch die Deaktivierung von Sicherheitsschichten lösen und diese Änderungen nicht rückgängig machen. Bei NB-IoT- und LTE-M-Geräten kommt hinzu, dass Angreifer auf Netzwerkebene ansetzen können, wenn Backend-Endpunkte keine Zertifikatsvalidierung erzwingen. Teams unterschätzen systematisch, dass die Angriffsfläche mit jeder hinzugefügten Kommunikationsschnittstelle multiplikativ wächst, nicht additiv.

Sicherheit bereits im Hardware-Design verankern

Sicherheitsrelevante Hardwareentscheidungen, die nach dem ersten Prototyp nachgerüstet werden, kosten im Schnitt zwei bis vier Wochen Redesign-Zeit und können Zertifizierungszyklen um Monate verschieben. Die Entscheidung, ob ein Mikrocontroller mit Hardware-Security-Features wie einem True Random Number Generator, einem Hardware-Crypto-Accelerator oder einem Secure Boot-Mechanismus eingesetzt wird, muss vor dem Schaltungsentwurf fallen, nicht danach.

Konkret bedeutet das: STM32-Mikrocontroller der L-Serie bieten Read-Out-Protection-Level bis RDP2, was den Speicherinhalt auch bei physischem Zugriff schützt. NXP i.MX-Prozessoren unterstützen HAB (High Assurance Boot) für eine kryptografisch verifizierte Boot-Chain. Wer diese Features nicht von Anfang an in den Schaltplan und die Simulation integriert, riskiert, dass sie im fertigen PCB-Layout nicht nutzbar sind, weil die entsprechenden Pins falsch verdrahtet oder Fuses nicht gesetzt wurden. Ein weiterer Designfehler mit Konsequenzen: externe Flash-Chips ohne Verschlüsselung, die über Standard-SPI angebunden sind, lassen sich mit einem Logikanalysator in wenigen Minuten auslesen.

Sichere Firmware-Entwicklung für eingebettete Systeme

Firmware-Sicherheit beginnt mit einem verifizierten Boot-Prozess. Secure Boot stellt sicher, dass nur signierte Firmware-Images ausgeführt werden. Fehlt dieser Mechanismus, kann ein Angreifer mit physischem Zugang oder einem kompromittierten Update-Kanal beliebigen Code einschleusen. Für Zephyr-basierte Systeme ist MCUboot als Bootloader mit Image-Signierung über ECDSA etabliert; FreeRTOS-Projekte erfordern eine explizite Implementierung, da FreeRTOS selbst keinen Secure-Boot-Mechanismus mitbringt.

Over-the-Air-Updates (OTA) sind ein besonders kritischer Angriffspunkt: Ein Update-Mechanismus ohne kryptografische Signaturprüfung erlaubt das Einspielen manipulierter Firmware über den legitimen Update-Kanal. Rollback-Protection, also das Verhindern des Downgrades auf eine ältere, verwundbare Firmware-Version, wird von Teams regelmäßig vergessen, obwohl sie in vielen Zertifizierungsanforderungen explizit gefordert wird. Zusätzlich sollten Firmware-Images keine Debug-Symbole, Testendpunkte oder hartcodierten Credentials enthalten, was durch automatisierte Build-Pipeline-Checks sichergestellt werden kann. Die Embedded-Softwareentwicklung muss diese Anforderungen von Beginn an als Designziele behandeln, nicht als nachträgliche Härtungsmaßnahmen.

Verschlüsselung und Authentifizierung in der Kommunikation

Jede Kommunikationsverbindung eines IoT-Geräts muss unter der Annahme entworfen werden, dass das Transportnetz kompromittiert ist. TLS 1.2 ist das praktische Minimum für MQTT- und HTTP-Verbindungen; TLS 1.3 reduziert den Handshake-Overhead und ist für Geräte mit eingeschränkten Ressourcen oft die bessere Wahl, sofern der verwendete TLS-Stack es unterstützt. Auf Geräten mit weniger als 64 KB RAM ist mbedTLS mit selektiv deaktivierten Cipher-Suites eine etablierte Option, die Footprint gegen Kompatibilität abwägt.

Für BLE-Geräte gilt: Pairing mit LE Secure Connections (LESC) und Numeric Comparison oder Passkey Entry ist gegenüber Just Works zwingend vorzuziehen, sobald das Anwendungsszenario es erlaubt. Just Works bietet keine Authentifizierung und ist anfällig für Man-in-the-Middle-Angriffe beim Pairing. Gerätezertifikate statt symmetrischer Pre-Shared Keys sind für skalierbare Deployments ab mehreren hundert Geräten die robustere Wahl, erhöhen aber den Provisioning-Aufwand pro Gerät und erfordern eine PKI-Infrastruktur auf Backend-Seite. Teams, die diesen Aufwand unterschätzen, entscheiden sich oft für PSK und stehen dann vor dem Problem, kompromittierte Keys in der Fläche zu rotieren, ohne einen zentralen Key-Management-Mechanismus zu haben.

Zertifizierungsanforderungen und regulatorische Rahmenbedingungen

Für IoT-Geräte, die in der EU vermarktet werden, ist der Cyber Resilience Act (CRA) ab 2027 verbindlich. Er fordert unter anderem Security-by-Design, eine Schwachstellenoffenlegungsrichtlinie und Sicherheitsupdates über den gesamten Produktlebenszyklus. Geräte, die heute entwickelt werden, müssen diese Anforderungen bereits im Design berücksichtigen, weil Nachzertifizierungen für bestehende Produktlinien erheblichen Aufwand bedeuten.

Für Medizinprodukte gelten zusätzlich die Anforderungen der MDR und die Leitlinien des MDCG zu Cybersicherheit, die explizit Bedrohungsmodellierung (Threat Modeling), Risikobewertung nach ISO 14971 und dokumentierte Sicherheitstests fordern. Der Zertifizierungsprozess für ein Klasse-II-Medizinprodukt mit Cybersicherheitsanforderungen dauert realistisch 12 bis 24 Monate und kostet je nach Benannter Stelle und Produktkomplexität 30.000 bis 150.000 Euro. Teams, die Cybersicherheitsdokumentation als nachgelagerte Aufgabe behandeln, verlängern diesen Prozess regelmäßig um drei bis sechs Monate, weil Prüfer fehlende Nachweise für Secure Boot, Verschlüsselung oder Patch-Management nachfordern.

Sicherheit als kontinuierlicher Prozess nach dem Markteintritt

Ein IoT-Gerät ist nach dem Launch nicht fertig abgesichert. Neue Schwachstellen in verwendeten Bibliotheken, Betriebssystemkomponenten oder Kommunikationsprotokollen entstehen kontinuierlich. Ohne einen funktionierenden OTA-Update-Mechanismus und einen definierten Prozess zur Schwachstellenüberwachung (z. B. über CVE-Datenbanken für verwendete Komponenten) ist ein Gerät nach 12 bis 18 Monaten im Feld mit hoher Wahrscheinlichkeit verwundbar.

Ein häufig unterschätzter Aspekt: End-of-Life-Planung für Sicherheitsupdates muss vor dem Markteintritt kommuniziert werden, nicht danach. Der CRA verpflichtet Hersteller, den Unterstützungszeitraum für Sicherheitspatches anzugeben. Wer diesen Zeitraum zu kurz ansetzt, riskiert Reputationsschäden; wer ihn zu lang ansetzt, bindet Entwicklungskapazitäten über Jahre. Realistische Planungshorizonte liegen je nach Produktkategorie bei drei bis zehn Jahren. Darüber hinaus sollte ein Incident-Response-Prozess definiert sein, bevor ein Sicherheitsvorfall eintritt: Wer kommuniziert mit Kunden? Wie wird ein Notfall-Patch ausgerollt? Wie werden betroffene Geräte im Feld identifiziert? Teams, die diese Fragen erst nach dem ersten Vorfall klären, verlieren wertvolle Zeit in einer Situation, in der jede Stunde zählt.

Wie Oxeltech bei der IoT-Sicherheit unterstützt

Wir bei Oxeltech integrieren Sicherheitsanforderungen von der ersten Konzeptphase an in unsere Entwicklungsprozesse, nicht als nachgelagerte Härtungsmaßnahme. Das bedeutet konkret:

Auswahl von Mikrocontrollern und Kommunikationsmodulen mit geeigneten Hardware-Security-Features bereits im Schaltungsentwurf
Implementierung von Secure Boot, OTA-Update mit Signaturprüfung und Rollback-Protection in der Firmware-Architektur
Integration von TLS, MQTT over TLS, BLE Secure Connections und zertifikatsbasierter Authentifizierung je nach Kommunikationsstack
Unterstützung bei der Zertifizierungsdokumentation für CE, MDR und CRA-Anforderungen, einschließlich Threat-Modeling und Risikobewertung
Aufbau eines OTA-Mechanismus, der Sicherheitsupdates über den gesamten Produktlebenszyklus ermöglicht

Wenn Sie ein IoT-Gerät entwickeln lassen oder ein bestehendes Embedded-System auf seine Sicherheitsarchitektur überprüfen wollen, sprechen Sie uns an. Wir analysieren Ihre konkrete Situation und zeigen Ihnen, welche Sicherheitsmaßnahmen in Ihrem Produktkontext sinnvoll und zertifizierungskonform umsetzbar sind.