Access provisioning sounds like one action: someone needs access, someone grants it. In practice it's a five-stage lifecycle, and organizations rarely fail at the stage everyone worries about, the initial grant. They fail at the stages nobody's watching: the request that bypassed the process, the review that never happened, the revocation that stopped at the login page. This guide covers all five, and what tends to go wrong at each one.
The access provisioning lifecycle is the systematic process an organization uses to manage user access to its systems, applications, and resources, from the moment access is first needed through every change that follows, to the moment it's finally removed.
It's the operational backbone of identity and access management, and it exists because access isn't a one-time decision. It's a standing relationship between a person and a system that has to stay correct for as long as it exists.
The 5 Stages of the Access Provisioning Lifecycle
Stage 1: Request
Access needs originate somewhere: a new hire needs their role's baseline tools, an existing employee needs something extra for a project, a contractor needs scoped access for an engagement.
The request stage captures that need in a structured way, specifying what's needed, for whom, and, ideally, for how long and why.
Where it breaks: when a governed request path exists but an ungoverned one is easier. An email to an app owner, a Slack DM, a favor between colleagues, all of these grant access outside the system that's supposed to track it, and once access exists outside the record, every downstream stage inherits the gap. The request stage only works if it's genuinely the path of least resistance, not the compliant-but-slower alternative to asking nicely.
Stage 2: Approval
Not every request should be automatic. The approval stage routes requests to whoever can actually judge them, a manager, an app owner, a security reviewer, for a decision informed by real context: does this person's role justify this access, is the access level appropriate, does anything about this request look unusual.
Where it breaks: context-free rubber-stamping. An approver looking at a bare request, an app name and a username, with no visibility into whether the access is standard or privileged, whether peers in the same role already have it, or whether this specific person has an unusual pattern with this specific app, will approve almost everything. Approval without context isn't a control, it's a delay with a signature on it.
Stage 3: Provisioning
This is the stage most discussions of the lifecycle treat as the whole thing: the actual granting of access, accounts created, roles assigned, licenses attached, permissions configured, across whatever systems the approved request touches.
Where it breaks: inconsistency and incompleteness. Manually executed provisioning varies by which admin does it and how many other tickets they're working that day, which is how identical roles end up with different footprints. Provisioning that only covers the applications an admin remembers to touch leaves gaps that surface later as unauthorized capability or, more often, as a new hire blocked from doing their job on day one because half their tools were never actually configured.
Stage 4: Review
Access correct at the moment of granting doesn't stay correct indefinitely. Roles change, projects end, people move teams, and the review stage is the recurring check that access still matches need: periodic certification of who has what, with a real decision to keep or revoke each grant.
Where it breaks: two ways, and both are common.
- Reviews that don't happen: scheduled but quietly skipped once or twice until they've stopped happening entirely
- Reviews that happen but don't mean anything: a manager clicking "approve all" on a list of forty grants they didn't actually evaluate, which produces a signed report and zero actual verification
A review stage that exists on paper but not in practice is worse than no review stage, because it looks like a working control in an audit.
Stage 5: Revocation
When access is no longer needed, whether from a role change, a project ending, or an employee departing, it needs to be removed, completely and promptly. This is the highest-stakes stage in the lifecycle, because the cost of getting it wrong compounds silently for as long as nobody notices.
Where it breaks: partial revocation mistaken for complete revocation. Cutting someone's SSO access revokes the login path; it does not touch the account, permissions, and license sitting inside each individual application. Accounts survive, API tokens keep working, licenses keep billing, and none of it shows up on the dashboard where the revocation was recorded as done.
Revocation that stops at the identity provider is the single most common gap in the entire lifecycle.
What Connects the Five Stages
The stages aren't independent steps executed once each. They're a loop, and the same identity data has to flow correctly through all five for any of them to be trustworthy.
- A request without a clear role and department behind it produces an approval decision made blind
- Provisioning that doesn't track exactly what was granted, to whom, under which request, leaves the review stage nothing accurate to certify
- Revocation is only as complete as the record of everything provisioning ever granted, across every stage before it, including the mid-lifecycle access requests that came in outside the original onboarding
This is why organizations that automate provisioning (Stage 3) while leaving request, review, and revocation manual often see limited improvement: the lifecycle is as strong as its weakest connected stage, not its best-executed one.
Automating the Lifecycle
Automation changes what's possible at every stage, not just the provisioning step its name implies.
Requests route through a self-service catalog with defined approval logic instead of ad hoc channels, and time-bound requests carry expiry built into the grant itself.
Approvals surface real context automatically: peer adoption, request history, whether the access is standard or privileged, so the decision is informed rather than blind.
Provisioning fires directly off HR events, evaluated against role and department conditions, so identical roles get identical access without per-hire manual configuration.
Reviews recur on a defined schedule with reviewer accountability and locked, timestamped decisions.
Revocation auto-populates from a person's actual current access footprint and executes inside each application, not just at the identity provider, closing the gap where the lifecycle most commonly fails.
Automating the loop rather than one stage is what turns the lifecycle from five separate processes, each with its own failure mode, into one system where each stage's output is the next stage's reliable input.
How Zluri Handles the Access Provisioning Lifecycle
Zluri runs all five stages as one connected system rather than five disconnected tools, on the same identity data throughout.
Requests flow through the Access Requests module (the employee app store) with defined approval logic and mandatory time-bound duration for external users.
Approvals get Approver Insights: peer adoption data, the requester's history with the app, and an explicit standard-versus-privileged flag, so the decision has context behind it.
Provisioning runs through conditional workflows and reusable playbooks, with Zero Touch Onboarding firing directly off HR hire dates and dedicated triggers handling role and department changes, so the mover stage doesn't just add access without removing what the old role no longer justifies.
Reviews run through Access Reviews with reviewer fallbacks, locked decisions, and non-editable timestamped reports, in the same IGA product as provisioning, so a review finding becomes a fixed workflow instead of crossing a tool boundary.
Revocation auto-populates from the person's actual current access footprint, including apps discovered beyond SSO federation, and executes inside each application, account, role, license, with per-action run logs proving exactly when access started and ended.
Standard integrations go live in 2 to 4 weeks. The full mechanics behind provisioning and offboarding specifically are covered in how Zluri solves user access management problems.
Frequently Asked Questions
Which stage of the access provisioning lifecycle fails most often?
Revocation, and specifically partial revocation mistaken for complete revocation. Cutting SSO access is often treated as equivalent to removing access, but it leaves application-level accounts, permissions, and licenses untouched, and that gap is the most common finding in access audits.
Is access provisioning the same as user provisioning?
They're used interchangeably in most contexts. Access provisioning sometimes refers to the broader lifecycle across all five stages; user provisioning more often refers specifically to Stage 3, the act of granting. In practice, evaluating either term means asking whether all five stages are covered, not just the granting step.
Why does automating only the provisioning stage produce limited results?
Because the lifecycle is a loop, not five independent steps. Automated provisioning still depends on requests and approvals for what to grant, and its output still needs to flow into review and revocation to close the loop. Automating one stage while leaving the others manual just moves the bottleneck to whichever stage is still manual, most often revocation.
How many times does an access provisioning lifecycle typically repeat for one user?
More than once, and often much more than once. Every role change, project assignment, and mid-tenure access request restarts the request-approval-provisioning sequence for that specific access, while the review stage runs on its own recurring schedule regardless. A single employee's full access history across a multi-year tenure usually reflects dozens of individual lifecycle instances, not one.
.svg)
