Skip to main content
Identity Authority
Category: User Provisioning

Pull Provisioning

Simply put

The evidence provided does not contain information about pull provisioning in the identity and access management sense. The sources describe wallet and push provisioning for adding payment cards to digital wallets, which is a distinct payments concept and not a basis for defining this IAM term.

Formal definition

Insufficient evidence to define this term accurately. The supplied sources address payment-card and digital-wallet provisioning (for example push provisioning of card credentials to mobile wallets such as Apple Pay or Google Pay), not IAM pull provisioning, in which a target application or service periodically retrieves or fetches account and entitlement data from an authoritative source or identity provider rather than having that data pushed to it. No claims about pull provisioning can be substantiated from the evidence packet; a definition should not be generated without sources specific to the term.

Why it matters

The evidence digest supplied for this term does not describe pull provisioning in the identity and access management sense. Every source addresses payment-card and digital-wallet provisioning, for example, adding a card to Apple Pay or Google Pay via push provisioning, which is a distinct payments concept unrelated to IGA account and entitlement provisioning. Because of this, no substantiated statement can be made here about why pull provisioning matters to identity governance, runtime access enforcement, or lifecycle management.

Generating a why-it-matters narrative from these sources would require importing claims that the evidence does not support, which would misrepresent both the IAM concept and the payments material the sources actually cover. In IGA practice, the distinction between provisioning models (how a target system receives account and entitlement data) has real consequences for timeliness, deprovisioning risk, and audit accuracy, but none of those consequences can be responsibly detailed without evidence specific to pull provisioning.

Accordingly, this term should be treated as insufficiently sourced. A complete and accurate entry requires evidence describing IAM pull provisioning directly, such as documentation of a target application periodically retrieving account and entitlement data from an authoritative source, before context fields can be written.

Who it's relevant to

Editorial and sourcing reviewers
This entry is flagged as insufficiently sourced. The supplied evidence covers payment-card and wallet provisioning, not IAM pull provisioning, so reviewers should route the term back for sourcing specific to identity governance provisioning models before publication.
IGA engineers and identity architects
Readers who design provisioning flows would be the intended audience for a completed entry, but they should be aware that no substantiated technical detail about pull provisioning is available from the current evidence. Any operational guidance on fetch cadence, connectors, or reconciliation should be sourced independently rather than inferred from this packet.

Inside Pull Provisioning

Client-Initiated Pull Model
In pull provisioning, the target application or service periodically requests (pulls) identity and account data from an authoritative source, rather than the source pushing changes to it. The target system controls the timing and frequency of synchronization.
Authoritative Source
The system of record from which identity data is retrieved, such as an HR system, an LDAP directory, or an IGA platform. Pull provisioning depends on the target being able to query or read from this source, typically via an exposed API or directory interface.
Polling Interval / Scheduling
Pull provisioning generally operates on a scheduled or on-demand basis, where the target polls the source at defined intervals. This means propagation of changes is not usually real-time and depends on the configured cadence.
Data Reconciliation
The process of comparing the pulled dataset against the target's current account state to determine creates, updates, and deactivations. This is an IGA administrative concern focused on account lifecycle rather than runtime access enforcement.
Relationship to SCIM
SCIM is more commonly associated with push provisioning, where the identity provider pushes changes to the service provider. Pull provisioning can still leverage read-oriented queries against a source, but the initiating party differs; the exact mechanism depends on the systems and interfaces involved.

Common questions

Answers to the questions practitioners most commonly ask about Pull Provisioning.

