IoT Security Guide: Protect Your Connected Devices

I have assessed IoT deployments at federal facilities — and the same problems appear every single time: default passwords that were never changed, devices communicating in plaintext, and everything on the same flat network as the domain controllers. IoT security is not a niche specialty anymore. It is table stakes for any professional who touches connected systems.

I have assessed IoT deployments at federal facilities — and the same problems appear every single time: default passwords that were never changed, devices communicating in plaintext, and everything on the same flat network as the domain controllers. IoT security is not a niche specialty anymore. It is table stakes for any professional who touches connected systems.

This guide covers the actual threats, the practical mitigations, and the checklist you should run through every time you deploy a connected device.

Why IoT Devices Are the Most Attacked Entry Point

IoT devices are compromised at a higher rate than any other device category because they combine three factors: weak default security, long unpatched lifetimes, and network exposure that nobody monitors.

A typical enterprise network in 2026 has 3–5x more IoT devices than traditional computers. That includes IP cameras, HVAC controllers, badge readers, printers, smart TVs in conference rooms, industrial sensors, medical devices in healthcare settings, and building management systems. Most of these were installed by facilities teams, not IT security teams. Most of them run Linux kernels from 2019 with unpatched vulnerabilities. Most of them communicate over the main corporate network with no segmentation.

Attackers know this. Shodan, a search engine that indexes internet-connected devices, returns millions of results for devices with default credentials or unencrypted management interfaces. Automated scanners probe the entire IPv4 address space in under an hour. If your IoT device has a weak credential and a routable IP address, it will be found and probed within minutes of connecting to the internet.

The Top IoT Threats in 2026

Botnet Recruitment

Mirai and its descendants turned compromised IoT devices into DDoS cannons. In 2026, Mirai variants are still active — they have simply expanded their credential lists and added exploit modules for specific device models. A compromised IP camera on your network becomes part of a botnet that attacks other organizations. You become an unwitting participant in attacks you never authorized.

Network Pivot

More sophisticated attackers use a compromised IoT device as a foothold to pivot deeper into the network. The camera compromised through a default credential gives the attacker a shell on your internal network. From there, they scan for other systems — the Windows domain controller that was never patched, the NAS with sensitive files, the industrial control system managing your facilities. This is the lateral movement phase of most enterprise breaches.

Data Exfiltration

Smart devices collect enormous amounts of data. IP cameras capture video continuously. Badge readers log who goes where and when. Smart speakers record ambient audio. HVAC sensors reveal occupancy patterns. An attacker with access to these systems has a surveillance network inside your facility. In industrial settings, sensor data exfiltration can expose proprietary process parameters and trade secrets.

Firmware Exploitation

IoT devices run stripped-down Linux (or RTOS) with minimal update mechanisms. Vulnerabilities in the kernel, the web management interface, or the communication stack persist for years because no patch is released or applied. OWASP's IoT Attack Surface Areas document catalogs dozens of firmware-level attack surfaces that are trivially exploitable on unpatched devices.

Default Credentials: The Easiest Attack That Still Works

Default credentials — admin/admin, admin/password, root/root — are the single most common way IoT devices are compromised. This attack is trivially easy to execute and still succeeds at massive scale in 2026.

Manufacturers ship devices with default credentials for manufacturing convenience. Many users never change them. Lists of default credentials for thousands of device models are publicly available. Mirai's original source code included a list of 61 default username/password combinations that successfully compromised over 600,000 devices in its first week of deployment.

The fix is simple and non-negotiable: change credentials before the device goes online. Use a password manager to generate a unique, strong password for every device. Document the credentials securely. Never reuse a password across multiple devices — if one is compromised through another vector, credential stuffing can take down the rest.

For enterprise deployments, implement a device onboarding procedure that requires credential change before network connectivity. Some modern enterprise IoT platforms (like AWS IoT Core with X.509 certificates) eliminate password-based authentication entirely in favor of mutual TLS — no passwords to default, none to compromise.

Network Segmentation: Limit the Blast Radius

Every IoT device should be on a separate VLAN, isolated from your primary corporate network. This is the single highest-impact security control you can implement for an existing IoT deployment.

Network segmentation does not prevent a device from being compromised. It limits what an attacker can do after compromise. If your IP cameras are on VLAN 20 with firewall rules that only allow outbound traffic on port 443 to your NVR's IP address, a compromised camera cannot scan your domain controllers on VLAN 10. The blast radius is contained to the IoT VLAN itself.

