Termin vereinbaren

IoT-Pentesting: Angriffsflächen vernetzter Geräte

Vernetzte Produkte sind keine reinen Softwaresysteme: Sie bestehen aus Platine, Firmware, Funkstrecke, Cloud-Backend und App. Ein IoT-Pentest prüft diese Ebenen zusammenhängend – dort, wo Angreifende ansetzen.

Bei vernetzten Geräten liegt die Angriffsfläche nicht nur im Netzwerk, sondern auch in der Hardware: Wer ein Gerät physisch in der Hand hält, kann Debug-Schnittstellen ansprechen, Flash-Speicher auslesen und die Firmware analysieren. Aus einem einzigen Gerät extrahierte Zugangsdaten oder Signaturschlüssel wirken dabei häufig über die gesamte Flotte hinweg. Für die fachliche Strukturierung solcher Prüfungen existieren etablierte Kataloge – der OWASP IoT Security Verification Standard (ISVS) für Anforderungen, der OWASP IoT Security Testing Guide (ISTG) für die Testdurchführung und ETSI EN 303 645 als Baseline für Consumer-IoT. Regulatorisch ist das Thema seit dem 1. August 2025 über den Delegated Act zur Funkanlagenrichtlinie verbindlich und geht ab dem 11. Dezember 2027 im Cyber Resilience Act auf.

Das Wichtigste im Überblick

01

Fünf Angriffsflächen, ein Ökosystem

Ein vernetztes Produkt ist selten ein einzelnes Prüfobjekt. Zu betrachten sind die Hardware (Debug- und Speicherschnittstellen, Bauteilbestückung), die Firmware (Bootkette, Dateisystem, hinterlegte Geheimnisse), die Funkschnittstellen (u. a. Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, LoRaWAN, Mobilfunk und proprietäre Sub-GHz-Protokolle), das Cloud-Backend mit seinen APIs sowie die begleitende Mobile- oder Web-App. Genau diese Aufteilung spiegelt sich in den fünf Anforderungskategorien des OWASP ISVS – IoT Ecosystem, User Space Application, Software Platform, Communication und Hardware Platform. Eine isolierte Prüfung einzelner Ebenen übersieht typischerweise die Übergänge, etwa das Onboarding eines Geräts in ein Nutzerkonto.

02

Hardware-Analyse: UART, JTAG, SPI

Die Hardware-Analyse beginnt mit der Identifikation von Bauteilen und Testpunkten auf der Platine. Serielle Konsolen (UART) geben in der Praxis häufig Bootlogs, Bootloader-Zugriff oder eine unzureichend geschützte Shell frei; Debug-Schnittstellen wie JTAG oder SWD erlauben je nach Sperrzustand des Controllers das Anhalten der CPU sowie Lese- und Schreibzugriffe auf den Speicher. Externe Flash-Bausteine an SPI oder I2C lassen sich in vielen Fällen im eingebauten Zustand oder nach Auslöten auslesen. Geprüft wird deshalb nicht nur, ob solche Zugänge existieren, sondern ob Debug-Ports produktiv deaktiviert bzw. authentifiziert sind, ob Secure Boot greift und ob sensible Parameter verschlüsselt oder in einem geschützten Element abgelegt sind.

03

Firmware-Extraktion und -Analyse

Firmware wird über Hersteller-Downloads, mitgeschnittene Update-Vorgänge oder einen Speicher-Dump beschafft und anschließend entpackt. Die statische Analyse sucht nach fest eingebauten Zugangsdaten, privaten Schlüsseln und Zertifikaten, unsicheren Konfigurationen sowie veralteten Komponenten, die über eine Stückliste (SBOM) mit bekannten Schwachstellen abgeglichen werden. Ergänzend wird die dynamische Analyse am laufenden oder emulierten System durchgeführt. Die OWASP Firmware Security Testing Methodology (FSTM) beschreibt dieses Vorgehen in neun Phasen von der Informationsbeschaffung über Extraktion und Emulation bis zur Verifikation der Findings. Zentrale Prüffrage bleibt die Update-Fähigkeit: Wird die Signatur eines Updates tatsächlich geprüft, und lässt sich ein Downgrade auf eine ältere, angreifbare Version verhindern?

04

Prüfkataloge: OWASP ISVS und ISTG, ETSI EN 303 645

Für Anforderungen und Testdurchführung stehen offene Kataloge bereit. Der OWASP ISVS bündelt Sicherheitsanforderungen für IoT-Ökosysteme in fünf Kategorien und liegt öffentlich als Release Candidate 1.0RC vor; der OWASP ISTG ergänzt seit seiner Version 1.0 vom 1. März 2024 eine Pentest-Methodik mit Geräte- und Angreifermodell sowie einem Testfallkatalog, der u. a. Funkschnittstellen, Verarbeitungseinheiten, Gerätespeicher, interne und physische Schnittstellen sowie Firmware und Update-Mechanismus abdeckt. Auf Produktebene definiert ETSI EN 303 645 in der Version V3.1.3 (2024-09) eine Baseline für Consumer-IoT mit 13 Themenbereichen – von der Abschaffung universeller Standardpasswörter über die Behandlung eingehender Schwachstellenmeldungen bis zur sicheren Ablage sicherheitsrelevanter Parameter – ergänzt um ein Kapitel zu Datenschutzbestimmungen. Die zugehörige Bewertungsmethodik liefert ETSI TS 103 701 (V2.1.1, 2025-05) mit Testfällen je Provision; das BSI legt beide Dokumente dem IT-Sicherheitskennzeichen für smarte Verbrauchergeräte zugrunde. Eine erste Selbsteinschätzung entlang des ISVS ist über das frei nutzbare Self-Assessment unter isvs.vamisec.com möglich.

