Here is a pattern we see all the time. A company builds a connected product, gets the device tested by one vendor, gets the APIs tested by another, and both reports come back reasonably clean. Then someone chains a hardcoded key from the firmware to an API endpoint nobody thought to test, and suddenly the “clean” product has a breach. 

The problem was never the testing. It was the scoping, because it rarely covers the complete ecosystem. A connected device is not one thing. It is hardware with a set of debug ports, the firmware running inside it, the short and long range protocols it talks over, the companion mobile and web applications, the cloud backend, and the APIs holding all of it together. Most pentest scopes skip this full picture, and that gap is the window an attacker uses to get into the IoT ecosystem. 

So if you are shopping for penetration testing for IoT and API security, here is how to do the scoping right. 

Map the attack surface before you ask for quotes 

Sit down and list what an attacker can actually touch. For most connected products, that comes down to the hardware (debug ports like UART and JTAG, flash memory), the firmware (how it is stored, signed, updated, and what secrets it leaks), the radio side (BLE, Zigbee, MQTT, Wi-Fi), the APIs connecting device, app, and cloud, and the companion app itself. 

Then weight your budget by exposure. Shipping a consumer device in lakhs of units? Attackers will have physical access, so hardware and firmware testing deserve real depth. Selling a B2B platform where devices live inside customer networks? You can probably shift more of the spend toward API vulnerability assessment and cloud-side testing. 

There is no universal split. There is only your product and your threat model. 

Match the method to the question you are asking 

Black box testing answers one question: what can a stranger do with zero inside knowledge? Useful, realistic, but slow, and it tends to miss business logic flaws. 

For most IoT device testing, grey box is the sensible default. Give the testers API docs, test credentials, and a firmware image, and they will find far more in the same number of days. Save white box, with full source access, for the products where a missed flaw means a recall or a regulator on the phone. Medical devices, PoS devices, and devices responsible for critical operations sit in that bucket. 

Our rule of thumb: the more painful a post-release fix would be, the more access you should hand your testers up front. 

Ask the awkward depth questions 

Depth is where vendors differ most, and where scoping calls go vague. Do not let them. 

On the device side, ask plainly: are you going to open the device and probe the debug interfaces, or just poke it over the network? Will you extract and reverse the firmware, or grep it for known CVEs? Will you actually sniff and replay the radio traffic, or assume it is fine because there is encryption somewhere? 

On the API side, ask whether the work goes past the OWASP API Security Top 10 into business logic abuse, broken object level authorization (BOLA), and rate-limit bypass. Ask whether device-to-cloud APIs get tested with a real or emulated device, or only the endpoints someone bothered to document. BOLA shows up in real breaches constantly, and automated penetration testing tools almost never catch it. 

If the answers sound like scanner output, that is what you will get: a vulnerability scan wearing a pentest invoice. 

Judge the vendor on evidence, not the brochure 

Three things separate teams that find real bugs from teams that format reports. 

Research output. Teams that discover CVEs, publish firmware teardowns, or speak at Nullcon, Black Hat, or DEF CON have proven they can find things scanners cannot. That is not marketing, that is a track record you can verify. 

A real, certified hardware lab. Genuine IoT security testing needs logic analysers, chip-off gear, and SDR rigs, run in a lab with the accreditation to stand behind its results. Ask to see the tooling list. Plenty of vendors quietly subcontract this part and hope you never ask. 

The sample report. Request a sanitised one. A good report chains findings across layers, say, a key pulled from firmware used to forge API tokens, with reproduction steps and fixes written for your stack. Not generic security hardening for APIs lifted from a checklist. 

And if your customers or regulators in India will eventually ask who tested the product, CERT-In empanelment and ISO 17025 accreditation are worth checking before you sign, not after. 

Five questions before you sign 

Make sure the proposal clearly answers these: 

• Which Layers Are Actually Tested?  

• How Is Each Layer Assessed?  

• Is the Assessment Performed Manually or Using Automated Tools?  

• What Does a Real Security Finding Look Like?  

• Is Retesting Included After Remediation?

A vendor who cannot answer these crisply on a call will not write a crisp report either. 

Test it the way it will be attacked 

Attackers do not care that your device team and your API team sit in different standups. Your pentest should not care either. The engagements that catch the scary stuff treat the connected product as one system and chain findings across layers, because that is exactly what a real adversary does. 

We have been testing connected products this way at Payatu since 2011, with an in-house hardware lab, our open-source EXPLIoT framework for IoT exploitation, and API testing that goes well past what a scanner can see. Get a scoped product security assessment covering your device, firmware, and APIs in one engagement: payatu.com/iot-security-testing