IoT Penetration Testing Before Release

Penetration testing is often treated as a compliance checkbox. Teams schedule it right before launch, expecting a quick pass result and a clear path to release. Yet, a rigorous pentest produces engineering findings, not a pass/fail result. Fixes may require firmware changes, configuration updates, or even a hardware re-spin. For IoT products, remediation can be even broader, spanning the entire device stack and requiring multiple engineering teams.

IoT penetration testing simulates real attacks across every layer of a connected product: hardware, firmware, wireless protocols, the companion app, and the cloud APIs that tie them together. 

The later security testing happens, the higher the cost of failure, as new device risks emerge and response windows shrink. This is visible in both threat intelligence and regulation: three in four of the riskiest device types identified in 2026 were not on the list two years earlier. At the same time, the EU's Cyber Resilience Act now requires a 24-hour early warning for actively exploited vulnerabilities. Finding issues before release gives IoT teams more time to remediate, retest, and decide on a controlled release.

This guide helps you plan IoT pentesting from scheduling to fixes and retesting to ensure the device’s attack surface is minimized before release. Along the way, you will learn what gets tested, how to scope the test, and what a usable report contains.

What Is IoT penetration testing?

IoT penetration testing (also called IoT pentesting) simulates real attacks against a connected device to find weaknesses before an attacker does. It matters for IoT devices because attackers can reach them from several directions at once: hardware, firmware, wireless protocols, companion app, and cloud backend—each introducing its own attack surface.

Unlike a web application, a connected product has layers a web-app test never reaches; web-app testing checks server logic and APIs but never touches the device’s flash chip, debug header, or Bluetooth stack.  IoT device penetration testing, in turn, treats the product as one system because vulnerabilities can cross layers managed by different teams. For instance, a UART header may be a hardware issue, a hardcoded cloud token a firmware issue, and an over-privileged API key a backend issue. Each layer may pass review while the product remains vulnerable end to end.

This system-level approach also changes what gets tested. Most scope against the OWASP IoT Security Testing Guide, which breaks a device into components: processor and memory, firmware and its update mechanism, internal interfaces such as UART, physical ports, wireless interfaces, and the user interface. Typical IoT penetration testing includes:

• Device hardware and debug interfaces (hardware penetration testing)
• Firmware and its over-the-air update path (firmware penetration testing)
• Wireless protocols such as Wi-Fi, BLE, Zigbee, LoRaWAN, and cellular
• The companion mobile or web app
• Cloud APIs and backend services

Security works best when teams address it throughout IoT product development, not only during the final pentest. Lemberg Solutions experts support teams across the IoT development process, from product engineering to connected software.

When should you run an IoT pentest in the product lifecycle? What is the role of embedded penetration testing?

Initial IoT device pentesting is most effective once hardware and firmware are feature-complete, but before manufacturing tooling and certification are finalized. Retests after fixes and again before any major firmware or hardware revision ships would further help catch issues before they reach production. Yet, remember, a pre-release pentest should not be the first security check. By then, automated analysis in the CI/CD pipeline should already have removed the basic vulnerabilities. In practice, treat IoT security testing as a release gate with a defined date, rather than leaving it to the last week before launch.

The pentest works best as the last of many checks, not the only one. Long before a board exists, the CI/CD pipeline can run SAST on the source code, SCA on third-party libraries, and DAST on whatever already runs. This embedded penetration testing catches hardcoded credentials and outdated libraries before a tester opens the enclosure.

Testing too early can produce findings tied to a bare development board, such as wiring and bootloader issues, that may not exist in the final production enclosure. Testing too late, by contrast, may require costly hardware rework once manufacturing tooling and regulatory certification are locked in.

Consider an IoT device moving from a working prototype toward production. By the time the hardware reaches a stable EVT/DVT stage, the enclosure, interfaces, wireless components, and other security-relevant elements should represent the product that will ship. The firmware should also have its core features in place. This is the point when a full pentest can uncover issues that matter to the final product while you still have time to fix them. Findings involving wireless communication, device authentication, or an exposed debug interface can often be addressed through a hardware or firmware change without disrupting the production schedule.

A major firmware update, a new wireless module, or a new hardware revision should trigger another security assessment. Compliance changes, such as the CRA reporting requirements, can also affect the timing. That makes finding and addressing vulnerabilities in time even more valuable.

