What is the difference between push-based and pull-based eSIM provisioning?

How Push-Based and Pull-Based eSIM Provisioning Actually Differ

Push-based provisioning is operator-initiated: the network or provisioning system delivers the profile to the eSIM-capable device as part of a controlled rollout. Pull-based provisioning is device-initiated: the device, or an intermediary acting on its behalf, requests the profile when it is ready to receive it. The key difference is not just direction, but where control, timing, and device readiness sit in the process.

That distinction matters because the provisioning model changes who has to be online, who controls the trigger, and how much the device must participate in the transaction. In constrained environments, the device may not be able to handle constant operator-driven coordination, which makes pull-based flow more practical for intermittent connectivity and low-power operation.

At a practical level, push-based models fit environments where the operator can reliably manage the delivery moment and the target device is reachable in a stable way. Pull-based models fit environments where devices are scattered, wake irregularly, or need to conserve energy and bandwidth. The provisioning choice therefore reflects device capability and operational reality, not just a preference in architecture.

Why the Trigger Model Changes Operational Fit

Push-based provisioning assumes the operator can initiate and complete the transaction at the right time. That works best when the device is discoverable, responsive, and able to accept the profile without much user or local system coordination. It is less forgiving when the endpoint sleeps often, moves between networks, or cannot maintain a long provisioning session.

Pull-based provisioning shifts the burden to the device side, which is useful when the device controls its own readiness state. The device can request a profile after boot, after network availability returns, or after local checks confirm that it is safe to proceed. In that sense, pull-based provisioning is often a better match for the NHI Lifecycle Management Guide because lifecycle timing and recovery conditions matter as much as initial enrollment.

That same lifecycle view is also reflected in Joiner-Mover-Leaver (JML) Guide, where provisioning and revocation are treated as state changes that need the right trigger, owner, and sequence. eSIM provisioning is similar in that the process must align with device state rather than force a one-size-fits-all activation path.

For broader identity and access governance, the underlying lesson is captured well in IAM and IGA Basics: the provisioning method should match the subject being managed. If the endpoint is a low-touch device rather than an interactive human user, the control pattern has to adapt accordingly.

What Matters for Constrained IoT and Distributed Devices

Pull-based provisioning is especially useful for constrained IoT devices because it reduces dependence on persistent operator interaction and frequent connectivity. A device that wakes occasionally can ask for a profile when it has enough power, signal, and local context to complete the exchange. That makes the model more resilient for fleets that are large, geographically distributed, or intermittently connected.

Push-based provisioning can still work in those environments, but it usually requires more infrastructure to coordinate retries, reachability, and delivery assurance. The more constrained the device, the more that a push-only assumption becomes brittle. In practice, the provisioning design needs to account for limited interfaces, narrow power budgets, and the reality that some devices cannot sustain long interactive setup flows.

From a security perspective, this is why many teams treat provisioning model choice as part of device governance rather than a pure connectivity question. The provisioning trigger influences how easily profiles can be staged, how quickly failed enrollments can be retried, and how cleanly stale or unused profiles can be retired.

Risk and Threat Considerations

Provisioning direction changes the attack surface around enrollment timing, delivery control, and replay of provisioning workflows. If the wrong side controls the trigger, a device may be enrolled too early, too late, or in a state that weakens assurance about the profile being installed.

Failure mechanism: Push-based flows can fail when the device is unreachable or poorly synchronized, while pull-based flows can fail when the requester or intermediary is not strongly authenticated, allowing unauthorized profile requests or replay of stale requests.

Impact: The result can be failed activation, delayed recovery, accidental profile exposure, or inconsistent fleet state, all of which make device management harder and can increase the chance of misprovisioning at scale.

Practitioner Guidance

What to prioritise: Choose the provisioning model based on the device’s real operating constraints first, then layer policy on top. If the device is low-power, intermittently connected, or hard to reach, a pull-based flow is usually easier to operate consistently than a model that depends on external timing.

What to verify: Confirm that the entity initiating a pull has a trusted identity, that retries do not create duplicate enrollment states, and that the device can safely request a profile only when it is genuinely ready. For push-based workflows, verify delivery acknowledgement and rollback handling before treating the profile as active.

Practitioner takeaway: The important decision is not “push versus pull” in the abstract, but which side can reliably prove readiness and control timing without creating enrollment fragility.

Related resources from NHI Mgmt Group

• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?