Past the Device: Securing IoT and Autonomous Systems

What this guide covers

A decade of checklists, and the failure they didn’t fix
The real shape of the problem: it was never just the device
The maturity model: device, system, autonomous system
Tier one: the failures that never left
Tier two: what changes when you stop treating IoT as endpoints
Tier three: when AI starts acting on what the devices say
The governance problem, still unresolved a decade later
The practical baseline: questions to ask of your estate
The honest close: what a maturity model can’t promise you

01 — THE FRAME

A decade of checklists, and the failure they didn’t fix

In March 2026, the U.S. Department of Justice, working with police in Canada and Germany, took down the command-and-control infrastructure behind four botnets called Aisuru, KimWolf, JackSkid and Mossad. Between them they’d infected more than three million devices: routers, DVRs, webcams, off-brand Android streaming boxes. The largest attack they launched hit 31.4 terabits per second and lasted 35 seconds. Cloudflare’s threat team described the traffic volume as roughly the entire populations of the UK, Germany and Spain typing a web address and hitting enter at the same instant.

Here’s the part worth sitting with. The way these devices got infected was not new. Default credentials. Firmware nobody patched. Routers and cameras exposed to the open internet with no segmentation behind them. It’s the same recipe that built the Mirai botnet in 2016, the one that took down Dyn’s DNS infrastructure and briefly broke half the internet. A decade of “secure the device” guidance sat between those two events, and the failure mode didn’t change. Only the scale did: Mirai’s biggest attack against Dyn ran to roughly 1.2 terabits per second. Aisuru’s biggest ran to 31.4. Same playbook, twenty-five times the punch, ten years apart.

That’s the uncomfortable starting point for this guide. If you go looking for the classic IoT security literature, most of it reads like a checklist written for a smaller, calmer internet: change the default password, encrypt the data, patch the firmware, log the activity. The advice isn’t wrong. It’s exactly right, in fact, which is what makes the last decade so damning. We knew the answers and the answers didn’t stick, because the thing that failed was never really about any single device. It was about how the whole system around the device was built, owned, and, increasingly, who or what is now allowed to act on it.

Ten years of “secure the device” advice produced a botnet twenty-five times more powerful than the one that started the genre. The lesson isn’t that the advice was wrong. It’s that the device was never the actual unit of the problem.

This guide takes a different starting point. Instead of another list of things to lock down, it gives you a way to read your own estate: a maturity model with three tiers, device, system, and autonomous system, that tells you not just what’s exposed but what kind of exposure you’re carrying and what a serious response actually looks like at each level. Most organisations are stuck fighting tier one with tools built for it a decade ago. Very few have reached tier two. Almost nobody is ready for tier three, and tier three is already live in production, because the same AI agents reshaping every other part of the enterprise are now being pointed at the telemetry these devices produce.

02 — THE REAL SHAPE OF THE PROBLEM

It was never just the device

Ask most security teams to name their IoT risk and they’ll describe a device: an unpatched camera, a smart sensor with a default password, a badge reader nobody’s updated since installation. That instinct isn’t wrong, it’s just years out of date. The device is the part of the system you can see. It is rarely the part that actually gets exploited to cause damage.

A connected device on its own does almost nothing interesting to an attacker. What makes it worth compromising is everything it talks to: the network it rides on, the data backplane that aggregates what it reports, the cloud service that stores and processes that data, the APIs that let other systems query it, and the identities, human and increasingly machine, that are allowed to act on what it says. Compromise the camera and you get a camera. Compromise the pipeline the camera feeds into and you get a foothold in the business.

Compromise the camera and you get a camera. Compromise the chain it feeds and you get the business. The device was always the cheapest, least interesting part of the system to attack.

Two things have changed since the device-centric era of IoT advice, and both make the chain longer, not shorter. First, scale: there are now roughly 21 to 22 billion connected devices online globally, on course to pass 30 billion before the end of the decade, according to IoT Analytics’s ongoing tracking. Every one of those devices sits at the front of a chain like the one above. Second, and this is the part the old advice has nothing to say about: the far end of that chain increasingly isn’t a human dashboard. It’s an AI agent, reading the telemetry, correlating it, and in a fast-growing number of deployments, acting on it directly.

