Skip to main content
Identity Authority
Category: User Provisioning

Request-Based Provisioning

Also known as: Access Request Provisioning, Self-Service Provisioning
Simply put

Request-based provisioning is a way of granting access to applications and resources only after someone explicitly asks for it, rather than assigning access automatically. A user (or someone acting on their behalf) submits a request, which is typically reviewed and approved before the access is created. This gives organizations control over who receives access and a record of why it was granted.

Formal definition

Request-based provisioning is an IGA provisioning pattern in which the creation, modification, or revocation of accounts and entitlements on target systems is initiated by an explicit access request rather than by automated rules such as attribute- or role-based assignment. In most deployments the workflow includes request submission, policy-driven approval or certification steps, and subsequent fulfillment, where the provisioning platform creates, modifies, or revokes accounts on target applications and directories (for example, an LDAP directory). This is a lifecycle/administration concern distinct from runtime access enforcement, and it typically produces auditable request records; the specific approval logic, controls (such as segregation of duties checks), and fulfillment mechanisms vary by vendor and configuration. Note that request-based provisioning governs access establishment and is separate from authentication of the requester at runtime.

Why it matters

Request-based provisioning matters because it forces access to be justified and recorded rather than assumed. In deployments that rely on automated assignment alone, users can accumulate entitlements as a side effect of role or attribute changes, often without a clear rationale attached to any single grant. By requiring an explicit request that is reviewed before fulfillment, organizations gain a documented reason for each grant, which supports least-privilege objectives and makes downstream access reviews and certifications more meaningful. Provisioning has been described as the process that determines who gets what access, when, and under what conditions, and request-based patterns make those conditions explicit at the moment access is established.

The pattern also addresses cases that automated rules do not cleanly cover: access to a resource outside a user's standard role, temporary or exception access, or entitlements too sensitive to grant without human judgment. Because the request workflow typically produces auditable records, it gives compliance and governance teams evidence of who requested access, who approved it, and why. This traceability is often what auditors expect to see when reviewing how access was granted, and it is a distinct benefit from the runtime controls that later govern whether a user can actually authenticate and use the access.

It is worth being precise about scope: request-based provisioning governs how access is established, modified, or revoked in target systems, not whether the person is legitimately who they claim to be at the time of use. The strength of the control depends heavily on the quality of the approval logic and any segregation-of-duties checks configured in the workflow. A poorly designed approval chain, for example, one that rubber-stamps requests, undermines the governance value even when the request record itself is complete.

Who it's relevant to

Identity Governance Leads
Request-based provisioning is a core IGA pattern for enforcing least privilege and maintaining defensible records of why access was granted. Governance leads use it to complement automated assignment, to route sensitive or exception access through human review, and to feed later access reviews and certifications with meaningful justification data.
Compliance and Audit Officers
Because request-based provisioning typically produces auditable request records showing who asked for access, who approved it, and when, it provides the evidence auditors expect when evaluating how access was established. Its value depends on approval logic and any segregation-of-duties checks being properly configured, so officers should confirm those controls rather than assume the request record alone demonstrates due diligence.
IAM Engineers and Administrators
Engineers configure the request submission, approval, and fulfillment steps and connect the provisioning platform to target applications and directories such as LDAP. They should treat this as a lifecycle concern distinct from runtime enforcement and authentication, and account for the fact that fulfillment mechanisms and approval logic vary by vendor and deployment.
Security Architects
Architects decide where request-based provisioning fits alongside automated, rule-driven assignment such as role- or attribute-based models. This involves designing which access types require explicit requests versus automatic grants, and ensuring the provisioning workflow remains separate from, and does not substitute for, runtime access decisions and requester authentication.

Inside Request-Based Provisioning

Access Request
The user- or manager-initiated submission for entitlements, roles, application access, or group membership. In most deployments, this is the trigger that starts the request-based provisioning flow, as opposed to automatic (birthright) or role-based assignment.
Approval Workflow
The routing logic that sends a request to one or more approvers (line manager, resource owner, application owner) before fulfillment. Depending on configuration, this may include multi-stage approvals, conditional routing, and escalation timers.
Segregation of Duties (SoD) Checks
Policy evaluation that detects toxic combinations of entitlements at request time. This is an identity governance (IGA) control that can block or flag a request before provisioning, and is distinct from runtime access enforcement.
Fulfillment / Provisioning Connector
The mechanism that actually creates or grants the access in a target system once approved, typically via SCIM, a directory operation, an API call, or a manual fulfillment task. This step is separate from the request and approval decision itself.
Requester and Beneficiary
The distinction between the principal submitting the request and the principal who receives the access. In many deployments these differ, for example a manager requesting access on behalf of a report.
Audit Trail
The recorded history of who requested what, who approved it, and when it was fulfilled. This supports later access reviews, certification, and compliance reporting within IGA.
Entitlement Catalog
The set of requestable items (roles, groups, application access, fine-grained entitlements) presented to requesters. What appears in the catalog is typically governed by policy and scope rules depending on configuration.

