IoT Threat Landscape 2026 - Edge Devices Are Becoming Attacker Infrastructure

A practitioner threat model for IoT risk in 2026: routers, DVRs, gateways, serial converters, RFID readers, and unmanaged edge devices as botnet, proxy, and lateral-movement infrastructure.

By Tatiana K. · Reviewed by Gleb Z.

Executive summary

The IoT threat landscape in 2026 is no longer centered only on hacked cameras and weak smart-home gadgets. The more useful attacker asset is the unmanaged edge device: routers, DVRs, gateways, serial-to-IP converters, network video recorders, RFID readers, Android TV boxes, and similar equipment that sits close to business operations but outside normal endpoint controls.

For Melina Security, the practical question is not “Can this device be infected?” Many can. The better question is: what role can this device play after compromise? In 2026, that role is usually one of three things: botnet node, residential or enterprise proxy, or pivot point into a connected-product or OT environment.

All techniques discussed here are for authorized security testing under written rules of engagement. Unauthorized access to systems is illegal.

What changed in 2026?

The important change is not that IoT malware exists. It has existed for years. The change is that compromised edge devices are now useful infrastructure for both financially motivated actors and state-linked operators.

Kaspersky’s Securelist Q1 2026 IoT telemetry reports continued IoT honeypot activity and notes that Mirai-family variants remain prominent among downloaded IoT threats. Akamai reported active exploitation of D-Link router vulnerability CVE-2025-29635 in March 2026 to deploy a Mirai variant called tuxnokill. Forescout’s 2026 device-risk research says routers and switches average roughly 32 vulnerabilities per device and account for a large share of devices with the most critical vulnerabilities.

Those facts point in the same direction: exposed infrastructure is valuable because it is always on, rarely monitored well, and often patched late.

The 2026 IoT risk map

Not every IoT device creates the same risk. A smart bulb on a guest network is not equivalent to a router terminating VPN traffic or a serial converter bridging Ethernet to a production controller.

Device class	Common exposure	Attacker value	Business risk
SOHO and branch routers	WAN admin, VPN, outdated firmware	Proxy, botnet, credential capture, traffic relay	Covert access and DDoS infrastructure
DVRs, NVRs, IP cameras	Internet-exposed web UI, RTSP, weak credentials	Botnet node, surveillance, internal foothold	Privacy breach and network pivot
IoT gateways	Cloud API, MQTT, cellular, local admin	Fleet pivot, command relay, data manipulation	Connected-product compromise
Serial-to-IP converters	Telnet, web UI, weak/default credentials	Bridge into OT or lab systems	Safety and uptime risk
RFID readers and time clocks	Flat network placement, old firmware	Identity and movement data abuse	Fraud, workflow disruption
Android TV boxes and media devices	Third-party firmware, sideloaded apps	Residential proxy, malware staging	Reputation and data exposure

The devices with the highest business impact are often the least visible. Security teams can usually list laptops. They often cannot list every gateway, converter, reader, or camera that was installed by facilities, manufacturing engineering, a logistics vendor, or a product team.

The attack chain that matters

Most 2026 IoT incidents still follow a simple operational pattern. Complexity appears later, after the device is already under attacker control.

The attacker finds an exposed device through scanning, leaked telemetry, botnet peer lists, or a known-vulnerable product fingerprint.
The attacker tries default credentials, weak credentials, known CVEs, or a public proof-of-concept exploit.
The device downloads a small loader or shell script.
The loader selects an architecture-specific payload: MIPS, ARM, x86, PowerPC, or another embedded target.
The device joins command-and-control infrastructure.
The actor uses it for DDoS, proxying, scanning, credential theft, or lateral movement.

This chain is not sophisticated in every case. That is exactly why it persists. Attackers do not need elegance when the device fleet still contains exposed admin panels, hardcoded credentials, unsupported firmware, or forgotten remote-access rules.

Why Mirai still matters

Mirai is still useful as a family pattern, not only as a specific malware sample. It showed the durable economics of IoT compromise: scan aggressively, authenticate cheaply, infect fast, and replace dead nodes with new ones.

Securelist’s ongoing IoT threat statistics and Akamai’s 2026 D-Link observations show that this pattern remains active. The exploit changes. The loader changes. The target device class changes. The business logic does not.

That has a clear implication for defenders: an IoT security program cannot be built around one malware name. It needs to reduce the conditions that make Mirai-style operations cheap:

Internet-exposed management interfaces
Default or shared credentials
Weak credential lockout behavior
End-of-life firmware
No egress monitoring
No asset owner for “small” network devices
No architecture-specific malware detection

