Every major dedicated device OS has a first-boot provisioning story.

Apple has Automated Device Enrollment (ADE) — register a serial, ship the device, it phones home on first boot and configures itself. Android GMS has QR code, NFC, and enrollment programs that work similarly. You pre-register the device, define its configuration, and the hardware does the rest. No one has to touch it individually.

AOSP has none of that infrastructure. No Google enrollment programs, no QR bootstrapping, no platform-level provisioning hooks. Esper built Seamless Provisioning to solve it anyway: a zero-IT-touch enrollment path for custom Android hardware that has no Google services underneath it. It is one of the harder problems in dedicated device management, and operators running AOSP fleets at scale depend on it.

Windows has Autopilot. Which requires Entra ID. Which requires a Microsoft tenant. Which requires user identity infrastructure that has nothing to do with a kiosk running one application in a restaurant that will never have a logged-in user. For dedicated device operators, Autopilot is the wrong answer to the right question. (When Windows shifts underneath a fleet, the breakage lands on the frontline.)

The result has been a gap that every Windows fleet operator knows: someone has to touch every device. Manually. At every location. Imaging pipelines, USB sticks passed around, techs dispatched to stores. The work that shouldn't exist.

Esper's PPKG-based seamless enrollment closes that gap. Starting June 22, 2026, all Esper tenants can generate a Provisioning Package from the console, embed it in an image or load it on a USB, and have Windows IoT Enterprise LTSC devices self-enroll to the correct tenant and Blueprint on first boot — with no tenant credentials in the package, no identity infrastructure required, and no IT touch after the package fires.

A note on naming: this is PPKG-based seamless enrollment, a Windows-native mechanism. In total it is Esper creating the Windows counterpart to Esper Seamless Provisioning, the Android and Linux product, as best as we can on Windows with its available infrastructure and constraints. Same outcome (self-provision on first boot, no IT touch), reached a different way. Counterpart, not the same product: different OS, different underlying mechanism, and Seamless Provisioning itself remains Android and Linux only.

Here is how it works, how to deploy it, and what the platform looks like once your devices land in it.

How PPKG-Based Seamless Enrollment Works

Provisioning Package (PPKG)  is a native Windows mechanism. It is not something Esper invented. Windows Configuration Designer and ICD.exe have supported it for years. What those tools require is deep Windows imaging expertise and a painful authoring process most fleet operators never want to touch.

Esper's implementation strips that away. You generate the package from the Esper console. You use Windows Configuration Designer to configure what matters — admin account name, credentials, and Wi-Fi if needed — and the console produces the package. No ICD.exe. No XML hand-editing.

The package carries no secrets

A key architecture decision to call out: your Esper tenant credentials are not in the PPKG.

Most PPKG-based enrollment approaches embed tenant-specific credentials directly in the package. That means every tenant needs its own package, those packages need to be managed carefully, and a leaked package is a security problem.

Esper's approach is different. Serial numbers are pre-registered in the Esper console before deployment. When a device enrolls, Esper's cloud matches the device serial to the correct tenant and Blueprint automatically. The PPKG itself carries only what it needs to bootstrap enrollment. It does not carry the keys to your tenant.

Per-tenant isolation. No per-tenant credential management. One package architecture that scales cleanly across a fleet.

What fires on first boot

When a PPKG-provisioned device starts up, a lightweight EXE agent embedded in the package runs first. That agent phones home, matches the device serial to your tenant, installs the full Esper Windows agent, and triggers Blueprint convergence. By the time a device is fully booted and shows up in your console, provisioning is already underway.

The PPKG fires once. What happens after that is Blueprint's job.

Seven Ways to Deploy It

PPKG-based seamless enrollment is not one deployment model. It is a mechanism that fits into whatever deployment reality you already have. Pick the path that matches your operation.

1. Custom ISO build

If your team builds your own Windows IoT LTSC image, embed the PPKG directly into the image. Devices self-provision on first boot. Nothing else required. This is the cleanest path for operators who already control their own imaging pipeline.

2. OEM-built ISO

If an OEM builds your factory image, supply them the PPKG and they bake it in. Devices ship pre-configured and enroll on first power-on. No staging step, no USB, no field prep. For OEM partners who want to discuss factory image integration, the Esper partner team is the right conversation.

3a. Bootable install USB — staging

If you have your own ISO but stage devices at a facility, create a bootable USB drive with the ISO and PPKG together. The PPKG sits in the correct folder structure on the drive. Windows setup picks it up during installation and executes it automatically. The device installs Windows and completes enrollment before anyone ever sees a desktop. Standard imaging workflow, seamless enrollment outcome.

