IoT Penetration Testing · Moritz Samrock

IoT Penetration Testing is the authorized, end-to-end security assessment of Internet of Things ecosystems. Unlike traditional pentests that focus on a single layer, IoT assessments span the entire stack: device hardware and firmware, wireless and wired communication protocols, cloud backend infrastructure, mobile companion applications, and the APIs that tie everything together. The goal is to find exploitable weaknesses across these interconnected components before an attacker chains them into a full compromise.

The challenge of IoT security testing lies in its breadth. A single smart device may communicate over BLE, connect to an MQTT broker over TLS, sync state with a cloud API, and be managed through a mobile app — each layer carrying its own attack surface, and vulnerabilities in one layer often enabling exploitation of another.

Who commissions this test?

IoT penetration tests are commissioned by IoT product companies, smart home and building automation manufacturers, medical device makers, industrial IoT vendors, and CISOs deploying IoT devices at enterprise scale. The request typically comes from product security teams during pre-launch validation, from compliance departments preparing for regulatory certification, or from enterprise security teams evaluating IoT devices before integrating them into corporate networks.

Test objectives

The primary objectives are to evaluate the security posture of the complete IoT ecosystem, to identify vulnerabilities that could allow unauthorized device access, data exfiltration, or device manipulation, and to assess whether the device can be compromised in ways that affect user privacy or safety. Specific objectives include testing firmware update integrity and authenticity, evaluating protocol-level security for wireless communications, assessing cloud API authorization and authentication, verifying TLS implementation correctness, and determining whether compromising one device enables attacks on others in the same deployment.

What is tested?

Testing covers the full IoT attack surface across four domains:

Device layer — Firmware extraction and analysis (hardcoded secrets, debug interfaces, update mechanisms), hardware debug ports (UART, JTAG, SWD), local storage encryption, bootloader security, and physical interfaces (USB, SD card, reset behavior).

Communication layer — Wireless protocols (BLE pairing and GATT services, Zigbee key exchange, Z-Wave S2 authentication, LoRaWAN session key management, Wi-Fi configuration), wired protocols (Ethernet, serial), and application-layer protocols (MQTT authentication and ACLs, CoAP security, HTTP/WebSocket APIs, UPnP/SSDP/mDNS service discovery exposure).

Cloud/backend layer — API authentication and authorization (OAuth flows, API key management, IDOR vulnerabilities), device provisioning and registration flows, over-the-air (OTA) update infrastructure (signing, delivery, rollback protection), data storage security, and multi-tenant isolation.

Mobile/companion app layer — Authentication flows, local data storage (keychain/keystore usage, plaintext credentials), certificate pinning implementation, API communication security, and inter-process communication (IPC) attack surface.

Common findings

Default or hardcoded credentials — Factory-set usernames and passwords that are identical across all devices and documented in publicly available manuals
Insecure firmware update mechanisms — OTA updates delivered without cryptographic signing, enabling man-in-the-middle firmware replacement
Unencrypted device communication — Sensitive data (telemetry, credentials, commands) transmitted in cleartext over the network or wireless channel
Weak BLE pairing — Devices using Just Works pairing or static passkeys, allowing passive eavesdropping or active MITM during pairing
MQTT without authentication — Message brokers accepting connections without credentials, enabling any network participant to subscribe to all topics or publish arbitrary commands
Exposed cloud APIs — Device management APIs with missing or broken authorization, allowing one user to control another user’s devices (IDOR)
Missing input validation on device APIs — Local web servers or command interfaces vulnerable to injection, buffer overflows, or command injection
Information disclosure via service discovery — UPnP, SSDP, or mDNS broadcasts revealing device type, firmware version, internal IPs, and sometimes credentials
Weak TLS implementation — Self-signed certificates accepted without validation, outdated TLS versions (1.0/1.1), or missing certificate pinning allowing traffic interception
Privacy leaks — Devices transmitting user behavior data, location information, or audio/video to cloud services without adequate consent mechanisms or encryption
Insecure device provisioning — Registration flows that allow an attacker to claim or reclaim devices, potentially hijacking a device by resetting it to factory defaults

Typical engagement workflow

Initial inquiry — The manufacturer or enterprise deployer reaches out for an IoT security assessment. The pentest team gathers information about the device ecosystem: the device itself, its communication protocols, cloud services, and companion apps. The number of device samples available for testing is discussed.

