Lifecycle automation changes access as people move, join, or leave, while access approval decides whether a request should be granted in the first place. A programme that treats them as the same control can still leave stale entitlements or weak escalation logic behind.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Lifecycle automation governs account and entitlement changes over time. |
| IA-5 — Authenticator Management | Lifecycle automation must also rotate and retire credentials tied to access changes. | |
| AC-6 — Least Privilege | Access approval should limit what is granted before access is issued. | |
| Recommendation — Automate provisioning, modification, and removal of accounts and entitlements. Track credential issuance, rotation, and revocation as identities change. Approve only the minimum access needed for the stated business purpose. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Separating grant decisions from ongoing access governance is core access control design. |
| A.5.18 — Access rights | Lifecycle automation directly manages changes and removal of access rights. | |
| Recommendation — Define approval and review rules for granting and maintaining access. Review and revoke access rights when roles, needs, or employment status change. | ||
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?