Designing zero trust architectures for clients running thousands of IoT devices changes how you think about “the network”. These aren’t laptops and servers sitting behind a predictable boundary. They’re sensors tracking warehouse capacity, systems automating movement of stock, retail analytics devices counting footfall and interaction—tiny computers scattered across physical spaces, often deployed faster than they can be governed.

The problem isn’t that IoT is inherently insecure. It’s that it’s inherently uneven. You’re dealing with a mixed ecosystem of manufacturers, firmware baselines, protocols, and operational ownership, and then you’re expected to treat the whole thing like a coherent fleet.

The two things that make IoT hard

IoT security tends to break down for two reasons that reinforce each other: heterogeneity and constraint.

Heterogeneity means there’s no “standard workstation build” equivalent. Some devices are cheap sensors with barely enough CPU to function. Others are complex embedded systems running an OS you’d recognise. Some speak modern protocols. Others speak whatever the vendor shipped and never meaningfully updated. That diversity makes blanket controls brittle, and brittle controls become exceptions, and exceptions become your attack surface.

Constraint is the second part. Many IoT devices are simply not built to carry heavyweight security features. You can’t assume agent-based endpoint protection. You can’t assume full-dress cryptography with generous key sizes and frequent handshakes. You often can’t even assume decent logging. Security architecture has to work with what’s there, which means designing controls that are lightweight, enforceable, and—most importantly—operable.

Patching is necessary, but it’s not a strategy

Firmware updates are the obvious baseline. They matter, and they’re still one of the most effective ways to remove known vulnerabilities from the fleet. But firmware updates are also where IoT security goes to die in practice, because they rely on two things that are often missing: user discipline and vendor support.

Plenty of devices don’t get updated because operations teams are understandably cautious about bricking equipment or disrupting a production environment. Plenty of devices don’t get updated because the manufacturer stops shipping updates, or only ships them through awkward tooling that never made it into operational routines. The result is an estate where known vulnerabilities persist for years, not because the organisation “doesn’t care”, but because the ecosystem isn’t designed for secure lifecycle management.

Encryption is essential, even when it hurts

Encryption is critical for protecting data in transit between devices, gateways, and control platforms. In IoT, though, “just encrypt everything” quickly collides with reality: constrained CPUs, limited memory, battery budgets, and sometimes protocols that weren’t designed with modern cryptographic expectations.

This is why lightweight cryptography matters. But the bigger point is architectural: if a device can’t do robust crypto, you need compensating design. That can mean pushing secure termination to a gateway, minimising what the device transmits, and ensuring the rest of the system treats device-originated data as untrusted until validated. In other words, don’t let weak devices drag your whole trust model down with them.

Segmentation is your blast-radius control

Network segmentation remains one of the most pragmatic, high-impact controls for IoT. It doesn’t “secure the device”, but it limits what a compromised device can reach, and that’s usually what matters when attackers land. IoT devices are often used as footholds, not final objectives.

The trick is that segmentation can’t be a one-off VLAN exercise anymore. Estates change. Warehouses expand. Stores get refitted. Devices move. If segmentation isn’t aligned to identity, function, and expected communication paths, it becomes either too permissive to be useful or too restrictive to operate. In mature environments, segmentation becomes policy-driven and continuously maintained, because static segmentation decays.

The shiny new ideas: blockchain and AI

Blockchain-based authentication gets proposed frequently in IoT because it sounds like the perfect fit: decentralised identity, tamper-evident records, and a ledger that can prove what happened. The reality is more nuanced. The underlying goal—strong device identity and non-repudiation of interactions—is valid. The open question is whether blockchain is the simplest way to achieve it at scale, given the overhead, integration complexity, and the fact that most IoT programmes struggle with fundamentals like inventory and key management long before they need distributed ledgers.

AI-driven threat detection is the other recurring promise: anomaly detection across device behaviour, spotting compromised sensors, detecting lateral movement patterns in near real time. The idea is sound, but the results in the real world are mixed, largely because the hardest problem isn’t the model—it’s the data. IoT telemetry is messy, inconsistent, and often missing the context needed to distinguish “weird but normal” from “weird reported to incident response”.

There’s also an organisational truth here: AI doesn’t replace ownership. Even if anomaly detection flags something, you still need a team who can interpret it, validate it, and act without taking down operations unnecessarily. Many “AI for IoT security” solutions fail because they optimise for detection demos rather than operational decision-making.

What actually works in practice

The most effective IoT security programmes I’ve seen don’t start with blockchain or AI. They start with boring, foundational discipline: asset inventory that’s accurate, lifecycle management that’s enforced, identity that’s real, segmentation that’s maintained, and a trust model that assumes compromise is inevitable somewhere in the fleet.

If you treat IoT as “endpoints, but smaller”, you lose. If you treat IoT as an untrusted, constrained edge that must be controlled through architecture—identity, policy, isolation, and continuous validation—you end up with something survivable.

That’s the real IoT security challenge: not inventing exotic controls, but designing a system where the weakest devices don’t get to define the security posture of the whole business.