Notifications
Clear all
Topic starter
25/06/2026 1:38 pm
TL;DR: Machine identities often stall governance when a single owner is absent, changes roles, or leaves, creating orphaned access, delayed certifications, and audit risk, according to SailPoint. Shared ownership and succession planning turn machine identity governance into a continuous process instead of a person-dependent one.
NHIMG editorial — based on content published by SailPoint: Machine identities don't take PTO, but their owners do: Why shared ownership and succession planning are critical
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What breaks when a machine identity has only one owner?
A: When only one person owns a machine identity, reviews, approvals, and exception handling can stall as soon as that person is absent or leaves.
Q: Why do machine identities need succession planning?
A: Machine identities outlive role changes, holidays, and employee departures, so ownership must transfer without delay.
Q: How do you know if machine identity ownership is working?
A: Look for uninterrupted certification cycles, clear owner assignment on every critical account, and no approvals waiting on a single unavailable person.
Practitioner guidance
- Assign at least two accountable owners to critical machine identities Require a primary and secondary owner for every business-critical service account or bot, with explicit authority to approve access reviews, changes, and exceptions when the primary is unavailable.
- Embed ownership transfer into offboarding workflows Make machine identity reassignment part of employee exit and role-change checklists so governance ownership moves before access decisions stall.
- Document successor authority for high-risk NHI accounts Record who can act, who can approve, and who can escalate for each critical identity so an audit or certification does not depend on one individual's calendar.
What's in the full article
SailPoint's full blog covers the operational detail this post intentionally leaves for the source:
- Product-specific examples of assigning multiple owners to a single machine identity group
- Succession planning workflow details for owner changes, leaves, and departures
- The vendor's before-and-after ownership scenario for governance continuity
- Use-case framing for how Machine Identity Security handles ownership transitions
👉 Read SailPoint's blog on shared ownership for machine identities →
Machine identity ownership gaps: what happens when one owner leaves?
Explore further
25/06/2026 3:37 pm
Single-owner machine identity governance is a brittle control model. The article describes a common failure pattern in NHI programmes: governance is assigned to one person, while the identity itself continues operating continuously. That assumption fails the moment the owner is unavailable, because approvals, reviews, and escalation paths stop with them. The implication is that ownership itself must be treated as a governed lifecycle object, not a static contact field.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often machine identity governance starts from an incomplete inventory.
A question worth separating out:
Q: Who should be accountable when a machine identity owner leaves?
A: Accountability should pass to a documented successor or secondary owner defined in the governance process before the departure occurs. The goal is continuity, not escalation after the fact. If no successor exists, the organisation has a process design problem, not just an administrative gap.
👉 Read our full editorial: Shared ownership is now essential for machine identity governance