That second shift is the reason a straight refresh of the old checklist won’t do. “Secure the device” was always a proxy for the real goal, which is secure the decisions that get made from what the device reports. For most of the last decade those decisions were made by people, slowly, with a human somewhere in the loop. That’s no longer a safe assumption, and the security model has to catch up with the assumption that’s replacing it.

03 — THE MATURITY MODEL

Device, system, autonomous system

Here is the framework this guide is built on, and the one thing worth taking away if you read nothing else. Every organisation’s IoT security posture sits at one of three maturity tiers, and the tiers are cumulative: you cannot skip to tier three by buying a product, you have to actually clear tier one and two first, or you’re building autonomous decision-making on top of a foundation that was never solid.

Each tier assumes the one below it is solid. Deploying an AI agent against telemetry from a tier-one estate doesn’t add a layer of risk, it multiplies the ones already there.

Tier one, securing the device, is the classic discipline: credentials, patching, encryption, logging, the fundamentals that were correct a decade ago and remain correct today. Most organisations sit here, and most sit here imperfectly, which is exactly what the Aisuru case demonstrates at internet scale.

Tier two, securing the system, is where the chain from the last section gets treated as a chain: protocols and interoperability, API security, identity and access management for both users and devices, application security across the software stack that touches the device, penetration testing of the whole ecosystem rather than the device in isolation, and above all, clear ownership of the problem end to end. Comparatively few organisations have genuinely reached this tier. It requires cross-functional authority that most security teams still don’t have.

Tier three, securing the autonomous system, is the tier this guide exists to name, because almost no other IoT security literature does. It’s what happens when an AI agent, not a person, is the thing reading the telemetry, correlating the alerts, and in a growing number of deployments, taking the next action. Government guidance on this only started arriving in the last several months. Almost nobody has caught up, and the gap between where the risk now sits and where most defensive programmes are looking is the central argument of this guide.

The rule this model gives you

Don’t ask “is our IoT secure.” Ask “which tier are we actually operating at, and does our tier-three exposure exceed our tier-one foundation.” Most breaches in the next few years will happen exactly there: an AI agent given real authority over an estate that never finished tier one.

04 — TIER ONE

The failures that never left

Start here because most estates still haven’t finished it, and because the case for taking it seriously has never been more concrete than it is right now, courtesy of a federal indictment.

Default and unpatchable credentials

This is the single most repeated failure in every major IoT botnet from Mirai through Aisuru, a full decade of the exact same door being left open. Devices ship with a default password, the password often can’t be changed at all, or it’s changed but never rotated, and firmware patching either doesn’t exist as a capability or arrives over an unencrypted, unsigned channel that’s itself an attack path. Aisuru’s operators didn’t need a novel technique. They scanned the internet for the same weak logins that worked in 2016, at a scale that reflects how many billions more devices there now are to find.

Weak or absent encryption

Data in motion and at rest across IoT deployments still gets encrypted inconsistently, particularly in industrial and infrastructure settings where teams worry, often wrongly, that encryption overhead will hurt device performance. Weak crypto is still weak crypto whatever the performance justification. The fix hasn’t changed: proven algorithms, the maximum key size the hardware will bear, and encryption key life-cycle management that’s actually managed rather than assumed.

Insufficient activity logging

Fortinet’s 2026 State of Operational Technology and Cybersecurity report found that full visibility into OT assets has actually fallen since 2022, from 61 percent of organisations down to 30 percent in 2025, before recovering slightly to 14 percent reporting full visibility in the most recent survey wave. Read that again: visibility got worse as the estate got bigger. You cannot secure, or hand to an AI agent, what you cannot see.

Sources: attack-size figures as reported by Cloudflare’s Cloudforce One threat research and DOJ court filings (District of Alaska, March 2026). Not to a linear scale; illustrative of relative magnitude.

What actually changed the calculus in 2026

Two things now put real teeth behind tier-one hygiene that didn’t exist a decade ago. First, regulation: the EU’s Cyber Resilience Act starts requiring manufacturers to notify vulnerabilities and incidents from September 2026, with full conformity obligations following, and non-compliant connected products simply won’t be sellable in the EU after that. Second, law enforcement capability: the Aisuru takedown involved the DoD’s own investigative service, the FBI, and close to two dozen technology companies coordinating together, a level of cross-industry response that didn’t exist when Mirai hit. Tier one is no longer just good practice. It’s becoming a market-access requirement with an increasingly credible enforcement arm behind it.

