IoT security assessment: what scanners miss in connected device environments
Amara OkaforApril 29, 2026
Key takeaways
Standard network vulnerability scanners miss the three most commonly exploited IoT attack surfaces: firmware credential storage, hardware debug interfaces, and unsigned update channels.
In Vulnox IoT assessments, hardcoded credentials surviving production deployment appear consistently across device categories including industrial sensors, smart building controllers, and medical peripherals — not as misconfigurations but as intentional manufacturer shortcuts never patched out.
A device that passes a compliance audit can simultaneously have an unauthenticated UART shell accessible to anyone with physical access and a thirty-dollar USB adapter.
OWASP IoT Top 10 structured assessment finds an average of 2.3x more exploitable findings than scan-first approaches on the same device, based on Vulnox assessment data, 2023-2024.
Firmware update mechanisms are the highest-leverage attack surface in most IoT environments: one unsigned update endpoint can compromise an entire device fleet simultaneously.
IoT security assessment scope must cover four distinct layers — hardware, firmware, communication protocols, and companion ecosystem — or the engagement has a false ceiling on its findings.
TL;DR
Most IoT security assessments are network vulnerability scans applied to a device category that was never designed to be tested that way. The real findings live in firmware binaries, on exposed debug headers, and in update mechanisms that accept whatever they are sent. This article covers what those assessments actually look like when done properly, what clients consistently get wrong going in, and why the compliance-to-security gap is wider in IoT than almost anywhere else.
The device that passed everything and was still owned
A manufacturer of industrial environmental sensors engaged for a pre-deployment security review. Internally, they had run a commercial network scanner against the device, reviewed the OWASP IoT Top 10 checklist documentation, and confirmed that all firmware was sourced from a reputable vendor. Their security lead described the engagement goal plainly: we just need a sign-off, we already know this is clean. The scanner had found two low-severity findings. Both were documented and accepted as residual risk.
Manual firmware extraction took eleven minutes. The filesystem contained a hardcoded SSH private key shared across every device in the product line, a root account with a blank password protected only by a PAM rule that had been commented out during a debug build and never restored, and a firmware update endpoint on port 8888 that accepted arbitrary binary uploads over HTTP with no signature validation. None of this appeared in the network scan. The device had been in production for fourteen months. Fleet size at time of assessment: approximately 3,400 units across twelve client sites.
Why network scanners produce false ceilings on IoT devices
Network vulnerability scanners were built for servers and workstations. They enumerate open ports, fingerprint services, and match banners against CVE databases. That workflow finds what it was designed to find. The problem is that the most dangerous IoT vulnerabilities do not live at the network layer. They live in the firmware binary, on physical hardware interfaces, and in the logic of custom communication protocols that have no CVE entries because no one has formally analyzed them. A scanner pointed at an IoT device produces a network-layer view of a device whose attack surface is mostly not at the network layer. Finding count looks low. Risk is not.
Example
UART and JTAG debug interfaces are the clearest example. These are physical headers on the PCB, present on the majority of production IoT hardware because removing them adds engineering cost manufacturers rarely justify. UART gives a serial console. JTAG gives full memory access and the ability to halt, inspect, and modify execution. Neither shows up in a network scan. Neither appears in a port enumeration. They require physical access and a USB-to-UART adapter — hardware costing under thirty dollars — to surface. In assessments where Vulnox specifically tests for exposed debug interfaces, active unauthenticated console access appears on roughly six out of ten devices examined.
Firmware extraction methods vary by device architecture. Direct flash chip access via SPI or I2C is most reliable when the chip is socketed or accessible. JTAG extraction works where the interface is present and not fused. UART boot interruption — holding a specific key during power-on to drop into a bootloader shell — works on a meaningful fraction of consumer and prosumer devices. Once the binary is extracted, binwalk handles most filesystem unpacking. What appears inside — credential files, private keys, hardcoded API tokens, PAM configurations, update scripts — is where the actual assessment work begins.
What the assessments actually show
Assessment base: Vulnox IoT and embedded device security assessments, 2023-2024
Hardcoded credentials surviving production deployment
Across IoT-focused engagements at Vulnox, hardcoded credentials — root passwords, SSH keys, API tokens — appear consistently across device categories including industrial sensors, smart building controllers, medical peripherals, and consumer networking equipment. These are not misconfigurations introduced during deployment. They are present in the shipped firmware, often documented in internal developer wikis as temporary, and present across the entire product line because firmware builds are not differentiated per device. The credential is identical on every unit running that firmware version.
Clients consistently assume that because credentials are not documented in their asset inventory, they do not exist. The actual root cause: the device was procured from a vendor and the buyer never had access to the firmware source. Embedded credentials are not discoverable through procurement documentation. They require firmware extraction and analysis to surface.
Unsigned firmware update channels
Update mechanisms in IoT devices follow a pattern that appears repeatedly: the update client fetches a binary from a URL, performs a checksum comparison using MD5 or SHA-1, and applies the update if the checksum matches. The checksum is either embedded in the update package itself or transmitted alongside it over an unencrypted channel. An attacker who can intercept or redirect the update request — through DNS spoofing, a compromised network segment, or a supply chain position — can supply their own binary with a matching checksum. Signature validation using a device-resident public key, which would prevent this, is absent in the majority of devices assessed by Vulnox.
This is not a per-device risk. It is a fleet-level risk. One successful update server compromise or DNS intercept produces persistent access across every device that checks in. Clients who model the threat as individual device compromise consistently underestimate it. The actual threat model is one exploit, entire fleet.
Authentication bypass in companion mobile and cloud APIs
IoT devices pair with mobile applications, report to cloud dashboards, and expose management APIs. In assessments where scope includes the companion ecosystem, authentication logic in mobile apps and cloud APIs produces the highest concentration of high-severity findings. Insecure direct object references — querying a device ID belonging to another user because the API does not validate ownership — appear across device management platforms in both consumer and enterprise IoT. In one building access control platform engagement, unauthenticated enumeration of door controller IDs was possible via the management API with no rate limiting and no ownership validation on responses.
The device firmware can be fully hardened and the system can still be compromised through the API layer. Scoping an IoT security assessment to the device alone is a common and significant error. The assessment must cover the full data path: device, local protocol, cloud ingestion, API, mobile client.
The device with the most CVEs is not the highest risk
Common belief
Security teams sorting IoT devices by CVE count or CVSS score assume they are prioritizing correctly. The device with seventeen known vulnerabilities gets remediation attention. The device with zero CVEs gets cleared.
What we found
In engagements where clients provided a risk-ranked device list before assessment, devices ranked highest risk by internal teams — based on CVE count and scanner output — produced critical findings in roughly half of cases. Devices ranked low risk or cleared produced critical findings at nearly the same rate. The ranking correlated with scanner visibility, not actual exploitability.
CVE coverage for IoT firmware is sparse. The NVD indexes vulnerabilities that have been discovered, reported, and assigned. Most IoT firmware contains proprietary code that has never been formally analyzed — no CVE history not because it is secure but because no one has looked. The device with zero CVEs and unextracted firmware may be running a hardcoded root credential and an unsigned update channel that has never been tested. The device with seventeen CVEs has, at minimum, been examined by someone. Its risk surface is more legible, not necessarily larger.
What gets missed in scoped assessments
Bluetooth Low Energy and Zigbee protocol security
Wi-Fi and wired Ethernet get tested. BLE and Zigbee, which handle communication for a large fraction of sensor and actuator devices, almost never do. BLE pairing vulnerabilities — particularly devices using Just Works pairing with no authentication — allow passive eavesdropping and active man-in-the-middle injection without breaking any cryptography. Zigbee networks using the default trust center link key, a known constant across many implementations, allow any device to join and monitor traffic. These protocols require different tooling and different expertise. Most assessments that claim to cover IoT never touch them.
Boot chain validation
Secure boot, implemented correctly, ensures each stage of the boot process validates the cryptographic signature of the next before executing it. When implemented incorrectly — which is common — it creates the appearance of a security control without the function. A device may advertise secure boot while accepting a modified bootloader if the signature check uses a publicly known test key, or while having a JTAG interface that bypasses the check entirely by allowing direct memory writes. Validating that secure boot actually works requires hardware access and testing, not documentation review.
Third-party component vulnerability exposure
IoT firmware is assembled from components: open-source libraries, vendor SDKs, RTOS kernels. These carry their own vulnerability histories. Without a software bill of materials and active CVE matching against it, a device can ship with a known-vulnerable version of OpenSSL, BusyBox, or a chipset firmware component. The manufacturer may not know. The buyer definitely does not know. SBOM generation from extracted firmware is technically feasible and almost never included in standard IoT security assessment scopes.
What clients say before the assessment, and what is actually happening
We reviewed the OWASP IoT Top 10 and our devices address all of it.
Root cause:The OWASP IoT Top 10 is a classification framework, not a test. Reviewing it and confirming that policies exist for each category is not the same as testing whether the controls function. A client can document a policy for secure firmware updates and simultaneously run an unsigned update channel because the policy was written against a prior device generation and never validated against the current one. The gap between documented compliance and tested reality is where almost every critical IoT finding lives.
The vendor confirmed the firmware is secure.
Root cause:Vendor security attestations for IoT firmware are typically self-assessments. They describe the security of the design, not the security of the build. A vendor can truthfully state their secure boot implementation uses RSA-2048 while shipping a device where the key validation logic has an edge case that allows bypass under a specific boot sequence. Without independent testing of the binary that shipped, the attestation covers the intent, not the implementation.
We have network segmentation, so a compromised device can only reach other IoT devices.
Root cause:Segmentation reduces lateral movement after compromise. It does not reduce the value of a compromised device to an attacker. A segmented industrial sensor reporting to a cloud platform can inject false telemetry, trigger automated responses in connected systems, or serve as a pivot if any path exists to the management network — including through the cloud platform itself. Segmentation is necessary. It is not a substitute for device-level security.
Where IoT security is heading in the next three years
Firmware SBOM requirements will become a procurement standard in regulated industries before they become a regulatory mandate, and organizations without SBOM generation capability will face procurement disqualification from enterprise buyers in healthcare and critical infrastructure by 2027.
The US Executive Order on Improving the Nation's Cybersecurity established SBOM as a software supply chain requirement for federal procurement. Healthcare and critical infrastructure sectors supplying federal agencies are already being asked for SBOMs on software components. The pressure will extend to firmware as IoT devices become more central to clinical and operational systems. Buyers will require it before regulators mandate it because the liability exposure from a supply chain compromise is too visible after recent incidents.
Confidence: highCheck major healthcare GPO and critical infrastructure procurement RFP templates in 2027. If fewer than 30% require firmware SBOM documentation, the prediction was wrong.A fleet-level IoT compromise affecting tens of thousands of deployed devices simultaneously through a poisoned update channel will occur in a non-consumer category and will not be detected for more than 60 days post-compromise.
The technical preconditions exist: unsigned update mechanisms are common, fleet-level update infrastructure is centralized and under-monitored, and IoT devices in operational environments are not covered by EDR or endpoint telemetry. The 60-day dwell time estimate follows the pattern from network-level breaches in similar environments where detection depends on someone noticing something unusual rather than automated alerting against behavioral baselines.
Confidence: mediumA publicly disclosed fleet-level IoT compromise with confirmed dwell time under 60 days would reduce confidence in this prediction. No such incident by end of 2027 would increase it.
The IoT assessment market is producing a false sense of coverage
Most organizations that have commissioned an IoT security assessment have not actually had one. They have had a network vulnerability scan with IoT written in the scope section. The deliverable looks like an assessment — it has findings, severities, and remediation recommendations. What it does not have is firmware extraction results, hardware interface testing outcomes, or protocol-layer analysis. The market has not failed to develop better methodology. The methodology exists. The market has failed to enforce scope requirements that would make clients pay for what actually protects them. A scan-only IoT assessment is approximately as useful as a building security review conducted entirely from the parking lot.
Counterargument
The reasonable counterargument is that comprehensive IoT assessments covering hardware, firmware, protocols, and ecosystem are expensive, require specialized tooling and expertise, and are not feasible for every device in a large deployment. Organizations must triage. A scan-first approach applied to many devices is more practical than a full assessment applied to one. This is correct as far as it goes. The problem is that scan-first is being sold and purchased as sufficient rather than as a triage step that identifies which devices warrant deeper work. When the scan result is clean, remediation stops. The devices most needing assessment — those with no CVE history and unextracted firmware — are precisely the ones most likely to be cleared and forgotten.
What to do before the next assessment gets scoped
Before you scope the next IoT security assessment, ask the vendor one specific question: does the scope include firmware extraction and static analysis, or is it network-based only? If the answer is network-based only, you are buying a scan. That is useful information, but it is not an IoT security assessment. The practical step this week: pull the firmware version from three devices in your environment — different categories if you have them — and run binwalk against the extracted binary. What you find in the filesystem will tell you more about your actual risk posture than any network scan report you have received. If you do not have the tooling or access to extract firmware in-house, that gap in your assessment capability is itself a finding worth documenting before the next engagement is scoped.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentGap Analysis
framework gap analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Web Security Testing Guide
OWASP IoT security frameworkNational Vulnerability Database NIST
NIST National Vulnerability Database
Frequently Asked Questions
What does an IoT security assessment find that automated scanners miss?
Automated scanners identify open ports and known CVEs but miss hardcoded credentials embedded in firmware, exposed UART and JTAG debug interfaces, unsigned firmware update channels, and authentication bypass flows in custom device APIs. These require manual firmware extraction, hardware inspection, and active protocol testing to surface.
How do you test IoT firmware for security vulnerabilities?
Firmware testing involves extracting the binary via JTAG, UART, or direct flash dump, then using tools like binwalk to unpack the filesystem, strings and Ghidra for static analysis, and QEMU for emulation where the architecture allows. The goal is identifying hardcoded credentials, insecure boot chains, and embedded private keys before the device hits a network.
What are the most exploited IoT vulnerabilities in real assessments?
Across Vulnox assessments, the three most consistently exploited classes are: hardcoded or default credentials that survived deployment, unencrypted MQTT or CoAP channels transmitting sensor data in plaintext, and firmware update mechanisms that accept unsigned binaries over HTTP. None of these are reliably detected by standard network vulnerability scanners.
Why do IoT devices fail security assessments even after passing compliance audits?
Compliance audits for IoT environments typically check network segmentation, patch cadence, and access control policy documentation. They rarely involve firmware extraction, hardware interface testing, or active protocol manipulation. A device can pass an audit with documented policies while running firmware containing hardcoded root credentials and an unauthenticated update endpoint.
What is the OWASP IoT Top 10 and how does it apply to security assessments?
The OWASP IoT Top 10 is a ranked list of the most common IoT vulnerability classes covering weak passwords, insecure network services, insecure ecosystem interfaces, lack of secure update mechanisms, and use of insecure or outdated components. Assessments structured around it produce more consistent findings than port-scan-first approaches because it forces testers to examine the device layer, not just the network layer.
How often should connected devices undergo security assessment?
Any firmware update is a reassessment trigger, not just a scheduled interval. A more defensible posture is continuous monitoring of firmware component SBOMs against CVE feeds, with manual assessment triggered by material changes or new exploitation activity against the device family. Annual intervals miss the window between update cycles when new vulnerabilities in shared components are published.
What does a realistic IoT penetration test scope cover?
A thorough scope covers four layers: the device hardware including debug interfaces and chip extraction, the device firmware including static analysis and boot chain validation, the communication protocols including MQTT, CoAP, BLE, and Zigbee, and the companion ecosystem including mobile app, cloud API, and update server. Testing only one layer produces a false ceiling on what is actually exploitable.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.