Microsoft is turning the final pages of the Windows 11 Out-of-Box Experience into a mandatory patch checkpoint. Starting with the September 2025 security update, enterprise-managed devices that are Entra-joined will automatically download and install the latest cumulative quality updates before any user ever reaches the desktop. The move, surfaced through Windows Autopilot’s Enrollment Status Page (ESP), closes the infamous “day-one patch gap” but forces IT teams to overhaul provisioning workflows, bandwidth planning, and failure recovery from the ground up.

For years, a freshly unboxed or reimaged PC would sit vulnerable for hours—or days—until the first manual or scheduled update cycle kicked in. With this change, the OOBE flow itself becomes the enforcer of organizational update policies. Devices will query Windows Update during the final setup page, fetch applicable quality updates (monthly cumulative security and reliability fixes), and may reboot multiple times before handing control to the end user. The capability is managed through a toggle inside the ESP profile in Microsoft Intune, with equivalent MDM and Group Policy options for non-Intune environments.

How the new OOBE update sequence works

The updated OOBE logic injects itself at the very end of the setup wizard—after language selection, network connection, and account setup but before the first sign-in. When the device reaches the final page, it performs a Windows Update scan. If quality updates are available and applicable, they are downloaded and installed immediately. The device may restart one or more times, then resume OOBE and continue to the desktop. Administrators can observe the progress through the ESP, which now displays “Installing Windows quality updates” as an additional step.

This is not a sneak preview of feature updates. Microsoft has deliberately scoped the mechanism to quality updates only: the monthly LCU/SSU combined packages that deliver security patches and non-security bug fixes. Feature updates—the big annual releases—and broad driver rollouts are excluded, keeping the OOBE footprint manageable and reducing the risk of sudden compatibility shocks at first boot. The same WU scan also respects any Windows Update for Business deferral or pause policies synced to the device during enrollment, so organizations retain control over which updates land.

Eligibility and technical prerequisites aren’t universal

Not every Windows 11 machine will suddenly start patching itself during setup. The capability is explicitly limited to:

  • Windows 11 version 22H2 or later, across Pro, Enterprise, Education, and SE editions.
  • Devices that are Microsoft Entra-joined (formerly Azure AD joined) or Entra hybrid-joined and under MDM management.
  • Devices that either ship with the necessary OOBE servicing code baked in by the OEM or are imaged with the June 2025 non-security servicing package (or any later update).

Microsoft began rolling out the supporting code in the August backup servicing window and designated the September 2025 security update as the trigger point where the behavior becomes default for new ESP profiles. If your image is older and doesn’t include that servicing payload, the device won’t even attempt an OOBE update—the toggle simply won’t function. For offline provisioning, the scan will skip if no internet is available, leaving the device on its baseline until a later managed update.

The Intune ESP toggle: yes by default, but only for new profiles

Inside the Microsoft Intune admin center, the control is labeled “Install Windows quality updates (might restart the device)” under the Enrollment Status Page profile settings. The fine print matters enormously:

  • New ESP profiles created after the capability ships will default to Yes (updates enabled).
  • Existing ESP profiles remain untouched and default to No until an administrator edits them.

This design decision means that organizations that spin up a fresh ESP profile for a pilot or a new device group could unexpectedly enable OOBE updates, potentially overwhelming staging networks. Conversely, long-standing profiles will not suddenly surprise admins—they must actively opt in or edit the profile. Microsoft has also confirmed MDM policy and Group Policy counterparts for non-Intune MDMs, though the exact implementation may vary by vendor.

Administrators must also verify that Windows Update for Business ring assignments (deferrals, pause windows) are properly applied to enrolling devices. The OOBE update scan honors those rings, so if a device is assigned to a ring with a 7-day quality update deferral, it won’t pull the very latest cumulative update—instead, it will apply the latest update that complies with the deferral. This fine-grained control is critical for organizations that validate patches before broad deployment.

Real-world impact: time, bandwidth, and the failure elephant in the room

Community reports and early adopter telemetry paint a consistent picture of added provisioning time. Installing a typical monthly cumulative update adds anywhere from 20 to 30 minutes to the OOBE flow, depending on download speed, update size, and the number of reboots. Larger packages or devices with slow network connections can push that well beyond 30 minutes. For a fleet of hundreds of machines being unboxed simultaneously, the sum of those minutes quickly becomes hours of idle time—and that’s assuming nothing fails.

Bandwidth is the other silent bottleneck. If a staging floor of 200 identically configured laptops all hit the same wireless network to pull the same 700 MB cumulative update, the result can saturate the link and delay every device. Microsoft’s guidance—and community wisdom—urges IT teams to deploy delivery optimization strategies: Windows Delivery Optimization peer-to-peer, BranchCache, local WSUS or SCCM distribution points, or even preloading the MSU packages into the image itself. For bandwidth-constrained branch offices, this is not optional; it’s a prerequisite.

And then there’s failure recovery. A failed update during OOBE doesn’t just delay provisioning—it can halt it entirely, leaving the device in a broken loop that requires technician intervention. The expanded attack surface of a full cumulative install at this early stage introduces new potential points of failure: driver incompatibilities, disk space exhaustion, or simple network drops. Microsoft’s message center guidance explicitly recommends extending temporary access password lifetimes and Autopilot/ESP timeouts, preparing offline recovery media with the latest SSU/LCU payloads, and running small-cohort pilots with robust telemetry before broad rollout.