05 — TIER TWO

What changes when you stop treating IoT as endpoints

Tier two is where an organisation stops securing individual devices and starts securing the system those devices belong to. It’s a genuinely different discipline, not just tier one done harder, and it’s where most programmes stall.

Protocols and interoperability

The alphabet soup of IoT communication protocols, MQTT, CoAP, Zigbee and the rest, hasn’t gone away, and neither have the vulnerabilities baked into some of them. What’s changed is the answer: a zero trust posture that assumes every device and every protocol hop is untrusted until proven otherwise, with encryption and segmentation applied uniformly rather than protocol by protocol. Segmentation in particular is doing more work than it gets credit for. It’s the difference between a compromised sensor and a compromised production line.

Unprotected APIs

Every IoT deployment of any real size now runs on a web of RESTful APIs connecting gateways, edge devices, analytics platforms and enterprise systems, and those integration points are frequently the least-assessed part of the whole estate. Security teams that have thoroughly hardened the device and the network still routinely wave the APIs through, because API ownership sits with a development team the security function doesn’t fully control. This is precisely the kind of gap that tier-three AI agents will find and use, because agents are relentless, systematic API consumers by design.

Identity, for devices as much as people

Full lifecycle identity management, provisioning, access policy, deprovisioning, needs to exist for devices the same way it exists for employees, including the messy edge cases: a device changing ownership in the aftermarket, a returned consumer product, a contractor’s access being revoked without anyone remembering the three sensors registered under their account. Most organisations have built identity discipline for people. Almost none have built it with the same rigour for the billions of devices now asking for access.

Application security and independent testing

IoT is a software problem wearing hardware’s clothes: the device firmware, the cloud backend, the mobile app that talks to the device, all of it is code, and all of it needs the secure development and testing discipline any other software gets, adapted for the fact that traditional pre-release testing tools don’t map cleanly onto embedded and constrained devices. Ongoing, adversarial penetration testing of the full ecosystem, not a one-off assessment of the factory-default configuration, is what actually surfaces what a real attacker would find.

The tier-two test

If your security team can name every device on the network but not every API those devices’ data flows through, you’re still at tier one wearing tier-two language. The system, not the device, is the actual unit of defence.

06 — TIER THREE

When AI starts acting on what the devices say

This is the tier the 2017 generation of IoT security advice had nothing to say about, because it didn’t exist yet, and it’s why a faithful refresh of that older advice would leave you defending yesterday’s estate. It is not a future risk to plan for eventually. It’s already production infrastructure.

The shift already underway

Google Cloud’s 2026 AI Agent Trends research, surveying more than 3,400 enterprise decision-makers, describes security operations moving from alerts to action: AI agents that don’t just flag an anomaly but pursue a multi-step response, coordinating tools and taking steps autonomously as new information arrives. Separately, a 2026 survey of over 900 executives and practitioners found 80.9 percent of technical teams already past the planning stage into active testing or production deployment of AI agents, while only 14.4 percent reported those agents going live with full security and IT approval. That gap, adoption racing ahead of governance, is the defining fact of this tier.

Why OT and IoT are a special case, not a generic one

An AI agent misreading a marketing dashboard is an inconvenience. An AI agent misreading operational technology telemetry, or worse, acting directly on it, has physical consequences: a safety-instrumented system that trips or doesn’t, a valve that opens, a production line that halts. That distinction is exactly why, between December 2025 and May 2026, CISA, the NSA and their Five Eyes international partners published three separate pieces of joint guidance on this problem in rapid succession: principles for AI in OT environments, secure connectivity principles for OT, and the first Five Eyes guidance specifically addressing agentic AI. Their central technical judgment is worth quoting almost verbatim, because it cuts against the instinct to just bolt an agent onto an existing OT environment and see what happens: large language models should not be trusted to make safety decisions in OT environments, and that limit holds even when the system in question is judging its own safety.

