IoT Penetration Testing: How to Test Connected Devices, Firmware, and Embedded Systems

There are an estimated 17 billion connected devices operating in the US today. Smart building systems manage HVAC, lighting, and physical access across commercial real estate. Medical devices monitor patient vitals and deliver treatment in hospitals. Industrial sensors control manufacturing processes. Connected cameras surveil critical infrastructure. Fleet management systems track thousands of vehicles. Smart meters measure energy consumption across the power grid.

Each of these devices runs firmware, communicates over wireless protocols, connects to cloud backends, and often operates with the same network access as your most sensitive IT systems. Most were designed with functionality first and security as an afterthought, if security was considered at all.

IoT penetration testing evaluates the security of these connected devices and their ecosystems: the firmware running on the device, the hardware interfaces providing physical access, the communication protocols transmitting data, the APIs connecting devices to cloud services, the mobile applications controlling devices, and the backend infrastructure managing device fleets.

Traditional IT penetration testing evaluates web applications, APIs, and network infrastructure. IoT penetration testing goes deeper, literally into the device itself: extracting and analysing firmware, probing debug interfaces on circuit boards, intercepting wireless communications, and testing what happens when an attacker has physical access to the hardware.

This guide covers what IoT penetration testing involves, what security teams test across the IoT stack, the OWASP IoT Top 10 framework, firmware analysis methodology, hardware testing techniques, communication protocol security, US regulatory considerations, and how to approach IoT security testing for your connected device ecosystem.

What Is IoT Penetration Testing?

IoT penetration testing is security assessment methodology specifically designed for Internet of Things devices and their supporting ecosystems. It evaluates connected device security by testing every layer of the IoT stack: hardware, firmware, communication protocols, APIs, mobile applications, and cloud infrastructure.

Unlike traditional IT penetration testing that focuses on software-level vulnerabilities in web applications and network services, IoT penetration testing addresses the unique security challenges connected devices introduce.

Physical attack surface. IoT devices exist in the physical world where attackers can access hardware directly. Debug ports, JTAG interfaces, UART consoles, and removable storage provide attack vectors that don't exist in cloud-hosted applications.

Firmware vulnerabilities. Device firmware contains the operating system, application logic, configuration, and often hardcoded credentials. Firmware extraction and analysis reveals vulnerabilities invisible to network-level testing.

Communication protocol diversity. IoT devices communicate over Bluetooth, Zigbee, Z-Wave, LoRaWAN, MQTT, CoAP, cellular, and other protocols that traditional network testing doesn't cover.

Constrained environments. Limited processing power, memory, and storage mean IoT devices often cannot run standard security controls. Encryption may be weak or absent. Patching mechanisms may not exist. Authentication may be minimal.

Ecosystem complexity. IoT security isn't just the device. It's the device, the mobile app, the cloud backend, the API layer, the communication protocol, and every integration connecting them. Weakness in any component compromises the entire ecosystem.

The IoT Attack Surface: What Gets Tested

Firmware Security Testing

Firmware is the software embedded in IoT devices, controlling all device functionality. Firmware penetration testing extracts, analyses, and exploits the software running on connected devices.

Firmware extraction. Testers obtain device firmware through direct download from manufacturer update servers, extraction from device flash memory using hardware tools, interception during over-the-air (OTA) update processes, or JTAG/SWD debug interface access.

Static firmware analysis. Extracted firmware is analysed without execution to identify hardcoded credentials (passwords, API keys, certificates), encryption keys embedded in firmware images, known vulnerable library versions, insecure default configurations, debug and backdoor functionality left in production builds, file system contents including configuration files and scripts, and certificate and key material enabling impersonation.

Dynamic firmware analysis. Firmware is emulated or run on the device under controlled observation to analyse runtime behaviour, memory contents, inter-process communication, and network activity during normal and adversarial conditions.

Common firmware findings in US IoT assessments: Hardcoded default credentials that cannot be changed by users remain the most prevalent firmware vulnerability. Outdated Linux kernels and libraries with known CVEs are standard. Unencrypted sensitive data in firmware file systems appears routinely. Debug interfaces and telnet/SSH backdoors left enabled in production firmware create direct access paths.

