Who should own lifecycle controls for account kits and secret retrieval identities?

Why This Matters for Security Teams

Account kits and secret retrieval identities sit at the boundary between identity governance and platform automation. They are not just another service account pattern. They are the mechanism that lets a pipeline, workload, or automation step fetch credentials, so ownership has to cover issuance, storage, rotation, revocation, and emergency recovery. When that responsibility is split or vague, the result is usually stale access that outlives the workload it was meant to support.

This is why lifecycle ownership matters as much as access design. NHI Management Group’s Ultimate Guide to NHIs shows that only 20% of organisations have formal offboarding and revocation processes for API keys, and 71% of NHIs are not rotated within recommended time frames. That is a lifecycle failure, not a tooling failure. The OWASP Non-Human Identity Top 10 reinforces the same pattern: unmanaged machine identities become durable attack paths.

In practice, many security teams encounter token abuse only after a pipeline or integration has already been repurposed, rather than through intentional lifecycle review.

How It Works in Practice

The cleanest operating model is shared ownership with clear division of duties. Identity governance should define policy, approval, and audit requirements. Platform teams should implement the mechanisms that create, bind, rotate, and revoke account kits and secret retrieval identities inside the automation stack. The important point is that neither side can own this alone. Governance without execution leaves drift. Platform execution without governance leaves shadow access.

At a practical level, lifecycle controls should treat the kit as a cryptographic trust package. That means the identity that retrieves secrets should be tied to a workload or automation context, not to a person or an enduring shared token. Current guidance suggests using short-lived credentials where possible, with clear TTLs, scoped retrieval rights, and automatic revocation when the job, environment, or integration changes. NHI Management Group’s NHI Lifecycle Management Guide is explicit that lifecycle discipline has to include onboarding, rotation, offboarding, and recovery, not just initial provisioning.

• Identity governance sets policy for approval, purpose, and review cadence.
• Platform teams implement issuance, storage, rotation, and revocation in the secrets path.
• Both teams should define break-glass recovery so emergency access cannot become permanent access.
• Monitoring must detect duplicated kits, stale retrieval identities, and secret access outside expected workflows.

For implementation detail, the Guide to the Secret Sprawl Challenge is useful because it shows how quickly credentials spread across code, tickets, and CI/CD systems. That matters because a retrieval identity is only as safe as the places where its output can land. These controls tend to break down in fast-moving CI/CD environments because pipeline owners, application owners, and security reviewers often change faster than the account kit registry does.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, so organisations have to balance speed against the risk of lingering trust. That tradeoff becomes most visible when platform teams want self-service provisioning but identity governance still needs approval, evidence, and rollback.

There is no universal standard for this yet, but best practice is evolving toward context-aware ownership models. For example, a shared secret retrieval identity used by multiple build systems may need stronger governance than a single-purpose workload identity issued per deployment. Likewise, an account kit used for break-glass recovery should have stricter review, stronger logging, and more constrained revocation paths than routine automation credentials. The 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which is a strong reminder that lifecycle ownership must include termination events, not just steady-state operations.

The most important edge case is outsourced or third-party automation. When an external system retrieves secrets on behalf of an internal workload, ownership can become ambiguous unless the contract, policy, and technical controls all name the accountable internal team. That ambiguity is where stale access survives reviews and audit evidence goes missing. In those environments, lifecycle control fails most often because no single team owns the full path from issuance to final revocation.

Related resources from NHI Mgmt Group

• Why do non-human identities need lifecycle controls, not just secret rotation?
• Who should own password reset and account unlock governance in the enterprise?
• Who should own passkey recovery and fallback access controls?
• How should security teams govern non-human identities at scale?