The IoT security landscape is fundamentally different from traditional IT security. Connected devices combine embedded hardware, custom firmware, wireless protocols, mobile apps, and cloud backends into a single attack surface. A vulnerability in any one of these layers can compromise the entire systemand IoT devices are deployed in environments where they are physically accessible to attackers, rarely patched, and expected to operate for years.
The IoT Attack Surface
IoT security testing must cover five distinct layers, each with its own vulnerability classes and testing techniques. Missing any layer leaves significant blind spots that attackers will find.
1. Hardware Layer
Physical access to IoT devices is often assumed. Testers examine debug interfaces (JTAG, SWD, UART), chip-level security (secure boot, hardware encryption), storage (eMMC, SPI flash), and tamper resistance. Extracting firmware through hardware interfaces is frequently the first step in a comprehensive IoT assessment.
2. Firmware Layer
Firmware analysis examines the device's software for vulnerabilities. This includes extracting and analyzing the filesystem, identifying hardcoded credentials and API keys, checking for known vulnerable libraries, examining custom application logic, and validating the firmware update mechanism. Many IoT devices ship with debug builds, hardcoded backdoor accounts, or unencrypted firmware that can be modified and re-flashed.
3. Communication Layer
IoT devices communicate over diverse protocols: WiFi, BLE, Zigbee, Z-Wave, LoRa, MQTT, CoAP, and proprietary RF protocols. Testing evaluates encryption implementation, authentication mechanisms, replay attack susceptibility, and man-in-the-middle vulnerabilities. Wireless testing expertise is essential for IoT assessments.
4. Mobile/Companion App Layer
Most consumer and many enterprise IoT devices are controlled through mobile applications. Testing covers the app's local data storage, API communication security, authentication implementation, and whether the app exposes attack paths to the device or cloud backend.
5. Cloud/Backend Layer
IoT cloud backends handle device management, data storage, user authentication, and firmware updates. Testing covers API security, authentication and authorization flaws, data exposure, and whether compromising one device's cloud account enables access to other devices. This overlaps with standard external penetration testing but with IoT-specific considerations.
OWASP IoT Top 10
| Category | Description | Testing Approach |
|---|---|---|
| Weak Passwords | Default, hardcoded, or easily guessable credentials | Firmware extraction, brute force testing, default credential databases |
| Insecure Network Services | Unnecessary or insecure services exposed on the device | Port scanning, service enumeration, protocol fuzzing |
| Insecure Ecosystem Interfaces | Vulnerable web, API, cloud, or mobile interfaces | API testing, web app testing, mobile app analysis |
| Lack of Secure Update | No ability to securely update the device | Firmware signing verification, update channel interception |
| Use of Insecure Components | Deprecated or vulnerable third-party libraries | Software composition analysis, CVE matching |
| Insufficient Privacy Protection | Improper handling of personal data on device or in transit | Traffic analysis, data storage review, privacy assessment |
| Insecure Data Transfer | Lack of encryption during data transmission | Traffic capture, protocol analysis, MitM testing |
| Lack of Device Management | No support for security management in production | Management interface review, asset tracking assessment |
| Insecure Default Settings | Devices shipped with insecure default configurations | Out-of-box configuration review, hardening analysis |
| Lack of Physical Hardening | Absence of physical security measures | Hardware interface probing, tamper testing, side-channel analysis |
IoT Security Testing Methodology
Reconnaissance and Scoping
Begin by understanding the device ecosystem: what does it connect to, what data does it process, what protocols does it use, and what is the expected deployment environment? FCC ID lookups, firmware downloads from manufacturer sites, and documentation review inform the testing approach.
Firmware Extraction and Analysis
Firmware is extracted through hardware interfaces (JTAG/UART/SPI), manufacturer downloads, or over-the-air update interception. Analysis includes filesystem extraction (binwalk), binary analysis (Ghidra/IDA), static analysis for vulnerabilities, and identification of hardcoded secrets. This is often the highest-value phase of IoT testing.
Network and Protocol Testing
All network communications are captured and analyzed. MQTT brokers are tested for authentication requirements and topic access controls. BLE communications are sniffed for unencrypted data. Custom protocols are reverse-engineered and fuzzed for vulnerabilities. TLS implementation is validated for proper certificate validation.
Cloud API Assessment
The cloud backend is tested for standard web application and API vulnerabilities with additional focus on device-to-cloud authentication, multi-tenancy isolation (can device A access device B's data?), firmware update integrity, and command injection through device management APIs.
Key consideration: IoT security testing often requires specialized hardware tools (logic analyzers, SDR equipment, BLE sniffers) and embedded systems expertise that general penetration testing firms may not possess. When selecting a testing provider, verify their experience with your specific device category and communication protocols.
Industry-Specific IoT Security
Industrial IoT (IIoT)
Industrial IoT devices in manufacturing, energy, and critical infrastructure environments use protocols like Modbus, OPC-UA, and BACnet. Safety implications are severecompromised IIoT devices can cause physical damage, environmental incidents, or endanger human life. Testing must be carefully scoped to avoid disrupting operational technology (OT) systems.
Medical IoT
Medical IoT devices fall under FDA cybersecurity guidance and HIPAA requirements. Testing covers patient data protection, device integrity, and safety-critical functions. The intersection of IoT vulnerabilities with patient safety creates uniquely high-stakes testing scenarios.
Smart Building and Physical Security
IoT-connected access control systems, surveillance cameras, HVAC controllers, and building management systems are increasingly targeted. Compromising these devices can grant physical access, disable security monitoring, or serve as network entry points. Testing validates that these systems are segmented from corporate IT networks.
Securing IoT Deployments
- Network segmentation. Place IoT devices on dedicated VLANs with strict firewall rules preventing access to corporate networks
- Secure boot and firmware signing. Ensure devices only execute authenticated firmware to prevent tampering
- Encrypted communications. Require TLS/DTLS for all device-to-cloud and device-to-device communications
- Unique credentials per device. Eliminate default and shared passwords; provision unique certificates or keys during manufacturing
- Regular firmware updates. Implement secure, automated update mechanisms and maintain a vulnerability monitoring program for deployed devices
- Asset inventory. Maintain a complete inventory of IoT devices, firmware versions, and network locations to enable rapid response to vulnerabilities
Need security testing or compliance support?
We provide penetration testing, compliance assessments, and security consulting for organizations at every stage.
