Ownership should be shared, but accountability must be explicit. Corporate IAM, OT engineering, HR and security all influence the access record, yet no one should be able to defer revocation because another team owns part of the process. The fix is a named lifecycle owner with authority across the full chain.
Who should own OT identity lifecycle decisions across plants and corporate IAM?
Ownership should be shared, but accountability must be explicit. Corporate IAM, OT engineering, HR and security all influence the access record, yet no one should be able to defer revocation because another team owns part of the process. The fix is a named lifecycle owner with authority across the full chain.
What “ownership” means in OT identity lifecycle governance
In OT, lifecycle ownership is not the same as system administration or policy authorship. The owner is the person or function that can decide when an identity is created, changed, reviewed, suspended, or removed, and who is accountable when those steps do not happen on time. That role needs visibility across plants, vendors, and corporate IAM so decisions are consistent rather than local and ad hoc.
This matters because OT identities often sit at the boundary between corporate onboarding processes and plant-level operational reality. A corporate IAM team may own the workflow, but it may not understand the operational consequence of revoking access too early. Plant teams may understand the process impact, but they should not be able to leave stale access in place indefinitely. NHI Ownership and Accountability Guide is useful here because the same accountability problem appears when identities become orphaned or ownership is ambiguous.
How to split duties without splitting responsibility
The clean model is to separate inputs from decision rights. HR supplies employment status, OT engineering supplies operational context, corporate IAM supplies the control plane, and security supplies risk policy and oversight. But one named owner must arbitrate disagreements, approve exceptions, and ensure revocation, recertification, and offboarding actually happen. That is the difference between shared participation and shared accountability.
A practical pattern is to treat plant-specific OT identities as governed assets with a lifecycle owner, while IAM operates the process and security verifies the controls. If the identity can access a control system, remote session broker, vendor connection, or shared engineering account, the decision to keep it active should not be left to whichever team is currently closest to the request. For lifecycle mechanics, Joiner-Mover-Leaver (JML) Guide aligns well because OT access should follow the same remove-old-access discipline as other identity domains.
OT environments also need explicit ownership because plant and corporate responsibilities often cross trust boundaries. A named owner should be able to answer who approved the access, who can revoke it, and what the fallback is if a plant contact is unavailable. The broader OT control context is well covered in OT and ICS Identity and Access Guide, which frames shared accounts, vendor access, and segmentation as governance problems as much as technical ones.
What good OT lifecycle ownership looks like in practice
Good ownership has three visible traits. First, every OT identity has a named business or operational owner, not just a technical administrator. Second, revocation does not depend on a single team’s convenience, because the owner has authority to escalate and close exceptions. Third, recertification is tied to operational reality, such as a project ending, a vendor leaving, or a role changing, rather than waiting for a quarterly cleanup that may never happen.
When plants and corporate IAM disagree, the decision rule should favour risk containment until the discrepancy is resolved. If nobody can confirm why the access still exists, treat it as a revocation candidate, not a default entitlement. That is especially important for vendor remote access, shared OT accounts, and any identity that can cross from IT into plant operations. Lifecycle Processes for Managing NHIs is relevant because the operational pattern is the same: ownership must be attached to the lifecycle, not assumed from the platform.
Risk and Threat Considerations
OT identity ownership failures usually create stale access, delayed revocation, and unclear exception handling. That exposes plants to privilege creep, orphaned accounts, and vendor access that persists after the original need has ended. NIST SP 800-82 Rev 3, OT Security Guide is relevant because OT access decisions sit inside a broader control and segmentation model, not just an IAM workflow.
Failure mechanism: when multiple teams can influence an identity but no single owner can force closure, revocation gets deferred, exceptions accumulate, and access survives role changes, plant changes, and vendor exits.
Impact: an attacker, displaced contractor, or accidental misuse can retain valid access to plant-connected systems longer than intended, increasing the chance of unauthorized changes, lateral movement, or unsafe operational disruption.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | OT identity lifecycle ownership determines creation, review, and removal of accounts. |
| IA-5 — Authenticator Management | OT lifecycle decisions include rotation and retirement of credentials used by plant and corporate identities. | |
| AC-6 — Least Privilege | OT ownership should prevent access creep and keep plant identities bounded to current duties. | |
| Recommendation — Assign one accountable owner for account lifecycle actions and enforce timely removal or disabling. Track authenticators through issuance, rotation, and revocation so expired access cannot persist. Limit OT accounts to the minimum access needed and remove excess rights at each lifecycle change. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control ownership is central to deciding who may approve and revoke OT identities. |
| A.5.16 — Identity management | OT lifecycle governance depends on clear identity ownership and lifecycle responsibility. | |
| Recommendation — Define access approval and revocation authority for OT identities across plants and corporate IAM. Maintain a formal identity ownership model for OT accounts, vendors, and service identities. | ||
Practitioner Guidance
What to prioritise: assign one accountable owner per OT identity class, then define which team supplies approval data, which team executes the change, and which team resolves disputes. The owner should not be the same thing as the approver for every request.
What to verify: test whether revocation can happen even when the plant is busy, a vendor is unavailable, or corporate IAM and local operations disagree. If the process requires consensus to remove access, it is not an ownership model, it is a delay mechanism.
Practitioner takeaway: shared inputs are normal, but lifecycle authority must be singular. In OT, the safest model is one accountable owner with enough authority to remove access when the evidence says the identity should no longer exist.
Related resources from NHI Mgmt Group
- Who should own identity lifecycle automation decisions across IT, security, and HR?
- Who should own non-human identity lifecycle decisions?
- Who should own cloud identity decisions when security architecture and IAM overlap?
- Who should own access decisions when identity controls are spread across multiple platforms?