The reasoning behind that limit matters. An AI agent’s behaviour is the output of a model that can be manipulated by what it’s fed, which means a malicious instruction hidden in a log entry, a document, or a tool’s response can redirect what the agent does next. The industry’s own emerging standard, the OWASP Top 10 for Agentic Applications, names exactly this: agent behaviour hijacking, tool misuse, and identity and privilege abuse sit among the most critical risks for autonomous systems, precisely because you can’t build a safety control on top of behaviour that the attacker can influence. The practical implication is one that OT security engineers have started converging on independently of any vendor’s product pitch: enforce the agent’s boundaries at the network layer, through identity-based segmentation defined by what a device does rather than which port it’s plugged into, not through trusting that the agent will behave.

The stakes if you get this wrong at scale

Dragos’s 2024 Year in Review counted 1,693 ransomware attacks against industrial organisations, an 87 percent increase year over year, with 75 percent of those incidents causing at least a partial operational shutdown. That’s the baseline threat tier-three exposure is being layered on top of. An AI agent with broad, poorly-governed access into that environment isn’t a hypothetical new risk category. It’s a faster, more automatable path into a threat surface that was already deteriorating before agents arrived.

The tier-three principle

Treat every AI agent with access to IoT or OT data as an untrusted, unpredictable connection into an environment where failure has physical consequences. Its boundaries belong at the network layer, enforced by identity and segmentation, not in the agent’s own judgment about what it should or shouldn’t do.

07 — THE GOVERNANCE PROBLEM

Still unresolved a decade later

If there’s one issue that has genuinely not changed at all since the earliest IoT security research, it’s this: nobody has settled who owns the problem, and the pace of change since has made the confusion worse rather than better.

The direction of travel looks encouraging on the surface. Fortinet’s most recent survey found the share of organisations assigning OT cybersecurity responsibility to the CISO or CSO has climbed from just 16 percent in 2022 to over half today, with the large majority intending to complete that consolidation within the next year. That sounds like progress toward clear ownership. But PwC’s 2026 Global Digital Trust Insights report, surveying the same landscape, found 39 percent of organisations still report a lack of governance and clear responsibility for OT and IoT cybersecurity specifically, and 40 percent report they don’t fully understand the scope of the risk they’re supposed to be governing. Ownership is moving toward the CISO in name faster than the underlying clarity about what that ownership actually covers is moving with it.

The EU’s Cyber Resilience Act has, if anything, exposed how unresolved this still is rather than resolved it. Survey data on how organisations are assigning responsibility for CRA compliance shows it scattered across product managers, compliance managers, CISOs, cybersecurity analysts and heads of software development in roughly even proportions, no single role capturing even a fifth of the responsibility, and close to a third of surveyed organisations having formed no dedicated group to own it at all. A regulation with real financial penalties, up to 15 million euros or 2.5 percent of global revenue, still hasn’t produced clear internal ownership.

Layer AI governance on top and the picture gets worse before it gets better. A 2026 CISO AI risk survey found 92 percent of respondents lack full visibility into the AI identities operating inside their own environment, and 95 percent doubt they could reliably detect or contain misuse of an AI system if it happened. That’s the governance foundation tier-three IoT security is currently being built on: not absent exactly, but thin, contested, and racing to keep pace with a technology moving faster than any prior wave.

What actually works

The organisations making real progress aren’t waiting for a perfect org chart. They’re standing up a genuine cross-functional governance body, security’s own leadership together with empowered representation from every business unit that touches the connected estate, with explicit authority to slow a launch on security grounds rather than being consulted after the decision’s made. And they’re treating AI agent access to OT and IoT data as its own governed category from day one, not an extension of existing IT AI policy, because the consequences of getting it wrong aren’t the same.

The governance test

Ask who in your organisation can currently say no to an AI agent being connected to OT or IoT telemetry, and have that decision stick. If the honest answer is “nobody, really,” you’ve found your actual governance gap, whatever the org chart says.

08 — THE PRACTICAL BASELINE

Questions to ask of your estate

This is the working checklist, organised by tier so you can locate where your genuine exposure sits rather than treating every item as equally urgent.

Tier one: the device

