IoT Penetration Testing: A Complete Methodology Guide with the OWASP ISTG Framework

In our last 20 IoT security assessments across automotive, MedTech, and consumer electronics, 17 devices had at least one debug interface (UART or JTAG) left fully accessible in production. In 9 of those cases, the exposed interface gave us an unauthenticated root shell within minutes of opening the enclosure. That single finding class alone invalidated every software-level security control the manufacturers had implemented.

IoT penetration testing is not web application testing with a different label. The attack surface spans hardware, firmware, wireless protocols, cloud APIs, and companion mobile apps, all interacting in ways that create vulnerabilities invisible to any single-layer assessment. Yet most testing methodologies available today either focus on only one of these layers or borrow heavily from web and network testing frameworks that miss IoT-specific risks entirely.

The OWASP IoT Security Testing Guide (ISTG) addresses this gap directly. Unlike the OWASP IoT Top 10 (last updated in 2018), which lists risk categories, the ISTG provides a structured, component-level testing methodology built for the realities of IoT device security. This guide breaks down how the ISTG works, how to apply it in real engagements, and where it fits alongside other frameworks like ETSI EN 303 645 and IEC 62443.

What Is IoT Penetration Testing?

IoT penetration testing is a structured security assessment that evaluates the resilience of a connected device and its surrounding ecosystem against real-world attacks. It differs from traditional network or application pentesting because the scope crosses multiple technical domains simultaneously: hardware, firmware, communication protocols, cloud infrastructure, and companion applications.

The goal is not just to list vulnerabilities. It is to understand how weaknesses in one layer (say, an exposed UART interface on the PCB) can chain with weaknesses in another (unencrypted firmware containing hardcoded API keys) to compromise the broader ecosystem.

A typical IoT pentest covers five distinct attack surfaces: the physical hardware and its debug interfaces, the firmware running on the device, the wireless and wired communication channels, the cloud or backend APIs the device connects to, and any mobile or web applications used to manage the device.

What Is the OWASP ISTG Framework?

The OWASP IoT Security Testing Guide (ISTG) is an open-source methodology specifically designed for penetration testing of IoT devices. It was developed from the master’s thesis of Luca Pascal Rotsch and builds on OWASP’s IoT Attack Surface Areas Project and the reference IoT architecture model proposed by Guth et al.

The ISTG is structured around three core concepts that work together to scope and execute an IoT pentest: the IoT Device Model, the Attacker Model, and the Test Case Catalog.

What makes the ISTG different from general penetration testing frameworks (like PTES or the BSI model) is that it accounts for the physical and hardware dimensions of IoT devices. Traditional pentest frameworks assume the target is a networked application or system. The ISTG starts from the assumption that the target is a physical device, potentially accessible to an attacker who can open the enclosure, probe debug interfaces, and dump memory chips.

How the ISTG Device Model Works

The ISTG defines every IoT device as a combination of components that can each be tested individually. These components fall into two categories: device-internal elements and interfaces.

Device-internal elements include the processing unit (x86, ARM, AVR processors), memory (EEPROM, flash), firmware (both the installed firmware and its update mechanism), and data exchange services (network services, debug services, bus listeners).

Interfaces are the pathways through which device-internal elements communicate with each other or with external systems. The ISTG categorizes these into four types: internal interfaces like JTAG, UART, and SPI that connect components inside the device enclosure; physical interfaces like USB and Ethernet that require a physical connection from outside; wireless interfaces like Wi-Fi, Bluetooth, BLE, and ZigBee; and user interfaces like touch displays, cameras, or locally hosted web applications.

This model matters for scoping. When a manufacturer says they want an IoT security assessment, the first step under ISTG is to map their device to this component model. Each component that exists in the target device becomes a potential item in the test scope.

How the ISTG Attacker Model Defines Test Scope

The ISTG uses an attacker model based on two dimensions: physical access level and authorization access level. This is a streamlined alternative to full threat modeling approaches like STRIDE, designed to be faster while still producing a well-scoped test.

Physical access levels range from PA-1 (remote, arbitrary distance, typically over the internet) through PA-2 (local, within LAN or WLAN range) and PA-3 (non-invasive physical access, device in hand but enclosure intact) to PA-4 (invasive physical access, device opened, internal components exposed).

Authorization access levels range from AA-1 (anonymous, no credentials) through AA-2 (low-privileged registered user) and AA-3 (high-privileged, access to configuration settings) to AA-4 (manufacturer-level, root or developer debug access).

The intersection of these two dimensions determines which components are testable. For example, processing units and memory are only accessible at PA-4 (invasive physical access). Internal interfaces like JTAG and UART also require PA-4. Wireless interfaces become testable from PA-2 onward. User interfaces may be testable remotely (PA-1) if the device hosts a web-based management interface.

