Open the device.Read the chain.

Bench-level pentest on your actual device. We pull JTAG, dump firmware, sniff the radio, and chain to the cloud, every finding ships as a working exploit with the patch path and a verified re-test.

BENCH · FIRMWARE · RADIO · CLOUD

See the bench method
IoT pentest converging, hardware, firmware, radio, and cloud surfaces, with one firmware path resolving to an extracted device key.

Five surfaces

Hardware bench · firmware · radio · mobile companion · cloud / MQTT, one engagement, every layer.

Bench evidence

UART shell, dumped flash, captured pairing handshake, proof-of-exploit on the actual device.

Re-test included

We verify your fixes, firmware reflash, OTA patch, radio config, at no extra cost.

Why now

The window from vulnerability discovery to exploitation has gone from weeks to hours.

Trusted by security teams across Fintech, SaaS & Education, Enterprise & Telecom, Security & Critical Infrastructure

Airbase
Quiltt
Pacvue
Imagine Learning

On record

  • CREST accredited
  • AICPA SOC 2 Type II

What we test —

Six surfaces. Every one read on the bench.

IoT is a stack — a board, a firmware, a radio, a mobile companion, a backend the device dials home to. Each layer is reviewed by hand against the real attack surface, in the protocols and tools your team ships in.

Hardware bench — UART · JTAG · SWD · SPI flash · I²C

Enclosure opened. Test points probed with a logic analyzer. Debug interfaces brought up under OpenOCD / J-Link. SPI flash desoldered or read in-circuit, then dumped. Boot ROM and bootloader behaviour exercised against fault-injection where in scope.

Firmware — binwalk · squashfs · u-boot · secure-boot · hardcoded creds

Image carved with binwalk, root filesystem mounted, init scripts and busybox binaries reviewed by hand. Hardcoded API tokens, TLS keys, and PEM blobs extracted. Weak secure-boot anchors and unsigned bootloader-stage upgrades reported with the patch path.

Radio — BLE · Zigbee · Z-Wave · LoRa · Sub-GHz · 802.11

Packet captures with HackRF, Ubertooth, RFCat. BLE GATT walked for unauth read / write. Pairing bypass under Just Works mishandling. Zigbee key-establishment replay. LoRa join-accept tampering. Wi-Fi WPS and EAP downgrade where the device exposes them.

Mobile companion — paired iOS / Android binary

Companion app pulled from the store, instrumented under Frida, the pairing flow and deeplink handlers walked end to end. Hardcoded device secrets, weak certificate pinning to the cloud, and OAuth-state mishandling in account-linking flows.

Cloud, MQTT & OTA channel

Broker authentication walked for client-id reuse and topic over-subscription. Topic tree walked from a low-priv account for tenant isolation gaps. OTA update channel tested for unsigned image acceptance, downgrade attacks, and roll-back to a vulnerable build.

Web / device admin UI

Local admin UI, mDNS / SSDP service, and any cloud portal tested for default credentials, CSRF on state-changing endpoints, exposed /debug or /diag routes, command injection in network-config forms, and authentication-bypass via unauth API parity.

Why a network scan misses the device

Scanners read the manifest. IoT penetration testing reads the board.

A vulnerability scanner reads what the device advertises, a MAC, a few open ports, a banner, maybe a CVE match against the firmware string. That's the manifest. None of it survives contact with the hardware bench. IoT penetration testing lifts the lid. Probe the test points, attach UART, desolder or in-circuit-read the SPI flash, and the hardcoded TLS key resolves out of the firmware image. The BLE pairing accepts Just Works on a device the datasheet calls 'secure'. The MQTT client-id is the serial number printed on the label. Scanners can't capture a Zigbee replay, can't walk a GATT service, can't downgrade an OTA channel, can't read a debug credential out of squashfs. Bench work does. Every IoT engagement we close ends the same way: a working proof-of-exploit on the device, the patch path, and a written re-test.

How AI fits in IoT pentests
Two columns. Left: a closed device enclosure with one MAC dot, what a network scanner sees. Right: the same device opened on a bench, with UART, JTAG, and SPI flash exposed and chained to an extracted private key and a root shell.
Two columns. Left: a closed device enclosure with one MAC dot, what a network scanner sees. Right: the same device opened on a bench, with UART, JTAG, and SPI flash exposed and chained to an extracted private key and a root shell.

WHAT LANDS IN SCOPE.

Counted, not claimed.

An IoT engagement at SecureLayer7 covers the full stack of a connected device. Numbers below describe what's in scope on a typical engagement. Not market-size claims.

Surfaces per device
6

Hardware bench · firmware · radio · mobile companion · cloud / MQTT · device admin UI. Each reviewed by hand on the bench.

Radio protocols in scope
6+ RF

BLE · Zigbee · LoRa · 6LoWPAN · NFC · Sub-GHz. Captured with HackRF, Ubertooth, RFCat. Z-Wave and Wi-Fi added when the device exposes them.