Hardware Penetration Testing

Hardware penetration testing evaluates physical security of IoT devices, testing what an attacker with physical access can achieve.

Debug interface testing. Circuit boards are inspected for exposed JTAG, SWD, and UART debug interfaces. These interfaces, intended for manufacturing and development, frequently remain accessible in production devices. JTAG access can enable firmware extraction, memory reading, and device debugging providing complete device control.

Bus sniffing and interception. Communication between components on the circuit board (SPI, I2C, UART buses) is monitored using logic analysers and oscilloscopes. Bus interception reveals data the device processes, encryption keys in memory, and authentication tokens.

Storage extraction. Flash memory, EEPROM, and other storage components are read directly to extract firmware, configuration data, cryptographic keys, and stored credentials.

Tamper resistance testing. Physical security controls (conformal coating, tamper-evident seals, secure enclosures) are evaluated for bypass feasibility. Many IoT devices lack any tamper protection, allowing attackers to access internals with basic tools.

Side-channel analysis. Power consumption, electromagnetic emissions, and timing characteristics during cryptographic operations can reveal encryption keys and other sensitive data through side-channel attack techniques.

Communication Protocol Security

IoT devices communicate using diverse protocols, each with distinct security characteristics requiring specific testing approaches.

Bluetooth and BLE (Bluetooth Low Energy). Testing covers pairing mechanism security, authentication weaknesses, data interception during communication, and device impersonation. BLE is widely used in consumer IoT, medical devices, and building automation with frequently inadequate security implementation.

WiFi. Standard WiFi security assessment including WPA configuration, rogue access point susceptibility, and network segmentation isolating IoT devices from critical infrastructure.

Zigbee and Z-Wave. Smart home and building automation protocols tested for encryption key management, replay attacks, device impersonation, and network join security. Zigbee security has historically been weaker than its specification allows due to implementation shortcuts.

