Who should own lifecycle platform decisions in IAM programmes?

Ownership should sit jointly with IAM, IGA, and the teams responsible for endpoints and application access. Lifecycle tooling touches identity state, device scope, and downstream entitlements, so governance fails when one team chooses the platform without the others signing off on the operating model.

Why This Matters for Security Teams

Lifecycle platform ownership is not a tool selection exercise. It determines who can create, modify, approve, deprovision, and audit identities across endpoints, applications, and directories. When IAM, IGA, and platform teams do not co-own the decision, the chosen product often optimises one layer while breaking the operating model in another. That is how organisations end up with duplicate workflows, unmanaged exceptions, and approval paths that look neat on paper but fail under real joiner, mover, and leaver pressure.

This is especially visible in NHI programmes, where lifecycle tooling must handle service accounts, API keys, and automation identities with the same discipline as human access. NHIMG research shows the scale of the gap: 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, which is one reason lifecycle decisions need broad operational ownership rather than a single-team mandate. The risk is not just poor provisioning, but weak revocation, shadow processes, and inconsistent policy enforcement across systems. Current guidance from the OWASP Non-Human Identity Top 10 and the NHI Lifecycle Management Guide points in the same direction: ownership must be aligned to the full access lifecycle, not just the identity repository.

In practice, many security teams encounter platform sprawl only after onboarding and offboarding failures have already become operationally normal.

How It Works in Practice

The practical answer is to assign decision rights, not just budget ownership. IAM should own identity policy, provisioning standards, and integration patterns. IGA should own approval logic, recertification, and lifecycle governance. Endpoint and application owners should own the technical constraints that determine whether access can actually be issued, enforced, or removed. That split works best when there is a single operating model that defines who approves the platform, who configures it, and who is accountable for exceptions.

For teams handling NHIs, that operating model should be documented around lifecycle events: request, approval, issuance, rotation, suspension, revocation, and audit. The Top 10 NHI Issues highlights why: if secrets, certificates, and tokens are managed separately from downstream entitlement policy, ownership breaks down at the exact moment automation scales. A lifecycle platform should therefore be evaluated on whether it can enforce governance across identity state and access state at the same time.

• Define a joint steering group for IAM, IGA, endpoint, and application access teams.
• Separate policy ownership from tool administration.
• Require each lifecycle workflow to have one business owner and one technical owner.
• Validate that provisioning, deprovisioning, and exception handling work across the full stack.

NHIMG research also shows why coordination matters in practice: the 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which is exactly the kind of failure lifecycle platforms are meant to prevent. These controls tend to break down in federated enterprises with multiple directories, bespoke app onboarding, and inconsistent ownership of downstream entitlements because no single team can see the full access path.

Common Variations and Edge Cases

Tighter lifecycle governance often increases coordination overhead, so organisations have to balance speed against control. That tradeoff is real, especially when business units want rapid onboarding of new apps or automation workflows. Best practice is evolving, but current guidance suggests that lifecycle platform decisions should be centralised enough to standardise policy and decentralised enough to respect application-specific constraints.

There are a few common edge cases. In small environments, one team may temporarily own both IAM and IGA, but that only works if endpoint and application stakeholders still sign off on requirements. In highly regulated or hybrid estates, platform choice may also depend on whether the tool can support recertification, segregation of duties, and revocation across cloud and on-prem systems without creating manual workarounds. The Ultimate Guide to NHIs on lifecycle processes is useful here because lifecycle ownership must include both policy and operational enforcement.

One further nuance: some organisations treat lifecycle tooling as an IAM-only procurement, then discover that app teams are unwilling to adopt it because it does not fit their deployment model. That is a governance failure, not a product failure. In the real world, lifecycle platforms succeed when they are chosen through shared accountability and measured against offboarding, entitlement drift, and exception reduction rather than feature checklists alone.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own access decisions when ITSM and IAM responsibilities overlap?
• How should organisations decide whether appsec, IAM, or platform teams own a control failure?
• Who should own access review decisions in an IAM programme?