What breaks when legacy identity systems are ignored in OT zero trust programmes?

Why This Matters for Security Teams

OT zero trust programmes fail when identity is treated as a greenfield problem. Legacy directories, shared operator accounts, service credentials, and embedded device identities often still govern real access paths. If those sources are ignored, the programme may look modern on paper while production control points continue to rely on exceptions, static trust, and undocumented approvals. That gap undermines segregation of duties, incident response, and auditability.

The practical issue is not simply technical debt. It is that OT environments often depend on long-lived identities tied to maintenance windows, vendor support, plant-floor tooling, and safety processes. A zero trust design that does not reconcile those dependencies can force teams into workarounds that bypass policy entirely. NIST SP 800-207 Zero Trust Architecture is clear that trust decisions should be continuous and policy-driven, but the policy only works if the identity sources behind it are complete and governed.

In practice, many security teams encounter hidden legacy access paths only after a maintenance outage, vendor dispute, or audit finding has already exposed the control gap.

How It Works in Practice

In OT, identity is often distributed across human users, jump hosts, local device accounts, historian integrations, engineering workstations, and vendor remote access channels. A zero trust programme that ignores legacy identity systems usually ends up layering new controls on top of old ones instead of replacing them. That creates duplicate entitlements, inconsistent enforcement, and uncertain provenance for who approved what. It also makes it harder to validate session context, especially where production uptime limits how aggressively authentication can change.

Practical implementation starts with an identity inventory that includes all active directories, local accounts, shared credentials, certificates, and service identities used by OT and adjacent IT services. Then the team maps which identities are authoritative for each access path, which are temporary exceptions, and which can be retired. Controls should align to least privilege, device posture, and conditional access where the environment supports it. NIST SP 800-53 Rev 5 Security and Privacy Controls is especially useful for mapping access control, audit logging, account management, and system integrity requirements into operational procedures.

• Identify every identity source that can still authenticate to OT-relevant systems.
• Separate permanent access from break-glass and vendor emergency access.
• Retire shared accounts where feasible, or place them under compensating controls.
• Log identity changes and access grants in a way that SOC and plant operations can both review.
• Test whether policy enforcement still works when the legacy directory is offline or delayed.

Where organisations connect OT into a broader enterprise security stack, they should also consider how identity events feed monitoring, incident response, and privileged access workflows. That means aligning directory governance, PAM, and session oversight rather than assuming a single new platform will absorb all access dependencies. These controls tend to break down when plants rely on offline authentication caches and vendor-managed local accounts because policy engines cannot reliably see or govern the true source of access.

Common Variations and Edge Cases

Tighter identity control often increases operational friction, requiring organisations to balance stronger assurance against maintenance speed and uptime constraints. That tradeoff is most visible in plants with aging controllers, third-party integrators, or safety-critical systems where authentication changes can disrupt support processes. In those environments, best practice is evolving rather than universally settled, and current guidance suggests phased containment instead of abrupt replacement.

Some legacy identity sources cannot be fully removed without unacceptable risk. In those cases, the safer pattern is to isolate them, wrap them with stronger monitoring, and document explicit compensating controls. That may include vendor-specific access windows, dedicated jump infrastructure, step-up approval for elevated actions, and periodic recertification of every exception. The key is to prevent temporary accommodations from becoming permanent shadow governance. Zero trust should shrink standing access, not conceal it behind a modern portal.

OT programmes also need to distinguish between technical reachability and governance authority. A system may be network-segmented and still be operationally dependent on a stale identity store, a shared local admin password, or a manual provisioning spreadsheet. That is where architecture reviews become essential. The identity model must reflect the way access really works, not how it was designed to work.

Related resources from NHI Mgmt Group

• Why does cloud identity coverage matter in federal Zero Trust programmes?
• Why do legacy industrial systems complicate zero trust access models?
• What breaks when Zero Trust is rolled out before identity cleanup?
• Why do legacy OT systems create more identity risk than standard IT environments?