How to Conduct IoT Penetration Testing

An Internet of Things product is rarely just one device. It may include embedded firmware, wireless connections, a mobile application, cloud APIs, an administrative portal, third-party services, and an update system. As a result, testing only the device’s web interface can leave major security gaps undiscovered.

IoT penetration testing is an authorized security assessment that examines how an attacker could misuse weaknesses across the connected product’s entire ecosystem. Unlike a basic vulnerability scan, it does not stop after listing outdated software or exposed services. Instead, testers carefully validate whether separate weaknesses can create a realistic path to unauthorized access, data exposure, device manipulation, or disruption.

The process must always begin with written permission, a defined scope, and agreed safety limits. Connected devices may control locks, machinery, medical equipment, vehicles, or environmental systems. Therefore, careless testing can create physical consequences, interrupt operations, or damage hardware.

What Is IoT Penetration Testing?

IoT penetration testing is an authorized security review that evaluates a connected product and its surrounding infrastructure for weaknesses an attacker could realistically exploit.

A typical assessment may cover:

• device hardware and exposed physical interfaces;
• installed firmware and boot behavior;
• local storage and memory;
• Wi-Fi, Bluetooth, cellular, Zigbee, or other communications;
• cloud services and APIs;
• companion mobile or web applications;
• user authentication and authorization;
• software and firmware updates;
• data protection and privacy controls; and
• logging, monitoring, and recovery functions.

OWASP’s IoT Security Testing Guide organizes testing around areas such as processing units, memory, firmware, data-exchange services, internal interfaces, physical interfaces, wireless communication, and user interfaces. This broader model reflects the fact that a weakness in one component may affect the security of the entire product.

Why Is IoT Security Testing Different?

A standard web application usually operates inside environments controlled by the business. By contrast, an IoT device may sit in a customer’s home, a factory, a vehicle, or an unattended outdoor location. In many cases, an unauthorized person can physically reach it.

Furthermore, embedded products often have limited processing power, memory, battery capacity, and update options. Those constraints can influence encryption, monitoring, storage, and patching decisions. ETSI’s consumer IoT security standard specifically recognizes that connected products may face limitations involving energy, bandwidth, processing capacity, and memory.

Consequently, an effective assessment must evaluate more than network exposure. It should consider what happens if someone obtains the device, intercepts its traffic, modifies its firmware, steals a user token, compromises the cloud account, or abuses an associated application.

Secure Written Approval and Establish Clear Testing Boundaries

Before any testing begins, clearly define which devices, systems, interfaces, and actions fall within the approved scope.

The approved test boundaries should specify the exact hardware versions, firmware builds, companion apps, web domains, APIs, communication methods, cloud systems, test credentials, and physical connection points included in the assessment. It should also clarify whether testers may open the enclosure, alter firmware, interrupt connectivity, reset devices, or access production data.

In addition, establish:

• the approved testing period;
• prohibited actions;
• rate and load limits;
• emergency contacts;
• conditions requiring an immediate stop;
• data-handling requirements;
• backup and restoration procedures; and
• rules for retaining evidence.

A production-connected device should not be treated like an isolated lab unit. Whenever possible, use a representative test environment containing non-sensitive data. NIST recommends planning security examinations carefully, analyzing findings, and developing mitigation strategies rather than treating penetration testing as uncontrolled experimentation.

Map the Complete IoT Ecosystem

Next, build a clear system map that shows how the device, applications, services, and data flows work together in practice.

Create a full inventory of the product’s hardware, storage, connection points, sensors, wireless modules, firmware, companion apps, cloud services, APIs, authentication systems, databases, and external integrations. Then trace the information moving between them.

For each connection, ask:

• What data enters or leaves this component?
• How is the other party authenticated?
• Is the traffic encrypted and integrity-protected?
• Where are keys, tokens, and credentials stored?
• Which system makes authorization decisions?
• What happens when connectivity disappears?
• Can one compromised component reach another?

This stage often exposes assumptions before active testing begins. For example, a device may appear to communicate only with the vendor’s cloud, while packet observation reveals additional analytics, update, or notification services.

The architecture map also supports threat modeling. Instead of testing every component with equal intensity, the team can prioritize areas that control safety, sensitive data, user identity, firmware updates, or large device fleets.

Examine Hardware and Physical Interfaces

Physical inspection helps testers understand how the device was assembled and which maintenance or debugging paths remain accessible.

The assessment may review external ports, removable storage, circuit-board markings, test pads, debug headers, serial connections, and memory components. However, the purpose is not to damage the product. Rather, it is to determine whether physical access could expose confidential information, administrative functions, cryptographic material, or an unrestricted maintenance interface.

Important questions include:

• Are unnecessary interfaces still enabled?
• Does a local console require authentication?
• Can sensitive storage be removed and read?
• Are production devices shipped with debugging functions active?
• Does a factory reset remove user information securely?
• Can the device detect or limit unauthorized configuration changes?

NIST’s IoT baseline includes logical access restrictions for local and network interfaces, authorized configuration changes, data protection, secure software updates, and awareness of the device’s cybersecurity state. These security functions offer a practical benchmark for evaluating hardware and embedded components during testing.

Analyze Firmware and the Update Process

Firmware security testing should examine both the installed software and the route used to deliver future versions.

Testers first identify the operating system, libraries, services, configuration files, certificates, credentials, and protection mechanisms present in the firmware image. They also look for unnecessary services, insecure defaults, sensitive information stored in readable form, outdated components, weak permissions, and undocumented functionality.

