The identity access provisioning lifecycle is the end-to-end process for creating, changing, reviewing, and removing access for people, applications, and non-human identities. In IAM, it covers request, approval, provisioning, verification, periodic recertification, and deprovisioning, ensuring access stays aligned to role, risk, policy, and business need.
What the identity access provisioning lifecycle covers
The identity access provisioning lifecycle is the operating model for access from first request to final removal. It spans onboarding, role or entitlement assignment, approvals, provisioning, verification, recertification, change management, and deprovisioning, so access does not drift away from business need.
It is broader than a one-time account creation step. A mature lifecycle treats access as something that must be continuously justified, adjusted, and eventually withdrawn across people, applications, and non-human identities.
Why provisioning lifecycle discipline matters
Access that is created well but never reviewed becomes stale, excessive, or orphaned. That is why lifecycle control is the difference between access that is merely granted and access that remains defensible over time.
Good lifecycle design reduces privilege creep, entitlement sprawl, and the operational gap between HR, application owners, and security teams. It also helps organisations keep identity and access management and identity governance basics aligned with actual business processes rather than ad hoc requests.
For non-human access, the same lifecycle issues apply, but the failure modes can be faster and harder to notice. A service account, API credential, or workload identity that is provisioned once and forgotten can persist long after the system or integration it supported has changed.
How the lifecycle is supposed to work
A strong lifecycle usually begins with a trusted source of truth, such as HR for employees or a system record for applications and infrastructure. Requests are then routed through approval logic that reflects role, sensitivity, and separation of duties before access is provisioned into the target system.
Provisioning is not the end state. Verification confirms that the right access was delivered, periodic recertification checks whether it is still needed, and deprovisioning removes access when the actor changes role, leaves the organisation, or no longer needs the entitlement.
This is where joiner, mover, and leaver design becomes critical. The lifecycle only works if changes in status trigger corresponding changes in permissions, not just initial account creation. That is why lifecycle automation is often paired with a Joiner-Mover-Leaver guide that ties access changes to real business events.
Where lifecycle failure creates exposure
Most lifecycle failures are not dramatic, they are cumulative. Over time, delayed removal, weak ownership, missed recertification, and manual exceptions create a large amount of access that nobody can confidently explain or defend.
That is especially dangerous when old credentials remain valid after a user, contractor, or integration has changed status. A failed offboarding or rotation step can leave dormant access paths behind, which is why lessons from incidents such as Home Depot Year-Long Token Exposure are so relevant to lifecycle governance. The same pattern appears in Internet Archive breach 2024, where unrotated access material enabled re-entry after the first issue was discovered.
Lifecycle risk also includes ownership gaps. If nobody owns an identity or entitlement, no one is accountable for reviewing it, which is how dormant access becomes effectively permanent. The problem is even sharper for machine credentials, where access can survive the original deployment context and outlive the business purpose that justified it.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle handling of credentials and authenticators in provisioning and removal. |
| AC-2 — Account Management | Directly governs account creation, modification, review, and disabling across the lifecycle. | |
| AC-6 — Least Privilege | Supports lifecycle decisions that keep entitlements limited to business need and role. | |
| Recommendation — Manage credential issuance, rotation, and revocation so access does not outlive its intended use. Automate account lifecycle events and disable accounts promptly when access is no longer justified. Grant only the access required for the current task or role and remove excess entitlements quickly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Addresses account provisioning, inventory, and removal as an operational control discipline. |
| Recommendation — Inventory accounts, review privileges, and remove unused or stale access on a recurring basis. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Defines assignment and administration of identities across their lifecycle. |
| Recommendation — Maintain a lifecycle process that assigns, updates, and removes identities under clear ownership. | ||
Practitioner Guidance
Governance implication: Treat provisioning as a governed lifecycle, not an IT ticket. Access decisions should be tied to an authoritative event, a named owner, and a clear expiry or review point so that every entitlement remains explainable.
What to watch for: Look for accounts or entitlements that are still active after role changes, project completion, vendor exit, or application retirement. Those are the common signals that the provisioning lifecycle has become disconnected from reality.
Practitioner takeaway: If access can be created without a reliable path for review and removal, the lifecycle is incomplete, even if provisioning itself is fast.
Related resources from NHI Mgmt Group
- How should security teams manage access provisioning across the full identity lifecycle?
- Why does manual user provisioning create more access risk in identity lifecycle management?
- Non-Human Identity Lifecycle Management
- How should security teams automate identity lifecycle management without creating new access risk?