Implementation steps:

• Create a dedicated IoT VLAN on your managed switch and router
• Configure inter-VLAN firewall rules: deny all traffic from IoT VLAN to corporate VLAN by default, allow only specific required flows
• If IoT devices need internet access, route through a firewall with application-layer inspection
• For home networks: most modern mesh routers (Eero, Ubiquiti, TP-Link Deco) support a "guest network" that is isolated — use it for all smart home devices

Secure Communications: TLS, MQTT, and CoAP

MQTT over plain TCP (port 1883) transmits all messages in cleartext. Anyone on the same network can read every sensor reading, command, and credential exchange. Use TLS on port 8883 for all production MQTT deployments.

MQTT is the dominant messaging protocol for IoT — lightweight, low overhead, publish/subscribe model. But it was designed for constrained networks and devices, and the default configuration is not secure. Securing MQTT requires four things:

• TLS encryption: Configure the broker (Mosquitto, EMQX, HiveMQ) to require TLS on port 8883. Issue device certificates via a private CA or use Let's Encrypt for the broker endpoint.
• Authentication: Require username/password authentication at minimum. For higher security, use client certificates (mutual TLS) so each device has a unique certificate that the broker validates.
• ACLs: Configure access control lists so each device can only publish to its own topic and subscribe to topics it legitimately needs. A temperature sensor should not be able to publish to the command topic for a door lock.
• Disable anonymous access: The default Mosquitto configuration allows anonymous connections. This must be explicitly disabled in the configuration file.

For CoAP (Constrained Application Protocol, common on constrained devices), use DTLS (Datagram TLS) to encrypt UDP traffic. For HTTP-based device APIs, enforce HTTPS and pin the certificate on the device firmware to prevent man-in-the-middle attacks.

Firmware Security and Update Management

Outdated firmware is the root cause of the majority of IoT exploits that reach production systems. A device you cannot patch is a liability, not an asset.

Firmware security has two dimensions: the security of the firmware itself and your ability to update it. For devices you build yourself, secure firmware development includes: using a secure boot chain so only signed firmware will run, disabling unused interfaces (UART debug console, JTAG), removing development credentials before production builds, and enabling memory protection on devices that support it.

For purchased devices, evaluate the vendor's update track record before buying. Questions to ask: How long does the vendor commit to releasing security updates? Is the update mechanism automatic or manual? Does the device verify firmware signatures before applying an update (to prevent malicious firmware injection)? Does the device report its firmware version to a management console?

For devices already in production that cannot be patched: isolate them aggressively on their own VLAN segment with the strictest possible firewall rules. Monitor their traffic for anomalous behavior. Plan a replacement timeline. A device that cannot be patched is a known risk you are accepting — document that decision explicitly.

Monitoring IoT Traffic for Anomalies

Known-good IoT devices have highly predictable behavior: a temperature sensor publishes a reading every 60 seconds, an IP camera streams video on port 554. Anomalies — sudden port scans, connections to new external IPs, unusual data volumes, lateral movement attempts — stand out sharply against this baseline.

Tools for IoT traffic monitoring:

• Zeek (formerly Bro): Network traffic analysis framework that generates structured logs from raw packets. Excellent for protocol-level visibility across IoT traffic.
• Suricata: IDS/IPS with IoT-specific rule sets (from Emerging Threats). Detects known attack patterns and anomalous behavior in real-time.
• ntopng: Network traffic monitoring with flow analysis. Good for visibility into which IoT devices are talking to which external IPs.
• Your router's logging: At minimum, enable firewall logging on your IoT VLAN and review it periodically for unexpected connection attempts.

IoT Security Checklist

Run through this checklist for every IoT device you deploy:

• Change default credentials before connecting to any network
• Place the device on a dedicated IoT VLAN, isolated from corporate and personal networks
• Configure firewall rules to deny all inter-VLAN traffic from IoT to corporate by default
• Enable TLS/HTTPS for all device communications — no plaintext HTTP or unencrypted MQTT
• Configure authentication on all device interfaces — disable anonymous access
• Disable unused services, ports, and interfaces on the device
• Enable automatic firmware updates if the device supports them
• Document the device model, firmware version, and expected behavior for monitoring baseline
• Plan a replacement or remediation path for devices that stop receiving security updates