IoT and Hardware Penetration Testing: Scope and Method

A connected device can pass every network scan and still ship with an open debug port, a shared administrator password in its firmware and a private key that unlocks the whole fleet. IoT and hardware penetration testing looks at the parts a network test never reaches: the circuit board and its interfaces, the firmware image, the radios, the update mechanism and the companion app and cloud services that make up the product. This guide explains how to scope and commission that kind of test, which methodologies to require, what each layer of the assessment should examine, how the results map to the UK PSTI regime, the EU Cyber Resilience Act and ETSI EN 303 645, and how to measure improvement across product releases. It is written for product security leads at manufacturers, for enterprise teams assessing devices before they buy or deploy them, and for the engineers who fix the findings. It stays at assessor level and does not describe how to carry out attacks.

Key takeaways

Test the whole product, not the box. Hardware, firmware, local services, radio, update path, mobile app and cloud back end form one attack surface; scope all of them or state clearly which are excluded.
Use a named methodology. OWASP's IoT Security Testing Guide (ISTG) and Firmware Security Testing Methodology (FSTM) give shared terms and test cases, and ETSI TS 103 701 defines how to assess conformance with EN 303 645.
Production units tell the truth. Engineering samples often have debug access enabled; insist on retail or production builds for the main test, with samples used only to speed up analysis.
Secrets in firmware are fleet secrets. A credential or key found in one image usually applies to every unit, so its discovery is a fleet wide incident, not a single finding.
Test before each hardware revision and significant firmware release. A product that changes chips or bootloaders between test and launch has not really been tested.

What an IoT and hardware test covers

A device test is closer to a product assessment than a network test. OWASP describes the ISTG as a shared framework for manufacturers, operators and penetration testers, so that results stay comparable as devices change. Its test case categories give a practical way to divide the scope, and the table adds the product layers that surround the device. For the governance side of device programmes see the IoT Security Guide; this page concentrates on testing.

Layer	OWASP ISTG category	What the assessment examines	What good looks like
Processing units and memory	ISTG-PROC, ISTG-MEM	Whether chips and external memory expose secrets or allow code and data to be read or altered	Read protection set, sensitive data encrypted at rest, keys held in a secure element or protected storage
Installed firmware	ISTG-FW[INST]	Credentials, keys, outdated components and unsafe configuration inside the image	No hard-coded credentials, current components with an SBOM, services off unless needed
Firmware update mechanism	ISTG-FW[UPDT]	Whether updates are authenticated, protected in transit and resistant to downgrade	Signed images verified on the device, anti rollback, failure recovery
Data exchange services	ISTG-DES	Network services the device offers or consumes, locally and to the cloud	Authenticated services, current TLS, no unused listeners
Internal interfaces	ISTG-INT (including I2C and UART)	Board level buses and serial consoles between components	Consoles disabled or authenticated in production, no secrets on internal buses
Physical interfaces	ISTG-PHY	External ports such as USB and debug connectors, and debug interfaces such as JTAG or SWD	Debug locked or fused in production units, ports limited to their intended function
Radio	Name each radio explicitly in scope	Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, cellular and sub-GHz links: pairing, encryption, replay resistance	Authenticated pairing, encrypted links, replay protection on commands
Ecosystem	Outside the device model; use OWASP WSTG and MASTG	Companion mobile app, cloud APIs, provisioning and fleet management	Per device authorisation in the cloud, no shared API keys in apps or firmware

The radio layer overlaps with the Wireless Penetration Testing Guide and the Bluetooth, RFID and NFC Security Guide, and the cloud layer with the API Penetration Testing Guide. Industrial controllers on a live plant need the safety controls in the OT Penetration Testing Guide rather than a lab style device test.

Methodologies and standards to require

Ask every provider which methodology they follow and to report findings against its identifiers. Four references cover most needs.

Reference	Publisher and status	What it gives you	Use it for
IoT Security Testing Guide (ISTG)	OWASP project	Device model, attacker model and test cases grouped by component (PROC, MEM, FW, DES, INT, PHY)	Structuring scope and the findings list
Firmware Security Testing Methodology (FSTM)	OWASP project	Nine stages from information gathering and obtaining firmware through filesystem analysis, emulation, dynamic and runtime analysis to binary exploitation	Checking that firmware analysis is complete, not just a strings search
ETSI TS 103 701 V1.1.1 (2021-08)	ETSI Technical Committee CYBER, Technical Specification	Test cases and assessment criteria for each EN 303 645 provision, split into conceptual (design) and functional (implementation) tests, supported by an IXIT document from the supplier	Conformance evidence for consumer IoT, first, second or third party
OWASP IoT Top 10 (2018)	OWASP project	Ten common weakness categories, from I1 Weak, Guessable, or Hardcoded Passwords to I10 Lack of Physical Hardening	Summarising results for executives and comparing releases