This mapping is practically useful. When scoping an engagement for a consumer smart home device (physically accessible, enclosure easily opened), the physical access level would be PA-4, and the test should cover all component categories. For a CCTV camera mounted at a secured facility, the practical physical access level might be PA-2 or PA-3, narrowing the scope to network-accessible components, wireless interfaces, and potentially the firmware (if accessible via SSH or a network service).

The ISTG Test Case Catalog: What to Test and How

The ISTG organizes its test cases by component, each identified with a structured naming convention. The catalog currently covers 8 component categories, each with test cases organized by security concern.

ISTG-PROC (Processing Units): Tests for side-channel vulnerabilities, fault injection susceptibility, and physical tamper resistance of the processor itself. Requires invasive physical access (PA-4).

ISTG-MEM (Memory): Tests for data at rest encryption, memory readout protections, and whether sensitive data (credentials, cryptographic keys) can be extracted from flash or EEPROM chips. Requires PA-4. In our experience, unencrypted flash memory is one of the most consistently exploitable findings in consumer IoT devices.

ISTG-FW (Firmware): Split into two sub-categories. ISTG-FW[INST] covers the installed firmware: hardcoded credentials, insecure cryptographic implementations, outdated libraries with known CVEs, exposed debug functions, and insecure data storage. ISTG-FW[UPDT] covers the firmware update mechanism: whether updates are signed, whether the integrity of firmware packages is verified before installation, whether the update channel is encrypted, and whether downgrade attacks are possible.

ISTG-DES (Data Exchange Services): Tests network services and protocols the device uses to communicate. Covers authentication, authorization, encryption, input validation, and information disclosure for services like MQTT, CoAP, HTTP, and proprietary protocols.

ISTG-INT (Internal Interfaces): Tests debug and inter-component interfaces like JTAG, UART, SPI, and I2C. The focus is on whether these interfaces are accessible, whether they expose sensitive functionality (root shells, memory dumps), and whether authentication is required. JTAG alone can often provide full read/write access to device memory if left unprotected.

ISTG-PHY (Physical Interfaces): Tests externally accessible physical ports like USB and Ethernet for unauthorized data access, DMA attacks, and network-based exploitation via physical connections.

ISTG-WRLS (Wireless Interfaces): Tests Wi-Fi, Bluetooth, BLE, ZigBee, Z-Wave, and other wireless protocols. Covers pairing security, encryption strength, replay attack resistance, and protocol-specific vulnerabilities.

ISTG-UI (User Interfaces): Tests web interfaces, mobile companion apps, touch displays, and other human-interaction surfaces. Covers authentication bypass, session management, input validation, authorization flaws, and information disclosure.

Each test case in the catalog includes what to test, why the test matters, how to perform it, and how to mitigate the issue. Test case IDs follow a hierarchical format (e.g., ISTG-FW-INFO-001) that allows testers to selectively enable or disable entire branches based on the scoped device model and attacker model.

A Practical IoT Pentest Workflow Using the ISTG

Applying the ISTG in a real engagement follows a structured workflow that integrates with existing pentest processes.

Phase 1: Device modeling. Before any active testing, map the target device to the ISTG device model. Open the device (if scope allows), identify the PCB layout, locate debug headers (UART, JTAG), identify wireless chipsets, note physical ports, and document the firmware platform (embedded Linux, RTOS, bare-metal). This mapping determines which ISTG component categories apply.

Phase 2: Attacker model definition. Agree with the client on the physical and authorization access levels that represent realistic threat scenarios. A medical device in a hospital room faces different threats than a consumer IP camera anyone can buy off the shelf. The attacker model directly determines which test cases from the catalog apply.

Phase 3: Hardware and interface testing. Start with the physical layer. Probe identified debug interfaces with a logic analyzer or Bus Pirate. Attempt to access UART consoles (baud rate detection, shell interaction). Test JTAG access for memory read/write capability. Check whether physical interfaces like USB expose mass storage or debug functionality. Many security assessments stop at software; the ISTG makes hardware testing a first-class concern.

Phase 4: Firmware extraction and analysis. Extract the firmware through whatever vector is available: from the device via UART/JTAG, from an OTA update mechanism, or from the manufacturer’s support site. Use Binwalk to extract the filesystem. Analyze with Ghidra for reverse engineering. Run known-vulnerability checks against extracted binaries and libraries. Search for hardcoded credentials, private keys, API tokens, and insecure configurations. Test the firmware update mechanism for signature verification and downgrade protection.

Phase 5: Network and protocol testing. Capture and analyze traffic between the device and its cloud backend, companion app, and other devices. Test MQTT, CoAP, or HTTP endpoints for authentication, authorization, and encryption issues. Fuzz custom or proprietary protocols. Test BLE pairing and communication for replay and eavesdropping vulnerabilities.

Phase 6: Application layer testing. Assess the device’s web interface, mobile app, and cloud APIs using established web/mobile testing methodologies (OWASP WSTG, MASTG) while keeping in mind the IoT-specific context. Focus on how application-layer vulnerabilities can chain with hardware or firmware findings.

