Should organisations separate IT and OT credentials or federate identity across both?

When separation is safer than federation

Separate IT and OT credentials when the environments have materially different safety, availability, and change-tolerance requirements, or when a shared identity plane would let a compromise move too easily from business systems into operational systems. Federation can still be appropriate, but only when the trust relationship is narrow, auditable, and explicitly limited to the use cases OT can safely absorb.

The practical question is not whether one directory exists, but whether the same credential, session, or privilege path can cross both domains without creating an unacceptable blast radius. In OT, the margin for error is usually smaller, so the credential model should reflect the consequence of misuse, not just the convenience of administration. NIST SP 800-82 Rev 3 is useful here because it treats segmentation, trust boundaries, and operational resilience as core design concerns, not add-ons.

Where federation is chosen, the safest pattern is usually controlled trust between separate administrative domains, not a single flattened account structure. That means distinct policy sets, explicit claims mapping, and clear rules for which identities, groups, or service accounts are allowed to cross into OT. The administration benefit of federation disappears quickly if it obscures ownership or makes emergency revocation too slow.

What the trust boundary has to preserve

Whatever model you choose, it must preserve traceability, revocation, and least privilege. Separate credential stores can make incident containment easier, while federation can make lifecycle operations cleaner if it does not collapse approval, authentication, and authorization into one shared control plane. The key control objective is to keep IT convenience from rewriting OT access rules by accident.

That is why identity federation should be evaluated as an access architecture, not just an authentication method. If the OT side cannot independently verify who is approved, what they may do, and how quickly access can be withdrawn, then the design has moved too far toward central convenience and away from operational safety. NIST Cybersecurity Framework 2.0 supports that judgment through its governance, access, and resilience themes, while ISO/IEC 27002:2022 Information Security Controls reinforces the need for tightly managed access control and secure administration.

In practice, the more safety-critical the OT environment, the more valuable it is to keep admin pathways narrowly scoped, time bound, and separately monitored. Federation can support that outcome, but only if the resulting sessions do not behave like universal keys across plant and enterprise systems.

How to decide between separate stores and federated identity

The decision should follow the operational dependency, not the org chart. If OT depends on strict segmentation, low change frequency, legacy protocols, or independent emergency access, separate credential stores often reduce risk. If the environment has mature controls, disciplined policy enforcement, and a clear need to reduce duplicate account administration, federation can work as long as it is designed as a controlled bridge rather than a shared identity pool.

• Use separate credentials when cross-domain compromise would be hard to contain, or when OT operations cannot tolerate delayed revocation.
• Use federation when it improves governance without broadening privilege, widening trust, or weakening recovery options.
• Treat exceptions as temporary and logged, with explicit approval and review.

The strongest technical anchor for either model is a clean trust boundary. CISA Industrial Control Systems guidance is relevant because it frames OT as a specialized environment with distinct security and operational constraints, while OpenID Connect Core 1.0 shows how federation can be built with explicit identity assertions rather than loose trust.

The best outcome is not “one identity system for everything.” It is a structure where the OT side can still enforce its own approval logic, session limits, and emergency cutoff even when authentication is federated upstream.

Risk and Threat Considerations

Shared identity across it and ot can turn a routine enterprise account compromise into a cross-environment incident. If attackers gain an IT foothold and the same trust plane reaches OT, they may be able to reuse credentials, pivot through federation, or abuse overly broad group mappings to reach systems that should have remained isolated.

Failure mechanism: A federated design that centralises authentication but not privilege boundaries can let one compromise propagate through claims, tokens, or shared administrative roles into OT. Weak revocation, stale entitlements, or over-trusted assertions make the boundary look stronger than it really is.

Impact: The result can be loss of containment, slower incident response, and higher operational risk, especially where OT systems support safety, continuity, or production stability. In the worst case, a credential event in IT becomes a plant or process disruption in OT.

Practitioner Guidance

What to verify: Confirm that OT can independently enforce access decisions, even if authentication is federated from IT. If revocation, emergency disablement, or step-up review depends entirely on the upstream directory, the design is too coupled for a critical environment.

Decision rule: If one identity compromise would create unacceptable reach into OT, keep credential stores separate or introduce a much narrower federation model with explicit scoping, separate admin roles, and separate break-glass paths. If federation is retained, test the failure case, not just the normal login path.

Practitioner takeaway: The safest model is the one that preserves OT autonomy under stress. Federation is acceptable only when it simplifies administration without turning IT identity compromise into OT operational exposure.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• When should organisations prioritise work identity login over building separate customer credentials?
• What do organisations get wrong about identity management when they rely on separate login systems across applications?