When an IoT breach makes the news, the writeup usually implies something sophisticated happened - a novel exploit chain, a nation-state actor, a zero-day nobody saw coming. In practice, that's rarely the story. 2025 research from deepstrike.io found that 60% of IoT breaches trace back to unpatched firmware - vulnerabilities that were already known, already documented, and simply never fixed on the device sitting on the network.
That statistic matters more every year, because the number of devices it applies to keeps climbing. IoT Analytics puts the global connected device count at 21.1 billion in 2025, on track to pass 25 billion in 2026 and approach 40 billion by 2030. Attackers have noticed the surface area: threat telemetry recorded more than 820,000 malicious IoT hacking attempts per day in 2025, a 46% year-over-year increase, with a 16.7% rise specifically in automated scanning for open ports, default credentials, and unpatched firmware.
The root cause is rarely novel - it's unpatched and already known
None of this requires an attacker to be clever. It requires them to be patient enough to scan, and to find a device that was never going to be patched in the first place.
Why Firmware Is the Soft Underbelly
Every other layer of enterprise security has matured around a shared assumption: you can install an agent, push a patch, and monitor for anomalies in something close to real time. Firmware breaks that assumption in three specific ways.
It operates below the layer your tools watch. Antivirus and EDR are built to observe an operating system's processes, memory, and file system. Firmware runs beneath that - in bootloaders, in the code that brings up network interfaces before an OS even loads, in the embedded logic of the device itself. A compromise at this layer isn't invisible because it's advanced; it's invisible because nothing is watching that far down the stack.
Device lifecycles don't match patch lifecycles. A laptop gets replaced every 3-5 years, on a schedule that roughly tracks its vendor's support window. An IP camera, an industrial sensor, a building access controller, or a piece of medical equipment routinely stays in service for 10 to 25 years. Few manufacturers commit to a firmware support plan that spans that long, which means a device can spend the back half of its working life running firmware nobody is maintaining.
Many devices can't run a security agent at all. Constrained CPUs, minimal memory, and proprietary or stripped-down operating systems mean the standard enterprise playbook - deploy an agent, monitor endpoint telemetry - simply doesn't apply. For a large share of the IoT estate, network-level monitoring is the only vantage point defenders have, because there's nowhere on the device itself to install anything.
Put together, that's a class of vulnerability that doesn't get fixed by a reset, isn't easy to uncover from the outside, and often requires physical access, vendor cooperation, or a full device recall to actually remediate - a very different remediation path than "deploy the patch on Patch Tuesday."
Case Study: BadBox 2.0
If you want a concrete illustration of what "unpatched firmware" looks like when it's weaponized at scale, BadBox 2.0 is the clearest recent example. Security researchers - including HUMAN's Satori threat intelligence team, working alongside Google, Trend Micro, and the FBI - tracked malware embedded directly into the firmware of Android-based smart TVs, streaming boxes, tablets, and projectors, largely low-cost, uncertified devices manufactured and sold globally. Reported scale estimates for the campaign have run into the millions of devices, with some researcher and industry estimates citing more than 10 million units affected across the full BadBox lineage.
What makes this case study worth studying isn't the malware's capability - turning devices into a residential proxy botnet for ad fraud, credential stuffing, and traffic laundering - it's the point of compromise. The malware wasn't delivered through a phishing email or a malicious app the user installed. It was present in the firmware before the device left the factory, sitting on a read-only partition that survives a factory reset.
Compromised before the box was ever opened
That single fact breaks almost every standard consumer and IT remediation playbook. "Reset the device" doesn't help, because the malware lives in the firmware partition, not the user data partition a reset clears. "Wait for a software update" doesn't help on generic, unbranded hardware with no formal support channel. The only path that reliably works is a vendor-issued firmware update that specifically targets the infected partition - and for many of the affected devices, no such vendor relationship exists. This is what "unpatched firmware" looks like when it's not an oversight but a manufacturing-stage failure: the vulnerability isn't waiting to be discovered in the field, it's already been placed there before retail.
The Regulatory Wave Firmware Is Sitting In
Firmware security is no longer purely a technical risk - regulators worldwide are starting to treat unpatched, insecure firmware as a compliance failure, not just an engineering one. This isn't confined to one region. The UK's PSTI Act already bans default and easily-guessed passwords on connected devices, with fines up to £10 million or 4% of global revenue for non-compliance. In India, the DoT and MeitY's Code of Practice for Securing Consumer IoT (TEC 31318:2021) sets the same "no default passwords, secure updates, vulnerability disclosure" baseline, alongside CERT-In's mandatory six-hour incident reporting window and the IoT System Certification Scheme's security testing requirements. The US has its own push through the IoT Cybersecurity Improvement Act and NIST device guidance shaping federal procurement. Wherever you manufacture or sell, some version of this is now arriving.
The furthest along, and the one with hard dates already on the calendar, is the EU's Cyber Resilience Act (CRA). If you sell into the EU market, it's worth knowing the specifics: manufacturers of products with digital elements must report actively exploited vulnerabilities to ENISA within 24 hours starting September 11, 2026, with full enforcement - secure-by-design and conformity requirements - following on December 11, 2027. Penalties run up to €15 million or 2.5% of global turnover, whichever is higher, and the obligation reaches legacy products already on the market, not just new ones.
The EU's version is furthest along - and a preview of where the rest are headed
Across every one of these frameworks, the practical requirements converge on the same list: secure boot with signature verification, no default or hardcoded passwords, a machine-readable software bill of materials (SBOM), and a real vulnerability-disclosure process. Those are exactly what a firmware security review is built to test - and the only reliable way to answer whether a specific product is affected by an actively exploited vulnerability today, regardless of which regulator is asking.
What a Firmware Security Review Actually Catches
This is where we spend most of our engagement time, and where most generalist penetration testing firms stop short. A network scan sees the device from the outside: open ports, exposed services, response fingerprints. It cannot see what's compiled into the firmware image itself. When we extract and reverse-engineer the firmware, this is what actually surfaces - the same class of issues that explain how devices like the ones behind BadBox 2.0 get compromised in the first place:
- Hardcoded credentials - default or backdoor accounts baked directly into the firmware binary, invisible to any external scan until someone extracts and analyzes the image.
- Insecure OTA update mechanisms - update channels that don't verify a cryptographic signature before flashing new firmware, which means anyone who can intercept or spoof the update server can push malicious firmware indistinguishable from a legitimate one.
- Missing secure boot / signature verification - without it, there's nothing stopping unauthorized firmware, whether pushed remotely or written locally by someone with brief physical access, from booting and running.
- Exposed debug interfaces - UART, JTAG, and SPI headers left active on production hardware, often undocumented, that give an attacker with physical access a direct line into the device's boot process and memory.
None of these show up in a Nessus report. We only find them by pulling the flash chip, extracting the image, and reverse-engineering what's actually running - the same work we walk through in our firmware debugging series, applied here on the audit side of the same skill set.
Building or shipping a connected device? Talk to us about a firmware security review - the same reverse engineering approach used throughout this blog, applied to your product before an attacker, or a regulator, finds the gap first.