Ownership should sit with a governance model that spans operational engineering and identity security, because OT access is both a safety issue and an access-control issue. Engineering teams understand process impact, while identity teams understand authentication, privilege, and lifecycle controls. The programme fails when either side owns it alone.
Who should own OT identity governance?
OT identity governance should be owned jointly, not handed to a single team. The operating model needs one accountable governance function, but it must draw on engineering for process safety and on identity specialists for authentication, privilege, lifecycle, and access review controls. That separation keeps access decisions aligned with plant reality while still enforcing consistent identity control.
The right owner is usually a shared governance forum with named control owners underneath it. Engineering, operations, and vendor management each contribute different facts about equipment criticality, maintenance windows, and remote access paths, while the identity team governs the entitlement model and review process.
In practice, this works best when ownership is defined by decision type. Engineering should define what access is operationally safe, operations should validate who can touch live systems, and identity security should enforce how access is granted, monitored, and revoked. Without that split, teams either over-restrict access and slow maintenance, or they accept ad hoc access that later becomes hard to remove.
How the ownership model should be split across engineering, operations, and identity
OT environments are different from office IT because access can affect availability, safety, and process stability. That means governance has to account for asset criticality, vendor support routes, shared engineering workstations, and exception handling for outages. A practical model assigns engineering ownership of process impact, operations ownership of plant execution, and identity ownership of the control plane.
OT and ICS Identity and Access Guide is a good starting point when you need a reference point for shared accounts, vendor remote access, and OT segmentation. It aligns well with the question of who owns the governance layer because it treats OT access as both a plant-operating issue and an identity-control issue.
Vendor access deserves explicit ownership, because it is often the most fragile part of the model. Business teams may sponsor the vendor relationship, but identity governance should still require named approvers, time limits, and revocation triggers. If vendor access is treated as a procurement issue only, the result is usually lingering access, weak recertification, and poor visibility into who can reach control systems.
Third-Party, B2B and Contractor Access Guide supports that split by making sponsorship, federation, and time-bound access part of the governance model rather than an informal exception process. For OT, that matters because third-party access often arrives through maintenance, integrator support, or emergency response paths that outlive the original need.
Why OT identity governance breaks when one function owns it alone
Single-function ownership fails because no one team sees the full risk picture. Engineering can understand process dependencies, but may underweight entitlement hygiene and review discipline. Identity teams can enforce policy, but may miss the operational consequences of removing access at the wrong time. Operations can keep the plant running, but may normalise exceptions that become permanent.
The most common failure mode is governance drift: an emergency vendor account, shared operator credential, or temporary maintenance role becomes routine because no one owns the full lifecycle. Once that happens, the organisation may still have “access control”, but it no longer has control over access.
IAM and IGA Basics is useful here because OT identity governance still depends on the core lifecycle disciplines of provisioning, access review, entitlement management, and least privilege. The OT context changes the consequences, but not the need for clear ownership of who approves, who implements, and who verifies removal.
Where OT programmes mature, they usually move to a three-line model: engineering defines operational policy, identity governance runs the controls, and operations validates exceptions and emergency use. That arrangement gives each team a real responsibility without letting any one of them own the entire problem in isolation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OT identity governance depends on controlling credential lifecycle and revocation. |
| AC-2 — Account Management | Who owns OT governance is defined by account provisioning, review, and removal responsibilities. | |
| AC-6 — Least Privilege | OT access ownership must constrain vendor and operator privilege to operational need. | |
| Recommendation — Enforce IA-5 to manage OT credentials, rotation, and revocation across engineering and vendor access. Use AC-2 to assign clear owners for OT account lifecycle, including contractor and vendor access. Apply AC-6 to limit OT users and vendors to the minimum access needed for safe operations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | OT governance is fundamentally about defining and enforcing access ownership and approval. |
| A.5.16 — Identity management | The question concerns who owns identity governance across teams and vendors. | |
| A.5.18 — Access rights | OT governance requires periodic review and removal of rights granted to staff and vendors. | |
| Recommendation — Set A.5.15 to govern OT access approvals, restrictions, and exception handling. Apply A.5.16 to establish ownership for OT identity lifecycle and third-party identities. Use A.5.18 to review, adjust, and revoke OT access rights on a defined schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | OT ownership is about managing accounts, permissions, and timely deprovisioning. |
| CIS-6 — Access Control Management | OT governance needs least-privilege enforcement and controlled vendor access. | |
| Recommendation — Implement CIS-5 to control OT account creation, review, and removal. Use CIS-6 to restrict OT access paths and enforce approval-based access. | ||
Practitioner Guidance
What to prioritise: Define a single accountable owner for the governance process, then separate the approver, implementer, and reviewer roles. If those roles collapse into one team, access exceptions will outlive their purpose.
What to verify: Check whether every vendor pathway has an expiry date, named sponsor, and removal trigger, and whether emergency access is reviewed after the fact. If not, the ownership model is still informal.
Decision rule: If the access decision could affect safety, uptime, or plant integrity, engineering must sign off on the operational impact, while identity security enforces the control mechanics. If it is only a convenience request, treat it as a standard entitlement review, not an OT exception.
Practitioner takeaway: OT identity governance works when one function is accountable for the programme and multiple functions are accountable for different parts of the decision. The critical mistake is assuming that operational knowledge or identity control alone is enough.
Related resources from NHI Mgmt Group
- Who should own identity governance when security, clinical operations, and vendor access all depend on the same platform?
- Who should own AI agent governance when identity and access are shared across teams?
- Why is it important to integrate identity and data governance?
- What is the difference between role-based access and API key governance for NHI security?