{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidaa6lbwumreudsytkwk6xygx7zfsgvdtj46l72b4zi6chna7ykhm",
    "uri": "at://did:plc:rrwxywdlrz5fkwj5g4u4jnrk/app.bsky.feed.post/3mgsfmdstev72"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreigyk3hsjlnyyfpcascye3cznt722et4vf2e3zxiowpgmbwhhbuufy"
    },
    "mimeType": "image/jpeg",
    "size": 3288831
  },
  "path": "/article/4143100/why-zero-trust-breaks-down-in-iot-and-ot-environments.html",
  "publishedAt": "2026-03-11T11:00:00.000Z",
  "site": "https://www.csoonline.com",
  "tags": [
    "Access Control, Identity and Access Management, Security, Zero Trust",
    "Zero trust",
    "Zero trust assumes that trust is explicit, identity-centric and continuously enforceable.",
    "CISA",
    "The unified linkage model: A new lens for understanding cyber risk",
    "ULM focuses on consequences and connection",
    "Federal guidance from NIST",
    "ULM distinguishes three forms of linkage that matter operationally:",
    "Another reason zero trust struggles in OT environments is enforcement locality",
    "Want to join?"
  ],
  "textContent": "## Zero trust solves the wrong problem in OT\n\nZero trust has become the dominant security narrative of the past decade, and rightly so. Its core principles, never trust, always verify; assume breach; enforce least privilege, have reshaped how organizations think about identity, access and lateral movement. In enterprise IT environments, these principles have produced measurable gains. Identity is stronger. Access is more deliberate. Implicit trust has been reduced.\n\nYet when zero trust is applied to IoT and OT environments, results are uneven. Controls are deployed. Architecture diagrams look reassuring. Then, incidents occur. Occurring often through systems that were never considered part of the trust model in the first place.\n\nZero trust is designed to govern access decisions. In IoT and OT environments, most high-impact failures propagate through inherited trust and shared control paths, which are outside the scope of zero trust.\n\nThis is not an implementation failure. It is a model mismatch.\n\nZero trust assumes that trust is explicit, identity-centric and continuously enforceable. IoT and OT (and AI) systems violate all three assumptions by design. As a result, zero trust often governs the wrong surfaces while leaving the most consequential paths unmodeled.\n\n## The IoT and OT blind spot\n\nIoT and OT environments consistently exhibit three characteristics that create persistent security blind spots.\n\nFirst, visibility is incomplete by design. Devices are frequently deployed by facilities teams, engineering groups, or third-party integrators rather than security organizations. Asset inventories lag reality. Telemetry is sparse, proprietary, or intermittent. Many devices communicate only during specific operational states, leaving long periods of silence that security tools interpret as usual.\n\nCISA has repeatedly warned that unmanaged devices, limited visibility and legacy operational protocols remain among the most common weaknesses in IoT and OT environments, particularly where systems were never intended to be continuously monitored or centrally governed.\n\nSecond, networks are functionally flat even when they appear segmented. Broadcast discovery protocols, shared gateways and centralized controllers undermine isolation assumptions. Devices that never communicate directly can still influence one another through shared infrastructure. Segmentation exists on paper, but coupling persists in operation.\n\nThird, trust is implicit and durable. Devices trust controllers because they always have. Controllers trust management platforms because they are “authorized.” Cloud services trust device identities embedded in firmware. These trust relationships are rarely documented and infrequently revisited once systems are operational. Zero trust assumes trust can be challenged continuously. OT systems assume trust persists unless something breaks.\n\n## Why topology fails as a security model\n\nSecurity teams are trained to reason about topology: subnets, firewalls, zones and accesspaths. That approach works reasonably well in enterprise IT, where systems are designed around routable connectivity and explicit authentication.\n\nIt fails in IoT and OT environments because compromise does not propagate primarily through routed paths.\n\nIn The unified linkage model: A new lens for understanding cyber risk, I introduced a ULM as a way to analyze security risk based on functional relationships, adjacency, inheritance and trust, rather than solely on network topology. That distinction is critical in OT environments, where connectivity diagrams rarely reflect operational dependency.\n\nTwo systems can be completely isolated at the network layer and still be functionally inseparable. Shared controllers, protocol translators and management platforms create dependencies that topology does not capture. When one system changes state, whether through compromise, misconfiguration, or update, the other changes with it.\n\nULM focuses on consequences and connection. That focus is what zero trust lacks in OT contexts.\n\n## Where attacks actually travel\n\nMost IoT and OT breaches do not unfold as identity failures or segmentation bypasses. They propagate through shared controllers, inherited firmware, update mechanisms and management platforms — places where trust already exists.\n\nFederal guidance from NIST has long emphasized that firmware, update services and shared infrastructure represent durable sources of inherited risk that perimeter-focused controls do not address. These components sit beneath access controls and persist across reconfigurations, ownership changes and even vendor transitions.\n\nOnce compromised, they automatically propagate trust. No lateral movement is required. No credentials need to be stolen from downstream systems. The attacker moves with the grain of the architecture.\n\nThis is why incidents so often originate in building automation systems, maintenance interfaces, or vendor-managed services. These components are rarely monitored as security-critical assets, yet they act as connective tissue across environments that defenders believe to be isolated.\n\n## From zero trust to trust mapping\n\nZero trust governs access. It does not model consequence.\n\nDefenders, therefore, need to supplement zero trust with a way to understand how trust actually propagates in IoT and OT systems. The unified linkage model itself emerged from earlier work on linkage-driven risk propagation in enterprise and industrial environments, before being applied more directly to security decision-making in complex systems.\n\nULM distinguishes three forms of linkage that matter operationally:\n\n  * **Adjacency** , created by shared controllers, gateways, brokers and protocol translators\n  * **Inheritance** , created by firmware, SDKs, update services and vendor platforms\n  * **Trust propagation** , created by delegated management, implicit authorization and long-lived credentials\n\n\n\nThese linkages determine how failures cascade. Linkages show why devices perceived as low risk routinely serve as upstream enablers of disproportionate mission impact. They also explain why identity-centric controls frequently fail to interrupt attacks once trust has already been established.\n\nZero trust answers the question _“Who is allowed to talk to what?”_\n\nULM answers the question _“What changes if this component fails?”_\n\nBoth questions matter. They are not interchangeable.\n\n## Why enforcement centralizes in OT\n\nAnother reason zero trust struggles in OT environments is enforcement locality.\n\nOT systems prioritize determinism, availability and safety. Control loops cannot pause for policy evaluation. Latency matters. Devices cannot tolerate frequent reauthentication or telemetry overhead. As a result, enforcement is pushed outward — to gateways, management platforms and cloud services.\n\nThese enforcement points become chokepoints. Once trusted, they are rarely revalidated. If compromised, they bypass every downstream zero-trust assumption simultaneously.\n\nZero trust assumes enforcement is everywhere. OT systems centralize it.\n\n## What security leaders should do differently\n\nThis is not a call to abandon zero trust. It is a call to scope it correctly.\n\nZero trust remains effective where identities are strong and enforcement is continuous. In IoT and OT environments, leaders must also account for inherited trust and centralized control paths that zero trust does not model.\n\nThat means mapping functional dependencies explicitly. It means identifying which components propagate trust across domains. It means disproportionately protecting management planes, update mechanisms and protocol gateways, not because they are attractive targets, but because they are structural amplifiers.\n\nIt also means rethinking vendor risk. Suppliers should be evaluated not just on what they deliver, but on how much trust they inherit and propagate across systems once integrated.\n\n## The real risk is what you’re not modeling\n\nZero trust addresses access decisions. It does not explain how compromise spreads once trust already exists. In OT environments, that distinction is decisive.\n\nLinkage-based analysis fills that gap. By making adjacency, inheritance and trust explicit, it exposes the invisible network beneath IoT and OT systems. For security leaders responsible for operational resilience, that visibility is leverage.\n\nIoT and OT security failures persist not because defenders lack tools, but because they rely on models that no longer reflect reality.\n\n**This article is published as part of the Foundry Expert Contributor Network.\nWant to join?**",
  "title": "Why zero trust breaks down in IoT and OT environments"
}