IOT PENETRATION TESTING

A connected device is not one thing to secure — it is five. The firmware running on the chip, the radio and network traffic it speaks, the physical board with its debug ports, the companion app your customers install, and the cloud backend it phones home to are all part of the same product, and an attacker will pick whichever of them is weakest. A web app pentest looks at one of those layers; a network scan looks at another; neither follows the chain from a soldered debug header to a hardcoded key in the firmware to the cloud API that key unlocks. That end-to-end path is exactly where IoT products fail, and it is what an IoT penetration test is built to walk. We assess the whole device against the OWASP IoT Top 10, and because IoT products vary enormously, we agree the exact depth of each layer with you before testing starts.

The five layers we test

An IoT product's attack surface spans five layers. Not every device exposes all of them — some ship without a debug port, some have no companion app — so we scope each layer to what your device actually has.

• Firmware — We pull the firmware, whether by flash memory dump, JTAG exploitation, or extracting an update package, then unpack and analyse the file system. From there we reverse-engineer the binaries looking for the things vendors assume no one will ever see: hardcoded secrets and credentials, weak or home-grown cryptography, debug functionality left enabled, and backdoors. Firmware analysis is where the device's real trust assumptions are written down, and where they most often turn out to be wrong.
• Network communication — We look at how the device talks — to its peers, its controller, and its backend. That means open port discovery, packet analysis of the protocols in use, and active testing: tampering with messages in transit, protocol exploitation, replay attacks that resend captured commands, and, where the device relies on wireless links, jamming-based attacks against availability. The question is whether an attacker on the same network, or within radio range, can read, forge, or replay what the device sends.
• Hardware — We examine the physical device itself: exposed interfaces, debug ports, and test points on the board that were meant for the factory but shipped to the field. Physical access often collapses every other defence at once — a debug port can hand over the firmware or a root shell — so we map what an attacker with the device in hand can reach. The specifics depend on your board; we agree them during scoping.
• Application — Almost every IoT product has software the user actually touches: a companion mobile app, and often a web application the device exposes or depends on. We test these with the same methodology as our standalone mobile application and web application engagements, including reverse-engineering the companion app to find how it authenticates, what it stores, and what it trusts.
• Cloud infrastructure — A smart device is only as safe as the cloud it trusts. We assess the backend the device connects to — the cloud environment and the APIs the device and app call — reusing our cloud security assessment methodology. A weak device API or a misconfigured backend can expose every device in the fleet at once, regardless of how well the hardware is built.

How we work

Every engagement runs through the same phases, so you always know where the project stands and what arrives next.

1. Scoping the device — We map the product with you: which layers it has, whether there is a debug port to work with, whether there is a companion app or a device-hosted web interface, and which cloud services and APIs it depends on. Because IoT products vary so much, this is where we agree the depth of each layer against your device and your constraints — untested surface is decided here, not discovered at the end.
2. Firmware & hardware analysis — We acquire the firmware (flash dump, JTAG, or update package), unpack the file system, and reverse-engineer it for secrets, weak crypto, and backdoors, while examining the board's physical interfaces and debug ports for what they expose.
3. Network & protocol testing — We discover open ports, capture and analyse the device's traffic, and actively test the protocols in use — tampering, protocol exploitation, replay, and where relevant jamming — to see what an attacker on the network or within radio range can do.
4. Application & cloud testing — We test the companion app and any web interface, and assess the cloud backend and its APIs, following our mobile, web, and cloud methodologies so these layers get the same depth as a dedicated engagement.
5. Reporting — We write up every finding with impact, a Risk Level, and a reproduction path, so your engineers can see exactly what we did.
6. Retest — Once your team has fixed the issues, we retest to confirm each one is genuinely closed and update the report accordingly.

What you get

Every report contains, at minimum:

• Executive summary — a business-level risk picture, suitable for management and auditors.
• Findings by Risk Level — each issue rated Critical, High, Medium, or Low so remediation can be prioritised objectively.
• Reproduction / POC for every finding — the exact steps, commands, and payloads that reproduce the issue, across whichever layer it lives in; your engineers should never have to guess how we did it.
• Remediation guidance — practical fixes tied to your device and architecture, not scanner boilerplate.
• Retest verification — findings are re-checked after your fixes and the report is updated to reflect closed items.

Team credentials

Testing is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination. The same offensive-security background that underpins our application and network testing is what the team brings to firmware reverse engineering and hardware analysis. See the full list of certifications the team holds.

Standards

Our IoT testing is grounded in the OWASP IoT Top 10, so findings line up with a framework your developers and auditors already recognise. Because an IoT engagement reaches across several disciplines, the app and cloud layers also draw on the standards behind our mobile application, web application, and cloud security assessment testing. A penetration test tells you where the product breaks today; where a device has to stay defensible across its lifetime, that becomes a broader security question our consulting team can help you address.