ETSI states that TS 103 701 targets a baseline security level rather than sophisticated or highly targeted attacks, and that it does not define a certification scheme. A conformance assessment therefore does not replace a penetration test for higher risk products; the two answer different questions. The IXIT, the supplier's Implementation eXtra Information for Testing, also makes conformance testing a grey box exercise: an incomplete IXIT can lead to an inconclusive verdict. See the ETSI EN 303 645 Consumer IoT Guide for the provisions themselves.

Scoping a device test

Who commissions: a manufacturer tests its own product and can supply source code, schematics and debug builds. An enterprise buyer tests a product it does not own the design of, so it needs the manufacturer's permission for anything beyond its own units and its own tenant, and must respect licence terms on firmware analysis. Get legal review of both.
Units and builds: provide at least two production units, because hardware work can be destructive, plus the current firmware image and release notes. Name the hardware revision and firmware version under test so results are not applied to the wrong build.
Knowledge level: white box (source, schematics, threat model, SBOM) gives the most findings per day. Black box shows what an outsider with a retail unit can learn and is useful for a final pre-launch check.
Destructive work: state whether removing chips from the board, fault injection or other methods that can destroy units are allowed, and how many units may be lost.
Radio rules: testing that transmits must stay within local radio licensing and equipment rules; require the provider to work in a shielded enclosure or under conditions that do not interfere with other users.
Cloud and app back end: the cloud service is usually hosted on a provider platform with its own testing rules; apply them, and get the service owner's written authorisation for every endpoint, as in any Cloud Penetration Testing Guide scope.
Disclosure: agree how findings in third party components (chip vendor SDKs, open source libraries) will be reported upstream. See the PSIRT Guide.

Where identity fits

Devices are non-human identities, and the most damaging hardware findings are usually identity findings: a shared credential, an extractable private key or a cloud API key embedded in firmware. ATT&CK records the attacker side as T1552.004 Private Keys and T1552.001 Credentials In Files. The UK PSTI security requirements already make one part of this a legal duty: passwords must be unique per product or set by the user, and product unique passwords must not be sequential, based on public information or easily guessed.

A real example: the hard-coded admin credentials in HPE Aruba Instant On access points sat in the firmware of every affected unit, so owners could not see or change them until a fixed firmware release removed them. That is exactly the class of issue firmware analysis exists to find before release.

Per device identity: check that each unit has its own key or certificate, ideally generated or held in hardware. See the IoT Device Identity with TPM and DICE Guide.
Cloud authorisation: confirm that one device's credential cannot read or control another device's data through the cloud API.
Provisioning: test how identities and credentials are injected on the production line and during onboarding. See the IoT Device Onboarding Guide.

Choosing the approach

Situation	Recommended approach	Trade-off
Manufacturer, new product before launch	White box test of hardware, firmware, radio, app and cloud against ISTG and FSTM, then a short black box check of the retail build	Highest cost, but findings can still be fixed in hardware
Manufacturer, firmware update to a shipped product	Focused firmware and update mechanism test, plus regression of previous findings	Cheaper; misses board level changes, so retest hardware on any new revision
Consumer product sold in the UK or EU	EN 303 645 conformance assessment under TS 103 701, plus penetration testing for higher risk functions	Conformance proves a baseline, not resistance to targeted attack
Enterprise buying devices at scale	Pre-purchase assessment of one or two units in a lab, focused on default credentials, services, update path and cloud tenancy	Limited by the vendor's terms; use the results in the contract
Small organisation buying a few devices	Ask the vendor for its own test evidence, conformance statements, support period and disclosure contact instead of testing	Relies on vendor evidence; check it is recent and names the version

The IoT Security Buyer's Guide lists the vendor questions that complement a lab test.

Implementation: running one device test well

Threat model first: list who would attack the product, what they could gain (fleet control, privacy, safety) and which layers matter most. Share it with the tester.
Prepare the package: production units, firmware images, SBOM, architecture diagram, cloud test tenant, test accounts with expiry dates, and for conformance work the completed IXIT.
Agree the rules: destructive limits, radio conditions, cloud authorisation, handling of extracted firmware and keys, and immediate notification of any fleet wide secret.
Run in phases: hardware and interfaces, firmware analysis, local and radio services, update mechanism, then app and cloud, with a mid-point review so critical findings reach engineers early.
Handle fleet secrets as incidents: if a shared key or credential is found, start your PSIRT process at once rather than waiting for the report.
Fix and verify: fixes in hardware need a new board revision; fixes in firmware need a signed release and a check that older vulnerable images cannot be reinstalled.
Close down: recover or destroy units, delete extracted firmware and keys held by the provider, and revoke test accounts and cloud credentials.
Retest and record: retest every high and critical finding on the production build and keep the evidence for regulatory files.

