Who should be accountable for OT identity governance?

Why This Matters for Security Teams

OT identity governance sits at the point where access control meets production safety. A weak answer to “who owns it” usually creates a split-brain model: security defines policy, while operations is left to absorb the risk when a change interrupts a control system, historian, engineer workstation, or remote maintenance workflow. The result is often over-approval, standing access, and delayed revocation, especially when teams are under pressure to keep plants running.

NHIMG research shows how quickly identity blind spots turn into exposure. In the State of Non-Human Identity Security, 45% of organisations cited lack of credential rotation as the top cause of NHI-related attacks. That matters in OT because shared accounts, service credentials, and vendor access are often tolerated longer than they should be. The governance question is not only who signs off, but who is accountable when access remains active after a shutdown, maintenance window, or vendor engagement ends. Current guidance from the NIST Cybersecurity Framework 2.0 supports shared accountability across governance and operations, not handoff without ownership.

In practice, many security teams discover ownership gaps only after a plant exception, audit finding, or unauthorized remote session has already forced the issue.

How It Works in Practice

Accountability works best when it is explicit, shared, and tied to the way OT environments actually operate. Security should own the identity governance standard: account classification, approval rules, logging requirements, credential lifecycle, exception handling, and evidence collection. OT operations should own operational validation: which identities are needed for process continuity, which controls cannot be changed during runtime, and what revocation timelines are safe for live systems. This is where a formal RACI model helps, but only if it is mapped to actual systems and maintenance processes rather than written as a generic policy.

For many environments, the right operating pattern is:

• Security defines the governance controls and minimum access standards.
• OT validates technical feasibility for production systems, vendors, and maintenance windows.
• Asset owners approve business-critical exceptions and compensating controls.
• Identity and platform teams implement provisioning, rotation, monitoring, and revocation.

That model aligns with the lifecycle focus in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because OT identities are not static entitlements. They need clear onboarding, bounded use, periodic review, and fast removal when the maintenance purpose ends. The operational control point should also be backed by compensating evidence from logging, session recording, or privileged access workflows, especially where direct agents or service accounts interact with PLC-adjacent tooling. Best practice is evolving, but current guidance suggests that no single team should be allowed to approve both the policy and the exception without oversight. These controls tend to break down in plants with legacy shared accounts and unmanaged vendor remote access because revocation is operationally expensive and often deferred.

Common Variations and Edge Cases

Tighter governance often increases coordination overhead, requiring organisations to balance production stability against access reduction. That tradeoff is most visible in brownfield OT, where legacy systems cannot support modern identity controls, and in emergency response scenarios where temporary access must be granted quickly. In those cases, accountability still needs to remain clear: security owns the control framework, while OT owns the decision to accept or reject the operational risk.

There is no universal standard for this yet across all OT sectors, so organisations usually adapt the model to plant criticality, regulatory exposure, and vendor dependency. For example, a high-risk facility may require dual approval for privileged OT access, while a lower-risk site may permit pre-approved break-glass accounts with enhanced monitoring. The important point is that “shared accountability” does not mean shared confusion. It means security cannot delegate governance away, and OT cannot be treated as a passive consumer of controls. Industry research such as the 2026 Infrastructure Identity Survey shows how quickly identity governance weakens when access grows faster than oversight, which is a useful warning for OT teams adopting more remote automation and vendor tooling. Where vendor access, emergency changes, or segmented legacy networks dominate, accountability frameworks fail if revocation, logging, and exception review are not jointly rehearsed before an incident.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• How should IAM teams prioritise identity governance deployment?
• How do security teams know whether identity governance is reducing risk?
• Who should own identity governance when it spans cloud and enterprise systems?