Zero trust solves the wrong problem in OT
Zero 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.
Yet 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.
Zero 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.
This is not an implementation failure. It is a model mismatch.
Zero 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.
The IoT and OT blind spot
IoT and OT environments consistently exhibit three characteristics that create persistent security blind spots.
First, 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.
CISA 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.
Second, 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.
Third, 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.
Why topology fails as a security model
Security 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.
It fails in IoT and OT environments because compromise does not propagate primarily through routed paths.
In 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.
Two 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.
ULM focuses on consequences and connection. That focus is what zero trust lacks in OT contexts.
Where attacks actually travel
Most 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.
Federal 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.
Once 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.
This 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.
From zero trust to trust mapping
Zero trust governs access. It does not model consequence.
Defenders, 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.
ULM distinguishes three forms of linkage that matter operationally:
- Adjacency, created by shared controllers, gateways, brokers and protocol translators
- Inheritance, created by firmware, SDKs, update services and vendor platforms
- Trust propagation, created by delegated management, implicit authorization and long-lived credentials
These 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.
Zero trust answers the question “Who is allowed to talk to what?”
ULM answers the question “What changes if this component fails?”
Both questions matter. They are not interchangeable.
Why enforcement centralizes in OT
Another reason zero trust struggles in OT environments is enforcement locality.
OT 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.
These enforcement points become chokepoints. Once trusted, they are rarely revalidated. If compromised, they bypass every downstream zero-trust assumption simultaneously.
Zero trust assumes enforcement is everywhere. OT systems centralize it.
What security leaders should do differently
This is not a call to abandon zero trust. It is a call to scope it correctly.
Zero 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.
That 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.
It 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.
The real risk is what you’re not modeling
Zero trust addresses access decisions. It does not explain how compromise spreads once trust already exists. In OT environments, that distinction is decisive.
Linkage-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.
IoT and OT security failures persist not because defenders lack tools, but because they rely on models that no longer reflect reality.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?