05

Regulatorischer Rahmen: RED-Delegated-Act und CRA

Die Delegierte Verordnung (EU) 2022/30 macht die Cybersicherheitsanforderungen aus Artikel 3 Absatz 3 Buchstaben d, e und f der Funkanlagenrichtlinie 2014/53/EU für bestimmte Kategorien von Funkanlagen anwendbar – für internetfähige Geräte, für Geräte, die personenbezogene Daten verarbeiten (u. a. Kinderbetreuungsprodukte, Spielzeug, am Körper getragene Geräte) sowie für Geräte, die virtuelle Werte oder Geld verarbeiten; ausgenommen sind sektorspezifisch regulierte Produkte wie Medizinprodukte, Luftfahrt- und Kraftfahrzeugausrüstung. Die Anforderungen gelten seit dem 1. August 2025, nachdem die Delegierte Verordnung (EU) 2023/2444 den ursprünglichen Termin um zwölf Monate verschoben hatte. Als harmonisierte Normen sind EN 18031-1, -2 und -3 im Amtsblatt gelistet (Durchführungsbeschluss (EU) 2025/138 vom 28. Januar 2025) – jedoch mit Einschränkungen, unter anderem für Konstellationen, in denen Nutzende auf die Vergabe eines Passworts verzichten können; in diesen Punkten entfällt die Konformitätsvermutung. Parallel greift der Cyber Resilience Act (Verordnung (EU) 2024/2847): Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027; zu diesem Datum hat die Kommission die Aufhebung der Delegierten Verordnung (EU) 2022/30 beschlossen, um Doppelregulierung zu vermeiden.

06

Typischer Testablauf

Ein IoT-Pentest beginnt mit dem Scoping: Prüfobjekte, Geräte- und Angreifermodell (physischer Zugriff und Autorisierungsniveau) sowie Anzahl der Testmuster und Rückbaurisiken werden festgelegt, ergänzt um eine gemeinsame Bedrohungsmodellierung. Darauf folgen Informationsbeschaffung, Hardware- und Schnittstellenanalyse, Firmware-Extraktion mit statischer Analyse, die Prüfung von Funk- und Netzprotokollen sowie von Cloud-API, Onboarding-Prozess und App – jeweils mit Verifikation der Findings am laufenden Gerät. Ergebnis ist ein Bericht mit reproduzierbaren Nachweisen, einer nachvollziehbaren Risikobewertung und einer nach Aufwand und Wirkung sortierten Maßnahmenliste; ein Retest belegt die Wirksamkeit der Behebung. Für Hersteller ist diese Dokumentation zugleich Nachweismaterial: Anhang I Teil II des Cyber Resilience Act verlangt wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit sowie die Identifikation und Dokumentation von Schwachstellen und Komponenten einschließlich einer maschinenlesbaren Stückliste.

Standards & Quellen

Die Inhalte dieser Seite basieren auf den folgenden öffentlich verfügbaren Leitfäden und Studien.

ETSI · 2024

ETSI EN 303 645 V3.1.3 (2024-09), CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements

Aktuelle Baseline für Consumer-IoT mit 13 Themenbereichen und ergänzendem Kapitel zu Datenschutzbestimmungen; Referenz für Geräteanforderungen im Pentest.

ETSI · 2025

ETSI TS 103 701 V2.1.1 (2025-05), Cyber Security (CYBER); Cyber Security for Consumer Internet of Things: Conformance Assessment of Baseline Requirements

Bewertungsmethodik mit Testfällen je Provision der EN 303 645; vom BSI zusammen mit der Norm dem IT-Sicherheitskennzeichen zugrunde gelegt.

OWASP Foundation · 2020

OWASP IoT Security Verification Standard (ISVS), Pre-Release 1.0RC

Anforderungskatalog in fünf Kategorien (IoT Ecosystem, User Space Application, Software Platform, Communication, Hardware Platform); Grundlage für Prüfumfang und Self-Assessment.

OWASP Foundation · 2024

OWASP IoT Security Testing Guide (ISTG) 1.0

Pentest-Methodik mit Geräte- und Angreifermodell sowie Testfallkatalog je Gerätekomponente; veröffentlicht am 1. März 2024.

Amtsblatt der EU / EUR-Lex · 2022

Delegierte Verordnung (EU) 2022/30 zur Ergänzung der Richtlinie 2014/53/EU

Macht Artikel 3 Absatz 3 Buchstaben d, e und f der Funkanlagenrichtlinie anwendbar; Geltung seit 1. August 2025 nach Verschiebung durch Delegierte Verordnung (EU) 2023/2444.

Amtsblatt der EU / EUR-Lex · 2024

Verordnung (EU) 2024/2847 (Cyber Resilience Act)

Anhang I fordert u. a. regelmäßige Sicherheitstests und eine Stückliste; Meldepflichten ab 11. September 2026, übrige Pflichten ab 11. Dezember 2027.

Ihr vernetztes Produkt auf dem Prüfstand?

Wir ordnen Prüftiefe, Standardbezug und Nachweisführung auf Ihren Produktkontext ein – von der Platine bis zum Cloud-Backend. Sprechen Sie mit uns über ein Erstgespräch.