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.
FAQ
What is the difference between the OWASP ISTG and the OWASP IoT Top 10?
The OWASP IoT Top 10 is a risk awareness document listing the 10 most common IoT security risks. It was last updated in 2018. The OWASP ISTG is a testing methodology with a structured device model, attacker model, and catalog of specific test cases. The IoT Top 10 tells you what risks to prioritize. The ISTG tells you how to test for them systematically.
How long does an IoT penetration test typically take?
Timelines depend on the device complexity and scope. A single consumer IoT device with hardware, firmware, and companion app testing typically requires 2 to 4 weeks. Industrial IoT devices with multiple communication protocols and integration points may require 4 to 8 weeks. The ISTG’s component-based scoping helps define realistic timelines by making the scope explicit upfront.
What physical access level is needed for a thorough IoT pentest?
For the most thorough assessment, PA-4 (invasive physical access) is recommended. This allows testing of all component categories, including processing units, memory, and internal interfaces. However, meaningful assessments can be performed at lower access levels depending on the threat model. A device deployed in a secured data center may only need testing at PA-1 or PA-2.
Can automated scanners replace manual IoT penetration testing?
Automated scanners can check for known CVEs in firmware components, scan hardware interfaces, and identify common misconfigurations. They cannot access and interact with hardware interfaces, reverse-engineer custom protocols, or identify logic-level vulnerabilities in device-specific implementations. Manual testing is essential for any assessment that aims to simulate real attacker behavior. The ISTG’s test cases are designed for manual execution, supplemented by automated tools where appropriate.
What compliance frameworks require IoT security testing?
ETSI EN 303 645 covers consumer IoT in Europe. IEC 62443 covers industrial control systems globally. The EU Cyber Resilience Act will mandate security testing for products with digital elements. In India, CERT-In empanelment requirements and sector-specific regulations from RBI and IRDAI increasingly expect IoT security assessments for connected devices in regulated industries.
How does the OWASP ISTG handle proprietary protocols?
The ISTG follows a generic, technology-agnostic approach. Its test cases define what security properties to verify (authentication, encryption, input validation) without prescribing specific protocol implementations. This means the same test case categories apply whether the device uses MQTT, a proprietary binary protocol over BLE, or a custom serial protocol. The framework’s expandable structure also allows teams to add protocol-specific sub-cases as needed.
Key Takeaways
The OWASP ISTG provides the most structured, IoT-specific testing methodology currently available as an open-source resource. Its component-based device model, threat-informed attacker model, and hierarchical test case catalog make it possible to scope, execute, and document IoT pentests with a level of rigor that generic frameworks cannot match. Organizations manufacturing or deploying IoT devices should use the ISTG as the backbone of their security testing program, complemented by the OWASP IoT Top 10 for risk communication and compliance frameworks like ETSI EN 303 645 and IEC 62443 for regulatory alignment.
If your organization manufactures or deploys IoT devices across automotive, MedTech, consumer electronics, or industrial environments, a structured IoT security assessment aligned with the OWASP ISTG framework is the clearest path to identifying vulnerabilities that automated tools miss. Get a scoped IoT security assessment from Payatu.
