A connected product is four targets pretending to be one: hardware, firmware, a radio and a cloud backend with an app in front of it. This is the order we test them in, what lands on your desk at the end, and what the engagement deliberately leaves out.
Ask three vendors to test "the device" and you get three different scopes. A connected product is not one target but a small distributed system, and the failures worth finding live in the seams between its parts: the board and its debug interfaces, the firmware and its update mechanism, the radios and their pairing flows, and the cloud API the whole fleet talks to.
A test that stops at the board is a hardware review. One that stops at the API is an API pentest. An IoT penetration test follows a finding across the boundaries: the key read off a flash chip that then authenticates to the production API.
OWASP’s IoT Security Testing Guide splits a device the same way, into processing units, memory, firmware, data exchange services, and internal, physical, wireless and user interfaces.
Before a screw comes out we agree in writing which hardware revisions and firmware versions are in scope, which cloud environment we point at, which radio bands we may transmit on, and what happens when a unit dies.
Physical testing destroys devices. If the only unit in existence is the one on your demo stand, the engagement ends when a soldering iron slips.
The rules of engagement settle the logistics that otherwise eat a week: who we call at 02:00, which addresses are ours, whether production telemetry is in play, and whether legal has cleared reverse engineering of third-party components.
Regulation sets the clock. The EU Cyber Resilience Act entered into force on 10 December 2024, with reporting obligations from 11 September 2026 and its main obligations from 11 December 2027. If your product carries a CE mark and connects to anything, that applies to you.
Reconnaissance here is less about scanning than about drawing the thing accurately. We take a unit apart, identify the components, and build a device model: what runs where, what stores what, and every interface carrying data in or out. In parallel we watch it boot and provision on a controlled network, capture its traffic and enumerate the backend endpoints it uses.
Then the physical layer, where an IoT test stops resembling anything else. A UART console still printing its boot log. A JTAG or SWD debug port. SPI or I2C flash readable off the board. Test pads left by the factory line. The questions are simple: can we get a shell without credentials, recover secrets from the flash, boot modified code, and is secure boot enforced or merely present?
The consumer baseline is direct about this. ETSI EN 303 645 requires unused network and logical interfaces to be disabled, and debug interfaces to be disabled or protected by authentication or access control. On a plant floor rather than a kitchen counter, the reference becomes IEC 62443: part 4-2 covers components, part 3-3 covers systems and security levels.
Firmware is the centre of gravity. We obtain the image from your build server, from the update endpoint or off the chip, then work through it in order. OWASP’s Firmware Security Testing Methodology sets out nine stages for exactly this, from obtaining the firmware through extracting and analysing the filesystem, emulation, dynamic and runtime analysis, and finally binary exploitation. Firmware analysis is the phase clients assume is optional and the one that pays for the engagement.
What comes out of it, over and over:
The update path is the one control that can repair everything else after shipping: a bypassable signature check turns a local hardware finding into a remote, fleet-wide one.
Network first: which ports listen, in which device state, and whether services reachable during setup stay reachable afterwards.
Then the radios, which depend on the product. For Wi-Fi we test the provisioning flow and the temporary access point almost every device raises during onboarding, and whether that window authenticates anyone at all. For Bluetooth Low Energy we test pairing mode, characteristic permissions and whether a GATT service accepts commands with no bond in place. For Zigbee, LoRaWAN or a proprietary sub-GHz link we test key provisioning, replay protection and behaviour under jamming. Encryption in transit gets checked, never assumed: a TLS session that does not validate the server certificate is a common finding on constrained devices.
Most of the value, though, is not in one device but in the fleet, and the backend serving a hundred thousand units fails the way multi-tenant APIs fail. The most productive single test is object-level authorisation: take your own account, take a device identifier that is not yours, and ask the API for it. Broken object level authorisation is the first entry in the 2023 OWASP API Security Top 10, and here it is rarely theoretical: identifiers are printed on the box, broadcast over the air, or sequential.
The companion app is tested against the OWASP MASVS control groups, and we check whether certificate pinning survives contact with an attacker rather than merely existing. We also read the app as documentation: it is often the fullest description of the API anyone has written.
Both surfaces are tested as what they are: the back end as a cloud environment, the companion app as a mobile application, not as accessories to the device.
Nothing reaches the report because a scanner flagged it. Every candidate finding is proven on the bench: we build the exploit, run it against a device we control, and capture the evidence.
Chaining is where the value is. A UART console on its own is a hardware note. A UART console that yields a shared API key, which authenticates to the production backend, which exposes other customers’ devices, is the finding that changes a roadmap. PTES keeps exploitation and post-exploitation as separate phases for this reason, and NIST SP 800-115 loops its attack phase back into further discovery, because access earns new information.
Prioritisation follows the evidence, not a score copied from a database. Where a component is already under attack in the wild, CISA’s Known Exploited Vulnerabilities catalogue is a useful tiebreaker: it records the flaws with confirmed exploitation, which is a different question from how high a score is.
The deliverable is a document, not a tool export. It contains:
We also run a live debrief with the engineers who will do the work: half an hour walking a firmware team through the exploit is worth more than the paragraph describing it. If you need an attestation letter, say so during scoping, because what it can honestly claim depends on what was in scope.
A finding is not closed because a ticket is. Once your team ships the fixes we run a retest against the new firmware and backend, re-running the original proof for each item and confirming the fix holds rather than moves. Because fixes ship as a firmware release, the retest also confirms the update mechanism actually delivered the change.
Ranges, not promises; the introductory meeting turns them into a date. A single device with one radio, a companion app and a small API is typically two to three weeks of testing. A product family with several hardware revisions, several radios and a substantial cloud platform runs four to six. Reporting and the debrief add a few days.
What moves the range:
What does not move it is how many units you have deployed. Testing one properly tells us about all of them.
Worth stating plainly, because a test sold as covering everything covers nothing well.
If that reads like a smaller promise than the one you have heard elsewhere, that is the point. The IoT pentesting service page sets out how we scope an engagement; the fastest way to find out whether this is the right test is to describe the product.
The real sequence of an external network penetration test: scope and rules of engagement, reconnaissance, perimeter analysis, exploitation, reporting and retest, plus what the test will not cover.
The sequence of a real internal network penetration test: the starting point we agree, what a domain account becomes, what you get at the end, how long it takes and what the exercise deliberately does not cover.
The real sequence of a wireless penetration test, from the rules of engagement to the retest: what happens at each phase, what you need ready, how long it takes, and what this test deliberately does not cover.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