Preparing a connected product for release? Lemberg’s embedded software and hardware testing covers firmware, protocols, and the board itself, including security checks on secure boot, firmware updates, and the attack surface, so an independent pentest starts from a cleaner build. 

How do you scope an IoT penetration test?

Defining the scope of IoT pentest means agreeing which layers get tested, how many device units and firmware builds the tester receives, and whether the engagement is black-box, grey-box, or white-box. Three decisions have the greatest impact on the scope, depth, and timeline.

• First, consider the device access. The depth of hardware analysis largely depends on the physical units, development boards, and debug interfaces (such as JTAG and UART) available during the engagement. The more physical access points available, the deeper the testing can go. Multiple units let the testing team investigate more thoroughly without risking the entire test setup.
• The second decision is how much information to provide. Black-box testing assesses the device from an external attacker's perspective, with no prior knowledge of the system. Grey-box testing provides the testing team with limited internal information, such as selected documentation, credentials, or source code. White-box testing gives the team extensive access to the underlying architecture, source code, and technical documentation. The right approach depends on the testing objective: the former best reflects an external attack, while the latter two provide deeper visibility when the goal is to identify vulnerabilities more thoroughly.
• The third decision is time, and this decision follows from the first two. From our experience,  a typical consumer IoT device covering hardware, firmware, and a companion app takes 2 to 4 weeks for a standard penetration test. More complex products with multiple devices, wireless interfaces, or deeper hardware and firmware access require a longer testing window — up to 10 weeks. The final timeline depends on the scope, level of access, and number of components included in the assessment.

What should be in an IoT penetration testing report?

A useful penetration testing report should work for both product managers and engineers and include an executive summary, technical findings, traceability, and status tracking. The executive summary gives product managers a clear view of the main risks and what needs attention, while the technical findings give engineers enough detail to reproduce and fix each issue. Findings should also be linked to the specific firmware build and hardware revision where they were identified.

The executive summary breaks down findings by severity, explains the business impact in plain language, and clearly shows release readiness. A product manager can use it as a roadmap without going through the detailed firmware analysis.

The technical section is for the engineers responsible for fixing the issues. Each finding should show how to reproduce it, identify the affected layer (hardware, firmware, radio, app, or cloud), and include proof-of-concept evidence and clear remediation guidance. Where possible, the report should point to a concrete fix, such as a patch, configuration change, or compensating control.

What connects the two parts is traceability. Each finding should include the firmware build number or hash and hardware revision, so the fix can be tied to the exact version where the issue was found and verified during retesting.

The last component is status tracking, which keeps the report in use after it is delivered. This lets you track findings as verified-fixed, risk-accepted, or partially remediated, keeping the report useful throughout the remediation process.

What happens after the pentest report?

After the pentest report, the team triages the findings to determine what must be fixed before release, what can be accepted as a known risk, and what can be mitigated through a later firmware or over-the-air update. Engineers address the agreed findings, and the testing team retests the affected components to verify that the vulnerabilities are actually closed. 

Severity, exploitability, and the cost of IoT vulnerability assessment after launch determine what to address before release. Firmware-level vulnerability remediation is often relatively quick, while hardware findings, such as an exposed debug port or missing secure boot, can require a board re-spin and potentially delay the release. 

Once the quick, critical fixes are in, testers retest them. The testers run the same attack again and check that it now fails. The testing should also cover reasonable variations of the original attack, since a fix that blocks one payload may not prevent a slightly modified version of the same attack.

The release decision comes after the retest. The security lead and product owner typically make the decision together, taking into account any unresolved findings and their associated risks. If a finding remains open, document risk acceptance that identifies the finding, responsible owner, business justification, and date for reviewing the decision.

In-house review or third-party IoT pentest: which do you need?

Whether you need an in-house security review or a third-party IoT pentest depends on the product stage and the level of assurance required. An in-house security review catches obvious misconfigurations early and cheaply, but only an independent third-party pentest produces the report that enterprise customers, auditors, and regulators accept. Most teams need both, at different points: continuous in-house checks during development and a third-party pentest as the pre-release gate.

When the testing approach depends on broader product architecture, engineering constraints, or development stage, tech consulting can help define the right path before committing to a specific assessment.

Conclusion

A pentest should not be the final check before an IoT product ships. Instead, it should give the engineering team enough time to understand the findings, make the necessary hardware or firmware changes, and verify the fixes before release. That means scheduling the test against the release plan, when the product is stable enough to represent the final design, and leaving room for remediation and retesting.