However, the update mechanism deserves equal attention. A secure product should be able to confirm that an update came from an authorized source and that its contents were not altered. Furthermore, the system should prevent unauthorized users from initiating updates or installing unapproved images.

The assessment should ask whether:

• updates are cryptographically verified;
• transport security is enforced;
• version checks prevent unsafe downgrades;
• interrupted updates fail safely;
• recovery is possible after an unsuccessful installation;
• update availability is communicated clearly; and
• unsupported devices receive an appropriate end-of-support plan.

NIST identifies authenticated, authorized, and configurable software updates as a core IoT security capability. Its revised foundational guidance, published in April 2026, also emphasizes building cybersecurity considerations into product development and support rather than leaving customers to manage the risk alone.

Test Network and Wireless Communications

The next phase examines how the device communicates locally and remotely.

Testers observe normal traffic first so they can understand protocols, endpoints, pairing behavior, session establishment, and error responses. Afterward, they evaluate whether the device properly authenticates peers, protects transmitted information, rejects unauthorized commands, and handles malformed or unexpected input safely.

The review should cover all relevant channels, including Wi-Fi, Bluetooth, cellular links, short-range radio protocols, Ethernet, and local discovery services.

Key concerns include:

• unencrypted sensitive traffic;
• weak pairing or onboarding;
• reusable credentials;
• predictable device identifiers;
• unnecessary listening services;
• insecure certificate validation;
• missing message-integrity checks; and
• excessive trust between devices on the same network.

Testing should remain controlled. Flooding, aggressive fuzzing, or repeated connection attempts may freeze a constrained device or affect neighboring systems. Therefore, such activities require explicit approval and conservative limits.

Assess Cloud APIs, Apps, and Administrative Portals

Many serious IoT weaknesses exist outside the physical product.

A companion application may expose tokens, use weak local storage, or trust data that the device supplies. Likewise, a cloud API may verify that a user is signed in but fail to confirm that the user owns the requested device.

The assessment should test whether one account can view, control, rename, delete, or reassign another customer’s device. It should also review enrollment, password recovery, device sharing, account deletion, administrator roles, and session revocation.

Additional questions include:

• Can a device be registered to more than one owner improperly?
• Are object-level authorization checks performed for every request?
• Do mobile and web applications store credentials safely?
• Can former employees or household members retain access?
• Are administrative functions separated from ordinary user actions?
• Does deleting an account remove or de-identify associated data?

Organizations planning new connected products can use professional iot consulting and solutions to define these trust boundaries before implementation, when changing the architecture is generally less disruptive.

Review Authentication, Privacy, and Data Protection

Testing should identify every human, device, and service identity involved in the ecosystem.

Default or shared passwords deserve particular attention because one exposed credential may affect an entire product line. Additionally, testers should examine password policies, multifactor authentication, certificate management, API keys, device secrets, account lockout behavior, and credential rotation.

Privacy testing should trace personal information from collection through deletion. Connected devices may gather audio, video, location, behavioral, health, occupancy, or telemetry data. ETSI notes that consumer IoT devices and associated services commonly process personal data and endorses security by design as a central principle.

Therefore, the assessment should determine whether the product collects more information than necessary, exposes data to unauthorized parties, retains it indefinitely, or continues transmitting after a user disables the related feature.

Validate Findings Without Creating Unnecessary Harm

A penetration test should prove risk with the least invasive method available.

For example, showing that a standard user can retrieve a harmless record belonging to a test account may be sufficient to confirm an authorization flaw. There is usually no need to extract an entire database or alter a production device.

For every finding, record:

• the affected component and version;
• the required access and conditions;
• the validated security impact;
• supporting evidence;
• possible effects on users and operations;
• a practical remediation recommendation; and
• any uncertainty or testing limitation.

OWASP emphasizes transparent, reproducible testing so developers can understand the issue, recreate it, apply a fix, and confirm the correction during a retest.

Report, Remediate, and Retest

The final report should serve both executives and technical teams.

An executive summary should explain the highest business, privacy, and safety risks in plain language. Meanwhile, the technical section should provide enough detail for engineers to reproduce each issue safely.

Prioritization should consider more than a generic severity score. A weakness may become more urgent when it affects every device, requires no physical access, exposes sensitive data, threatens safety, or cannot be patched remotely.

Once fixes are applied, retesting should confirm that the original attack path is closed and that the correction has not created a different weakness. Moreover, findings should feed back into development standards, architecture reviews, automated checks, and future product requirements.

Common IoT Penetration Testing Mistakes

Common failures include testing only the network interface, ignoring the mobile app and cloud API, using production devices without recovery plans, and treating automated scanner output as confirmed risk.

Another mistake is overlooking the product lifecycle. A device may be secure at launch yet become vulnerable when certificates expire, cloud services change, libraries age, or security updates stop.

Therefore, IoT penetration testing should not be a one-time launch activity. Testing should be repeated after significant firmware changes, architectural updates, newly supported protocols, major cloud revisions, and serious security incidents.

Frequently Asked Questions

Final Thoughts

Effective IoT penetration testing examines the connected product as an ecosystem rather than a single piece of hardware. The device, firmware, communications, cloud platform, APIs, applications, update process, and operational environment all contribute to risk.

A disciplined assessment starts with authorization, maps the complete architecture, tests each trust boundary carefully, validates findings with minimal disruption, and ends with remediation and retesting. Most importantly, the results should improve future product decisions instead of remaining inside a one-time report.

Organizations preparing an authorized assessment can contact us to discuss product scope, testing boundaries, risk priorities, and an appropriate IoT security review.