Scoping conversation — A detailed technical discussion with the product team to map the full IoT architecture: device hardware and firmware, wireless and wired protocols in use, cloud platform (AWS IoT, Azure IoT Hub, custom), mobile app platforms (iOS, Android), and any third-party integrations. The tester and client agree on which layers are in scope and the depth of testing per layer.

Proposal and approval — The proposal specifies the testing methodology for each layer (device, communication, cloud, mobile), expected duration, device samples needed, test accounts required, and deliverables. It is reviewed by product management, engineering, legal, and — for enterprise deployments — the CISO.

Scope definition — Device model, firmware version, app version, cloud environment (staging vs. production), and specific test accounts are documented. The scope explicitly defines whether hardware-level testing (opening the device, probing debug interfaces) is included or limited to firmware-level and above.

Letter of engagement — Signed authorization covering all ecosystem components, IP handling, NDA terms, and responsible disclosure timelines for any vulnerabilities found that could affect devices already deployed in the field.

Additional authorizations — Cloud platforms (AWS, Azure, GCP) may require notification or approval for security testing. App store review guidelines may apply if the mobile app will be reverse-engineered.

Information exchange — The client provides device samples, test accounts (multiple roles if applicable), cloud API documentation, firmware binaries or source code (for White-Box testing), mobile app builds, and network architecture diagrams. For Black-Box assessments, the tester receives only the device, app store link, and any public documentation.

Kick-off call — Final alignment with the product team, cloud operations, and security contacts. Communication channels, the handling of findings that could affect production devices, and the testing schedule are confirmed.

Execution — Testing proceeds layer by layer, but with an eye toward cross-layer attack chains. Device testing: firmware extraction, debug interface probing, local API testing, reset behavior analysis. Communication testing: protocol capture and analysis, encryption validation, replay attacks, MITM attempts. Cloud testing: API fuzzing, authentication bypass attempts, authorization boundary testing, OTA update integrity verification. Mobile app testing: static and dynamic analysis, network traffic inspection, local storage review, authentication flow testing. The tester documents findings per layer and specifically identifies chains where weaknesses in one layer enable exploitation of another. Stakeholders receive regular updates; critical findings (RCE, authentication bypass, privacy violations) are reported immediately.

Vulnerability assessment and rating — Findings are documented with technical evidence, rated by severity (CVSS or OWASP IoT risk rating), and assessed for real-world impact considering the device’s deployment context.

Final report — A comprehensive report covers findings across all layers, highlights cross-layer attack chains, provides remediation guidance specific to each component (firmware fix, API patch, configuration change, protocol upgrade), and includes an executive summary for non-technical stakeholders.

Presentation — Results are presented to the product team, security leadership, and executives. The presentation walks through the most critical attack scenarios and demonstrates end-to-end exploitation chains.

Project closure — Remediation priorities are agreed, differentiating between fixes deployable via OTA update and those requiring hardware changes. Recommendations for ongoing security testing (regression testing after firmware updates, periodic reassessment) are documented.

Who should commission this test — and when?

IoT product manufacturers should commission testing before market release — this is increasingly not optional but legally required. The EU Cyber Resilience Act mandates security assessment for products with digital elements sold in the European market. ETSI EN 303 645 provides a baseline security standard for consumer IoT that many retailers and markets now expect compliance with. Medical device IoT falls under MDR/IVDR and FDA premarket cybersecurity guidance. Industrial IoT is covered by IEC 62443.

Beyond pre-launch, IoT pentests should be repeated after significant firmware updates, when adding new communication protocols or cloud integrations, when deploying IoT devices into enterprise networks (assessment by the deploying organization), and periodically for devices with long field lifespans where the threat landscape evolves around them.

IoT Security: The discipline of securing connected devices and their ecosystems against cyber threats.
Penetration Testing: Authorized, methodical testing of systems for exploitable weaknesses.
Firmware Security: Protecting the software that runs directly on hardware from extraction, modification, and exploitation.
Hardware Security Module: A dedicated cryptographic device that safeguards keys and performs secure operations.
API Security: Protecting application programming interfaces from unauthorized access and abuse.
TLS: The cryptographic protocol that provides encrypted communication between devices and services.