IoT security history is short and brutal. Most of the named attacks on IoT are not subtle: default credentials, no encryption, exposed admin interfaces, telnet on port 23. The fixes are equally unsubtle, but they require vendor cooperation that didn't exist until governments started showing up with fines. This page covers the threat history, the practical defenses you actually deploy, and the regulations now reshaping the supply chain.
A short history of IoT in headlines
The OpenSSL bug that made the world realize how many embedded devices ran out-of-date crypto libraries. Tens of millions of IoT devices had Heartbleed-vulnerable OpenSSL and no update path.
A botnet built almost entirely from IP cameras and DVRs with default credentials. Source code released publicly. At peak, Mirai took down Krebs on Security (620 Gbps DDoS), then Dyn DNS (which knocked most of the US internet's east coast offline for several hours on October 21).
How it spread: Mirai scanned the internet for telnet on port 23. When it found one, it tried 62 username/password combinations — most of them factory defaults like root:xc3511 and admin:admin. Roughly half of all infected devices were a handful of camera brands shipping that exact password.
A North American casino lost 10 GB of high-roller data to attackers who pivoted from a smart-thermometer in the lobby fish tank. The thermometer had network access to monitor temperature; it was on the same VLAN as the corporate environment. The defining anecdote for IoT segmentation policy.
VPNFilter (May 2018) infected ~500k home routers. Mirai variants (Satori, Okiru, Hajime, Reaper) used newer router exploits instead of telnet defaults. The pattern shifted from "default creds" to "unpatched CVEs the vendor abandoned in firmware."
19 vulnerabilities in a TCP/IP stack used by hundreds of millions of devices — HP printers, Schneider Electric controllers, Caterpillar equipment, medical devices, infusion pumps. The supply-chain awakening: a bug in one library reaches every industry simultaneously.
EU Cyber Resilience Act (in force 2024, full applicability December 2027). UK Product Security and Telecommunications Infrastructure Act (April 2024). California SB-327 (2020) plus federal IoT Cybersecurity Improvement Act (2020). The legal landscape finally penalizes vendors who don't bother with basic security.
The threat catalog
| Threat | Why it happens | Real example |
|---|---|---|
| Default credentials | Vendor ships every device with the same root/admin password. User never changes it. | Mirai (telnet:root:xc3511). Still the highest-impact IoT problem in 2024. |
| Unauthenticated admin interfaces | Web UI on port 80 accepts commands without login, or "internal use only" assumption made. | Open MQTT brokers indexed by Shodan; CoAP servers exposing device control to the internet. |
| Unencrypted communication | HTTP instead of HTTPS, plaintext MQTT, unauthenticated CoAP. Passive sniffer captures everything. | Smart-home cameras streaming video over HTTP to the cloud, found by Shodan banner search. |
| Hardcoded keys | Vendor builds one symmetric key into firmware, used across the entire product line. | Extract once from any device, decrypt every device. Common in cheap consumer locks and cameras. |
| No update mechanism | Device ships with vulnerable code and no path to fix it. | Vast amount of consumer IoT pre-2020; vendor support windows shorter than device lifespan. |
| Insecure boot | Firmware not signature-verified. Attacker can flash modified firmware via JTAG or recovery mode. | Modified-firmware persistence after a known-vendor RCE. |
| Side channels | Power analysis, timing attacks recover keys from cheap microcontrollers without true tamper resistance. | Smart locks, key fobs — demonstrated repeatedly at DEF CON Car Hacking Village. |
Shodan: the IoT search engine
Shodan (shodan.io) is a search engine that indexes internet-facing services by their banners — the strings they send when you connect. Where Google indexes web pages, Shodan indexes what's listening. For IoT, it's a recon weapon and a defensive instrument depending on who's using it.
Useful Shodan queries you should know:
port:23— everything with telnet open. Should be zero results from your environment.product:"MQTT" port:1883— unauthenticated MQTT brokers."server: lighttpd" "ttp/1.1 401"— embedded webservers asking for HTTP basic auth.org:"Your Company" port:23,2323,3389,5985— admin services exposed under your org's ASN. Run this monthly.http.title:"Camera Login"— internet-facing cameras.
Shodan also runs the Shodan Monitor service which alerts you when new services appear in your IP space. Set this up. It's how you find the shadow-IT IoT before an attacker does.
Firmware analysis in 30 seconds
When a vendor's "security audit" returns "this is fine, trust us," firmware analysis is how you check. The flow:
- Get the firmware. Download from vendor support site, dump via JTAG/UART, extract from update files.
- Identify the format. Tools:
binwalk,file. Most embedded firmware is a binary blob containing a bootloader, a kernel, and a SquashFS or JFFS2 root filesystem. - Extract the filesystem.
binwalk -e firmware.binrecovers the rootfs. - Walk the filesystem.
/etc/shadowfor hardcoded creds./etc/init.dfor what runs at boot./usr/binfor binaries. Strings on each binary looking for embedded keys, URLs, credentials. - Run binaries through Ghidra or Cutter. Decompile to look for obvious bugs —
system()calls on user input, hardcoded crypto keys, debug interfaces.
Practical defenses
1. Segment — the casino-fish-tank rule
Put IoT on its own VLAN. Put guest IoT on a separate VLAN from corporate IoT. Restrict east-west traffic between IoT VLAN and other VLANs to only the explicitly required management endpoints. The thermometer should not be able to reach the file server.
For home networks, modern routers (Eero, Plume, Asus) increasingly support an "IoT network" as a separate SSID. Use it.
2. Inventory · you can't defend what you don't see
NAC (network access control), MAC-address fingerprinting, and DHCP fingerprinting can identify every device that touches the network. Tools like Armis, Forescout, and Cisco ISE classify devices automatically. Open-source: nmap with OS detection plus a CMDB.
Inventory is the precondition for everything else — you can't patch, segment, or monitor what you can't enumerate.
3. Change defaults at onboarding
Force a password change on first boot. Document any device that won't allow this. SB-327 in California has required this since 2020 for any IoT device sold there; vendors who care to ship in California do this already. For devices that don't, isolate them at the network layer because you can't fix them at the auth layer.
4. OTA updates required, signed, automatic
Before buying: ask the vendor what their support window is, how updates are signed, and whether updates are mandatory or opt-in. If the vendor cannot answer "five years minimum with signed mandatory updates," the device is a liability. For deployed devices that don't have OTA, set a calendar for replacement.
5. Egress filtering at the perimeter
IoT devices should talk to a known set of cloud endpoints and nothing else. Allowlist their destinations at the firewall. Mirai needed C2 traffic to coordinate; egress filters block that even when the device is compromised. A camera that needs to reach only manufacturer.com shouldn't be allowed to scan port 23 across the internet.
6. Monitor for the wrong-looking traffic
An IoT thermostat that suddenly initiates outbound SSH at 3 AM is interesting. Tools like Zeek/Suricata on the IoT VLAN catch this. NDR (network detection and response) products specialize in exactly this signal.
The regulatory shift
2024-2027 is the period when IoT security stops being optional. Three regulatory regimes you should know:
| Regulation | Region | What it requires |
|---|---|---|
| EU Cyber Resilience Act | European Union (in force 2024, fully applicable Dec 2027) | Mandatory vulnerability handling, free security updates for entire support period, no known exploitable CVEs at sale, SBOM. Fines up to €15M or 2.5% global revenue. |
| UK PSTI Act | United Kingdom (in force April 2024) | Default passwords banned. Minimum security support period must be declared at purchase. Vulnerability disclosure point of contact required. |
| NIST IR 8259 / IR 8425 | United States (2020, 2022) | Recommends baseline for IoT manufacturers. The U.S. Cyber Trust Mark (announced 2024, rolling out 2025) is the consumer-facing label backed by 8425. |
| California SB-327 | California (since 2020) | Default passwords must be unique per device or require user setup. Practical impact: vendors making devices for the California market often apply the same change globally. |
A buying checklist
When evaluating an IoT product (for home, for office, for a hospital), ask the vendor in writing:
- How long will this product receive security updates? (Look for a calendar date, not "as long as we support it.")
- How are updates delivered — OTA, signed, mandatory, or opt-in?
- Are there hardcoded credentials? (The honest answer is sometimes "yes, for debug, removed at production." Verify.)
- What's the default network behavior? Local-only, cloud-required, or hybrid?
- Is there a published vulnerability disclosure process — an email, a bug bounty, anything?
- What standards/certifications does it meet? (Matter, UL 2900, IEC 62443, CE/UKCA, Cyber Trust Mark.)
The decade from Mirai to Matter was a slow, painful lesson that IoT vendors will not voluntarily produce secure products at consumer prices. The fixes that work are operational: segment the IoT VLAN, inventory everything, force credential changes, monitor egress, replace the unfixable.
The regulatory landscape is finally catching up. Vendors who want EU market access in 2027+ have to ship secure-by-default firmware with funded patch cycles. The right play in 2024-2025 is to align your IoT procurement with that direction now — the product list shrinks, but the survivors are the ones that won't be a liability in three years.
Sources
- Antonakakis, M., et al. (2017). Understanding the Mirai botnet. USENIX Security. https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
- Schneier, B. (2017, July 21). The casino fish tank hack. Schneier on Security. https://www.schneier.com/blog/archives/2017/07/the_casino_fish.html
- JSOF. (2020). Ripple20: 19 zero-day vulnerabilities in the Treck TCP/IP stack. https://www.jsof-tech.com/disclosures/ripple20/
- European Commission. (2024). Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- UK Department for Science, Innovation and Technology. (2024). Product Security and Telecommunications Infrastructure (PSTI) Act 2022. https://www.gov.uk/government/collections/the-product-security-and-telecommunications-infrastructure-psti-bill-factsheets
- NIST. (2022). NISTIR 8425: Profile of the IoT core baseline for consumer IoT products. https://csrc.nist.gov/publications/detail/nistir/8425/final
- Shodan. (2024). Shodan search engine. https://www.shodan.io/