Phase 7: Reporting with ISTG references. Structure findings using ISTG test case IDs for traceability. Each finding maps back to a specific component and test case, making it clear what was tested, what was found, and what the manufacturer needs to fix. This also makes retesting straightforward: rerun the specific ISTG test cases that produced findings.

How the ISTG Relates to the OWASP IoT Top 10

The OWASP IoT Top 10 (2018) and the ISTG serve different purposes. The IoT Top 10 is an awareness document that lists the most common IoT security risks: weak passwords, insecure network services, insecure ecosystem interfaces, lack of secure update mechanisms, use of insecure or outdated components, insufficient privacy protection, insecure data transfer and storage, lack of device management, insecure default settings, and lack of physical hardening.

The ISTG is a testing methodology. Each item in the IoT Top 10 maps to one or more ISTG test case categories. For example, “Weak, Guessable, or Hardcoded Passwords” (IoT Top 10 #1) maps to authentication test cases across ISTG-FW, ISTG-DES, ISTG-INT, and ISTG-UI. “Lack of Physical Hardening” (IoT Top 10 #10) maps directly to ISTG-PROC, ISTG-MEM, ISTG-INT, and ISTG-PHY test cases.

The practical value is that the ISTG tells you how to test for the risks the IoT Top 10 identifies. Use the IoT Top 10 for stakeholder communication and risk prioritization. Use the ISTG for test execution and coverage assurance.

Where the ISTG Fits With Compliance Standards

Several regulatory frameworks now require or strongly recommend IoT security testing. The ISTG’s component-level approach maps well to these requirements.

ETSI EN 303 645 defines baseline security requirements for consumer IoT devices. Its 13 provisions (no default passwords, implement a vulnerability disclosure policy, keep software updated, securely store credentials, etc.) can each be verified through specific ISTG test cases.

IEC 62443 governs security for industrial automation and control systems. Its zone and conduit model aligns with the ISTG’s interface categorization, and its security level requirements can be validated through ISTG test cases at the appropriate physical and authorization access levels.

The EU Cyber Resilience Act (CRA), which mandates cybersecurity requirements for products with digital elements sold in the EU market, requires manufacturers to perform risk assessments and security testing. The ISTG provides a structured, auditable testing methodology that directly supports CRA compliance evidence.

India’s CERT-In guidelines and sector-specific regulations (RBI for fintech, IRDAI for insurance) increasingly expect connected device security assessments. The ISTG’s structured approach produces the kind of documented, repeatable test evidence that regulators expect.

Common Vulnerabilities We Find in IoT Assessments

Across our IoT security assessments, certain vulnerability classes appear with striking consistency.

Hardcoded credentials in firmware remain the single most common critical finding. These include SSH/Telnet passwords, API keys for cloud backends, and RTSP stream credentials on IP cameras. Once the firmware is extracted (often trivially, via an unprotected UART console), these credentials are recoverable in minutes using basic string analysis.

Exposed debug interfaces are the second most frequent finding. UART headers left populated on production PCBs, JTAG pins accessible without authentication, and SPI flash chips readable with a $15 clip. Manufacturers often leave these enabled because disabling them complicates post-production troubleshooting. The ISTG’s ISTG-INT test cases specifically target this category.

Unsigned firmware updates are alarmingly common. Without signature verification, an attacker who can intercept or modify the update channel can push arbitrary code to the device. The ISTG-FW[UPDT] test cases systematically verify this attack surface.

Insecure wireless implementations, particularly in BLE and ZigBee, frequently lack proper pairing security or use deprecated encryption. The ISTG-WRLS test cases cover these protocol-specific concerns.

Tools Commonly Used in ISTG-Aligned IoT Pentesting

The ISTG is tool-agnostic by design, but certain tools map well to its component categories.

For hardware and interfaces (ISTG-PROC, ISTG-MEM, ISTG-INT, ISTG-PHY), we use Bus Pirate and JTAGulator for interface probing, logic analyzers for signal analysis, and chip-off equipment for direct flash memory reads when needed. We also use our in-house tools, EXPLIoT Nano for IoT hardware exploitation and the Bus Auditor for automated identification and interaction with on-board debug and communication interfaces like JTAG, SWD, UART, SPI, and I2C.

For firmware analysis (ISTG-FW), Binwalk handles filesystem extraction, Ghidra and IDA Pro provide reverse engineering capability, Firmadyne and QEMU enable dynamic emulation, and tools like FACT (Firmware Analysis and Comparison Tool) automate known-vulnerability detection.

For wireless testing (ISTG-WRLS), Ubertooth handles BLE sniffing, Wireshark decodes captured traffic, and protocol-specific tools like KillerBee (for ZigBee) and HackRF (for SDR-based analysis) cover specialized wireless assessments.

For network and application layers (ISTG-DES, ISTG-UI), standard tools like Burp Suite, Nmap, and MobSF (for mobile companion apps) apply, supplemented by IoT-specific fuzzers for MQTT, CoAP, and custom protocols.

‍