Older OT systems were not designed for modern identity governance, so they often lack individual attribution, central logging, or flexible access controls. That means security teams must govern risk around systems that cannot easily prove who accessed them, which increases audit gaps and incident response uncertainty.
Why This Matters for Security Teams
Legacy OT assets make convergence harder because they were built for availability and deterministic control, not for modern identity governance. Many devices cannot support per-user attribution, short-lived credentials, or centralized telemetry, so security teams inherit blind spots at the exact point where IT controls are expected to extend into plants and critical infrastructure. That creates gaps in accountability, segregation, and incident response, especially when shared accounts or vendor access are still normal.
NHI Mgmt Group has shown how often identity risk persists in practice: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In OT environments, those same control failures are amplified by long asset lifecycles and limited patch windows. The result is that convergence projects can look modern on paper while still depending on credentials and access paths that are effectively ungovernable. In practice, many security teams encounter this only after a vendor account, service credential, or remote maintenance path has already been abused.
How It Works in Practice
Secure convergence starts by accepting that many OT assets cannot be forced into the same identity model as IT endpoints. Current guidance suggests treating legacy controllers, historians, and embedded appliances as constrained workloads that sit behind compensating controls rather than as fully manageable identities. That usually means segmenting them, placing strict access brokers in front of them, and limiting who can reach them through jump hosts, PAM workflows, or tightly scoped remote support paths.
Where possible, teams should map each asset to the minimum control set it can actually support. For some systems that means only network-based authorization and maintenance windows. For others it may include unique operator accounts, local logging exports, or gateway-mediated authentication. The NIST Cybersecurity Framework 2.0 is useful here because it forces a governance view across identify, protect, detect, respond, and recover, rather than assuming a single technology can solve convergence.
- Inventory OT assets separately from IT assets, including vendor-managed and embedded devices.
- Replace shared access where feasible with named accounts, brokered sessions, and approval-based access.
- Use compensating logging at the gateway, jump host, or historian layer when the device itself cannot log reliably.
- Restrict secrets and maintenance credentials to vaults, with strict rotation and time-bound access.
- Validate remote support paths as part of change control and incident response planning.
For asset classes that cannot support modern controls, the practical answer is containment, not normalization. The Schneider Electric credentials breach is a reminder that exposed or weakly governed access paths can turn operational convenience into enterprise-wide risk. These controls tend to break down when flat networks, shared vendor credentials, and undocumented maintenance exceptions are allowed to persist because there is no trustworthy way to attribute activity at the device level.
Common Variations and Edge Cases
Tighter OT access control often increases operational overhead, requiring organisations to balance safety and uptime against visibility and least privilege. That tradeoff is real, especially in plants where maintenance schedules are fixed and downtime is expensive. Best practice is evolving, but there is no universal standard for retrofitting every legacy asset into a full identity-aware model.
In brownfield environments, the common edge case is a mixed estate where some assets support modern controls and others do not. In that situation, convergence should be phased: enforce strong identity governance on the IT side, broker every OT session that can be brokered, and isolate the rest behind network zones and monitored choke points. Where third parties need access, current guidance favors temporary, task-scoped access with clear revocation, rather than standing vendor accounts. That is especially important because NHIs outnumber human identities by 25x to 50x in modern enterprises, so weak governance scales badly.
The other frequent exception is safety-critical equipment that cannot tolerate authentication changes or added latency. In those cases, the secure design pattern is compensating controls around the asset, not forced modernization of the asset itself. Security teams should document the exception, define compensating monitoring, and review whether the exception is still justified after each major maintenance cycle.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy OT often relies on unmanaged machine and service identities. |
| NIST CSF 2.0 | PR.AA | Convergence hinges on identity governance and access accountability. |
| NIST AI RMF | Governance of constrained systems requires risk framing and accountability. |
Inventory OT service accounts and secrets, then reduce standing access wherever the asset cannot self-govern identity.