MQTT. The most common IoT messaging protocol tested for authentication enforcement (many MQTT brokers allow anonymous access), topic authorisation (whether devices can subscribe to topics they shouldn't), message interception on unencrypted connections, and broker security configuration.

LoRaWAN. Long-range IoT communication tested for join procedure security, encryption implementation, and session key management.

Cellular (LTE-M, NB-IoT). Cellular IoT connectivity tested for SIM security, data transmission encryption, and network-level access controls.

API and Cloud Backend Security

IoT devices connect to cloud services through APIs for device management, data collection, firmware updates, and command-and-control. Cloud backend security directly impacts device security.

Device API authentication. Testing validates how devices authenticate to cloud services, whether authentication tokens can be extracted from devices and replayed, and whether compromised device credentials enable access to other devices' data or functionality.

Device management API security. Testers assess whether device management functions (firmware updates, configuration changes, device commands) are properly authenticated and authorised, preventing attackers from pushing malicious firmware or controlling devices.

Data transmission security. Communication between devices and cloud backends is tested for encryption implementation, certificate validation, and man-in-the-middle attack susceptibility.

Fleet-level impact. Testing evaluates whether compromising a single device provides access to the broader device fleet, management systems, or enterprise infrastructure.

API penetration testing techniques apply to IoT cloud backends with additional device-specific considerations.

Mobile Application Security

Most consumer and many enterprise IoT devices are managed through mobile applications. Mobile app security directly affects device security.

Mobile-to-device communication. Testing evaluates how the mobile app communicates with the device (Bluetooth, local WiFi, cloud relay) and whether that communication channel is secure.

Mobile-to-cloud communication. API calls from the mobile app to cloud backends are tested for authentication, authorisation, data exposure, and injection vulnerabilities.

Credential storage on mobile. Device credentials, API keys, and authentication tokens stored on the mobile device are assessed for secure storage implementation.

Local data storage. Sensitive device data stored on the mobile device is evaluated for encryption and access control.

Mobile application penetration testing covers iOS and Android companion applications controlling IoT devices.

OWASP IoT Top 10: The Risk Framework

The OWASP IoT Top 10 provides the standard risk taxonomy for IoT security assessment. Comprehensive IoT penetration testing should systematically address all ten categories.

I1: Weak, Guessable, or Hardcoded Passwords

Default credentials that cannot be changed, hardcoded passwords in firmware, and weak password policies remain the most common IoT vulnerability. Many IoT devices ship with admin/admin credentials and no mechanism forcing users to change them.

What testers check: Default credential databases against device login interfaces. Firmware analysis for hardcoded credentials. Password policy enforcement (or absence). Credential storage security.

I2: Insecure Network Services

Unnecessary network services running on IoT devices expand attack surface. Telnet, FTP, and unencrypted web interfaces frequently remain enabled in production devices.

What testers check: Open port inventory on devices. Service identification and version fingerprinting. Known vulnerabilities in running services. Necessity assessment for each exposed service.

I3: Insecure Ecosystem Interfaces

Web, API, cloud, and mobile interfaces within the IoT ecosystem contain vulnerabilities enabling device compromise without physical access.

What testers check: API authentication and authorisation. Web interface security (OWASP Top 10 for web). Mobile application security. Cloud backend configuration.

I4: Lack of Secure Update Mechanism

Devices without secure firmware update mechanisms cannot be patched when vulnerabilities are discovered. Insecure update mechanisms allow attackers to push malicious firmware.

What testers check: Whether OTA update mechanisms exist. Whether updates are encrypted and signed. Whether update integrity is verified before installation. Whether update mechanisms can be hijacked for malicious firmware delivery.

I5: Use of Insecure or Outdated Components

IoT firmware frequently contains outdated operating system components, libraries, and third-party software with known vulnerabilities.

What testers check: Firmware component inventory (Software Bill of Materials). Known CVEs in identified components. Library versions against current secure versions. End-of-life software still in use.

I6: Insufficient Privacy Protections

IoT devices collecting personal data without adequate privacy protections violate user expectations and regulatory requirements.

What testers check: Data collection beyond stated purpose. Data transmission without encryption. Data storage without protection. User consent mechanisms. Data retention practices.

I7: Insecure Data Transfer and Storage

Data transmitted between device components, to cloud services, and stored on devices without adequate encryption creates exposure risk.

What testers check: Encryption implementation for data in transit. Certificate validation preventing man-in-the-middle attacks. Data storage encryption on device. Key management practices.

I8: Lack of Device Management

Inability to manage devices in the field, including updating firmware, rotating credentials, and monitoring security posture, creates long-term vulnerability accumulation.

What testers check: Device management capabilities. Remote update mechanisms. Credential rotation capability. Security monitoring and logging. Decommissioning procedures.

I9: Insecure Default Settings

Devices shipping with insecure default configurations (open ports, default passwords, unnecessary services, verbose logging) require users to actively harden devices, which rarely happens.

What testers check: Default configuration security. Whether setup processes enforce security configuration. Hardening guides availability. Default vs secure configuration gap.

I10: Lack of Physical Hardening

Devices without physical security measures allow attackers with physical access to extract data, modify firmware, or compromise device integrity.

What testers check: Debug interface accessibility (JTAG, UART, SWD). Storage readability. Tamper detection mechanisms. Physical access control to internal components.

IoT Penetration Testing Methodology

Phase 1: Reconnaissance and Scoping

Identify all components within the IoT ecosystem requiring assessment. IoT pentesting scope typically includes the physical device hardware, device firmware, communication protocols (Bluetooth, WiFi, Zigbee, MQTT), cloud backend APIs and infrastructure, mobile companion applications, device management interfaces, and OTA update mechanisms.

Scoping also establishes how many device variants require testing, whether production or development devices are provided, and which firmware versions are in scope.

Phase 2: Firmware Acquisition and Analysis

Obtain device firmware through available methods (download, extraction, interception). Perform static analysis identifying embedded credentials, vulnerable components, cryptographic material, and insecure configurations. Dynamic analysis through emulation or on-device observation reveals runtime behaviour and vulnerabilities.

Firmware analysis tools used in professional IoT pentesting include Binwalk for firmware extraction and analysis, Ghidra and IDA Pro for reverse engineering, EMBA and Firmware Analysis Toolkit for automated firmware assessment, QEMU for firmware emulation, and Firmwalker for file system analysis.

Phase 3: Hardware Assessment

Physically examine device hardware for accessible debug interfaces, exposed buses, readable storage, and tamper susceptibility. JTAG, UART, and SWD interfaces are probed for active debug access. Logic analysers capture bus communication. Flash storage is read directly for content extraction.

Hardware testing requires specialised equipment including JTAG debuggers (JTAGulator, Segger J-Link), logic analysers (Saleae, DSLogic), UART adapters, flash programmers, and soldering equipment for accessing test points.

Phase 4: Communication Protocol Testing

Assess security of all communication channels the device uses. Bluetooth/BLE interception and manipulation using tools like Ubertooth and BTLE. WiFi assessment using standard wireless testing methodology. MQTT broker security testing. Custom protocol analysis through traffic capture and reverse engineering.

Phase 5: API and Cloud Backend Testing

Test cloud services the device connects to using API penetration testing and cloud penetration testing techniques. Validate device authentication to cloud services. Test device management APIs for authorisation flaws. Assess fleet-level impact of single device compromise.

Phase 6: Mobile Application Testing

Assess companion mobile applications using mobile application penetration testing methodology. Test device-to-mobile communication security. Evaluate credential and data storage on mobile devices.

Phase 7: Attack Path Demonstration

Chain individual findings into complete attack scenarios demonstrating real-world impact. For example: extracting credentials from firmware (Phase 2) to authenticate to the cloud management API (Phase 5) to push malicious firmware to the entire device fleet (Phase 4), demonstrating how a single compromised device enables fleet-wide takeover.

Phase 8: Reporting and Remediation

Document all findings with evidence, severity ratings, and remediation guidance specific to IoT constraints. IoT remediation guidance must account for hardware limitations, firmware update mechanisms, and the challenge of patching devices already deployed in the field.

For reporting standards, see our penetration testing reports guide.

IoT Security Vulnerabilities: Real-World Impact

Healthcare: Medical Device Vulnerabilities

Medical device security has become a critical US healthcare concern. FDA has issued multiple guidance documents on medical device cybersecurity. Insulin pumps, infusion pumps, pacemakers, and patient monitoring systems have all demonstrated exploitable vulnerabilities in security research.

In 2023, CISA issued multiple ICS-CERT advisories for medical devices including infusion systems with hardcoded credentials and patient monitoring platforms with unencrypted data transmission. Medical device penetration testing validates that devices protecting patient safety resist exploitation.

US hospitals operating under HIPAA must assess medical device security as part of their risk management programmes. Connected medical devices processing ePHI require security validation proportionate to patient safety and data protection risks.

Industrial IoT and Critical Infrastructure

Industrial IoT (IIoT) devices controlling manufacturing processes, energy distribution, water treatment, and transportation systems face threats from nation-state actors and cybercriminals. The 2021 Oldsmar, Florida, water treatment facility attack demonstrated that industrial control systems accessible through the internet can be manipulated to endanger public safety.

CISA's Cross-Sector Cybersecurity Performance Goals include IoT device security requirements for critical infrastructure operators. NIST Cybersecurity Framework addresses IoT security within its Identify and Protect functions.

Consumer IoT Privacy and Safety

Consumer IoT devices including smart home systems, connected cameras, and voice assistants collect intimate personal data within homes. FTC enforcement actions have targeted IoT manufacturers for inadequate security practices. Ring cameras, baby monitors, and smart doorbells have all experienced security incidents exposing users to surveillance and harassment.

California's SB-327 (IoT Security Law) requires connected device manufacturers to equip devices with reasonable security features. Similar state-level legislation is expanding IoT security requirements across the US.

Automotive IoT

Connected vehicle systems, telematics, and V2X communication create an automotive IoT attack surface. Researchers have demonstrated remote vehicle control through telematics vulnerabilities. NHTSA addresses cybersecurity in connected vehicle safety guidance.

US Regulatory Landscape for IoT Security

FDA Medical Device Cybersecurity

FDA requires cybersecurity information in premarket submissions for connected medical devices. The Consolidated Appropriations Act of 2023 gave the FDA explicit authority to require cybersecurity documentation. Manufacturers must provide a Software Bill of Materials (SBOM), evidence of secure design practices, and post-market cybersecurity management plans.

Medical device penetration testing validates that device security meets FDA expectations. Testing should cover device firmware, communication security, update mechanisms, and integration with hospital networks.

NIST IoT Cybersecurity

NIST has published multiple IoT-focused resources, including NIST IR 8259 (IoT Device Cybersecurity Capability Core Baseline), NISTIR 8259A (IoT Device Cybersecurity Requirements), and the NIST Cybersecurity Framework's application to IoT environments.

NIST recommendations inform IoT security expectations across federal procurement and serve as baseline references for commercial IoT security programmes.

CISA IoT Security

CISA provides IoT security guidance through ICS-CERT advisories on specific device vulnerabilities, Cross-Sector Cybersecurity Performance Goals, including IoT, the Secure by Design initiative promoting manufacturers' security responsibility, and vulnerability disclosure coordination for IoT manufacturers.

State-Level IoT Legislation

California SB-327 requires manufacturers of connected devices sold in California to equip devices with reasonable security features appropriate to the device's function and the information it handles.

Oregon HB 2395 establishes similar requirements for IoT devices sold in Oregon.

Additional state-level IoT legislation is expanding across the US, creating a patchwork of security requirements manufacturers must address.

PCI DSS for Payment IoT

Point-of-sale terminals, payment kiosks, and connected payment devices fall under PCI DSS requirements. PCI DSS Requirement 11.3 mandates penetration testing of payment environments. IoT devices processing payment data require security assessment as part of PCI compliance.

See our PCI DSS penetration testing guide.

SOC 2 for IoT SaaS

IoT platform providers serving enterprise customers face SOC 2 requirements demonstrating security control effectiveness. IoT penetration testing provides evidence supporting Trust Services Criteria for IoT cloud platforms. See how SOC 2 pentests support compliance.

IoT Penetration Testing Checklist

Firmware Security

• [ ] Firmware extracted and analysed for hardcoded credentials
• [ ] Known vulnerable components identified (SBOM analysis)
• [ ] Encryption keys not embedded in firmware images
• [ ] Debug functionality disabled in production firmware
• [ ] Sensitive data not stored unencrypted in firmware file system
• [ ] Firmware signed and signature verified during updates

Hardware Security

• [ ] JTAG/SWD debug interfaces disabled or protected
• [ ] UART console access restricted or disabled
• [ ] Flash storage encrypted or read-protected
• [ ] Tamper detection mechanisms present where appropriate
• [ ] Circuit board test points not exposing sensitive buses

Communication Security

• [ ] All data transmission encrypted (TLS, DTLS, or protocol-specific encryption)
• [ ] Certificate validation preventing MitM attacks
• [ ] Bluetooth/BLE pairing using secure methods
• [ ] MQTT broker requiring authentication
• [ ] WiFi using WPA3 or WPA2 with strong configuration

API and Cloud Security

• [ ] Device-to-cloud authentication using per-device credentials
• [ ] Device management APIs requiring authorisation
• [ ] Firmware update delivery encrypted and signed
• [ ] Fleet-level access not achievable through single device compromise
• [ ] API rate limiting preventing enumeration and abuse

Mobile App Security

• [ ] Device credentials not stored in plaintext on mobile
• [ ] Mobile-to-device communication encrypted
• [ ] Mobile-to-cloud API calls authenticated and authorised
• [ ] Local data storage protected

Default Configuration

• [ ] No default/hardcoded passwords in production devices
• [ ] Unnecessary services disabled by default
• [ ] Setup process enforcing password change
• [ ] Secure configuration as default, not optional

When to Conduct IoT Penetration Testing

During product development (pre-market). IoT penetration testing during development identifies vulnerabilities when fixes are cheapest and easiest. For medical devices, pre-market testing supports FDA submission requirements.

Before product launch. Validate that production firmware and hardware configuration resist attack before shipping devices to customers.

After firmware updates. New firmware versions require security validation confirming updates didn't introduce vulnerabilities and that update mechanisms function securely.

Annually for deployed device fleets. Ongoing assessment of production devices validates that security posture remains adequate as new attack techniques and vulnerabilities emerge.

When entering new markets. US-specific regulatory requirements (FDA, California SB-327) may require testing not conducted for other markets.

After security incidents. Post-incident testing validates remediation and identifies additional vulnerabilities in affected device types.

For frequency guidance, see our guide on how often to do penetration testing.

How AppSecure Delivers IoT Penetration Testing

AppSecure provides comprehensive IoT penetration testing, evaluating every layer of your connected device ecosystem.

Full-Stack IoT Assessment

AppSecure tests the complete IoT stack: device firmware, hardware interfaces, communication protocols, cloud backend APIs, mobile companion applications, and OTA update mechanisms. Full-stack assessment ensures no component is tested in isolation while others remain unvalidated.

Expert Firmware Analysis

Certified security professionals extract, reverse-engineer, and analyse device firmware, identifying hardcoded credentials, vulnerable components, cryptographic weaknesses, and insecure configurations. Firmware analysis reveals vulnerabilities invisible to network-level testing.

Hardware Testing Capability

Hardware penetration testing evaluates physical attack surface including debug interfaces, bus communication, storage extraction, and tamper resistance. Testing validates what an attacker with physical device access can achieve.

Zero False Positives

Every IoT vulnerability is manually validated through exploitation with proof-of-concept evidence. Zero false positives ensure your engineering team addresses genuine, exploitable vulnerabilities rather than theoretical issues.

Attack Path Demonstration

Individual findings are chained into realistic attack scenarios demonstrating fleet-level impact. Attack path demonstration communicates risk far more effectively than individual vulnerability lists, showing stakeholders what actually happens when IoT security fails.

OWASP IoT Top 10 Coverage

Testing methodology systematically addresses all OWASP IoT Top 10 categories. Reports map findings to the framework for standardised risk communication.

US Regulatory Alignment

Reports align with FDA medical device cybersecurity requirements, NIST IoT guidance, and applicable compliance frameworks (PCI DSS, SOC 2, HIPAA). Regulatory alignment supports both security improvement and compliance demonstration.

3-Week Delivery

Standard IoT penetration testing engagements deliver within three weeks. 90-day post-delivery support includes remediation guidance accounting for IoT-specific constraints (firmware update limitations, deployed device management) and complimentary retesting.

Comprehensive Security Services

IoT testing integrates with broader application security assessment, web application testing, and cloud infrastructure testing for organisations requiring end-to-end security validation across their technology stack.

Ready to test your IoT devices against real-world attack techniques?

Contact AppSecure:

• Schedule IoT Penetration Testing
• Application Security Assessment
• Penetration Testing Methodology

Frequently Asked Questions

1. What is IoT penetration testing?

IoT penetration testing is security assessment designed specifically for connected devices and their ecosystems. It tests every layer of the IoT stack: device firmware (extracting and analysing embedded software for vulnerabilities), hardware interfaces (probing debug ports, buses, and storage), communication protocols (Bluetooth, WiFi, MQTT, Zigbee), cloud backend APIs, mobile companion applications, and OTA update mechanisms. IoT pentesting goes beyond traditional IT security testing by addressing physical attack surface, constrained computing environments, and the diverse communication protocols IoT devices use.

2. What does IoT penetration testing cover that traditional pentesting doesn't?

IoT penetration testing addresses attack surface traditional IT pentesting doesn't reach. Firmware extraction and analysis identifies hardcoded credentials and vulnerable components embedded in device software. Hardware testing probes debug interfaces (JTAG, UART), circuit board buses, and physical storage. Communication protocol testing covers Bluetooth, Zigbee, MQTT, and LoRaWAN, protocols absent from traditional network testing. Physical tamper resistance assessment evaluates what attackers with physical device access can achieve. Traditional pentesting covers web applications, APIs, and networks. IoT pentesting covers the device itself.

3. How much does IoT penetration testing cost?

IoT penetration testing cost depends on the number of device types requiring assessment, testing depth across hardware, firmware, and communication layers, ecosystem complexity (cloud backends, mobile apps, fleet management), regulatory requirements driving testing scope, and whether hardware testing equipment and specialised expertise are required. IoT testing typically costs more than standard web application testing due to specialised equipment, firmware analysis expertise, and multi-layer assessment scope. The investment should be evaluated against the cost of IoT security incidents, regulatory penalties, and product recall expenses.

4. What are the most common IoT security vulnerabilities?

The most common IoT security vulnerabilities found during penetration testing include hardcoded default credentials in firmware, outdated software components with known CVEs, unencrypted data transmission between devices and cloud services, exposed debug interfaces (JTAG, UART) on production hardware, insecure firmware update mechanisms allowing malicious update delivery, insufficient access controls on device management APIs, weak or absent authentication on MQTT brokers and communication protocols, excessive data collection beyond device function requirements, and missing physical tamper protection.

5. Is IoT penetration testing required for FDA medical device approval?

FDA requires cybersecurity documentation in premarket submissions for connected medical devices. The Consolidated Appropriations Act of 2023 gave FDA authority to require cybersecurity information including Software Bills of Materials and evidence of secure design. While FDA doesn't mandate penetration testing by name, demonstrating device security through professional testing provides the strongest evidence supporting FDA cybersecurity requirements. Medical device manufacturers conducting IoT penetration testing are better positioned for FDA review and demonstrate due diligence for patient safety.

6. What is the OWASP IoT Top 10?

The OWASP IoT Top 10 is the industry-standard risk framework for IoT security assessment. It identifies the ten most critical IoT security risks: weak/hardcoded passwords, insecure network services, insecure ecosystem interfaces, lack of secure update mechanism, use of insecure/outdated components, insufficient privacy protections, insecure data transfer and storage, lack of device management, insecure default settings, and lack of physical hardening. Comprehensive IoT penetration testing systematically tests all ten categories.

7. How often should IoT devices be tested?

IoT devices should be tested during product development (identifying vulnerabilities early), before initial product launch, after firmware updates introducing new code, annually for deployed device fleets, when entering new regulatory markets (US FDA, California SB-327), and after security incidents affecting the device type. Annual testing of production devices validates that security posture remains adequate as attack techniques evolve. Continuous monitoring of device fleet behaviour supplements periodic deep-dive testing.

8. What tools are used for IoT penetration testing?

Professional IoT penetration testing uses specialised tools including Binwalk for firmware extraction and analysis, Ghidra and IDA Pro for reverse engineering, EMBA for automated firmware assessment, JTAGulator for debug interface discovery, Saleae logic analysers for bus communication capture, Ubertooth for Bluetooth security testing, Wireshark for protocol analysis, and standard tools (Burp Suite, Nmap, Metasploit) for API, web, and network testing of IoT ecosystems. Hardware testing requires additional equipment including flash programmers, UART adapters, and soldering stations.

9. Can IoT penetration testing be done without physical device access?

Partial IoT testing can be conducted remotely by assessing cloud APIs, mobile applications, network-accessible device interfaces, and publicly available firmware. However, comprehensive IoT penetration testing requires physical device access for hardware assessment, firmware extraction from storage, debug interface testing, and communication protocol interception. Organisations should provide test devices to pentest providers. Development or pre-production devices are acceptable when production devices aren't available, though production firmware should be tested.

10. How do I choose an IoT penetration testing provider?

Evaluate providers based on IoT-specific expertise (not just traditional IT pentesting skills), firmware analysis capability (extraction, reverse engineering, emulation), hardware testing equipment and experience (JTAG, logic analysers, bus sniffing), communication protocol expertise (Bluetooth, Zigbee, MQTT), full-stack testing covering hardware through cloud, OWASP IoT Top 10 methodology coverage, sample report quality with exploitation evidence, and regulatory expertise relevant to your industry (FDA, NIST, PCI DSS). IoT security testing requires fundamentally different skills than web application testing, so verify IoT-specific capability rather than assuming general pentest expertise transfers.