IoT Penetration Testing: How to Assess Connected Device Security and Embedded Systems

IoT penetration testing is a controlled security assessment of connected devices and the systems they rely on, including firmware, communications, applications, and cloud services. It looks for ways an attacker could cross those boundaries, access data, or affect device behavior. If you are evaluating connected products alongside mobile, web, or other specialized systems, see Penti's broader guide to types of penetration testing.

Discuss an IoT security assessment

What is IoT penetration testing, and why is it different from web app testing?

An IoT product is rarely just a device. It is a collection of components that may include hardware, embedded software, wireless protocols. A mobile application, an API, a cloud control plane, and the organization's update or support process. A weakness at one point can change the risk elsewhere. For example, a device may use a secure web dashboard but still expose sensitive information through an unprotected local interface.

Web application testing usually centers on application behavior, identity, data handling, and server-side logic. IoT testing adds physical access, hardware interfaces, firmware, device-to-device communication, and the consequences of changing a device's state. The assessment must also account for devices deployed outside a controlled office, sometimes with limited opportunities for patching or direct monitoring.

The goal is not to prove that every imaginable attack is impossible. It is to test a defined system under agreed conditions, validate meaningful weaknesses, and give owners a practical path to reduce risk. A useful assessment defines:

• Assets: device models and revisions, firmware versions, companion apps, APIs, cloud components, and test accounts.
• Trust boundaries: where data or commands cross between device, user, network, vendor, and cloud.
• Safety limits: what systems may be tested, which actions are prohibited, and how to stop a test safely.
• Success criteria: what evidence is needed to confirm a finding and how results will be prioritized.

This systems view distinguishes IoT assessments from a test limited to a single web application. It also helps teams connect device findings with related API security testing rather than treating each component as an isolated product.

Which IoT attack vectors should an assessment examine?

Test cases depend on device design and authorized scope. Common areas include exposed interfaces, weak trust assumptions, and unsafe handling of updates or credentials. The following are categories to consider, not a claim that every device has each weakness.

• Firmware and secrets: Review whether firmware can be obtained or inspected, and whether it contains credentials, keys, debug information, or sensitive configuration that should not be exposed. Consider how secrets are stored and whether they can be reused across devices.
• Hardware interfaces: Identify accessible debug or maintenance ports and determine whether they permit unauthorized access to data, a shell, or device functions. Physical testing should be specifically authorized and performed on designated units.
• Protocol and network behavior: Observe how a device discovers peers, authenticates, encrypts traffic, and handles malformed or unexpected messages. Examine whether commands can be replayed or accepted from an untrusted source.
• Identity and provisioning: Test the enrollment process, default setup, recovery flow, and device identity checks. Determine whether one device can impersonate another or whether credentials are inadequately separated.
• Mobile apps and APIs: Assess account permissions, session handling, authorization checks, and the way the app or API maps a user to a particular device. A device-specific feature can become a wider exposure if access controls are inconsistent.
• Cloud and update mechanisms: Examine how devices receive configuration and software updates, how update authenticity is checked, and what happens when an update fails or is interrupted. Review cloud permissions and device-to-cloud trust as part of the overall system.
• Operational behavior: Check whether a security issue could affect availability, safety, privacy, or a dependent business process. The impact is not limited to data theft.

Firmware extraction, protocol manipulation, or state changes can disrupt a device or expose sensitive information. For that reason, a test plan should specify permitted devices, data handling, network boundaries, and prohibited actions before testing begins. Do not test a production device or third-party service without clear authorization.

What might an end-to-end test scenario examine?

Consider a hypothetical connected room sensor that reports readings to a gateway, a cloud service, and a mobile dashboard. A tester could first document how the device is enrolled and paired, then check whether a separate authorized test account can see only its own sensor. In a controlled setup, the assessment could observe whether device-to-gateway traffic is authenticated. Whether commands are accepted only from approved sources, and whether the cloud API enforces the same ownership boundaries as the app. Firmware and update handling would be assessed separately under the agreed rules. If an access-control gap is confirmed, the report should state which account and device conditions made it possible. What data or operation was exposed, and how to reproduce the issue safely. This scenario is illustrative; actual tests must be based on the product architecture and authorized scope.

