IOT PENETRATION TESTING
Firmware, hardware, network protocol, application, and cloud, with reverse engineering, mapped to the OWASP IoT Top 10.
A connected device has five layers to secure. 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 covers one of those layers and a network scan covers another; following the chain from a soldered debug header to a hardcoded key in the firmware to the cloud API that key unlocks takes testing across all five. That end-to-end path is where IoT products fail, and an IoT penetration test follows it. 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 hardcoded secrets and credentials, weak or home-grown cryptography, debug functionality left enabled, and backdoors.
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
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
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. Anything left out of scope is agreed at this stage.
Because IoT products vary so much, this is where we agree the depth of each layer against your device and your constraints.
Firmware & hardware analysis
We acquire the firmware (flash dump, JTAG, or update package), unpack the file system, and reverse-engineer it, while examining the board's physical interfaces and debug ports for what they expose.
Looking for secrets, weak crypto, and backdoors.
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.
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.
Reporting
We write up every finding with impact, a Risk Level, and a reproduction path, so your engineers can see exactly what we did.
Retest
Once your team has fixed the issues, we retest to confirm each one is genuinely closed.
The report is updated 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 to reproduce each finding, across whichever layer it lives in.
Remediation guidance
Practical fixes tied to your device and architecture.
Retest verification
Findings are re-checked after your fixes and the report is updated to reflect closed items.
Team credentials
- OSCP
- OSCE
- CREST CRT
- CREST CPSA
- GIAC GREM
Testing is performed by our in-house team, with certifications earned through hands-on practical 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.
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.
Related services
Mobile application penetration test
The companion app is tested with the same methodology as our standalone mobile application engagements.
Web application penetration test
The web application the device exposes or depends on is tested with the same methodology as our standalone web application engagements.
Cloud security assessment
The cloud environment and the APIs the device calls are assessed with our cloud security assessment methodology.
Consulting
A penetration test tells you where the product breaks today; our consulting team can help where a device has to stay defensible across its lifetime.
Last reviewed: 12 Oct 2026
IoT Penetration Test
Tell us which layers your device has: debug port, companion app, cloud services. We agree the depth of each layer with you before testing starts.
Frequently asked questions
What does an IoT penetration test cover?
We test five layers against the OWASP IoT Top 10: Firmware, Network communication, Hardware, Application, and Cloud infrastructure. We follow each finding across layers, so a weakness in one (a debug port, say) is traced through to what it exposes in another (a cloud API).
What if my device has no debug port or companion app?
Not every device exposes all five layers, so we scope each layer to what your device actually has. During scoping we map which layers exist: whether there is a debug port to work with, a companion app or device-hosted web interface, and which cloud services it depends on. We then agree the depth of each against your device and constraints.
Which standard do you follow?
The OWASP IoT Top 10 for the device itself, and the standards behind our mobile, web, and cloud testing for the layers around it, because a connected product is assessed by whichever discipline owns the layer in front of you. A firmware finding often cannot be fixed the way a web finding is, since the fix ships as an update your customers have to install, so remediation advice for that layer is written with the rollout in mind.
Related articles
ARTICLES/3 Apr 2025
เรื่องราวของ “Kingpin” ผู้บุกเบิกโลกของ Hardware Hacking
Joe Grand หรือ Kingpin เริ่มแกะและดัดแปลงระบบอิเล็กทรอนิกส์มาตั้งแต่ยุค 1980 จนกลายเป็นผู้บุกเบิกงานแฮ็กฮาร์ดแวร์ที่ยังส่งอิทธิพลถึงวงการทุกวันนี้
ARTICLES/17 Jun 2019
DEF CON China 1.0 Badge Hacking
บันทึกจากงาน DEF CON China 1.0 ครั้งที่สองที่จัดนอกอเมริกา ว่าด้วยการแกะและแฮ็ก badge ประจำงานว่าทำอะไรได้บ้าง
ARTICLES/25 Jan 2019
ทำ Rogue Device เพื่อแทรกซึมเข้าสู่ระบบเครือข่ายเป้าหมาย
การแทรกซึมเครือข่ายเป้าหมายด้วย rogue device คืออะไร ทำงานอย่างไร และต่างจากการโจมตีผ่าน spear phishing หรือผ่าน vendor ตรงไหน
Tell us what your device is made of
We map which layers it has and agree the depth of each before testing starts.