Can every device on our estate have its default credentials changed, and are we verifying that it’s actually been done, not just that the policy exists on paper?
Can we patch firmware over the air, signed and over an encrypted channel, and is it technically impossible to disable that patching mechanism?
Is data encrypted in motion and at rest with proven algorithms and real key-lifecycle management, or have we quietly accepted weaker crypto somewhere for performance reasons?
Do we have genuine visibility into device activity across the whole estate, not the subset that happens to report into a dashboard someone remembered to build?

Tier two: the system

Have we assessed every API our IoT data flows through, including the ones owned by a development team outside security’s direct control?
Do we manage device identity with the same rigour as user identity, including the aftermarket, ownership-transfer, and deprovisioning edge cases?
Is our network genuinely segmented so that a compromised device can’t reach a safety-critical system, verified by testing rather than assumed from the network diagram?
Do we run ongoing, adversarial testing against the full ecosystem, not a point-in-time assessment of the factory-default configuration?

Tier three: the autonomous system

Does any AI agent currently have access to our IoT or OT telemetry, and can we name it, its scope, and who approved it? If the honest answer is uncertain, that uncertainty is itself the finding.
Are that agent’s boundaries enforced at the network layer through identity-based segmentation, or does the control rely on trusting the agent’s own judgment about what it should do?
Have we explicitly excluded AI agents from making safety-critical decisions in OT environments, in line with current CISA, NSA and Five Eyes guidance, rather than assuming a capable model is a safe one?
Is AI agent access to OT/IoT data governed as its own category, with its own risk owner and its own approval path, rather than folded into a general AI usage policy that wasn’t written with physical consequences in mind?

How to use this list

Don’t try to answer all twelve questions at once. Answer the four tier-one questions honestly first. If any answer is genuinely no, that’s this quarter’s work, whatever tier-three ambitions are on the roadmap. You cannot govern the autonomous system on top of a device layer that’s still leaking.

09 — THE HONEST CLOSE

What a maturity model can’t promise you

I won’t pretend this framework makes the problem simple. It doesn’t. The connected estate is heading toward 30 billion devices by 2030 on current trajectories, the failure modes that built Mirai are still the failure modes that build the botnets making headlines this year, and the governance structures meant to own all of it are, by the industry’s own survey data, still genuinely unresolved for a third to two-fifths of organisations depending on which report you read.

What the maturity model does give you is a way to stop asking the wrong question. “Is our IoT secure” invites a checklist answer and a false sense of completion. “Which tier are we actually operating at, and where’s the gap between our tier-one foundation and our tier-three ambition” invites an honest one, and an honest answer is the only kind that actually changes what happens next.

The device was never the unit of risk. The system was. Now the system has a new occupant reading its telemetry and, in a fast-growing number of cases, acting on it. Secure the layer that occupant depends on, not just the layer it was named after.

This is, in the end, the same story running through most of the current conversation about AI and how organisations are built to withstand it: concentration and dependency quietly outpacing the governance meant to hold them in check. A connected estate built without device discipline, without system-level ownership, and now handed to an AI agent without tier-three governance, isn’t three separate problems. It’s one problem, compounding at each layer, and the compounding is exactly why the failures that seemed containable in 2017 are the ones making federal indictments in 2026.

Start with tier one, honestly assessed. Build toward tier two with real cross-functional ownership, not an org chart that reassigns a title without changing what’s actually governed. And before any AI agent gets access to what your connected devices are telling you, ask who can say no to that access and make it stick. That’s the whole of the advice, and unlike the checklist genre this guide replaces, it’s built to still be true in five years.

Past The Device - a working guide to securing IoT in the age of autonomous systems.

The opinions here are a point of view; the guidance is grounded in current reporting including the U.S. Department of Justice's March 2026 disclosure on the Aisuru, KimWolf, JackSkid and Mossad botnet takedown, Cloudflare's Cloudforce One threat research, joint CISA/NSA/Five Eyes guidance on AI in operational technology (December 2025–May 2026), the OWASP Top 10 for Agentic Applications, Dragos's industrial ransomware research, Fortinet's State of Operational Technology and Cybersecurity report, PwC's Global Digital Trust Insights, and IoT Analytics's device-count tracking. Figures are directional and current as of 2026; the landscape moves quickly, so treat the maturity model as durable and the specific numbers as a snapshot. This guide pairs with The Fork in the Road, our companion field guide on AI and the future of work: the same concentration-and-dependency story runs through both.