What should security leaders do when IT and OT access models use different authentication standards?

Why Different Authentication Standards Become a Security Decision

When IT and OT use different authentication standards, the problem is not the variation itself, it is whether the variation creates a weaker trust boundary. Security leaders should decide whether the split is intentional, risk-based, and documented, or whether it leaves OT as the easier entry point for credential abuse, lateral movement, and privilege escalation.

That distinction matters because attackers rarely need the strongest path if a weaker one exists. A fragmented identity model can let an intruder compromise the less protected environment first, then use interconnects, remote access, or shared administrative workflows to move into higher-value systems.

For OT, this is especially important when OT and ICS Identity and Access Guide is used as the reference point for shared accounts, vendor access, and segmentation expectations. If the two environments cannot meet the same control intent, the weaker environment should be treated as the one that defines the effective security floor.

What Consistent Identity Policy Should Cover Across IT and OT

A consistent policy does not mean forcing identical tools everywhere. It means aligning the security outcome: strong authentication for privileged access, clear account ownership, limited shared access, and controlled exceptions for systems that cannot support modern methods.

Security leaders should define which authentication factors are mandatory for each access path, who approves exceptions, how compensating controls work, and when access is time-bound or session-scoped. In mixed environments, the most important question is whether an operator, contractor, or engineer can cross from one trust domain into another using a weaker factor than IT would allow.

For OT-specific guidance, NIST SP 800-82 Rev 3 is useful because it frames OT security around architecture, segmentation, and operational constraints rather than assuming IT-style controls fit unchanged. The practical takeaway is to standardise the policy objective first, then adapt the implementation to plant realities.

How Leaders Should Manage Exceptions Without Creating a Gap

Some OT assets will not support the same authentication standards as IT, especially legacy controllers, vendor-maintained systems, or tightly coupled operational tools. That does not make the exception harmless. It means the exception must be boxed in with compensating controls such as strong remote-access control, administrative separation, segmentation, and monitored privileged sessions.

Where authentication cannot be modernised immediately, leaders should reduce the blast radius instead of accepting the exposure. That usually means limiting who can reach the OT enclave, preventing direct trust inheritance from IT, and ensuring remote administration is mediated rather than open-ended.

CISA Industrial Control Systems is a useful external reference for that posture because it reinforces the need to treat OT as a specialised environment with distinct operational and security constraints. The governance question is not whether OT is different, but whether the difference is controlled.

Risk and Threat Considerations

Different authentication standards create a predictable attack pattern: adversaries look for the least resistant login path, then pivot to the more valuable environment once inside. In IT and OT converged estates, that can turn a weaker remote-access method, legacy account, or shared credential into an entry point for broader compromise.

Failure mechanism: A weaker OT authentication model, especially when combined with remote access or shared administrative pathways, gives attackers a softer initial foothold and can undermine trust across the connected environment.

Impact: The result can be unauthorised access, loss of segregation between IT and OT, and operational disruption if the attacker reaches systems that support engineering, monitoring, or control.

Practitioner Guidance

What to prioritise: Classify every IT-to-OT access path by business criticality and authentication strength, then focus first on the paths that can reach privileged OT functions or vendor-administered systems.

What to verify: Confirm that any weaker OT method is paired with segmentation, session oversight, and explicit exception approval, not just a written tolerance. If an IT user can reuse a weaker OT credential or token path, the control design is incomplete.

Decision rule: If the OT authentication standard is weaker and cannot be upgraded immediately, treat the difference as a temporary risk condition with compensating controls and an expiry date, not as an accepted steady state.

Practitioner takeaway: Mixed IT and OT authentication can be supportable, but only when the weaker side is deliberately constrained so it cannot become the easiest route into the stronger one.

Related resources from NHI Mgmt Group

• How should security teams govern computer-use models that change access inside enterprise systems?
• How should security teams use access control models without creating entitlement sprawl?
• How should security teams use certificate-based authentication for BYOD access?
• What breaks when identity and security operations use different access records?