How should teams plan and conduct an IoT penetration test?

A structured assessment moves from an inventory and threat model to controlled validation and remediation. OWASP's IoT Security Testing Guide presents concepts, models, and test steps for device penetration testing. Use an applicable testing guide alongside the product's design and safety constraints, not as a substitute for scoping.

Before active testing, gather the product architecture or an equivalent system diagram, the supported device and firmware versions, user roles, and known external integrations. Identify who owns each component: the product team may control firmware, while a cloud provider or supplier may manage another service. Confirm access permissions and test accounts with those owners. If a dependency is outside the authorized boundary, record it as an exclusion and decide whether a separate review is needed. This avoids accidentally probing a supplier's environment and helps the report distinguish a product weakness from a dependency or configuration issue. A concise scope matrix can list each asset, owner, test method, environment, and limitation, giving everyone a shared reference before work begins.

1. Agree on scope and rules. Record device types, hardware revisions, firmware versions, accounts, interfaces, cloud endpoints, and test environments. Identify excluded assets and any vendor-managed services. Set a testing window, escalation contact, data-handling rules, and stop conditions. For devices that can control physical processes, document the safe test setup before any active test.
2. Build an architecture and data-flow map. Trace how a device is provisioned, communicates, receives commands, stores data, and updates. Include mobile and web applications, APIs, identity systems, gateways, and cloud services. Mark trust boundaries and data that would be sensitive if disclosed or altered. This step often reveals assets missing from a simple device inventory.
3. Perform reconnaissance and configuration review. Identify exposed services and interfaces, observed protocols, firmware versions, and configuration choices. Compare expected behavior with what can be reached in the test environment. Keep observations tied to the exact device version; results from one model or revision should not automatically be generalized to an entire product family.
4. Test access controls and communications. Verify authentication and authorization across device, app, API, and cloud. Test whether data and commands are protected in transit and whether a device accepts requests from the expected parties only. Use controlled accounts and devices to check for cross-account or cross-device access.
5. Inspect firmware and update behavior. Where authorized, review firmware for exposed secrets or unsafe configuration. Examine whether updates are authenticated and whether the device handles invalid, interrupted, or outdated update scenarios safely. Avoid destructive experiments unless the rules of engagement expressly allow them and recovery has been planned.
6. Validate suspected weaknesses safely. Reproduce a suspected issue to establish its conditions and impact, using the least disruptive proof possible. Record what access was required, which version was tested, and what the tester observed. Do not collect more personal or production data than needed to demonstrate the issue.
7. Report, remediate, and retest. Give engineering owners clear reproduction steps and practical remediation options. After changes, retest the relevant condition and record whether the original risk is resolved, reduced, or still present.

Research and training resources can help teams understand test concepts. For example, a USENIX paper describes using commercial off-the-shelf IoT devices in a taught cybersecurity course. It is an educational example, not a substitute for a scoped professional assessment or a product-specific test plan. See Penetration Testing IoT Devices in the Classroom.

Teams that operate connected systems alongside cloud workloads can coordinate the work with their cloud-native security review. A wider attack surface management process can help keep device, API, and cloud assets in view as the environment changes.

What should an IoT penetration test report include?

A report should let security and engineering teams understand what was tested, why each issue matters, and what to do next. Avoid vague findings that say only "weak encryption" or "insecure device." Identify the relevant system component, conditions, evidence, and affected version.

• Scope and limitations: device models, firmware revisions, environments, interfaces assessed, exclusions, and dates.
• Executive summary: the main risk themes and decisions that require attention, in language appropriate for business owners.
• Finding details: title, affected component, severity rationale, prerequisites, steps to reproduce, and evidence that avoids unnecessary sensitive data.
• Attack path and impact: explain how a weakness could be used in context, including relevant consequences for confidentiality, integrity, availability, privacy, or physical operation.
• Remediation guidance: specific changes or design questions for the responsible team, plus any compensating controls when a direct fix is not immediately feasible.
• Retest record: changes reviewed, tests repeated, and the resulting status for each finding.