Common questions

Answers to the questions practitioners most commonly ask about Request-Based Provisioning.

Is request-based provisioning the same thing as automated provisioning?
No. Request-based provisioning is a workflow-driven model in which a user (or someone acting on their behalf) explicitly requests access, which typically routes through approval steps before an account or entitlement is granted. Automated provisioning, often driven by attributes, roles, or lifecycle events such as a joiner event from an HR source, grants access without an explicit human request. Many deployments combine both: birthright access via automated provisioning and discretionary or sensitive access via request-based flows. Treating them as interchangeable obscures where approval controls and human judgment actually sit in your process.
Does an approved access request mean the user is authenticated and immediately able to use the access?
No. Request-based provisioning is an identity governance and administration (IGA) lifecycle concern, it determines whether an entitlement is granted and provisions it to a target system. It does not authenticate the user; authentication happens separately at runtime when the principal accesses the resource. There is also typically a fulfillment step between approval and usable access, and propagation to downstream systems can introduce latency depending on the connector or provisioning mechanism. Approval establishes that access should exist, not that it has been verified or is already enforceable in the moment.
How should approval workflows be structured for request-based provisioning?
Approval structures vary by deployment and by the risk associated with the requested access. Common patterns include single-level manager approval, multi-level chains, resource-owner or application-owner approval, and dynamic routing based on attributes of the request. Higher-risk or segregation-of-duties-relevant entitlements are often configured to require additional approvers or explicit policy checks. The appropriate structure depends on your governance requirements, regulatory obligations, and how you have modeled entitlement ownership, so there is no single universally correct chain.
How does request-based provisioning interact with segregation of duties (SoD) controls?
In many IGA deployments, SoD policies are evaluated at request time so that conflicting entitlement combinations are detected before approval or fulfillment. Depending on configuration, a detected conflict may block the request, require an additional or higher-level approval, or generate a documented exception with mitigating controls. Because request-time evaluation is a preventive check, it typically complements rather than replaces periodic access reviews and certification, which serve as detective controls after access has been granted.
What happens to access granted through a request after the initial provisioning?
Request-based provisioning grants the entitlement, but ongoing governance generally requires additional lifecycle handling. Depending on the deployment, granted access may be subject to time-bound expiration, periodic recertification through access reviews, or automatic deprovisioning tied to leaver or mover events. Without such controls, request-granted access can accumulate and contribute to entitlement sprawl. Whether expiration or review applies is a configuration decision and should be defined per entitlement or per policy rather than assumed.
How is request-based provisioning fulfilled in target systems?
Fulfillment mechanisms depend on the target and on your provisioning architecture. Common approaches include standards-based provisioning such as SCIM to compatible applications, directory operations against an LDAP directory, vendor-specific connectors, or, where no automated connector exists, manual fulfillment tasks routed to an administrator. The chosen mechanism affects propagation latency, error handling, and the reliability of eventual deprovisioning. Manual fulfillment paths in particular warrant tracking, since they can leave gaps between what governance records show and what exists in the target system.

Common misconceptions

Request-based provisioning grants access as soon as the user submits a request.
Submission is only the trigger. In most deployments, the request passes through approval workflows and policy checks (such as SoD) before any fulfillment occurs, and the actual provisioning is a separate downstream step.
Request-based provisioning is a real-time access enforcement mechanism.
It is an identity governance and administration (IGA) lifecycle process concerned with granting and provisioning entitlements. It does not perform runtime authorization decisions; that remains the responsibility of enforcement components such as a PDP and PEP at access time.
Request-based provisioning replaces role-based or birthright provisioning.
These approaches typically coexist. Birthright and role-based provisioning cover predictable, automatic access, while request-based provisioning handles exceptions and additional access that fall outside standard assignments. Neither is universally superior.

Best practices

Enforce segregation of duties (SoD) policy checks at request time so toxic combinations are flagged or blocked before approval and fulfillment, not discovered later during access reviews.
Route approvals to the parties with genuine context, such as resource or application owners in addition to line managers, and configure escalation and timeout handling for stalled requests.
Automate fulfillment through provisioning connectors (for example SCIM or directory operations) where possible to reduce manual errors, while retaining tasks for systems without automated integration.
Capture a complete audit trail of requester, beneficiary, approvers, and fulfillment timestamps to support later certification, access reviews, and compliance reporting.
Keep the entitlement catalog scoped and curated so requesters only see items appropriate to their context, reducing over-requesting and rubber-stamped approvals.
Pair request-based provisioning with periodic access certification, since granting access at request time does not guarantee it remains appropriate over time.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps