IoT security is the discipline of protecting devices the vendor stopped maintaining about six months after they shipped. The economics drive everything: vendors hit a $50 bill of materials, sell millions of units, and never push firmware updates because there’s no business model that pays for them. The defender’s job is to harden what the vendor didn’t, monitor what the vendor doesn’t tell you about, and segment the network so that the device the vendor abandoned doesn’t take the rest of the environment down with it.
This post covers the defender-side controls that actually work in 2026: secure boot and signed firmware updates, communications security with TLS 1.3 and DTLS, credential management for devices that ship with hardcoded passwords, network segmentation tuned for the IoT use case, and the modern monitoring platforms that catch IoT-specific bad behavior. The companion offensive post covers what operators look for when testing these controls; reading both gives you the full picture.
The four control families that matter#
IoT defense organizes around four overlapping control families: device integrity, communications security, identity and access, and network segmentation. Each one has a half-dozen specific controls underneath it. The mistake most IoT security programs make is treating these as a checklist without thinking about which devices on the network actually support each control.
Device integrity: secure boot, signed firmware, no rollback#
The control: every device should boot only firmware signed by a key the device’s hardware trusts, and reject older firmware versions to prevent rollback to known-vulnerable releases.
The implementation: a hardware root of trust (TPM 2.0 chip on the more expensive devices, ARM TrustZone on Cortex-A class processors, a dedicated secure element like NXP’s SE050 or Microchip’s ATECC608 on the cheaper SoCs) verifies a digital signature on the first-stage bootloader. The bootloader verifies the kernel. The kernel verifies the file system. By the time the application runs, every layer underneath has been validated as authentic. A version-counter check during the verification process rejects firmware older than the current installed version.
The defender’s reality: most consumer IoT devices don’t implement this at all. The cheaper segment of the industrial-IoT market doesn’t either. When you’re auditing a real deployment, the question is which of the device classes on the network actually have hardware-backed verified boot and which have a soft-fuse setup that any attacker with physical access can flip. The answer is usually “the expensive ones do, everything else doesn’t.”
For organizations that get to choose their IoT hardware (industrial deployments, building automation, healthcare devices), the procurement requirement should include “demonstrate hardware-rooted verified boot per IEC 62443-4-2 or NIST IR 8259A.” For consumer-grade devices that nobody chose deliberately (the doorbell the receptionist bought, the smart TV in the conference room), the answer is “assume it’s compromisable and segment it accordingly.”
Communications security: TLS 1.3 plus DTLS#
The control: every connection between the device and anything else should be encrypted, mutually authenticated, and resistant to passive interception or active man-in-the-middle.
The implementation: TLS 1.3 (RFC 8446, August 2018) for TCP-based traffic, DTLS 1.3 (RFC 9147, April 2022) for UDP-based traffic where small packet sizes and unreliable delivery matter. Both sides authenticate with X.509 certificates (or the modern alternative, raw public keys per RFC 7250 when you don’t want the certificate parsing overhead). The device’s private key sits in hardware-protected storage (TPM, secure element) so even a fully compromised software stack can’t exfiltrate it. Perfect Forward Secrecy via ephemeral key exchange (X25519 or P-256 ECDHE) protects past sessions if the long-term key ever leaks.
The defender’s reality: a lot of IoT devices still ship with TLS 1.2 (acceptable but trailing the state of the art), TLS 1.1 or 1.0 (broken, must be disabled), or no encryption at all (the older Zigbee deployments, the surprisingly large installed base of plaintext MQTT, the consumer light bulbs that decided HTTPS was too expensive). For deployments that have to interoperate with this kind of device, the segmented-network approach is the only workable answer: put the unencrypted devices on an isolated VLAN, accept that traffic between devices on that VLAN is plaintext, and apply heavy monitoring on the boundary to anything else.
Mutual authentication is the harder requirement to enforce in the field. Most enterprise CA infrastructures issue device certificates per IT-managed device, but the typical IoT device manufacturer doesn’t integrate with the enterprise CA, doesn’t have a sensible way to enroll a device certificate during onboarding, and doesn’t have a way to rotate the certificate if the device’s private key is suspected of being compromised. Matter (the Connectivity Standards Alliance smart-home standard, 1.0 released October 2022) is the first consumer-IoT standard that built device certificates and operational credentials into the protocol from day one; whether the Matter ecosystem actually solves the consumer-IoT identity problem is still being worked out.
Identity and access: no default passwords, no shared keys#
The control: every device should have a per-device unique credential at first boot, and the user should be required to change it before the device exposes any management interface to the network.
The implementation: factory provisioning that writes a unique password (or, better, a unique certificate) into each device before it leaves the manufacturer. Mandatory password change on first login, enforced by the device itself rejecting any management commands until the default is changed. Multi-factor authentication for any remote management interface. Hardware tokens (FIDO2) or push notifications instead of SMS for the MFA factor.
The defender’s reality: this is the area where regulation has finally started to bite. California’s SB-327 (2020) and the UK’s Product Security and Telecommunications Infrastructure Act (PSTI, in force April 2024) both prohibit shipping consumer IoT devices with universal default passwords. The EU’s Cyber Resilience Act (full applicability 2027) extends similar requirements across the entire EU IoT market with penalties for non-compliance. The regulation is shifting the manufacturer side; the installed base of pre-regulation devices is still the operator’s biggest risk.
Mirai is the canonical case study for why default passwords matter. The 2016 botnet’s scanner.c carried a hardcoded list of 62 username/password pairs for telnet on port 23, and that list owned 600,000 IoT devices over seven months. The covered version is in the IoT hacking post
; the defender takeaway is the same one regulators have spent the past decade enforcing: shipping universal default credentials is no longer acceptable.
Network segmentation: the IoT VLAN pattern#
The control: IoT devices live on their own network segment, can’t reach the corporate user network or server network without explicit allow rules, and can’t reach the internet except through a controlled egress.
The implementation: a separate VLAN (or several, sorted by trust level) for IoT devices. Inter-VLAN traffic blocked by default; specific allow rules for the few legitimate communications the IoT devices need (NTP, DNS, the vendor’s cloud endpoint for telemetry, the management interface for the operator’s controller). Outbound internet traffic egresses through a proxy that logs and inspects, blocking traffic to anywhere the IoT devices shouldn’t be talking to. Inbound internet traffic to IoT devices: zero. If a device needs remote access, it goes through a tunneled remote-management gateway, not via direct exposure.
The defender’s reality: this is the most-implemented IoT defense because it works regardless of whether the devices themselves are properly hardened. Even a fully compromised IoT VLAN is a blast radius limited to itself plus whatever explicit allow rules let the attacker through. The catch is that a meaningful IoT segmentation requires actually identifying which devices are IoT (the badge readers, the IP cameras, the smart TVs in conference rooms, the building-automation controllers, the printer that turned out to be a Linux server with USB ports), which is harder than it sounds because the IT department usually didn’t deploy half of them.
Network discovery and asset inventory is the prerequisite. Tools that help (covered in detail below): Armis, Forescout, Claroty, Nozomi, Palo Alto IoT Security, Microsoft Defender for IoT.
Firmware: the layer where most bugs live#
A separate section because the firmware-level controls deserve their own attention.
Firmware update channels need to be secure end-to-end: signed updates delivered over authenticated channels, verified by the device before installation, with rollback protection. The mechanics are described in the device-integrity control family above; what matters operationally is that the update channel actually gets used. Vendors who ship a device with a great firmware update mechanism and then never push an update through it have provided the worst of both worlds: the operational complexity of the update infrastructure without the security improvements of actual updates.
For organizations evaluating IoT devices, three procurement-time questions cut to the heart of the firmware story:
- How long does the vendor commit to providing security updates? PSTI requires this disclosure in the UK; the EU Cyber Resilience Act will require it across the EU. The honest answer is often “we don’t, and we won’t.”
- How does the update get delivered? OTA over the internet is the modern default; USB-based updates require physical access (not always bad); update-via-app from the user’s phone is the consumer-IoT default and has its own attack surface.
- What’s the worst-case behavior if an update fails or arrives corrupted? A device that bricks itself after a bad update is a known failure mode that costs vendors money; a device that keeps running the old firmware and reports the failure is the correct behavior.
For firmware analysis on the testing side, the operator’s toolkit is covered in the IoT hacking post : binwalk, qemu-user-static for emulation, Firmadyne and FirmAE for whole-device emulation, Ghidra and Binary Ninja and radare2 for static analysis. The defender uses the same tools to validate that their own firmware doesn’t contain credentials, debug interfaces, or test-mode bypasses that survived into the shipping build.
The vulnerability families to know#
A handful of multi-CVE vulnerability families have shaped what IoT defense looks like in 2026. Knowing them by name helps when you’re triaging a finding:
- Ripple20 (JSOF, June 2020): 19 vulnerabilities in the Treck TCP/IP stack, shipping in countless embedded devices since 1997. Heap overflows, integer overflows, info leaks. The supply-chain extent (medical devices, industrial controllers, IoT gateways) made remediation enormously difficult because most affected devices didn’t know they were affected.
- URGENT/11 (Armis, July 2019): 11 vulnerabilities in the IPnet TCP/IP stack used in Wind River VxWorks, the dominant real-time OS in industrial and medical devices. Some allowed remote code execution; the install base was huge.
- AMNESIA:33 (Forescout, December 2020): 33 vulnerabilities across four open-source TCP/IP stacks (uIP, FNET, picoTCP, Nut/Net) used in millions of embedded devices.
- Name:Wreck (Forescout and JSOF, April 2021): 9 vulnerabilities in DNS implementations across multiple TCP/IP stacks (FreeBSD, NetX, Nucleus NET, IPnet). DNS message-compression bugs that allowed remote code execution.
- NUMBER:JACK and INFRA:HALT are additional research lines from the same teams targeting smaller embedded stacks.
What these have in common is the supply-chain nature of the problem. The vulnerabilities live in third-party network stacks that thousands of device vendors integrated and shipped, and most of those vendors don’t have a tracking relationship with the stack’s upstream maintainer. Coordinated disclosure goes to the stack vendor; the device vendors learn about the issue from CISA or US-CERT advisories, often months after public disclosure; and even then, applying the patch requires a firmware update that most installed devices won’t ever receive.
For defenders, the operational answer is detection plus segmentation. Network monitoring catches the actual exploitation traffic (most of these issues produce distinctive on-the-wire patterns); segmentation contains the blast radius if a device is exploited.
Monitoring platforms#
The IoT-specific monitoring market matured significantly between 2018 and 2026. The platforms that dominate now:
- Armis, agentless network-based visibility and threat detection for IoT/OT/IT. Discovers devices by passive traffic monitoring, classifies them against a large device fingerprint database, alerts on anomalous behavior. The Armis platform was acquired by Insight Partners in 2020 and is one of the most-deployed IoT-specific monitoring tools in enterprise.
- Forescout, network access control plus IoT visibility. Originated as a NAC product (the Forescout CounterACT line) and grew into IoT/OT visibility. Currently owned by Crosspoint Capital Partners.
- Claroty, OT-focused with strong industrial-control-system coverage. Operates the well-respected Team82 research group that publishes a lot of the public ICS vulnerability research.
- Nozomi Networks, also OT-focused; the operational-technology-side equivalent of an EDR product. Particularly strong in industrial settings (power generation, water treatment, manufacturing).
- Dragos, ICS/OT-focused threat detection and incident response. Heavyweight in industrial environments; often grouped with Claroty and Nozomi as the OT-side triumvirate. Per Gartner’s 2026 CPS Protection Platforms Magic Quadrant, Claroty, Armis, Nozomi, Dragos, and Microsoft Defender for IoT are in the Leaders quadrant.
- Microsoft Defender for IoT, Microsoft’s IoT/OT monitoring product, originated from the CyberX acquisition (2020). Integrates with the rest of the Microsoft Defender XDR stack.
- Palo Alto IoT Security, Palo Alto’s IoT visibility product (originally Zingbox, acquired 2019), integrated into the Cortex XSOAR ecosystem.
For pure consumer IoT or small environments, the open-source alternatives (Home Assistant’s built-in monitoring, Zeek for network-level visibility, IoT Inspector by Princeton) cover the same ground at lower scale and with more operator effort. Most enterprise deployments end up running one of the commercial platforms because the device-fingerprint database and the threat intelligence integration are the parts that take years to build internally.
Standards and regulatory environment#
The standards environment that defenders actually reference:
- IEC 62443, the international standard for industrial automation and control systems security. Multiple parts covering systems (62443-3-3), products (62443-4-2), and processes. The reference for industrial deployments.
- NIST SP 800-82, Guide to Operational Technology (OT) Security, the U.S. government’s reference for industrial control system security. Currently at Revision 3 (September 2023).
- NIST IR 8259 series, the U.S. government’s IoT-specific cybersecurity profiles. NIST IR 8259A defines core baseline capabilities; 8259B covers non-technical supporting capabilities.
- ETSI EN 303 645, European standard for consumer IoT cybersecurity, basis for the UK PSTI Act.
- UK PSTI Act, Product Security and Telecommunications Infrastructure Act, in force since April 2024. Bans universal default passwords on consumer IoT, requires vulnerability disclosure mechanisms, requires transparency on minimum support periods.
- EU Cyber Resilience Act (CRA), full applicability scheduled for December 2027. Extends similar requirements across the EU IoT and software market with significant non-compliance penalties.
- U.S. Cyber Trust Mark, voluntary labeling program for consumer IoT devices, launched 2024. Devices that meet defined security criteria can carry the mark.
The regulatory environment is where most of the meaningful change is happening. The standards have existed for years; the difference now is that selling a non-compliant device in the UK or EU eventually carries financial consequences.
Matter, briefly#
Matter is the consumer smart-home standard developed by the Connectivity Standards Alliance (the renamed Zigbee Alliance), with Matter 1.0 released October 4, 2022 and the spec at Matter 1.4 as of 2026. It addresses the historical mess of consumer-IoT identity and communication: every Matter device has a per-device Device Attestation Certificate (DAC) provisioned at manufacturing, devices on a Matter fabric speak a common IPv6-based application-layer protocol over Wi-Fi, Thread, or Ethernet (with Bluetooth LE used only for commissioning), and the security model includes both device authentication and operational credential rotation.
Whether Matter actually delivers on its promise is still being decided. Apple, Google, Amazon, and Samsung all support Matter; the major lighting and access-control vendors have shipped Matter-compatible products. The protocol’s complexity is real and the certification process is non-trivial, which has kept some smaller manufacturers from adopting it. The longer-term question is whether having a strong protocol on the wire is enough to fix a market that has historically prioritized cost over security.
For the defender, Matter is worth knowing about because it represents the first widespread consumer-IoT standard that took identity and authentication seriously by design rather than as a bolt-on. If the rest of the consumer-IoT market follows Matter’s lead, the next decade of IoT defense gets meaningfully easier. If it doesn’t, the segmentation-and-monitoring playbook the rest of this post describes continues to be the operational answer.
What this comes down to#
IoT security is the asymmetric problem where the defender has to harden devices the vendor doesn’t care about, on networks the IT department didn’t fully inventory, against attackers who only need one exposed default credential or one unpatched stack vulnerability to land. The controls that work are unglamorous and well-understood: secure boot with hardware roots of trust, signed firmware with rollback protection, TLS 1.3 with mutual authentication, per-device credentials enforced at first boot, IoT VLAN segmentation, and continuous monitoring with one of the IoT-specific platforms.
The single biggest operational lever for most organizations is the network segmentation: even badly-secured IoT devices on a well-isolated VLAN have a limited blast radius. The vendor-side market is finally being shaped by regulation (UK PSTI, EU CRA, the U.S. Cyber Trust Mark) in ways that should improve the baseline over the next five years. The installed base of pre-regulation devices will remain the defender’s problem for considerably longer.
For the offensive companion to this post, see the IoT hacking post that covers what operators look for when testing the controls described above.