3b. Field tech USB

A USB stick loaded with the PPKG, handed to a tech in the field. The tech either resets the device and leaves the USB in during OOBE, or copies the PPKG to a running Windows machine and invokes it directly. The tech needs to be able to prepare the machine for enrollment, clearing an existing MDM if one is present. This path works for distributed fleets where devices are already deployed and need to be moved to Esper without pulling them back to a staging facility. Windows IT Ops know this workflow.

4. Remote script — post-OOBE

For unmanaged devices already active in the field with no RMM or MDM in place, a remote PowerShell script can download the PPKG from a cloud storage location and run the Install-ProvisioningPackage cmdlet silently. No USB required, no physical access needed. This path requires pre-existing local admin access or a remote execution mechanism on the endpoint. Contact the Esper team for help scoping the script for your environment.

5. Remote Monitoring and Management (RMM)-assisted push

If you have an existing RMM tool managing your fleet, it can push the PPKG and execute Install-ProvisioningPackage silently across running Windows machines. The general approach is straightforward: the RMM handles delivery and execution, Esper handles enrollment. Contact the Esper team for help with the specifics.

6. MDM migration

If your fleet is already enrolled in another MDM, that MDM can push the PPKG alongside a PowerShell script that handles unenrollment from the current platform and Esper enrollment in sequence. One script, one pass across the fleet. Contact the Esper team for help scoping the migration script.

7. Preboot Execution Enivornment (PXE) boot — mass infrastructure scale

For centralized IT staging labs or factory floors running at volume, PXE is the right path. Devices boot directly from the local network via a PXE server instead of using physical media. The server streams the Windows OS image and injects the PPKG automatically during the task sequence. No USB drives, no physical staging per device. If you are running a high-volume deployment operation with the network infrastructure to support it, PXE is the most scalable path available.

Trying It for the First Time

For prospects evaluating Esper Windows, or existing customers whose Windows team wants to get hands on PPKG enrollment before rolling it to the fleet, the path is straightforward.

Generate a PPKG from the Esper console. Use WCD to configure your admin account name, credentials, and setup flow choices. Load it on a USB stick. Take it to a lab device.

From there you have two options. Copy the PPKG to a running Windows machine and invoke it directly, removing any existing MDM enrollment first. Or factory reset the machine and run the PPKG off the USB stick during OOBE for a clean view of the full first-boot experience.

Deep link enrollment also exists as an option, and Windows IT ops will recognize it immediately as a familiar path. It requires per-tenant enablement, which currently involves a short wait on the Esper side. That is not ideal when you want to evaluate a device today. PPKG is the faster path to getting hands on a device right now. Serial pre-registration support for deep link is on the near-term roadmap.

Enrollment Gets the Device In the Door. Blueprint Provisions It.

PPKG-based seamless enrollment is a one-time event. The device checks in, matches its serial to your tenant, and enrollment is done. What happens next is provisioning, and that is Blueprint's job.

Blueprint defines the desired operational state of the device. Which apps are installed. What Windows Update policy is enforced. Which network profiles apply. What scripts run on enrollment. What remote access is configured. The moment a device enrolls, Blueprint convergence kicks in and walks it to that state. No manual configuration step. No imaging follow-up. No one touching the device after the PPKG fires.

Unlike the PPKG, which runs once, Blueprint is continuous. If a device drifts from desired state, Blueprint corrects it. That is the operational model for a fleet that runs reliably at scale across hundreds of locations.

Windows IoT Enterprise LTSC is the right OS for this model. A 10-year support lifecycle with no forced feature updates means the Blueprint you define today is not going to be broken by a Microsoft feature update six months from now. LTSC and Blueprint are designed for each other: stable OS, enforced configuration, long operational life.

What's New on the Platform Since the January Beta

PPKG-based seamless enrollment shipped in Esper DevRel 192. The Windows platform devices enroll into has been building since the January 2026 beta. Here is what has been added since then. For the complete Windows feature set, see the Windows device management overview.

EXE app management. The beta launched with MSI support; EXE app management is now live alongside it. Together they cover the overwhelming majority of Win32 LOB applications running on dedicated Windows device fleets. If your POS software, kiosk application, or signage player ships as an installer, Esper deploys and updates it.

Remote control built for kiosk support. Remote Viewer now supports full keyboard shortcut injection — CTRL+SHIFT+R to hard-refresh a browser session, WIN+D to reach the desktop on a frozen device — and the full-screen viewport fills the operator's display rather than letterboxing the device stream. For support teams recovering kiosk devices without dispatching a tech, that is the difference between a remote session that resolves an incident and one that still requires a truck roll.

