IoT and embedded device penetration testing

The finding that matters in a connected product is almost never a bug in one device. It is one key, burned into every unit you shipped, that anyone with $40 CAD of hardware and a weekend can pull out of a flash chip.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

Testing a connected product properly costs $20,000 to $60,000 CAD and often more. It is not one engagement. A device with a mobile app and a cloud back end is four attack surfaces that share a brand: the hardware itself, the firmware running on it, the companion application, and the API the device talks to. Firms that quote $9,000 CAD for IoT testing are testing one of those, usually the cloud API, and calling it the product. Useful, but it will not find the class of flaw that forces a recall.

Four surfaces, four prices

Buying all four at once is the right answer for a first assessment of a product you are about to ship at volume. For a product already in market, the cloud API and the companion app are the layers where a flaw is exploitable at scale without physical access, and the two you can fix without a firmware update. Start there. The API half of that work is the same discipline described on API penetration testing, and the app half on mobile penetration testing.

What happens on the bench

Hardware testing is the part buyers have never bought before and price badly. A tester takes a production unit, opens it, and works through a standard ladder. It is slow, it is physical, and it consumes devices.

1. Identify the board. Photograph it, read the part numbers off the microcontroller and the flash, and pull the datasheets to find out what debug interfaces exist.
2. Find the debug pads. UART headers are frequently left populated and frequently drop straight to a root shell with no password. That is how the firmware team worked during development.
3. Try JTAG or SWD. If the debug port was never fused off in production, the tester can halt the processor and read memory directly, which ends the conversation about firmware confidentiality.
4. Pull the firmware anyway. Desoldering the flash chip and reading it on a programmer works whether or not debug is locked, and costs the tester an hour and a device.
5. Take the image apart. Unpack the filesystem, look for keys, certificates, hardcoded credentials, and the update-verification code.
6. Check secure boot honestly. Modify the image, reflash it, and see whether the device boots it. A device that says it verifies signatures and boots a modified image anyway is the most consequential finding in the category.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

Over-the-air updates decide how bad a finding is

Ask two questions about your update mechanism before you scope anything else. The answers change the severity of every other finding on the report. Can the device be updated in the field at all, and does it verify the signature of an update before installing it, using a key it does not also store in a readable form?

A device with signed, verified, field-deployable updates can recover from a firmware flaw. A device without them cannot, and a finding that would be a medium on a web application becomes a critical, because the remediation is a truck roll or a recall. That relationship is why severity on a hardware report looks harsher than buyers expect, and why the scoring method should be agreed in advance. More at CVSS v3.1 versus v4.0 and on how to read a penetration test report.

Scoping, and the line items nobody warns you about

Supply several units, in the production configuration rather than an engineering build, and accept in writing that some will not come back. Desoldering a flash chip is destructive and reading a fused microcontroller sometimes involves techniques that are worse. Supply the schematics and the firmware source if you have them. A white box hardware engagement finds substantially more per day than a black box one, for the reasons on penetration testing types.

Say which radio the device uses, whether there is a provisioning or pairing flow, how devices enrol with your cloud, and whether the same firmware runs on several product variants. The last question changes the price most: a shared firmware base means one engagement can cover a family, separate codebases cannot. Write it all into the scope document using how to write a penetration test scope, then compare quotes against what a quote should itemise. Not every firm has a hardware lab. Ask, and ask whether the hardware portion is subcontracted.

The regulatory picture, briefly

Consumer connected products sold into the United Kingdom fall under the product security regime of the Product Security and Telecommunications Infrastructure Act 2022, which brought in duties around default passwords, vulnerability disclosure contacts and stated support periods. In the European Union the Cyber Resilience Act sets security requirements for products with digital elements, with the bulk of the manufacturer obligations arriving at the end of 2027 and some reporting duties earlier. The United States has a voluntary consumer labelling program rather than a mandate. Dates and thresholds in this area have moved more than once, so confirm the current text against the regulator before you plan a launch around it.

For a Canadian manufacturer the practical effect is that the assessment you buy for your own assurance is increasingly also the evidence a foreign market asks for. If your device handles personal information about the people using it, your obligations at home run through PIPEDA, and in Quebec through Law 25, regardless of what any product regulation elsewhere requires.

When you should not buy a hardware pentest

If you did not build the device, do not buy this. A company deploying somebody else's sensors, cameras or gateways cannot fix a firmware flaw and cannot change a shared key, so the report would be a list of problems belonging to your supplier. What you need instead is supplier assurance: ask the manufacturer for their own test report and its date, ask about their update policy and stated support period, and put both into your vendor questionnaire. Security questionnaire answers covers how that exchange normally runs.

The other case is the pre-production prototype. Testing a board that will change before manufacture spends money on a version that will not ship. Test the release candidate, once the production firmware and the production provisioning process are settled, and if you want earlier feedback buy a design review of the key management and update architecture rather than a bench engagement. That review costs a fraction of the test and catches the fleet-wide key problem before it is burned into a hundred thousand units.

Common questions