Overview
Testing begins with the board: exposed debug interfaces, flash memory that can be read directly, boot configuration that can be interrupted. Firmware is extracted and analysed for credentials, keys, update-verification logic and the services that run at boot.
From there the engagement follows the data: the radio protocol and its pairing and encryption, the companion application, and the cloud API the device authenticates to. A recurring critical pattern is a device identity that is shared across an entire production run, extract it once, impersonate any unit.
Engagement at a glance
- Surfaces
- Hardware, firmware, radio and network, companion application and cloud backend
- Typical duration
- 10 to 20 working days depending on surface count
- Requirements
- Two or three physical units, ideally one expendable for invasive testing
- Standards
- OWASP IoT Top 10, OWASP ISVS, ETSI EN 303 645
- Radio
- Wi-Fi, Bluetooth Low Energy, Zigbee and sub-GHz where in scope
- Deliverable
- Findings per layer, plus what a device-owning attacker recovers
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Debug interface identification and access (UART, JTAG, SWD)
- Flash memory extraction and firmware recovery
- Firmware unpacking, filesystem and binary analysis
- Hardcoded credentials, keys and certificates
- Secure boot and firmware update verification
- Bootloader interruption and recovery modes
- Radio protocol analysis, Wi-Fi, BLE, Zigbee, sub-GHz
- Pairing, provisioning and onboarding flows
- Device-to-cloud authentication and identity
- Companion mobile application testing
- Cloud API and device management platform
- Physical tamper resistance and port exposure
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Hardware access | Board inspection, test point identification, debug interface probing and enablement | Direct memory and execution access on the device |
| Firmware | Extraction from flash or update packages, unpacking, secret sweep, binary analysis | Credentials, keys and endpoints recovered from any purchased unit |
| Update integrity | Signature verification, downgrade protection, transport security, rollback handling | Attacker-supplied firmware accepted and persisted |
| Radio | Traffic capture, protocol reconstruction, pairing and encryption analysis, replay testing | Commands injected or captured from radio range |
| Device identity | Per-unit versus shared credentials, certificate provisioning, revocation | One extracted identity impersonating the whole fleet |
| Cloud | Device management API tested with a device identity, including other devices’ resources | Fleet-wide control from a single compromised unit |
What we commonly find
A shared secret across the production run
Recover it from one unit and every device in the field speaks with the same authority.
UART still enabled with a root shell
Four solder points and a serial adapter, and the filesystem is open.
Firmware updates without signature verification
The device checks the version number, not the signature, persistent compromise follows.
A cloud API that trusts the device identifier
Change the identifier in the request, control someone else’s device.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Before mass production, while hardware changes are still possible.
- Ahead of certification against ETSI EN 303 645 or a comparable consumer IoT baseline.
- When entering a regulated market or a large retail channel.
- After a firmware architecture change, particularly to the update mechanism.
Questions
How many devices do you need?
Two or three. At least one should be expendable: invasive testing such as chip removal or flash desoldering can render a unit unusable, and that unit often yields the most significant findings.
Can you test without hardware modification?
Yes, though it limits depth. Non-invasive testing covers radio, network, companion application and cloud. Firmware extraction and debug interface work require physical access to the board and are where hardcoded secrets are usually found.
Do you test the companion app and cloud too?
Yes. They are part of the product’s attack surface and are frequently where the most severe findings sit. A device compromise that stops at one unit is far less serious than a cloud API that lets one device control the fleet.
What about certification requirements?
Findings are mapped to the relevant ETSI EN 303 645 provisions and OWASP IoT Top 10 categories, which gives your certification body evidence in a shape they already work with.
How much does IoT or embedded device testing cost?
Scope is driven by device count and variety, whether firmware and hardware access are available, and whether the companion app and cloud backend are included. A fixed quote follows a short scoping call, and the device, app and cloud are usually cheaper tested together than separately.
Do you extract and analyse firmware?
Yes. Firmware is extracted where the hardware permits, unpacked and analysed for hardcoded credentials, keys, certificates, debug interfaces and update verification logic. An update mechanism that does not verify signatures is the finding that turns one device compromise into a fleet compromise.
Can you test hardware interfaces like UART, JTAG or SPI?
Yes, on devices provided for the engagement. Exposed debug interfaces are a recurring finding, and the question is what they grant: a console, a memory dump, or the key material that lets a cloned device authenticate as a real one.
Do you test the radio protocols our devices use?
Bluetooth Low Energy, Wi-Fi and Zigbee are covered where they are in scope, along with pairing and provisioning flows. Proprietary and sub-GHz protocols are assessed case by case and agreed at scoping rather than promised in advance.
Will testing damage the devices?
Possibly, and that is agreed in advance. Hardware testing can be destructive, so devices supplied for the engagement are treated as expendable and we say which techniques carry that risk before using them. Nothing destructive is performed against a device in service.