Use a consistent risk-rating method, but explain its assumptions. A technical severity score alone may not capture deployment scale, exposure, safety impact, or the feasibility of exploitation in the product's real environment. Clear evidence also helps teams distinguish a confirmed vulnerability from a theoretical concern.

For example, a report finding about device enrollment should make clear whether the issue affected only an isolated test account or could cross device ownership boundaries. A firmware finding should name the tested revision and describe what exposure was confirmed without including reusable secrets in a widely distributed report. A communication finding should identify the relevant interface and conditions, rather than making a broad statement about all traffic. Those details help product engineers reproduce the issue without ambiguity and help leaders assign it to the right owner. If the assessment did not test a particular device variant, protocol, or deployment mode, say so plainly. Explicit limitations prevent readers from treating a bounded test as a certification of the entire product ecosystem.

For organizations that need to prepare assessment materials for reviewers, Penti's guide to pentest reports and audit documentation covers how to organize test evidence. The report should describe what was actually assessed; it should not imply that a single test guarantees a product is secure.

Which regulatory requirements apply to IoT security testing?

There is no single testing frequency or universal IoT penetration-testing checklist that applies to every device and organization. Obligations depend on the sector, jurisdiction, product role, contractual commitments, and the systems or data involved. A requirement to manage security risk should not automatically be translated into a claim that a particular regulation mandates a specific IoT pentest.

Start by mapping the device and the data it handles to the standards, laws, customer requirements, and internal policies that apply to the organization. Ask legal, compliance, and security owners to confirm the interpretation. Then use testing as one possible way to evaluate relevant technical controls and document evidence where appropriate.

Where a program already uses a framework or formal assessment process, align the test scope and evidence to the responsible control owners' needs. Penti's overview of cybersecurity frameworks and its guide to continuous security assurance offer related background. Confirm compliance interpretations with qualified counsel or the appropriate assessor rather than relying on a blog article alone.

How can IoT testing fit into continuous security assurance?

Connected products change over time. Teams release firmware, add device models, alter cloud services, update mobile apps, and change network configurations. A test performed against one version is evidence about that version and scope; it does not automatically establish the security of later changes or every deployed device.

A practical program can combine scheduled assessments with change-triggered testing. Consider revisiting scope when:

• a new device model, hardware revision, or major firmware release is introduced;
• the provisioning, authentication, communications, or update mechanism changes;
• a new API, cloud service, mobile application, or external integration is added;
• a vulnerability or incident reveals a previously unexamined trust boundary; or
• deployment conditions or customer commitments materially change.

Not every software release requires the same depth of manual testing. Triage changes according to exposure and potential impact, and use appropriate review and testing to catch issues early. Then periodically revisit broader attack paths that span device, application, network, and cloud components. Penti's article on continuous security testing explains how teams can think about security validation between major assessments.

Talk with Penti about testing connected systems

Frequently Asked Questions

What does IoT penetration testing cover?

It can cover device hardware and interfaces, firmware, wireless or network protocols, provisioning, companion apps, APIs, cloud services, and update mechanisms. The exact scope depends on the product architecture, authorization, safety limits, and assessment goals.

Can an IoT penetration test be performed on a live device?

Testing live devices may create safety, availability, or data risks. Define authorized assets and stop conditions first. Use a controlled test unit or environment when possible, and do not test production devices or third-party services without explicit authorization.

How often should an organization test IoT devices?

There is no universal interval for every IoT product. Set a schedule based on risk and applicable obligations, and reassess after significant changes to firmware, hardware, communications, identity, or cloud services. Confirm any required cadence with the organization's compliance or legal owners.

Is a vulnerability scan the same as IoT penetration testing?

No. A scanner can help identify potential weaknesses. But a penetration test assesses selected attack paths in context and validates whether suspected issues are reachable and meaningful within the agreed scope. The methods can complement each other.

Start with a clear inventory, safe scope, and defined outcomes. Then use validated findings to guide fixes and decide what should be tested again as the connected system evolves.