Is pull provisioning just push provisioning done in reverse?
Not exactly. The distinction is about which system initiates the account synchronization. In push provisioning, the identity source (typically an IGA platform or identity provider) initiates changes and sends them to the target application, often via SCIM. In pull provisioning, the target application or service periodically queries the identity source to retrieve account and attribute data, then reconciles its own store. The data flow direction differs, but more importantly the control point differs: in pull models the target owns the schedule and reconciliation logic. Behavior varies by vendor and connector design, so confirm which side holds authority over conflict resolution in your specific deployment.
Does pull provisioning provide real-time access enforcement?
No, and this is an important boundary. Pull provisioning is an identity governance and administration (IGA) lifecycle concern focused on synchronizing account and attribute state, typically on a scheduled or polled basis. It is not a runtime enforcement mechanism. Whether a principal is granted access at the moment of a request is handled separately by authorization components such as a policy decision point (PDP) and policy enforcement point (PEP), and by token validation. Because pull cycles run on an interval, there is usually latency between a change in the source and its reflection in the target, which is why it should not be relied on for time-sensitive deprovisioning without additional controls.
How do you determine an appropriate pull interval?
The interval is a trade-off between freshness and load on the identity source. Shorter intervals reduce the window during which the target holds stale account or attribute data, which matters most for deprovisioning and segregation-of-duties concerns; longer intervals reduce query volume and processing overhead. Many deployments tune this per attribute sensitivity, and some supplement scheduled pulls with event-driven triggers where the source supports them. There is no universal correct value; it depends on your risk tolerance, the source system's capacity, and whether the target participates in real-time authorization checks that already gate access independently of provisioning state.
How should conflicts and reconciliation be handled during a pull cycle?
Because the target initiates the pull and updates its own store, you need explicit reconciliation rules for cases where local state diverges from the source. Common approaches designate the identity source as authoritative for specific attributes while allowing the target to own others, but this varies by connector and configuration. You should define what happens to accounts present in the target but absent from the source (candidates for suspension or deprovisioning), how attribute mismatches resolve, and whether reconciliation actions are automatic or queued for review. Auditing each reconciliation decision supports later access certification and review.
What happens to deprovisioning latency in a pull model, and how can it be mitigated?
In a pull model, an account disabled or removed at the source is typically not reflected in the target until the next pull and reconciliation cycle completes, creating a latency window. To reduce risk during that window, deployments commonly rely on runtime enforcement that is independent of provisioning state, such as short-lived access tokens with revocation checks, session termination controls, or authorization policies evaluated at request time. Where the source supports it, event-driven notifications can supplement scheduled pulls to shorten the gap. Treat pull-based deprovisioning as eventual rather than immediate.
How is pull provisioning secured against exposing identity data during synchronization?
Since the target queries the identity source, the connection and the retrieved data both need protection. In most deployments this includes transport-layer protection for the query channel, authenticated and authorized access for the target service to the source (scoped to only the attributes it requires), and controls limiting which attributes are exposed. Note that protecting data in transit is distinct from protecting it at rest in the target store, and both should be addressed. Logging pull operations and the credentials or service identity used supports audit and access review. Specific mechanisms depend on the source system, connector, and profile in use.

Common misconceptions

Pull provisioning delivers real-time account synchronization.
Because pull provisioning typically relies on scheduled polling, changes in the authoritative source are usually not reflected in the target until the next poll cycle. Latency depends on the configured interval, so it is generally less immediate than event-driven push models.
Pull provisioning handles runtime access decisions.
Pull provisioning is an identity lifecycle and administration (IGA) function concerned with creating, updating, and deactivating accounts. It is distinct from runtime authorization enforcement performed by components such as a PDP or PEP at access time.
Pull and push provisioning are interchangeable and one is universally better.
They differ in which party initiates the data exchange and in propagation timing. The appropriate choice depends on deployment context, source and target capabilities, latency requirements, and network or security constraints; neither is superior in all cases.

Best practices

Define polling intervals based on how quickly account changes must propagate, balancing timeliness against load on the authoritative source.
Implement robust reconciliation logic to correctly detect creates, updates, and deactivations, and to handle deletions or disabled accounts from the source.
Secure the connection and credentials used by the target to query the authoritative source, and grant only the read access needed for provisioning.
Log and monitor each pull cycle, including failures and discrepancies, so gaps in synchronization can be detected and remediated.
Confirm whether your source and target interfaces support pull-oriented queries, and document that pull provisioning is not typically real-time when setting expectations with stakeholders.
Keep pull provisioning lifecycle actions separate from runtime access enforcement, ensuring that account state changes do not substitute for authorization checks at access time.
Promotional banner for the Penetration Report Template Kit