Multi-script execution and WNS. Background script support is live with multi-script execution: PowerShell scripts deployed via Blueprint, running on enrollment, on schedule, or on demand. Windows Notification Service integration means commands dispatched from the console reach devices immediately rather than waiting on the next check-in cycle. For fleet commands like reboot, WNS is what makes the console feel responsive at scale.

Windows Update scheduling, Remote File Manager, automatic device certificate renewal, and data-folder preservation across agent upgrades round out the platform. The Windows device management page covers them in full.

Who This Is For

The right fit:

Windows IoT Enterprise LTSC, Windows IoT Enterprise, and Windows Enterprise SKUs. Win32 app-based fleets. POS terminals, self-service kiosks, digital signage, healthcare terminals, warehouse devices. No Entra ID required, no domain join, no Microsoft Store dependency.

Windows Pro is supported for operators who need it, though IoT Enterprise LTSC is the right SKU for dedicated device deployments. It carries the management APIs, the lockdown capabilities, and the long-term servicing model that Pro does not.

If your devices run one application, continuously, across a fleet of locations, and you need to manage that fleet without enterprise identity infrastructure, this is built for you.

Not the right fit:

Windows Home and Windows Server are not supported, and we have not validated on the Windows Education editions. BYOD and corporate employee laptop scenarios are not what this platform is designed for.

OEM partners building Windows IoT hardware for enterprise operators: the Esper partner team wants to talk about factory image integration.

Get Started

PPKG-based seamless enrollment is available now across all Esper tenants.

If you are already an Esper customer, Windows management is in the same console you use today.

If you are evaluating Esper for a Windows dedicated device fleet, request a demo or sign up to try it.

For OEM factory image integration, contact the partner team.

Frequently Asked Questions

What is PPKG-based seamless enrollment for Windows?

Esper's PPKG-based seamless enrollment lets operators provision Windows IoT Enterprise LTSC devices to their Esper tenant and Blueprint on first boot, with no Autopilot, no Entra ID, and no IT touch required. A Provisioning Package generated in the Esper console is embedded in an image or loaded on a USB stick. When the device starts up, it self-enrolls, matches its pre-registered serial to the correct tenant, and Blueprint convergence begins automatically.

Is PPKG-based seamless enrollment the same as Esper Seamless Provisioning?

No. They are counterparts, not the same product. Esper Seamless Provisioning is the Android and Linux first-boot provisioning product. PPKG-based seamless enrollment is the Windows-native equivalent, built on the Windows Provisioning Package mechanism. They share the same outcome — devices self-provision on first boot with no IT touch — but use different underlying mechanisms, and Seamless Provisioning does not cover Windows.

How is this different from Windows Autopilot?

Autopilot requires Entra ID and Microsoft identity infrastructure; it is designed for corporate employee devices tied to user accounts. Esper's PPKG-based seamless enrollment has no identity infrastructure dependency. It is built for dedicated devices that run one application continuously with no end-user login. If your device will never have an Entra ID account, Autopilot is the wrong tool and PPKG-based seamless enrollment is designed for that scenario.

What Windows SKUs are supported?

Windows IoT Enterprise LTSC is the primary target SKU; it provides a 10-year support lifecycle with no forced feature updates, which is the right choice for dedicated devices expected to run reliably for years. Windows IoT Enterprise, Windows Enterprise, and Windows Pro are also supported. Windows Home and Windows Server are not supported. We have not validated on the Windows Education editions.

What happens after a device enrolls?

Enrollment is a one-time event. Once a device is enrolled, Esper Blueprint convergence provisions it to its desired operational state: apps, update policy, network config, scripts, remote access. Blueprint is continuous, so if a device drifts from desired state it gets corrected. The PPKG fires once; Blueprint runs for the life of the device.

Can I use this to migrate devices from another MDM?

Yes. If your fleet is already enrolled in another MDM, that MDM can push the Esper PPKG alongside a PowerShell script that handles unenrollment from the current platform and Esper enrollment in sequence. Contact the Esper team for help scoping the migration script for your environment.

What if I have unmanaged Windows devices already in the field?

A remote PowerShell script can download the PPKG from a cloud storage location and run the Install-ProvisioningPackage cmdlet silently on any Windows machine where you have local admin or remote execution access. No USB required, no physical access to the device. Contact the Esper team for help setting this up.