Why do lifecycle automation and access approval solve different IAM problems?

Why these are different IAM controls

lifecycle automation and access approval sit at different points in the access chain. Lifecycle automation manages access changes over time, while approval governs a specific request before it is granted. Treating them as interchangeable creates a blind spot: one control can be working while the other still allows excess access to accumulate or persist.

That distinction matters because access problems are often time-based, not just request-based. A good approval decision does not revoke access when a role changes, and a good joiner-mover-leaver process does not tell you whether a new entitlement should have been granted at all.

For a deeper lifecycle view, see Joiner-Mover-Leaver (JML) Guide and the Lifecycle Processes for Managing NHIs, which both show how provisioning, deprovisioning, and rotation solve a different problem from access request handling.

What lifecycle automation is designed to control

Lifecycle automation answers: who should have access now, given the current state of the person, system, or account? It is the control that keeps access aligned to status changes such as hire, move, leave, role change, contract end, credential expiry, or environment change.

Its main value is preventing drift. If an identity changes role or exits the organisation, the old access must be removed or adjusted without waiting for someone to submit a fresh request. That is why lifecycle controls are tied to provisioning, deprovisioning, recertification, and periodic entitlement cleanup rather than individual approvals.

In practice, lifecycle automation is where stale access, orphaned accounts, and excessive standing privileges should be removed. The strongest programmes also treat it as a discovery and reconciliation problem, not just a workflow problem, because the system must compare what should exist with what actually exists.

The Top 10 NHI Issues and the Key Challenges and Risks section both highlight the operational impact of stale accounts, excessive permissions, and unmanaged credentials when lifecycle controls are weak.

What access approval is designed to control

Access approval answers: should this requested access be granted right now? It is a decision control, not a lifecycle control. The approval step is meant to validate business need, risk, scope, and exception handling before access is issued or elevated.

That makes approval especially important for high-risk access, privileged entitlements, and exceptions to standard role design. A sound approval process can reject unnecessary access, constrain scope, or require additional justification, but it does not by itself maintain the access after the request has been approved.

Approval logic also fails when it is too coarse. If a request is approved only because a requestor belongs to a broad role, the control may miss whether the exact entitlement, resource, duration, or elevation path is justified. That is why access approval needs clear decision criteria, not just a ticket closure step.

For practical control context, Identity Security Programme Guide is useful for governance design, while IAM and Identity Provider Buyer's Guide is useful when choosing platforms that must support both request workflows and lifecycle enforcement.

Risk and Threat Considerations

When organisations blur lifecycle automation and access approval, they create two common failure modes: access can be approved once and then persist far too long, or access can be removed on paper while systems continue to carry stale entitlements. Both outcomes enlarge the attack surface and weaken accountability.

Failure mechanism: A request approval process without lifecycle enforcement leaves access untouched after role change, offboarding, or privilege reduction; lifecycle automation without approval logic can keep distributing access that was never sufficiently justified.

Impact: The result is excessive standing privilege, orphaned access, slower incident containment, and a higher chance that compromised or outdated access paths will be abused before anyone notices.

Practitioner Guidance

What to verify: Check whether request approval and lifecycle reconciliation are measured separately. If the same workflow is expected to prove entitlement, grant access, and later remove it, the control design is too weak to show where failures occur.

Decision rule: If the issue is “should this user get access now?”, focus on approval logic, scope, and exception criteria. If the issue is “should this access still exist after a status change?”, focus on lifecycle automation, source-of-truth integration, and removal timing.

Common mistake: Teams often declare victory when approval tickets are in place, even though dormant entitlements, role drift, or delayed deprovisioning keep the real exposure intact.

Practitioner takeaway: Approval controls the grant decision, lifecycle automation controls the persistence of access, and mature IAM needs both to prevent unnecessary access at creation and stale access after change.

Related resources from NHI Mgmt Group

• Why do AI agents create access problems that human approval processes do not solve well?
• Why do privileged access tools and secrets managers solve different security problems?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?