Regulation that drives device testing

Regime	Status as of November 2026	What testing should evidence
UK Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023	In force since 29 April 2024	Unique or user set passwords; a published vulnerability reporting contact with response timescales; a published defined support period. See the UK PSTI Act Guide
EU Cyber Resilience Act, Regulation (EU) 2024/2847	In force 10 December 2024; reporting obligations apply from 11 September 2026; main obligations from 11 December 2027	Conformity assessment, third party by a notified body for some product classes, and CE marking. See the EU Cyber Resilience Act Guide
ETSI EN 303 645 with TS 103 701	European Standard with a published conformance assessment specification	Baseline consumer IoT provisions, tested conceptually and functionally
NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline	Final, May 2020	Device capabilities for identification, configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. See the NIST IR 8259 IoT Device Cybersecurity Baseline Guide

Dates and status move: confirm them against the official texts before relying on them for a compliance decision.

Detection and measurement

For a manufacturer, measurement is about whether each release is more resistant than the last. For an enterprise, it is about whether deployed devices stay in their tested state.

In the fleet: monitor firmware versions and integrity reports from devices that support attestation, failed update verifications, and devices reporting debug or recovery modes.
In the cloud: alert on one device credential used from many locations or for many device IDs, which indicates a shared or extracted secret.
In the product pipeline: scan each firmware build for credentials, private keys and known vulnerable components before signing.

Metric	What it shows	Direction
High and critical findings per release, by ISTG category	Where the design is weakest	Down
Production units with debug interfaces locked	Manufacturing control of hardware hardening	Up, towards 100 percent
Firmware builds released with zero embedded secrets	Pipeline control of credentials and keys	Up, towards 100 percent
Days from finding to signed fix available	Product security response speed	Down
Repeat findings across releases	Whether fixes reach the shared code base	Down, towards zero
Deployed devices on a supported, tested firmware version	Fleet exposure for operators	Up

Framework mapping

Framework	Reference	How device testing relates
NIST SP 800-53 Rev. 5	SA-11 Developer Testing and Evaluation; CA-8 Penetration Testing	Testing by the developer and independent testing of the product
NIST SP 800-53 Rev. 5	SI-7 Software, Firmware, and Information Integrity; SR-11 Component Authenticity	Firmware integrity and genuine components, both examined in a hardware test
NIST CSF 2.0	ID.RA-01; ID.IM-02	Vulnerabilities identified and validated; improvements from tests
MITRE ATT&CK v20	T1542.001 System Firmware; T1495 Firmware Corruption; T1200 Hardware Additions; T1552.004 Private Keys	Attacker behaviour the hardware and firmware tests reproduce under control
MITRE D3FEND	D3-FV Firmware Verification	The defensive technique a signed update and secure boot review validates. See D3-FV Firmware Verification
OWASP IoT Top 10 (2018)	I1 to I10	Summary categories for reporting

Common failure patterns

Testing an engineering sample: debug access is open on the sample and closed on the retail unit, or the reverse, so findings do not match what customers receive.
Network scan only: the device is scanned like a server, and the firmware, board interfaces and radio links are never examined.
Ignoring the ecosystem: the device is hardened but the cloud API lets any device credential read other devices' data, or the mobile app carries a shared API key.
One test for the product's lifetime: a later board revision changes the microcontroller or bootloader and nobody retests.
Treating an embedded secret as one finding: a shared key is fixed in the next firmware release while every deployed unit keeps it, with no rotation plan.
Conformance read as assurance: a pass against a baseline standard is presented to customers as proof of resistance to targeted attack.

Practitioner checklist

Scope hardware, firmware, update path, radio, mobile app and cloud, and list anything excluded.
Require OWASP ISTG categories and FSTM stages in the statement of work and the report.
Test production units and name the hardware revision and firmware version.
Agree destructive limits, radio conditions and cloud authorisation in writing.
Confirm debug interfaces and serial consoles are locked or authenticated in production builds.
Check for hard-coded credentials, private keys and API keys in every firmware image and app.
Verify signed updates, anti rollback and per device identity.
Start your PSIRT process immediately for any fleet wide secret.
Map results to PSTI, CRA and EN 303 645 evidence where those regimes apply.
Retest on every new hardware revision and significant firmware release.

IoT and Hardware Penetration Testing Guide: Firmware, Debug Ports and Radio