What breaks when organisations try to enforce zero trust uniformly across OT and legacy industrial systems?

Uniform enforcement can disrupt production, block essential device communications, and create unsafe conditions if older controllers or proprietary protocols cannot support modern identity checks. The result is often brittle security that operators work around. A better approach is to introduce zero trust in layers, preserving safety and availability while reducing trust at the edges.

Why Uniform Zero Trust Fails in OT and Legacy Environments

Uniform zero trust sounds tidy in policy documents, but OT and legacy industrial systems were not designed around modern identity, continuous authentication, or frequent policy decisions. In practice, availability and safety often depend on fixed device-to-device relationships, deterministic timing, and protocols that cannot tolerate repeated control-plane checks. For that reason, the same control pattern that improves posture in enterprise IT can break production when applied without adjustment to industrial networks. NIST’s NIST SP 800-207 Zero Trust Architecture is useful here because it clarifies that zero trust is an architecture to adapt, not a single switch to flip. In practice, many security teams discover these constraints only after an enforcement change has already interrupted a process line or forced operators to bypass controls.

The core issue is that OT risk is not shaped only by confidentiality. It is also shaped by process stability, real-time control, and the safety consequences of dropped sessions or delayed commands. Legacy industrial assets may have weak authentication options, vendor-specific protocols, or no practical way to support per-request identity evaluation. When organisations try to force uniform enforcement across those systems, they often create a gap between the policy design and the plant reality.

What Actually Breaks When the Policy Meets the Plant

Zero trust implementation usually fails at the boundary where identity controls meet deterministic operations. A controller, historian, engineering workstation, or remote maintenance channel may rely on fixed allowlists, shared credentials, or protocol behavior that was never intended to be challenged on every transaction. If the enforcement model assumes modern device posture, user authentication, or microsegmentation at every step, then legitimate traffic can be blocked or slowed enough to interfere with production.

The breakdown is often operational rather than technical in the abstract. A plant may lose visibility into critical devices because the monitoring path is segmented too aggressively. A maintenance workflow may fail because a vendor session cannot satisfy the same access policy used for office users. A safety-related communication path may be interrupted because a legacy controller cannot speak the new authentication language. That is why the question is not whether zero trust is useful, but where and how it can be applied without damaging the process it is meant to protect.

Essential machine communications can be interrupted when policies do not match protocol constraints.
Operators may create exceptions or informal workarounds when controls are too brittle for plant uptime.
Legacy assets may remain unmanaged if the rollout assumes capabilities they do not possess.
Safety and availability can degrade if access enforcement is placed in the wrong layer.

Modern identity controls can still help, but they need to be introduced around the constraints of industrial environments rather than over them. NIST SP 800-53 Rev. 5 Security and Privacy Controls is relevant because it supports control selection and tailoring, which matters when the environment includes assets that cannot all support the same mechanism. The guidance breaks down when organisations assume every device can be treated like a managed enterprise endpoint.

Where the Edge Cases Sit: Safety Systems, Vendor Access, and Legacy Protocols

Tighter enforcement often increases operational friction, requiring organisations to balance stronger access control against uptime, maintainability, and safe recovery. That tradeoff becomes most visible in environments with safety instrumented systems, vendor-supported equipment, or deeply embedded legacy protocols. In those settings, the right answer is often not “apply the same control everywhere,” but “apply different controls to different trust zones with clear operational exceptions.”

There is also a consensus gap in the industry: many teams agree on the direction of zero trust, but not on how aggressively to apply it to OT segments that cannot tolerate disruption. Some assets can support network segregation, jump-host mediation, or tightly governed remote access. Others can only be protected by surrounding compensating controls, stronger monitoring, and strict change governance. The practical mistake is to treat these cases as if they only differ by age. They differ by failure consequence.

That is why identity guidance such as NIST SP 800-63 Digital Identity Guidelines is only partially transferable to OT. It helps where human authentication and assurance levels matter, but it does not solve the deeper issue of devices and protocols that cannot participate in the same trust model. Organisations that ignore this distinction often end up with a paper design that is sound in theory and unsafe in operation.

Risk and Threat Considerations

The material risk is not just failed rollout. In OT, overly uniform zero trust enforcement can create availability loss, unsafe process states, and blind spots that reduce resilience instead of improving it. The threat side is equally important: when legitimate access becomes unreliable, operators and vendors tend to seek bypasses, which can expand the attack surface and make remote access harder to govern.

Failure mechanism: The control fails when modern identity checks, session mediation, or segmentation rules are imposed on assets and protocols that cannot support them. That creates dropped communications, broken maintenance paths, or local exceptions that become standing workarounds.

Impact: Production can stop, recovery can become slower, and safety-relevant communications can be disrupted. Over time, the organisation may gain the appearance of stronger policy while actually increasing unmanaged access paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	OT zero trust depends on tailoring access control to critical operational assets.
Recommendation — Tailor access policies to OT zones so essential communications remain available.
CIS Controls v8	6 — Access Control Management	The question centers on access enforcement breaking operational workflows and exceptions.
Recommendation — Segment access paths and remove standing exceptions that undermine enforced policy.
NIST AI RMF	GV.4 — AI Risk Management Culture	No direct AI subject is present, so this is not selected.
NIST Zero Trust (SP 800-207)	ID — Identity-oriented access decisions	Zero trust must be adapted to legacy OT identity and communication constraints.
Recommendation — Apply zero trust only where identity checks can be enforced without disrupting process control.
MITRE ATT&CK	T1021 — Remote Services	Remote vendor and maintenance access is a common exposure point in OT enforcement failures.
Recommendation — Harden remote access paths and monitor for abuse of maintenance channels.

Practitioner Guidance

What to prioritise: Separate “where the policy applies” from “where the process cannot tolerate interruption.” In OT, the first design decision is usually zoning and dependency mapping, not user policy tuning.

Decision rule: If a device, protocol, or workflow cannot support the proposed enforcement method without affecting timing, availability, or vendor support, treat it as a compensating-control case rather than forcing uniform enforcement.

What to verify: Validate which communications are operationally essential, which are safety-related, and which can tolerate authentication or segmentation changes. The key test is whether the control can fail safely, not whether it looks strong on paper.

Common mistake: Treating legacy industrial assets like ordinary endpoints and expecting the same identity model to work everywhere. That usually leads to brittle controls, exception sprawl, or unsafe bypass behavior.

Practitioner takeaway: The best zero trust rollout in OT is usually the one that reduces trust without breaking deterministic operations; if the control damages uptime or safety, it is mis-sized for the environment.