If those conditions stay in place, the next Mirai variant does not need to be novel.

Edge devices as proxy infrastructure

The most underestimated role of compromised IoT devices is proxying. A router, DVR, or smart device in a real residential or business network gives attackers an IP address that looks ordinary. That matters for credential stuffing, fraud, reconnaissance, scanning, and hiding command-and-control traffic.

Government advisories have repeatedly warned that routers and IoT devices can be used as botnet infrastructure. The 2024 joint advisory from NSA, FBI, CISA, and partners on PRC-linked botnet activity specifically focused on compromised routers, firewalls, NAS devices, and IoT devices. That pattern is strategic: the edge device becomes a relay that makes attribution and blocking harder.

For companies, the risk is not limited to “our router gets used to attack someone else.” A compromised edge device can also become the entry point into the company’s own environment. If it can see internal DNS, management VLANs, VPN traffic, or administrative interfaces, it is not just a botnet node. It is a foothold.

Why connected-product companies should care

IoT manufacturers often treat botnets as an operator problem: the customer deployed the device, the customer exposed it, the customer failed to patch it. That view is too narrow.

Manufacturers inherit risk in four places:

Product reputation when devices are conscripted into botnets
Support load when customers cannot identify compromise
Regulatory pressure when secure-by-design expectations apply
Fleet risk when the same vulnerability exists across product generations

The strongest product-security teams design for hostile deployment reality. They assume some customers will expose management ports, delay updates, reuse passwords, and connect devices to flat networks. The product should still resist cheap compromise.

Security controls that actually reduce risk

For operators, the first control is asset visibility. You cannot patch or segment what you cannot name.

Control	Why it matters	Test question
External exposure inventory	Finds internet-facing admin surfaces	Which devices answer from the public internet today?
Firmware lifecycle tracking	Detects unsupported devices	Which deployed devices are end-of-life or missing security updates?
Credential policy	Blocks cheap authentication attacks	Are default credentials disabled at first boot?
Network segmentation	Limits pivot value	Can an IoT camera reach domain services or production systems?
Egress monitoring	Catches botnet behavior	Can devices initiate arbitrary outbound connections?
Vulnerability intake	Shortens response time	Do product owners subscribe to vendor PSIRT advisories?

For manufacturers, the equivalent controls belong in the product:

No shared default credentials
Forced credential change or unique per-device credentials
Secure update mechanism with rollback protection
Clear end-of-support policy
SBOM at release time
Network services disabled by default
Local admin surfaces bound to local-only interfaces unless explicitly enabled
Logging that exposes failed login bursts and suspicious outbound connections

Melina Security assessment model

When Melina Security assesses an IoT product or device fleet, we separate the work into four layers:

Exposure review: internet-facing services, local network services, wireless interfaces, cloud endpoints, mobile app interfaces.
Compromise path analysis: authentication, command injection, firmware extraction, secret handling, update flow, debug interfaces.
Post-compromise role analysis: botnet suitability, proxy potential, lateral movement, data access, persistence.
Fleet remediation review: update path, device identity, key rotation, logging, customer guidance, end-of-life handling.

That fourth layer is where many assessments become useful. Finding a command injection bug is important. Understanding whether the vendor can safely update a 200,000-device fleet is what turns a finding into business risk.

A practical 30-day plan

Teams that need a fast improvement cycle can start here:

Week	Action	Output
1	Build an inventory of exposed IoT and edge devices	Public exposure list with owner and firmware version
2	Remove unnecessary internet exposure and default credentials	Reduced attack surface and credential exceptions list
3	Segment high-risk device classes	Network policy separating IoT from identity, admin, and production systems
4	Test one representative device class deeply	Findings mapped to exploitability, fleet impact, and remediation path

Do not begin with a generic policy document. Begin with devices that exist, ports that answer, firmware that is old, and credentials that still work.

Conclusion

The IoT threat landscape in 2026 is best understood as an infrastructure problem. Attackers want durable, cheap, geographically distributed nodes. Edge devices provide them. For connected-product companies and industrial operators, the defense is not a single malware signature. It is product design, asset visibility, exposure reduction, segmentation, and a realistic remediation process.

The question for every IoT device in 2026 is simple: if it is compromised, what can it become?

Sources

Service: IoT & Embedded Security Assessment
Solution: Supply-Chain Security Assessment
Research: IoT Supply-Chain Vulnerabilities - A Procurement and Architecture Framework for 2026
Glossary: SBOM · CVE · CVSS