Penetration testing for AI products: robots, AIoT devices and edge AI

AI product penetration testing is a security test for devices with embedded AI – such as robots, AI cameras, voice assistants or edge AI in machinery. It covers hardware, firmware, wireless, cloud API, app, the on-device model and the LLM integration. The central question is whether an attacker can take over the product or make it perform actions in the physical world.

An IoT pentest examines hardware, firmware, wireless and cloud. With an AI product, attacks on the model and the LLM integration are added – prompt injection, jailbreaks, model extraction, adversarial examples – as well as the question of what physical consequences an attack via actuators and sensors can have. For devices without AI functionality, we recommend our IoT pentesting.

Yes. Documented cases include root access via Bluetooth to Unitree robots (UniPwn, 2025), jailbreaks of LLM-controlled robots with success rates of up to 100% in a research test (RoboPAIR, 2024) and a critical vulnerability in the cobot software from Universal Robots (CVE-2026-8153, CVSS 9.8). Typical entry points are wireless interfaces, network services, cloud APIs and the AI planner itself.

Yes, if model outputs become commands without validation or the model has overly broad permissions – in the 2026 OWASP edition, these are Improper Output Handling (LLM10) and Excessive Agency (LLM03). Researchers have shown that voice commands, text in the camera image or calendar invitations can control robots, drones and smart home devices. That is why we specifically test whether a deterministic safety layer is in place between AI planning and actuators.

For the AI layer: the OWASP Top 10 for LLM Applications 2026, the OWASP Top 10 for Agentic Applications 2026, OWASP AISVS 1.01, the OWASP AI Testing Guide, the OWASP GenAI Red Teaming Guide and MITRE ATLAS. For device and wireless: OWASP ISTG, OWASP ISVS, the OWASP IoT Top 10, the OWASP FSTM firmware methodology and, for robots, DDS Security with SROS 2. As formal standards: ETSI EN 303 645, EN 18031, ETSI EN 304 223 and IEC 62443-4-1/-4-2.

MAESTRO is a threat modeling framework from the Cloud Security Alliance for agentic AI, with seven architecture layers from Foundation Models to Agent Ecosystem. STRIDE answers what type of threat is involved, MAESTRO where in the AI architecture it arises. For products with sensors and actuators, we add a layer for the physical world – Microsoft already lists adversarial examples in the physical domain as a separate threat class in its threat modeling for AI/ML systems.

The CRA does not prescribe a procedure called a pentest, but Annex I Part II does require effective and regular tests and reviews of the security of the product. A pentest is the common way to demonstrate this. The reporting obligations have applied since 11 Sep 2026, all other requirements apply from 11 Dec 2027.

Yes: in Class I, Annex III of the CRA lists smart home general-purpose virtual assistants (No. 16), smart home products with security functionalities such as security cameras, baby monitors and alarm systems (No. 17), connected toys with social interactive or location tracking features (No. 18) and certain wearables (No. 19). Implementing Regulation (EU) 2025/2392 explicitly mentions smart speakers with voice assistants. Self-assessment (Module A) is only possible for Class I if harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level “substantial” or higher are applied in full (Art. 32(2) CRA) – as long as no standards have been published in the Official Journal, the route usually leads through a notified body.

That depends on the applicable product legislation. For AI as a safety component in products under Annex I Section A – such as toys, radio equipment or medical devices – the high-risk obligations including Art. 15 apply from 2 Aug 2028 under the Digital Omnibus, where a third-party conformity assessment is required. The Omnibus moved machinery to Section B: for AI in robots and machinery, the requirements come via delegated acts under the Machinery Regulation, which itself applies from 20 Jan 2027. The transparency obligations under Art. 50 have already applied since 2 Aug 2026.

With an agreed safety concept: a defined test zone, emergency stop within reach, reduced speeds and approval by the manufacturer’s safety officers. We first test critical scenarios in simulation or on a digital twin before reproducing them on the real system.

Yes. We check whether model files are stored unprotected on the device or in the app, whether the loading process and signature are secure, and how robust the model is against adversarial examples, manipulated sensor data and poisoning. Where relevant, we also assess side-channel risks on accelerators (ISTG-PROC-SIDEC).

Yes. We analyze firmware, services and network traffic for undocumented connections, remote maintenance tunnels and hidden functions. Examples from research include the covert telemetry of the Unitree G1 and the remote access tunnel in the Unitree Go1 (CVE-2025-2894).

A grey-box or white-box approach is most effective: two to three test devices, access to the app and cloud test environment, architecture documentation and – if possible – firmware images and source code excerpts. A black-box test is possible, but covers less attack surface in the same amount of time.

That depends on the product class, the number of interfaces, testing depth and the modules you need. After a free scoping call, you receive a fixed-price quote. A focused test of a single device including the report usually takes a few weeks.

At a minimum before every major product release and after significant changes to firmware, model or cloud functions. Because models and attack techniques evolve quickly, we also recommend an annual retest – the CRA requires regular testing throughout the entire support period.