Firmware secrets surfaced
3 classes

Keys · creds · endpoints. Hardcoded TLS keys, debug credentials, OTA-update endpoints, and signing material pulled from extracted images.

Re-test after fix
Included

Same researcher, same chain. Firmware reflash, OTA patch, or radio-config change verified and signed in writing.

FIRMWARE TO RF.

What a bench engineer finds on a device a network scanner cannot see.

5
  1. 01
    Firmware extraction

    Dump SPI flash with a clip and a Bus Pirate, unpack the squashfs, recover hardcoded API keys and update-signing certificates.

  2. 02
    Hardware debug to root

    Find UART headers under the shield can, drop to U-Boot, enable single-user mode, read /etc/shadow and the device private key.

  3. 03
    Radio capture and replay

    Sniff BLE, Zigbee, or LoRa with an SDR, replay pairing or join frames, forge sensor messages the gateway treats as authentic.

  4. 04
    Companion app to backend

    Reverse the Android APK for the device API, find an IDOR on the device-id route, control any unit on the fleet.

  5. 05
    OTA chain to cloud

    Push a signed image with a recovered key, pivot from the device MQTT identity into the broker, read tenant topics.

IOT METHODOLOGY.

Eight phases. Bench to cloud.

Threat-modelled to your device class, board revision, radio mix, and cloud reach. Not a checklist run against every device that lands on the bench.

  1. 01
    Scope & threat-model
  2. 02
    Surface recon
  3. 03
    Hardware bench
  4. 04
    Firmware extraction
  5. 05
    Radio capture & replay
  6. 06
    Mobile companion & cloud
  7. 07
    Exploit synthesis
  8. 08
    Patch verification

Meet our engagement lead

One lead across firmware, cloud, and radio.

John Dill

vCISO at SecureLayer7

Bench-led

IoT engagement model

HW · FW · Radio

In scope by default

98%

Engagement-lead close rate

John scopes IoT pentest engagements against your device class, board revision, radio mix, and cloud reach. He runs kick-off, status reviews, and sign-off so the bench pod stays heads-down on the device.

  • Scopes engagements across consumer, industrial (IEC 62443), automotive, and medical IoT against your real risk model.
  • Owns kick-off, mid-engagement walkthroughs, and live review of every bench, firmware, and radio finding.
  • Drives remediation review and re-test until every chain is closed and the patch is verified on the device.
SL7 Lab. Published CVE research.
John Dill, vCISO at SecureLayer7

Ready to scope an IoT pentest? Book 30 minutes with John to walk through your device class, board revision, radio mix, and timeline.

Book a 30-min call

Tested by industry.

The bug classes named below come from real engagements in each sector. Pick the closest fit.

Retail

POS terminals, kiosks, scanner devices, in-store IoT controllers.

HealthTech

Medical devices, infusion pumps, monitor networks, MQTT/HL7 IoT gateways.

Tech SaaS

Connected-device SaaS, firmware OTA chains, fleet-control APIs.

Built for Australia engagements

What changes when we deliver here.

  • Regulatory framework

    SOCI Act RMP findings tag

  • Compliance scoping

    CISC notification templates included

  • Local engagements

    AU utility — 1200 field devices, 3 OT zones

  • Local pricing

    AUD per-device-class pricing, GST itemised

  • Compliance scoping

    SBOM + firmware signing-chain report

Questions Australian OT and IoT owners ask first.

  • Does the report help our SOCI Act RMP?

    Yes. Findings feed the SOCI risk management programme directly. Cyber and information security hazards are tagged for the CISC-required annual review.

  • How do you handle CISC reporting obligations?

    Cyber security incident criteria under the SOCI Act amendments are listed per finding. Templates for 12-hour and 72-hour CISC notifications are in the bundle.

  • Do you test firmware and supply chain?

    Yes. Firmware reverse engineering, secure-boot bypass, and OEM signing-chain risk are in scope. SBOM ships with the report.

  • What about radio and protocol fuzzing?

    Zigbee, BLE, LoRaWAN, and Wi-Fi HaLow are tested. Each finding lists the protocol RFC and the ASD ISM wireless control.

Delivery in Australia

SOCI Act. ACSC OT. CISC reporting.

Device, gateway, and cloud findings cite SOCI Act risk-management programme clauses. OT and SCADA gaps map to ACSC and CISC operational technology guidance.

Direct line
+61-2-0000-0000
Office
Sydney, Australia

Frameworks scoped: ASD Essential 8 · APRA CPS 234 · Privacy Act · ISO/IEC 27001.

Sample IoT pentest report, chain · evidence · patch path · re-test

Sample IoT engagement report

See what arrives in your inbox.

A pre-vetted sample report: full IoT pentest narrative, working proof-of-exploit on the device (hardware, firmware, radio, cloud), the patch path, and the re-test confirmation. Sent on request after a 5-minute scoping call.