Identity lifecycle management is too broad to govern with one control

At a glance

What this is: This is an analysis of identity lifecycle management that says the discipline is too broad to govern with one control because provisioning, access, authentication, authorisation, management, and offboarding create different risks.

Why it matters: It matters because IAM teams need to separate lifecycle governance by identity type and privilege level if they want to reduce access drift, improve auditability, and make offboarding actually remove risk.

Context

Identity lifecycle management is the set of processes that create, govern, and remove digital identities across their full lifecycle. The article’s central claim is that this is not one control, but a chain of distinct governance problems that must be managed differently.

For IAM, IGA, and PAM teams, the practical issue is that onboarding, access governance, authentication, authorisation, management, offboarding, and reporting do not fail in the same way. A single lifecycle policy may look complete on paper while still leaving gaps in privilege changes, recertification, and account removal.

Key questions

Q: What breaks when identity assurance is managed as one single control?

A: A single-control model hides which layer failed, so weak identity proofing, weak authentication, or weak federation can all appear equally compliant. That makes remediation slow and often misdirected. A modular approach isolates the real problem and gives governance teams a clear place to act.

Q: Why do lifecycle problems create compliance and security risk?

A: Because identity drift changes who can still reach systems after the business relationship or role has changed. That creates audit gaps, weak least privilege, and access that outlives its intended purpose. The risk is highest when changes happen faster than reviews or de-provisioning.

Q: What should IAM teams look for in lifecycle governance evidence?

A: They should look for traceable proof that access changes, certifications, and revocations were driven by actual lifecycle events and can be reconstructed for audit. If the platform cannot show that chain cleanly, governance exists on paper but not operationally. Evidence quality is part of lifecycle maturity, not a reporting extra.

Q: What is the difference between lifecycle management and PAM?

A: Lifecycle management governs identities across their full existence, including onboarding, role change, and retirement. PAM adds stricter control over elevated access inside that lifecycle. They overlap, but PAM is narrower and should be treated as the higher-risk layer within the broader identity programme.

Technical breakdown

Why provisioning and offboarding cannot be treated as the same control

Provisioning creates an identity and assigns initial access, while offboarding removes that identity and its entitlements when it is no longer needed. Those are opposite control moments with different failure modes: one creates authority, the other removes it. If teams treat them as one administrative workflow, they often miss the fact that creation can be clean while termination remains incomplete. In practice, that leaves dormant access paths behind even when the joiner process works well.

Practical implication: govern provisioning and de-provisioning as separate control checkpoints with separate evidence and ownership.

How access governance and authorisation differ inside the lifecycle

Access governance is the continuous policy layer that decides how lifecycle decisions should be made, while authorisation is the runtime enforcement layer that decides whether access is allowed in the moment. The article points to both as part of ILM, but they do not solve the same problem. Governance can define who should have what access; authorisation enforces that decision against resources, context, and role. If either layer is assumed to cover the other, privilege creep and stale entitlements are likely to persist.

Practical implication: separate policy governance from runtime authorisation so certification gaps do not become access exposure.

Why reporting and auditing are not the same as lifecycle control

Reporting and auditing show whether lifecycle controls are operating, but they do not themselves enforce identity changes. That distinction matters because many programmes confuse visibility with control. The article ties auditing to reviewing access rights, logs, and certification campaigns, which makes sense only if the underlying lifecycle actions are already happening. Without enforcement underneath, reports become evidence of drift rather than evidence of governance.

Practical implication: use reporting to detect lifecycle failure, not as a substitute for access removal or entitlement correction.

Threat narrative

Attacker objective: The objective is to retain access after it should have been removed, so identity drift becomes a standing path for misuse or insider threat.

1. Entry occurs at onboarding when an identity is created and initial privileges are assigned without enough governance over scope and necessity.
2. Escalation follows when role changes, privilege changes, or temporary exceptions are not cleaned up, leaving access broader than the current job requires.
3. Impact appears when offboarding or audit processes fail to remove or challenge those lingering rights, creating backdoor access and compliance exposure.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity lifecycle management is not one control, it is a set of distinct governance problems. Provisioning, access governance, authentication, authorisation, management, offboarding, and reporting each fail differently and therefore require different control logic. The article is right to separate them conceptually because collapsing them into one label encourages shallow governance and incomplete accountability. Practitioners should treat ILM as a control family, not a single control.

Offboarding is the lifecycle stage that most often exposes the real governance gap. Creation is visible and easy to celebrate, but removal is where identity programmes most often lose certainty about what still exists. That is why lifecycle discipline must include explicit removal evidence, not just account creation records. The practical conclusion is that offboarding is where identity risk becomes measurable.

Access reviews do not compensate for weak lifecycle boundaries. Certification campaigns can confirm what should exist, but they cannot repair unclear ownership, stale privileges, or delayed de-provisioning. This is the point where ILM and PAM intersect: the more elevated the access, the less tolerant the programme should be of lifecycle ambiguity. Teams should therefore govern privileged and standard identities through different control expectations.

Lifecycle governance must be separated by identity type, not assumed to be portable across them. Human users, service accounts, and higher-risk privileged accounts do not move through the same trust and termination patterns. A joiner-mover-leaver process that works for employees can still fail for machine credentials or elevated accounts because their renewal, ownership, and retirement models differ. Practitioners should design lifecycle governance around the identity being governed, not the workflow being reused.

Continuous lifecycle discipline is the real anti-drift control. The article shows that identity governance only works when the programme keeps pace with role changes, access changes, and termination events. That means the issue is not just automation, but continuous reconciliation between policy, entitlement, and actual access state. Teams should measure lifecycle control by how quickly drift is detected and removed.

What this signals

Identity lifecycle governance works only when removal is as formal as creation. Many programmes invest heavily in onboarding and access assignment, then leave offboarding, role changes, and exception cleanup to fragmented operational habits. That creates a control gap where the identity state in the directory no longer matches the identity state in the business.

Separate control paths are the real design principle here. Provisioning, access governance, and reporting do not collapse into one function simply because they are managed by the same team. The practical signal for practitioners is to stop treating lifecycle as a single workflow and start measuring whether each stage has independent ownership, evidence, and review logic.

For practitioners

• Separate joiner, mover, and leaver controls Create distinct approval, validation, and removal checkpoints for onboarding, role changes, and offboarding so each lifecycle stage has its own evidence trail.
• Assign ownership for every identity lifecycle stage Make one team accountable for creation, one for entitlement changes, and one for removal so no stage is left to informal handoffs.
• Review privileged accounts on a different cadence Use stricter review and removal expectations for elevated accounts than for standard users, because PAM risk does not match ordinary lifecycle handling.
• Tie audit reporting to actual de-provisioning evidence Require proof that access was removed, not just that a ticket closed or a report was generated, so audit artefacts reflect real state change.

Key takeaways

• Identity lifecycle management fails when teams collapse creation, change, governance, and removal into one broad process.
• The article’s core warning is that access drift and weak offboarding are often governance failures, not just administrative mistakes.
• Practitioners should separate lifecycle controls by stage and identity type so evidence, ownership, and removal can be verified independently.

Key terms

• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
• Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• Privilege Drift: Privilege drift is the gradual gap between the permissions an identity was meant to have and the permissions it actually retains. In AI agent environments, drift grows quickly because roles are reused, tasks change, and lifecycle reviews often lag behind deployment velocity.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.