They often assume the answer is direct integration. In many OT environments, that approach is unsafe or impractical. The better first step is to understand the identity boundary, map what is locally administered, and treat the site directory as a governed system rather than an afterthought.
Why This Matters for Security Teams
Bridging IT and OT identity is not a directory-sync problem. In OT, identity is tied to uptime, deterministic control, vendor access windows, and local trust relationships that often predate modern IAM. Treating the plant like an enterprise app stack can break operations, expose privileged pathways, or force teams to keep unsafe exceptions alive indefinitely. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of drift that becomes harder to correct when IT assumptions are pushed into OT.
The main mistake is assuming identity can be standardized before the boundary is understood. In reality, many sites have local accounts, shared engineering workstations, vendor-maintained credentials, and authentication methods that were selected for resilience rather than central governance. The right first question is not “how do we integrate?” but “what is locally administered, what can be governed centrally, and what must remain segmented?” Current guidance in the NIST Cybersecurity Framework 2.0 supports governance and asset visibility first, which is a better fit for hybrid environments than a pure integration mindset. In practice, many security teams encounter identity failures only after a site exception has already become a permanent control.
How It Works in Practice
The practical starting point is identity boundary mapping. Security teams should inventory where identities originate, who administers them, and which systems enforce them. That usually includes domain services in IT, local accounts in OT, jump hosts, engineering workstations, service accounts, PLC or SCADA admin paths, and any vendor remote-access workflow. The goal is to separate authoritative identity sources from locally governed identities, then decide which ones can be federated, which ones need containment, and which ones should never be directly joined.
In mature programs, central identity does not replace OT autonomy. Instead, it governs access at the boundary through controlled pathways, session monitoring, and time-bounded elevation. That means using least privilege, strong approval workflows, and where possible, short-lived access rather than standing accounts. The NHI problem set matters here because machine and service identities can outnumber human identities by 25x to 50x, and those identities are often what bridge IT and OT zones in practice. The same lifecycle discipline described in Ultimate Guide to NHIs applies: know where credentials live, rotate them, and revoke them when they are no longer needed.
- Document which identities are locally administered versus centrally governed.
- Segment engineering, operations, and vendor access paths instead of collapsing them into one directory model.
- Use jump hosts or brokered access for administrative sessions rather than direct trust across zones.
- Apply just enough federation to support auditability without breaking deterministic OT operations.
Where this guidance breaks down is in legacy plants that depend on shared accounts, flat network trust, or equipment that cannot support modern authentication without firmware or process changes.
Common Variations and Edge Cases
Tighter identity control often increases operational friction, requiring organisations to balance traceability against maintenance constraints and safety requirements. That tradeoff is why there is no universal standard for OT identity convergence yet. In some sites, the right answer is not federation at all, but stronger segmentation, better logging, and disciplined management of local credentials. In others, a small set of enterprise identities can be safely brokered into OT through a jump environment while the control network itself remains isolated.
The biggest edge case is vendor access. Third-party engineers often need urgent, time-limited entry, but permanent shared credentials are a frequent source of exposure. This aligns with broader NHI findings from 52 NHI Breaches Analysis, where credential misuse and poor lifecycle controls repeatedly show up as root causes. Security teams should also be cautious with assumptions about IAM tooling. What works in IT, such as broad single sign-on integration, may fail in OT because authentication methods are tied to availability, vendor support contracts, or devices that cannot tolerate frequent policy changes.
Best practice is evolving toward governed identity boundaries rather than full convergence. The practical test is simple: if an identity control cannot be applied without risking downtime or invalidating a safety process, it should be redesigned at the boundary, not forced straight through it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Identity bridging starts with understanding OT context and ownership boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when federating or brokering OT identities. |
| OWASP Non-Human Identity Top 10 | NHI-01 | OT bridges often rely on over-privileged non-human identities and shared secrets. |
Map IT and OT identity authorities before changing access models or directory integration.
