Connected devices have quietly become critical infrastructure. Consumer gadgets, industrial controllers, medical equipment, smart buildings, vehicles, and sensors all communicate with each other and with the cloud, often on fragile, legacy, or hastily assembled software stacks. When one of these systems breaks, it is no longer just a bug. It can mean production downtime, a safety hazard, or large-scale exposure of data.
For any organisation running a fleet of connected devices, penetration testing is often the most realistic way to understand how those systems actually behave under attack. The point is not to surface one or two impressive demo bugs, but to map how an attacker could move across hardware, firmware, protocols, and cloud platforms as a single connected chain. Securing IoT properly takes more than a basic application pentest, and this is a look at what that involves, how a serious engagement is run, and how it now ties directly to a fast-tightening set of regulations.
Why IoT Testing Is Not Just Another App Test
A traditional application pentest assumes a fairly predictable set of layers: a web or mobile frontend, an API, a database, and some integrations. IoT adds an entire stack beneath and around that, and each part is a potential way in:
Custom hardware and debug interfaces, firmware and bootloaders, wireless and local protocols such as Wi-Fi, Bluetooth Low Energy, Zigbee, LoRa, and proprietary radio, cloud backends and device management platforms, and the companion web and mobile apps that control everything.
Every one of those layers brings its own constraints. Devices are often resource-constrained, expected to run for five to fifteen years in the field, and updated rarely if at all. That combination is why insecure defaults, outdated libraries, weak or missing cryptography, and temporary debugging features that were never removed so often survive into shipped products and stay there for years.
The consequences compound because these devices are networked. Once a single unit is compromised, an attacker can use it as a foothold to pivot into corporate networks, impersonate trusted endpoints, manipulate sensor readings, or press the device into a botnet. A meaningful IoT test therefore has to treat the whole ecosystem as one target rather than a collection of isolated parts.
What IoT Penetration Testing Covers
Good IoT testing aims at the realistic attack surface across every layer, not just a network scan for known CVEs.
Hardware and Physical Interfaces
Testers begin with the board itself: its layout, exposed connectors, and accessible ports. Debug and programming interfaces such as JTAG, UART, and SWD, along with unlabelled test pads, can open the door to bypassing secure boot, extracting or altering firmware directly, and reaching cryptographic keys, secrets, or sensitive data stored on the device. Physical access is treated as out of scope in many corporate IT tests, but in IoT it is an everyday assumption, because these devices live in public spaces, on industrial floors, inside vehicles, and on customer premises where anyone might get their hands on one.
Firmware and the Boot Chain
Firmware images are examined both statically and while running. Common problems include hardcoded credentials and backdoor accounts, obsolete or home-grown cryptography, update mechanisms with no signature checking or rollback protection, and leftover debugging endpoints or test logic. This layer is also where supply-chain weaknesses appear, in the form of vulnerable third-party components and SDKs that have been reused across an entire product line, so a single flaw can affect many devices at once.
Wireless and Network Communication
Testers study how devices talk to local gateways, to each other, and to cloud services over Wi-Fi, Bluetooth, Zigbee, low-power wide-area networks, cellular, or proprietary radio. They look for weak or absent encryption, predictable keys, traffic that can be captured and replayed, and protocol misuse that allows spoofing, jamming, or man-in-the-middle attacks.
Cloud Backends, APIs, and Device Management
Many of the most serious issues live not on the device but in the orchestration layer behind it. Testers probe for authorisation flaws in device management APIs, broken separation between different customers or fleets, insecure handling of over-the-air updates, and weak boundaries between staging and production environments. A flaw here can expose thousands of devices at once.
Companion Apps and Admin Consoles
Web dashboards and mobile apps are tested as part of the same chain, because they are part of it. A cross-site scripting or access-control flaw in a portal that manages thousands of devices is, in effect, an IoT vulnerability, even though the bug lives in a browser.
How a Serious Engagement Is Structured
Methods vary between providers, but experienced teams tend to follow a predictable arc.
Scoping and threat modelling comes first. The team maps the business context and the realistic threats: what the device does, where it is deployed, which safety constraints apply, and which assets matter most, whether that is availability, safety, data confidentiality, brand, or regulatory compliance. This is also where the layers in scope are agreed, from hardware only to the full stack.
Lab setup and asset mapping follows. Testers build a controlled environment with test benches, debug adapters, radio tools, cloned or sandboxed backends, and representative device samples, so they can reproduce real conditions while keeping everything safe and observable.
Reconnaissance and attack surface mapping enumerates services, open ports, wireless interfaces, exposed debug points, firmware components, and cloud endpoints, building a picture of where exploitation is both technically feasible and actually meaningful to the business.
Exploitation and cross-layer pivoting is where the value shows. The focus is on demonstrating credible end-to-end paths: from extracting a firmware image to recovering keys, from weak radio cryptography to impersonating a device, from a web portal flaw to remote control of an entire fleet.
Reporting, remediation, and retesting closes the loop. Findings are prioritised by risk, ease of exploitation, and impact, and a good report includes concrete proof-of-concept demonstrations, supporting traces, and remediation guidance aimed separately at the embedded, backend, and app teams who have to fix things. A later retest confirms that the fixes work and did not introduce new problems.
The Regulatory Picture Has Changed
For a long time IoT security was largely voluntary. That is no longer true, and the shift is one of the strongest reasons testing has moved from optional to expected.
The most significant development is the EU Cyber Resilience Act, Regulation (EU) 2024/2847, which sets binding cybersecurity requirements for almost any product with digital elements sold in the EU, including connected hardware, firmware, and apps. It entered into force in December 2024. Its mandatory vulnerability and incident reporting obligations took effect on 11 September 2026, requiring manufacturers to report actively exploited vulnerabilities within tight deadlines, and its full requirements, covering secure-by-design engineering, conformity assessment, CE marking, a software bill of materials, and security updates across a product’s expected lifetime, apply from 11 December 2027. The reach is broad: manufacturers outside the EU are in scope if their products reach the EU market, and penalties run to 15 million euros or 2.5 percent of global annual turnover.
The CRA does not stand alone. In the United Kingdom, the Product Security and Telecommunications Infrastructure (PSTI) regime sets baseline security requirements for consumer connected products. In the United States, the Cyber Trust Mark provides a voluntary security label for consumer IoT. Alongside these laws sit widely referenced technical standards: ETSI EN 303 645 for consumer IoT, and IEC 62443 for industrial automation and control systems, along with sector-specific guidance for healthcare, automotive, and industrial environments.
For device makers, the practical effect is that penetration testing now feeds directly into compliance. Demonstrating secure-by-design engineering, running a real vulnerability management process, and being able to show evidence of testing are increasingly things a manufacturer has to do rather than choose to do.
What to Look for in a Provider
Choosing a testing partner is less about brand recognition and more about whether their skills match the product’s actual attack surface. The strongest teams can demonstrate several things.
Cross-domain expertise is the first, meaning genuine capability across embedded engineering, radio security, and cloud and app testing rather than just one of them. Hands-on hardware capability matters too, backed by appropriate labs and tooling and by real examples of hardware-level findings, not just theory. Familiarity with the relevant standards and regulations, such as ETSI EN 303 645, IEC 62443, the CRA, and any sector-specific rules, shows a provider understands the environment the product ships into. Risk-based reporting is essential, mapping each technical issue clearly to a real abuse case, whether that is a botnet, sabotage, a privacy violation, or a safety incident. Finally, support for integrating security into the development lifecycle, through threat modelling, design reviews, and developer guidance, matters far more than a single test bolted on at the end. The best engagements feel like working with an extended security team rather than ticking a box.
When to Test in the Product Lifecycle
Timing matters as much as quality. Leaving IoT security until late in production almost guarantees either expensive redesigns or long-lived risk that ships with the product.
Security-mature teams schedule focused testing at several points: at the early design or functional prototype stage, to validate the architecture and its assumptions before they harden into the product; at pre-certification or pre-launch milestones, particularly in regulated or safety-critical sectors; around major firmware or feature releases that add new connectivity, protocols, or cloud dependencies; and after significant external events, such as a serious vulnerability in a shared component or a public incident involving similar devices. Treating testing as a recurring activity, aligned to real engineering milestones, keeps the risk profile understandable as the product evolves rather than letting it drift.
Conclusion
IoT devices sit at the meeting point of the physical and digital worlds, usually with long lifecycles and constrained paths for updates. A single weak point can become a route into corporate networks, a safety problem, or a reputational incident that is hard to undo. A capable testing programme, run by specialists who genuinely understand hardware, firmware, protocols, and cloud, turns that uncertainty into a mapped and prioritised set of risks, and gives engineering teams concrete ways to improve with each iteration. With regulation now making security a verifiable product requirement rather than a nice-to-have, the organisations that treat IoT testing as a standard, repeatable control, rather than an occasional exception, are the ones best placed for what is coming.
