Who should own non-human identity lifecycle decisions?

Why This Matters for Security Teams

Non-human identity lifecycle ownership is a governance decision, not just an access-control task. The team that owns the workload and its dependencies is best placed to decide when an NHI is needed, what it should reach, and when it should be retired. Security still needs to set guardrails, but if it becomes the sole operator for creation, rotation, and decommissioning, decisions slow down and stale identities linger. That pattern is especially dangerous because NHI sprawl is already a known control gap: the Ultimate Guide to NHIs shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, while only 5.7% of organisations have full visibility into their service accounts. The governance lesson is simple: ownership must sit with the business and engineering team that can explain intent and impact, with security enforcing standards through review, evidence, and escalation paths. Current best practice is also consistent with the OWASP Non-Human Identity Top 10, which treats lifecycle failures as a systemic risk rather than a narrow IAM issue. In practice, many security teams encounter broken offboarding only after a token leak, outage, or audit finding has already exposed the ownership gap.

How It Works in Practice

A workable operating model separates accountability from control. Product, platform, application, or workload owners should decide whether an NHI is required, approve its business purpose, and confirm the dependency graph it serves. Security should define the lifecycle rules: approved identity types, minimum secret strength, rotation windows, logging, vault standards, and decommission evidence. That division helps avoid the common failure mode where no one can explain why a token still exists or who can revoke it. The NHI Lifecycle Management Guide is useful here because lifecycle steps only work when ownership is explicit at each stage. The Guide to the Secret Sprawl Challenge also highlights why this matters operationally: secrets often spread into code, tickets, and CI/CD systems, which makes revocation and traceability harder. In practice, the ownership model should include:

• Creation approval from the workload owner, not only from security.
• Security-approved templates for vault placement, TTL, and rotation policy.
• Change-management hooks so app owners are notified before dependency changes break an NHI.
• Offboarding evidence, such as disabled service account status, revoked API keys, and confirmed vault cleanup.
• Periodic attestation that the NHI still maps to an active business function.

Where environments are highly distributed, the accountable owner may be a platform team, but the principle is unchanged: the team closest to the workload must own lifecycle decisions, while security remains the control authority. This guidance tends to break down in legacy estates where no single team can trace which application still uses a shared secret because dependency mapping is missing.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, so organisations have to balance governance rigor against delivery speed. That tradeoff is real, especially in shared-platform, outsourced, or M&A environments where several teams may touch the same NHI. Best practice is evolving, but there is no universal standard that says every lifecycle decision must be made by the same team; the key is that accountability must be unambiguous. Shared service accounts, vendor-managed integrations, and break-glass credentials often need a different approval path, yet they still require a named business owner and a named technical custodian. The Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both point to the same practical outcome: ownership must follow operational reality, not organisational charts. For agentic or autonomous workloads, current guidance suggests moving further toward intent-based authorisation and just-in-time credentials, because static role assignments do not capture changing tool use or runtime context. In those cases, NHI ownership should extend to the team that can explain the agent’s goal, boundaries, and revocation triggers. The model becomes brittle when multiple teams share one secret without a single revocation owner, because no one can safely decide when the identity is no longer needed.

Related resources from NHI Mgmt Group

• Who should own non-human identity lifecycle governance in practice?
• Why do non-human identities complicate identity governance programmes?
• Who should own identity recovery decisions during an incident?
• Who is accountable when a non-human identity is over-privileged?