Key Findings:
- An IoT product is four attack surfaces, not one: firmware, companion app, communication layer, and cloud backend. Each is a separate scope with its own toolchain and its own testing days.
- A pentest report is evidence for specific SOC 2 criteria, not a SOC 2 pass. It counts for the layers your system description actually names.
- Our IoT scope is software-side. Firmware analysis is static, from a binary you supply. Chip-off, JTAG and side-channel work is a hardware lab engagement and we say so.
- Most critical findings we report on connected products sit in the cloud backend and the communication layer, not in the firmware.
An IoT pentest report is evidence for specific SOC 2 criteria covering the layers it actually tested, not a blanket answer to a SOC 2 or enterprise onboarding requirement. SOC 2 evidence follows your system description: a test of the cloud backend evidences CC7.1 (Vulnerability Detection) for the backend, and as an independent third-party evaluation it supports CC4.1 (Ongoing and/or Separate Evaluations), but it says nothing about firmware or a companion app your system description also names. An IoT product is normally four separate scopes: device firmware, companion mobile app, the communication layer such as BLE or MQTT, and the cloud backend and its APIs. One scope means one layer, at 5 business days per layer. Decide which layers you are buying by asking where the sensitive data sits and which layer your enterprise buyer named in their questionnaire.
Cybersecify is a founder-led penetration testing firm in Bengaluru. IoT penetration testing is one of our ten pentest scopes. Connected-product companies almost always arrive at it the same way: an enterprise customer sends a security questionnaire, or a SOC 2 auditor asks for the most recent test report, and the founder has to work out what to buy without a security background. This page is written for that moment.
Does an IoT pentest count for SOC 2 evidence?
It counts for the part of your system it actually tested, which is usually less than a buyer assumes.
Start with the thing most vendors skip. The AICPA does not require a penetration test for SOC 2, for Type 1 or for Type 2. What auditors commonly accept a pentest as is evidence for specific criteria, principally CC7.1 (Vulnerability Detection). That is a different statement, and it is the honest one. Our SOC 2 pentest guide covers the general case.
For a connected product the practical question is narrower: which layers does your SOC 2 system description commit you to?
- If your system description covers the cloud backend receiving device telemetry and the customer-facing dashboard, then a test of that backend and dashboard is evidence for those systems.
- If your system description also names the device firmware and the companion mobile app, a test that covered only the cloud API leaves those uncovered, and the gap is visible to the auditor when they compare your scope statement against your system description.
The failure mode is not that the report is rejected. It is that the report covers less than the boundary you described, so a scope gap appears at evidence review with no time left to close it. Ask your auditor which systems they expect covered before you scope the test, not after.
An independent third-party test also supports CC4.1 (Ongoing and/or Separate Evaluations), because a third-party test is a separate evaluation of your controls. That one is worth naming in the report, and many vendors do not.
What counts as one scope in an IoT penetration test?
One layer of the product, not the whole product.
This is the single biggest source of mismatched expectations in IoT engagements. A connected product is four separate attack surfaces:
| Layer | What is tested | What you supply |
|---|---|---|
| Device firmware | Hardcoded credentials and keys, insecure defaults, vulnerable libraries, debug paths left in a production build, update verification | The firmware binary |
| Companion mobile app | Authentication, insecure local storage, hardcoded API keys, authorization gaps between app and server | An installable build |
| Communication layer | Encryption in transit, certificate handling, MQTT and CoAP security, BLE pairing and characteristic access | A device or simulator |
| Cloud backend and APIs | Authentication, per-device authorization, tenant isolation, device identifier handling | A test tenant and credentials |
Each has its own toolchain, its own class of finding and its own testing time. A vendor quoting a whole connected product as one scope is either planning a shallow pass over four surfaces or has not understood the product. Either way you find out at report time.
The realistic starting point for most startups is two scopes: the cloud backend and its APIs, plus whichever of the companion app or the firmware your enterprise buyer actually named. That maps to our Growth Pentest at INR 1,79,999, two scopes over 10 business days.
What are the four layers of an IoT penetration test?
Firmware. We analyse the binary you supply for hardcoded credentials and API keys, private keys and certificates shipped in the build, insecure default configurations, vulnerable or outdated third-party libraries, debug interfaces left enabled in production builds, and update mechanisms that do not verify what they install.
Companion mobile app. Authentication flaws, insecure local storage of tokens and device secrets, hardcoded API keys, and the authorization gap that matters most: checks the app enforces which the server does not.
Communication. Interception and analysis of traffic between device, cloud and app. Encryption in transit and certificate handling. MQTT and CoAP protocol security where they are in use. BLE pairing, discoverability and characteristic access control.
Cloud backend and APIs. This is an API pentest with device-shaped questions on top. Authentication, per-device authorization, tenant isolation, and whether one customer’s device identifier can be used to read or command another customer’s device. If you want the general version of this, API pentest versus web app pentest covers what makes an API surface distinct.
Most of the critical findings we report on connected products sit in the last two layers rather than in the firmware. That is worth knowing before you spend your first engagement on firmware because it feels like the most technical layer.
Does an IoT pentest include hardware attacks?
Ours does not, and you should ask any vendor to say so plainly either way.
We evaluate IoT devices and their supporting platforms for software-side vulnerabilities: firmware static analysis from a supplied binary, protocol and communication testing, authentication and access control testing, companion app review, and cloud backend assessment.
We do not do chip-off memory extraction, JTAG or UART debug port work, side-channel analysis, or fault injection. Those need a hardware security lab, different equipment and different people.
If your enterprise customer or your regulator is specifically asking about physical tamper resistance or secure element attacks, that is a hardware lab scope. We will tell you that rather than sell you the software test and let you find the gap at review time. A vendor who answers “yes, we cover hardware” without naming the equipment is worth a second question.
Is firmware analysis static or dynamic in an IoT pentest?
Static, from a binary you supply.
Static analysis finds a large share of the real issues at a predictable cost: credentials and keys baked into the image, certificates shipped in the build, insecure defaults, outdated libraries with known vulnerabilities, debug interfaces alive in a production build, and update mechanisms with no verification of what they install.
What it does not do is exercise the running firmware on the device under attacker-controlled conditions. That is a dynamic exercise, usually paired with hardware access, and it is a different engagement. If you need it, say so at scoping so it is quoted as what it is rather than assumed to be included.
What is ETSI EN 303 645 and will an enterprise customer ask about it?
ETSI EN 303 645 is a European baseline standard of security provisions for consumer Internet of Things devices. It covers provisions such as no universal default passwords, a means to manage reports of vulnerabilities, keeping software updated, securely storing sensitive security parameters, and communicating securely.
Two things to understand about it. First, it is a baseline of provisions, not a certification you pass the way SOC 2 or ISO 27001 works. Second, whether anyone asks you about it depends almost entirely on your market.
- Consumer device companies and European distribution partners raise it, sometimes as a procurement condition.
- US enterprise security teams onboarding a SaaS vendor almost always raise SOC 2 and their own questionnaire instead.
We use it as a testing reference on consumer device work rather than presenting it as a badge, because presenting a baseline as a pass would be the kind of claim that falls apart in the first serious review.
How do you test BLE and companion app pairing?
By treating pairing as an authentication protocol and asking the questions you would ask of any authentication protocol.
- Can the pairing exchange be observed and replayed?
- Is the device discoverable and connectable by anyone in range after it has already been provisioned to an owner?
- Does the device accept a pairing request from a second phone without the owner approving it?
- Are the characteristics exposed over the connection readable or writable without authentication, including any that change device state?
- Does the companion app enforce a check that the device itself does not?
That last one is the most common serious finding we see in this layer, and it is the reason testing the app alone is not enough. If the app decides whether an action is permitted and the device just does what it is told, then the check disappears the moment someone talks to the device directly rather than through the app. Nothing in an app review surfaces that. It takes a device, a radio and someone willing to skip the app entirely.
What does an enterprise security questionnaire ask an IoT vendor?
The questions cluster into five areas, and only one of them is answered by a pentest report:
- Do you hold SOC 2 Type 2 or ISO 27001, and if not, when will you?
- Has an independent third party tested the product in the last 12 months, and what was in scope?
- How do device identity and per-device authorization work? This is really a question about whether one customer’s device can reach another customer’s data.
- How are firmware updates signed and delivered?
- What happens to device data: where is it stored, for how long, and who can reach it?
A pentest report answers question two directly and provides evidence for question three. The rest are documentation and architecture answers. Buying a pentest and hoping it closes the questionnaire is a common and expensive mistake, and our security questionnaire guide covers the rest of the surface.
Which ISO 27001 controls does an IoT pentest report evidence?
Two, and precision matters here because control mapping is where vendors pad a proposal.
- A.8.8, management of technical vulnerabilities. Evidenced by the findings register with severities and the dated remediation trail.
- A.8.29, security testing in development and acceptance. Evidenced by the test event itself.
It does not evidence A.8.25, secure development life cycle. That is evidenced by process, not by a test result. If a vendor’s control mapping claims it for a pentest deliverable, they are padding.
Against SOC 2 the report supports CC7.1 (Vulnerability Detection), and as an independent third-party evaluation it supports CC4.1 (Ongoing and/or Separate Evaluations). Where authentication and per-device authorization were in scope, findings there also touch CC6.1 (Logical Access). If ISO controls are new to you, ISO 27001 controls explained is the plain-language version.
Do you need a physical device to run an IoT pentest?
It depends which layers are in scope:
- Cloud backend and API: a test tenant and credentials. No device needed.
- Companion app: an installable build. Works better with a device or simulator so real flows can be exercised.
- Firmware: the firmware binary, which you supply. We do not need to extract it from hardware.
- Communication and BLE: a physical device, because there is nothing to intercept otherwise.
So a cloud-plus-app engagement runs entirely remote, and a communication-layer engagement needs a unit shipped to us or a scheduled window with one on your side. Settle this at scoping. A device arriving on day three of a five-day engagement costs you testing days that you have already paid for.
How long does an IoT penetration test take?
5 business days per scope, and for an IoT product a scope is a layer.
- One layer (for example, the cloud backend and its device APIs): 5 business days, Startup Pentest INR 74,999.
- Two layers (for example, cloud backend plus companion app): 10 business days, Growth Pentest INR 1,79,999.
- Three layers: 15 business days. Four layers: 20 business days.
Scopes run sequentially by default. Parallel testing is available on request and is never guaranteed, because it depends on who is free that week.
Add lead time before the start for the logistics that are specific to connected products: a firmware binary, a test device or simulator, a test tenant in your cloud environment, and an installable build of the companion app. These take longer to assemble than founders expect, and they are the usual reason an IoT engagement starts late.
What does an IoT pentest report contain?
- Executive summary framing the risk in product terms rather than protocol terms
- Technical findings with reproduction steps and CVSS v3.1 severity ratings
- Firmware static analysis results, where firmware was in scope
- Communication and protocol security assessment, where that layer was in scope
- Companion app findings, where the app was in scope
- Cloud backend findings, where the backend was in scope
- Remediation guidance written for the team implementing it
- Control mapping to ISO 27001:2022 A.8.8 and A.8.29 and to the SOC 2 criteria the findings touch
- One free retest within one month of the v1.0 report, delivered as a v2.0 report that supersedes v1.0 with per-finding retest status and fresh evidence of the fixed state
If you want to see the shape of the deliverable before committing to any vendor, our sample report is ungated, and what a good pentest report looks like explains what to check in someone else’s.
Working with us
Rathnakara (OSCP, M.Sc Cyber Security) leads the testing. Both founders are on every engagement. The methodology baseline for connected products is PTES, with the OWASP IoT Top 10 and ETSI EN 303 645 used as testing references.
We are not CERT-In empanelled, and we are not ourselves ISO 27001 or SOC 2 certified. We deliver the testing evidence and the control mapping; a separate accredited certification body or licensed CPA firm issues the certificate or attestation.
If your product spans several layers and you are not sure which to test first, the answer usually comes out of a 20-minute conversation about where the sensitive data sits and what your enterprise buyer actually asked for.
IoT pentest service | View pricing | See a sample report | How to scope your first pentest | Book a 30-minute scoping call