Pentest für KI-Produkte: Roboter, AIoT-Geräte und Edge-KI sicher testen

Ein Pentest für KI-Produkte ist ein Sicherheitstest für Geräte mit eingebetteter KI – etwa Roboter, KI-Kameras, Sprachassistenten oder Edge-KI in Maschinen. Geprüft werden Hardware, Firmware, Funk, Cloud-API, App, das Modell auf dem Gerät und die LLM-Integration. Im Mittelpunkt steht die Frage, ob ein Angreifer das Produkt übernehmen oder zu Handlungen in der physischen Welt bringen kann.

Ein IoT-Pentest prüft Hardware, Firmware, Funk und Cloud. Beim KI-Produkt kommen Angriffe auf das Modell und die LLM-Integration hinzu – Prompt Injection, Jailbreaks, Modell-Extraktion, Adversarial Examples – sowie die Frage, welche physischen Folgen ein Angriff über Aktorik und Sensorik haben kann. Für Geräte ohne KI-Funktion empfehlen wir unser IoT-Pentesting.

Ja. Dokumentiert sind unter anderem Root-Zugriffe per Bluetooth auf Unitree-Roboter (UniPwn, 2025), Jailbreaks LLM-gesteuerter Roboter mit Erfolgsraten von bis zu 100 % im Forschungstest (RoboPAIR, 2024) und eine kritische Lücke in der Cobot-Software von Universal Robots (CVE-2026-8153, CVSS 9,8). Typische Einstiege sind Funk-Schnittstellen, Netzwerkdienste, Cloud-APIs und der KI-Planer selbst.

Ja, wenn Modellausgaben ungeprüft zu Befehlen werden oder das Modell zu weitreichende Rechte hat – in der OWASP-Ausgabe 2026 sind das Improper Output Handling (LLM10) und Excessive Agency (LLM03). Forschende haben gezeigt, dass Sprachbefehle, Texte im Kamerabild oder Kalendereinladungen Roboter, Drohnen und Smart-Home-Geräte steuern können. Wir prüfen deshalb gezielt, ob zwischen KI-Planung und Aktorik eine deterministische Sicherheitsschicht greift.

Für die KI-Schicht die OWASP Top 10 for LLM Applications 2026, die OWASP Top 10 for Agentic Applications 2026, den OWASP AISVS 1.01, den OWASP AI Testing Guide, den OWASP GenAI Red Teaming Guide und MITRE ATLAS. Für Gerät und Funk den OWASP ISTG, den OWASP ISVS, die OWASP IoT Top 10, die Firmware-Methodik OWASP FSTM und für Roboter DDS Security mit SROS 2. Als Normen ETSI EN 303 645, EN 18031, ETSI EN 304 223 und IEC 62443-4-1/-4-2.

MAESTRO ist ein Threat-Modeling-Framework der Cloud Security Alliance für agentische KI mit sieben Architekturschichten von Foundation Models bis Agent Ecosystem. STRIDE beantwortet, welche Art von Bedrohung droht, MAESTRO, wo in der KI-Architektur sie entsteht. Für Produkte mit Sensorik und Aktorik ergänzen wir eine Schicht für die physische Welt – Microsoft führt Adversarial Examples in der physischen Domäne bereits als eigene Bedrohungsklasse im Threat Modeling für KI/ML-Systeme.

Der CRA schreibt kein Verfahren namens Pentest vor, verlangt aber in Anhang I Teil II wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts. Ein Pentest ist der gängige Weg, das nachzuweisen. Die Meldepflichten gelten seit dem 11.09.2026, alle übrigen Anforderungen ab dem 11.12.2027.

Ja: Anhang III des CRA nennt in Klasse I universelle virtuelle Assistenten für das Smart Home (Nr. 16), Smart-Home-Produkte mit Sicherheitsfunktionen wie Sicherheitskameras, Babyphones und Alarmanlagen (Nr. 17), vernetztes Spielzeug mit sozialer Interaktion oder Ortung (Nr. 18) sowie bestimmte Wearables (Nr. 19). Die Durchführungsverordnung (EU) 2025/2392 nennt Smart Speaker mit Sprachassistent ausdrücklich. Eine Selbstbewertung (Modul A) ist für Klasse I nur möglich, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema mindestens der Stufe „substanziell“ vollständig angewendet werden (Art. 32 Abs. 2 CRA) – solange keine Normen im Amtsblatt stehen, führt der Weg in der Regel über eine benannte Stelle.

Das hängt vom Produktrecht ab. Für KI als Sicherheitsbauteil in Produkten nach Anhang I Abschnitt A – etwa Spielzeug, Funkanlagen oder Medizinprodukte – gelten die Hochrisiko-Pflichten einschließlich Art. 15 nach dem Digital Omnibus ab dem 02.08.2028, wenn eine Konformitätsbewertung durch Dritte vorgesehen ist. Maschinen hat der Omnibus in Abschnitt B verschoben: Für KI in Robotern und Maschinen kommen die Anforderungen über delegierte Rechtsakte zur Maschinenverordnung, die selbst ab dem 20.01.2027 gilt. Die Transparenzpflichten nach Art. 50 gelten bereits seit dem 02.08.2026.

Mit einem abgestimmten Safety-Konzept: definierte Testzone, Not-Halt in Reichweite, reduzierte Geschwindigkeiten und Freigabe durch die Safety-Verantwortlichen des Herstellers. Kritische Szenarien prüfen wir zuerst in Simulation oder am Digital Twin, bevor wir sie am realen System nachstellen.

Ja. Wir prüfen, ob Modelldateien ungeschützt auf dem Gerät oder in der App liegen, ob Ladeprozess und Signatur sicher sind und wie robust das Modell gegen Adversarial Examples, manipulierte Sensordaten und Poisoning ist. Wo relevant, bewerten wir auch Seitenkanalrisiken an Beschleunigern (ISTG-PROC-SIDEC).

Ja. Wir analysieren Firmware, Dienste und Netzwerkverkehr auf undokumentierte Verbindungen, Fernwartungs-Tunnel und versteckte Funktionen. Beispiele aus der Forschung sind die verdeckte Telemetrie des Unitree G1 und der Fernzugriffs-Tunnel im Unitree Go1 (CVE-2025-2894).

Am effektivsten ist ein Grey- oder White-Box-Ansatz: zwei bis drei Testgeräte, Zugang zu App und Cloud-Testumgebung, Architekturunterlagen und – wenn möglich – Firmware-Images und Quellcode-Ausschnitte. Ein Black-Box-Test ist möglich, deckt in gleicher Zeit aber weniger Angriffsfläche ab.

Das hängt von Produktklasse, Anzahl der Schnittstellen, Testtiefe und gewünschten Modulen ab. Nach einem kostenlosen Scoping-Gespräch erhalten Sie ein Festpreisangebot. Ein fokussierter Test eines einzelnen Geräts inklusive Bericht dauert in der Regel wenige Wochen.

Mindestens vor jeder größeren Produktfreigabe und nach wesentlichen Änderungen an Firmware, Modell oder Cloud-Funktionen. Da sich Modelle und Angriffstechniken schnell entwickeln, empfehlen wir zusätzlich einen jährlichen Retest – der CRA verlangt regelmäßige Tests über den gesamten Supportzeitraum.