Ownership has to be shared between security, operations, and system owners because the consequences are physical, not just digital. Security can define policy, but operations must validate what can be enforced safely, what needs approval, and what must be preserved during incident containment.
Why OT identity ownership cannot sit with security alone
OT identity decisions are not just access-control choices. They can affect uptime, operator safety, maintenance access, failover behaviour, and the ability to contain an incident without interrupting a control process. That is why ownership has to include security, operations, and the system owner, with each party holding a different veto or approval role.
Security should own the policy logic, but it cannot safely decide in isolation which identities may be changed, disabled, segmented, or forced through stronger authentication if those actions could disrupt a plant process or safety function. Operations knows the process dependency; the system owner knows the asset’s intended behaviour and tolerance for control changes.
In practice, the ownership model should reflect the fact that OT environments often mix human operators, vendor access, shared accounts, and tightly coupled control assets. That mix makes identity governance a cross-functional design decision rather than a pure security administration task. A useful reference point is OT and ICS Identity and Access Guide, which ties identity controls to OT realities such as remote access and segmentation.
How to separate policy authority from operational safety approval
The cleanest split is to let security define the minimum policy, then require operations to validate where enforcement is safe and where exceptions are justified. That avoids a common failure mode in which identity standards are designed for IT convenience and then applied to OT assets that cannot tolerate the same lockout, rotation, or session constraints.
Shared ownership also helps resolve conflicts between segregation and response speed. If incident containment requires disabling an account, revoking a token, or cutting off vendor access, operations must confirm whether that step preserves safe state, keeps manual fallback available, and avoids unintended process interruption. Security should not be the only approver for actions that can change physical risk.
For the same reason, ownership should be documented at the level of identity type and asset criticality, not as one blanket rule for the whole plant. A control-room account, a vendor maintenance account, and a read-only monitoring identity do not justify the same approval path or review cadence. Identity governance becomes far more reliable when the owner is attached to the operational consequence, not just the directory entry.
What a workable OT identity decision model looks like
A practical model assigns security as policy owner, operations as operational approver, and the system owner as the final business and technical authority for exceptions. That division gives you one team to set control intent, one team to test physical feasibility, and one accountable owner for the specific asset or process.
- Security defines acceptable authentication, least-privilege, logging, and review requirements.
- Operations validates whether those requirements can be enforced without unsafe side effects.
- The system owner approves exceptions, compensating controls, and emergency access paths.
- Maintenance and vendor access should be reviewed against both process risk and cyber risk, not one or the other.
When the model is working, no team can silently change OT identity behavior on its own, and no identity decision is made without a clear answer to who absorbs the operational risk if the control fails. This is especially important where OT environments depend on legacy protocols, shared credentials, or segmented remote access patterns that are hard to unwind quickly. The NIST OT guidance is useful here because it frames identity as part of the broader control architecture, not a standalone admin function, and CISA’s industrial control system guidance reinforces the operational context that makes these decisions different from ordinary enterprise IAM.
Risk and Threat Considerations
When OT identity ownership is unclear, organisations tend to overcorrect in one of two directions: security imposes controls that break operations, or operations preserves access paths that leave excessive privilege and weak accountability in place. Either outcome increases exposure, because attackers often target the weakest identity path while engineers are forced to keep exceptions alive for availability.
Failure mechanism: A single owner may disable, rotate, or constrain an identity without understanding process dependencies, or may preserve access for continuity while leaving standing privilege, shared accounts, or unmanaged vendor access in place.
Impact: The result can be unsafe process interruption, delayed incident containment, untraceable operator or vendor actions, and a larger blast radius if an OT identity is compromised.
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 CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | OT identities and machine access paths must be authenticated and governed. |
| AC-6 — Least Privilege | OT identity ownership must minimise standing access that can affect process safety. | |
| AU-2 — Event Logging | Shared OT ownership needs auditable identity and access changes for accountability. | |
| Recommendation — Apply IA-9 to control non-human and service authentication paths in OT. Restrict OT identities to the minimum access needed for each process role. Log OT identity changes and access events so approvals and exceptions are traceable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | OT identity ownership is fundamentally an access-control governance decision. |
| Recommendation — Define OT access ownership, approval, and exception handling in policy. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud and connected OT identity governance requires clear ownership and enforcement. |
| Recommendation — Assign named owners for OT identity lifecycle, approval, and review decisions. | ||
Practitioner Guidance
What to verify: Confirm that every OT identity class has a named security owner, an operational approver, and a system owner, and that emergency access is documented separately from normal access. If that trio is not explicit, the approval chain will fail under pressure.
Decision rule: If a control could affect process availability, operator safety, or recovery procedures, require operations sign-off before enforcement. If the control only changes administrative convenience, security should own the decision and operations should not be the bottleneck.
Common mistake: Treating OT identity as a directory problem. The real issue is whether the identity change can be enforced safely in the live process environment, which means approval must follow consequence, not just policy.
Practitioner takeaway: In OT, the right owner is the one who can judge both cyber exposure and physical consequence, so shared decision-making is not bureaucracy, it is risk containment.
Related resources from NHI Mgmt Group
- Who should own cloud identity decisions when security architecture and IAM overlap?
- Who should own identity lifecycle automation decisions across IT, security, and HR?
- Who should own identity decisions when business and IT priorities conflict?
- Who should own decisions when device signals and identity controls conflict?