A security win with operational strings attached

From a security standpoint, the logic is airtight. Cutting the window between device unboxing and fully patched state from days or weeks to minutes dramatically reduces the chance of an opportunistic exploit against a known vulnerability. Devices that inherit Windows Update for Business policies reach a tenant-approved baseline before any interactive user logon, and the feature eliminates the post-enrollment patch/reboot shuffle that often generates help-desk calls. For regulated industries or high-security environments, this shift makes devices resilient at the moment of first use.

But the security upside carries residual risks that IT leaders cannot ignore. If a monthly update introduces a regression—say, breaking a critical VPN driver or causing blue screens on a specific model—every new device processed through OOBE will be dead on arrival. Over-reliance on network connectivity widens the gap between well-provisioned headquarters and bandwidth-starved remote locations, where the feature could stall enrollments for hours. And the default-on behavior for new ESP profiles could cause nasty surprises for teams accustomed to creating test profiles on the fly without auditing every toggle.

Consumer devices and unmanaged PCs are not in scope, though the line blurs slightly: consumer OOBE already attempts dynamic updates if an internet connection is detected, but without the policy-driven enforcement or ESP visibility. Microsoft’s enterprise change is distinct because it puts the organization—not the user—in control.

Imaging and offline workflows feel the squeeze

For shops that build and maintain gold images, the new OOBE update logic demands a hard look at servicing. Images must now include the June 2025 (or later) servicing payload; otherwise, devices enrolled through Autopilot won’t even recognize the ESP update toggle. Offline or air-gapped provisioning becomes more complex: without internet access, the device cannot fetch updates, so IT must either prestage the latest cumulative packages into the image using DISM, or establish a local distribution point (WSUS/SCCM) that the provisioning network can reach.

The guidance is clear: offline media should be built with the latest SSU and LCU already applied, and technicians should carry up-to-date recovery images that include those same payloads. For many imaging teams, this means one more monthly validation step alongside the usual driver and firmware updates.

The rollout checklist IT teams need today

No administrator should flip the switch on OOBE updates without a deliberate, phased plan. A pragmatic checklist emerges from both Microsoft’s documentation and community experience:

  1. Inventory and verify prerequisites. Confirm all target devices run Windows 11 22H2 or later and fall under a supported SKU. Check that images include the June 2025 non-security servicing package; if not, plan to inject the August 2025 OOBE ZDP or later before enrollment.
  2. Audit ESP profiles now. Existing profiles will not change, but any new profile created after September 2025 will default to on. Edit defaults as appropriate, and consider locking profiles to avoid accidental changes.
  3. Deploy a small-cohort pilot. Select a representative mix of hardware models and network conditions, enable OOBE updates in a dedicated ESP profile, and monitor update compliance, OOBE duration, restart counts, and failure modes closely.
  4. Plan for bandwidth. Implement Delivery Optimization or a local update source. Schedule mass unboxings during off-peak hours and verify network capacity for concurrent downloads.
  5. Strengthen recovery runbooks. Prepare offline media with the latest cumulative updates. Extend Autopilot timeouts and temporary access password lifetimes. Train help-desk staff on troubleshooting failed OOBE update scenarios.
  6. Communicate openly. Let stakeholders and end users know that initial setup will take longer and explain the security rationale. Provide clear instructions for returning a bricked device to IT.

These steps aren’t just advisory—they are the difference between a smooth security upgrade and a help-desk firestorm.

Measuring success with hard numbers

Once OOBE updates are live, IT leaders should track a few key performance indicators to judge whether the security gains justify the operational cost:

  • First-sign-in compliance rate: the percentage of devices that reach the desktop with the intended update baseline already installed.
  • Average OOBE time: compare pre-change baselines with post-change durations to quantify the added overhead.
  • Update failure rate during OOBE: categorize root causes—network timeouts, package compatibility, driver conflicts—to target fixes.
  • Help-desk ticket volume in the first week of provisioning: watch for spikes that correlate with update-related issues.
  • Bandwidth utilization on provisioning networks: confirm that delivery optimization is keeping peak consumption under control.

These metrics will tell the real story of whether baked-in OOBE updates deliver a net positive or become a logistical headache.

The bigger picture: a new baseline for endpoint provisioning

Microsoft’s move is part of a broader industry push to shift security hardening as far left in the device lifecycle as possible. Apple’s Automated Device Enrollment and Google’s zero-touch enrollment have long emphasized immediate compliance checks. Embedding quality updates directly into the Windows OOBE flow closes a gap that enterprises have tolerated for too long. For OEMs and third-party MDM vendors, the focus will now shift to ensuring their images include the necessary servicing payloads and that their tools provide clear telemetry and recovery options.

Done right, this change sets a new expectation: no managed Windows 11 device should ever be handed to a user in a demonstrably insecure state. Done poorly, it becomes yet another source of provisioning pain and Help Desk aggravation. The difference lies entirely in preparation. Review your Intune ESP profiles today, update your images, pilot relentlessly, and build the operational muscle to handle failures before they happen. The September 2025 default is coming—whether your fleet is ready is up to you.