1
Scope and ship
We agree the models, firmware versions and radio protocols in scope, and you send us units we may dismantle.
Cloud & devices
Hardware & IoT pentest
A test of the device itself and everything around it — firmware, debug interfaces, radio, the cloud it calls home and the app that controls it — carried out on physical units in our lab.
8
areas covered
5
stages, scoping to retest
In-house
testers, never subcontracted
portal.cyberlysecure.com/acme-health/coverage
Acme Health — Test coverage4 practices · 15 services · one team
In-houseWeb app
API
SaaS
Mobile
Client-side
External
Internal
Segment test
Wireless
Cloud config
Hardware & IoT
AI & LLM
Social eng.
Physical
Red team
ApplicationsNetworkCloud & devicesPeople & premises
6 in scope · one team · one report
In-house testers 0 subcontracted
Every surface one team
What this is
What the test covers.
A connected device is shipped into an environment you do not control, and anyone who buys one can take it apart. If secrets live in firmware, or an update can be replaced, one device becomes every device.
We test physical units end to end: what the board exposes, what the firmware holds, what the radio says and whether the cloud trusts the device more than it should.
OWASP IoT Top 10 OWASP Firmware Security Testing Methodology PTES
What we test
- Physical interfaces: UART, JTAG, SWD and SPI flash access
- Firmware extraction, unpacking and analysis
- Secure boot, signing and update integrity, including rollback
- Secrets and keys stored on the device, and whether they are shared across the fleet
- Device-to-cloud communication: transport, authentication and provisioning
- Companion mobile or web application and its API
- Radio protocols in scope — Bluetooth Low Energy, Zigbee, LoRa or proprietary
- Tamper resistance and what physical access yields
How it runs
From scoping call to retest, here’s what happens.
Typically two to four weeks, depending on the device and protocols involved.
2
Open the device
We identify components, find debug interfaces and recover firmware from the board where possible.
3
Analyse the firmware
We unpack and review the firmware for secrets, weak cryptography, exposed services and update handling.
4
Test it live
We watch and manipulate what the device says to the cloud, to its app and over the air.
5
Report, readout and retest
Findings come with photographs, captures and reproduction steps, followed by a readout and a retest.
What it surfaces
The kind of thing this test tends to find.
Real examples of what this engagement uncovers — anonymized, and never every time. What matters is that you find out before somebody else does.
A live debug interface with an unauthenticated root shell
One signing or API key shared across an entire product line
Firmware updates accepted without verified signatures
Cloud APIs that trust a device identifier the device itself supplies
Pairing and provisioning flows that a nearby attacker can take over
Getting started
What you get, and what we need from you.
What you get
- Technical report — Every finding, the evidence behind it and clear guidance your engineers can act on.
- Executive summary — Your risk explained in plain language for leadership and the board.
- Attestation letter — Signed confirmation of testing to hand your auditors.
- Readout call — A walkthrough with the people who tested your systems.
- Retest — Confirmation your fixes worked, documented for whoever needs to see it.
What we need from you
- Two or more physical units we are permitted to open and potentially damage
- Current firmware images and, where available, schematics or a datasheet
- Cloud and app test accounts
- Confirmation of which radio protocols are in scope
Missing something on this list? Bring it to the call — we scope around what you have.