Microsoft is giving enterprise IT teams a long-awaited lever to close the day-one patching gap: the ability to install Windows quality updates during the Out-Of-Box Experience itself. Starting with the September 2025 security update, eligible Entra‑joined and Entra hybrid‑joined Windows 11 devices can emerge from provisioning already current with the latest cumulative fixes—provided administrators flip the right switches and accept the operational trade‑offs.

The capability, delivered through Windows Autopilot’s Enrollment Status Page and controllable via Microsoft Intune, marks a significant shift in how newly deployed endpoints reach a trusted state. Instead of a post‑provisioning scramble of reboots and helpdesk calls, the device does the heavy lifting before the first user ever sees the desktop. But the rollout demands careful choreography: longer provisioning times, potential credential expiry, and the very real risk of baking a buggy update straight into the fleet.

The Long Road to Day-One Compliance

For years, the Windows provisioning journey has contained a quiet absurdity: a machine fresh from the factory or imaging bench would complete OOBE, enroll in management, and then immediately demand a round of updates and restarts. That gap left devices exposed between first sign‑in and patch application, with security teams cringing at every new endpoint hitting the floor.

Microsoft signalled its intent to fix this in stages throughout 2024 and 2025. The plan, now materialising, uses a policy control that instructs an Entra‑joined device to query Windows Update on the final OOBE screen, pull down approved quality updates, and apply them while still in setup mode. The mechanism is scoped deliberately: monthly cumulative updates (security and reliability fixes) and critical zero‑day patches are in scope; feature updates and broad driver rollouts are not. That focus keeps the OOBE patch window lean and reduces the risk of introducing larger‑scale change during provisioning.

What the Feature Actually Does

The official details are straightforward but layered with conditions. Microsoft will make the behaviour available alongside the September 2025 Windows security update, and administrators can toggle it via an Enrollment Status Page profile setting in Microsoft Intune.

  • Eligible devices: Windows 11 version 22H2 or later, on Pro, Enterprise, Education, or SE SKUs. Devices must be Microsoft Entra‑joined or Entra hybrid‑joined and managed by Intune (or an MDM that supports ESP controls).
  • Admin control: The new ESP profile toggle reads “Install Windows quality updates (might restart the device)” and sits under Devices > Enrollment > Enrollment Status Page in the Intune admin center. New ESP profiles default to Yes; pre‑existing profiles default to No, so admins must explicitly edit older profiles to enable the behaviour.
  • Prerequisites: The device must carry specific servicing payloads. Machines imaged with the June 2025 Windows non‑security update will already include the new setting, and devices that receive the August 2025 OOBE zero‑day patch will likewise expose the capability. Without those platform updates, the ESP option simply won’t appear.
  • Policy alignment: The OOBE update flow honours Windows Update for Business deferral and pause settings already configured for the tenant. So existing update‑ring policies are respected from the outset.

Step by Step Through the New OOBE Flow

  1. The device boots and progresses through OOBE until the final screen, where the new update check triggers.
  2. It connects to Windows Update using the network established during OOBE, queries for applicable quality updates, and downloads any approved packages.
  3. If updates are found, the device installs them while still in OOBE and may restart one or more times to complete the installation.
  4. Once installation finishes, setup resumes and the first user signs into a device that, in theory, is current with the tenant’s approved quality updates.

Two important constraints govern the process: feature updates and broad driver updates are excluded, and the entire flow can be enabled or disabled through ESP profiles in Intune (or equivalent MDM/Group Policy controls where available).

Why Admins Should Care

The value proposition is compelling on paper:

  • Day‑one security: New endpoints enter the environment with the latest security fixes applied, shrinking exposure windows and boosting initial compliance posture.
  • Fewer helpdesk incidents: Cutting out the post‑provisioning patch‑and‑reboot cycle means fewer surprise restarts and fewer immediate support tickets.
  • Policy consistency from the start: Because the ESP behaviour syncs with Windows Update for Business deferral and pause settings, devices behave consistently with organisational update rings during provisioning.

For security-conscious teams, that translates into cleaner enrollment baselines and a reduced attack surface during those critical first hours after unboxing.

Prerequisites and Preflight Checks

Before enabling the feature, administrators should verify several prerequisites:

  • OS and SKU: Windows 11 22H2 (or later) on Pro, Enterprise, Education, or SE.
  • Join type and management: Entra‑joined or hybrid‑joined, enrolled in Intune or an ESP‑capable MDM. Environments using Autopilot device preparation without device ESP may lack the ability to disable OOBE updates.
  • Servicing baseline: Images must include the June 2025 non‑security update, or the device must receive the August 2025 OOBE zero‑day patch so the ESP setting is present.
  • Network and power: Devices require reliable internet access during OOBE and should remain plugged into power to avoid disruptions during downloads and reboots.

Missing any of these elements can render the feature unavailable—or worse, cause unexpected behaviour during provisioning.

The Trade‑Offs That Deserve a Spotlight

The capability is not a free lunch. It shifts risk from the post‑provisioning phase into the provisioning phase, and the costs become visible in real‑world scenarios.

Longer Provisioning Times

Microsoft openly warns that applying updates during OOBE may take 30 minutes or more in some cases. The actual duration depends on update size, network bandwidth, and hardware performance. Many environments will see averages of 20–30 minutes for routine cumulative updates, but pilot measurements are essential because worst‑case scenarios can stretch significantly—especially on lower‑end hardware or congested links. In high‑volume deployments (classrooms, retail desks, procurement staging areas), those extra minutes per device add up fast.

Temporary Credential Expiry

Organizations that rely on Temporary Access Passes or other time‑limited credentials must extend validity windows. If a TAP expires while the device sits in an OOBE update loop, provisioning fails and the helpdesk rings. Microsoft and community advisories have already flagged TAP expiration as a practical gotcha, and planning around it is non‑negotiable.

Network and Bandwidth Considerations

Mass downloads during OOBE can saturate networks, especially in environments where dozens or hundreds of devices are provisioned simultaneously. Pre‑staging images with the June 2025 non‑security update, using Delivery Optimization, or setting up local distribution points can mitigate the problem. But without such measures, a large rollout can turn into an unintended denial‑of‑service event.

The Very Real Danger of Buggy Updates

The August 2025 update cycle stands as a stark reminder. Microsoft’s own KB5063878 (OS Build 26100.4946) and its associated cumulative patches caused a spate of documented issues: streaming app performance degradation, broken recovery and reset functionality, and installation failures on WSUS and SCCM systems. In some reports, the update also triggered problems with certain SSDs. Microsoft subsequently issued mitigation steps and out‑of‑band emergency fixes, but the damage was done for organizations that had already pushed the updates broadly.

Applying that same class of update during OOBE means a compromised device arrives at first sign‑in already broken. The risk is amplified because the machine is essentially off‑line from management tooling during OOBE, so remediation happens only after the user is blocked. For cautious IT shops, this reality demands a staged rollout philosophy and a robust rollback plan.

Technical and Compliance Caveats

  • Timing matters: The OOBE update mechanism respects Windows Update for Business deferral and pause policies, but only if those policies are enforced before the OOBE update window begins. If app installations or other provisioning tasks delay ESP significantly, timing mismatches can let unexpected updates slip through. Admins should validate timing sequences in their Autopilot flows.
  • MDM variability: The ESP setting appears as an MDM policy, and Microsoft provides Group Policy counterparts, but third‑party MDM vendors vary in support. Verify your MDM’s ESP capability before relying on non‑Intune tooling.
  • Not all updates are offered: Microsoft retains discretion over which quality updates actually appear during OOBE. Critical zero‑day patches may still apply outside ESP controls when required for device operability, and some monthly updates might be omitted if they are deemed incompatible with the OOBE context.

A Practical Admin Checklist

Based on the experience of early adopters and the patterns from August’s turbulent updates, a methodical approach pays off:

  1. Pilot first, then scale
    - Select a small, representative device set (different OEMs, SSD types, chipsets).
    - Create a dedicated ESP profile in Intune and test the toggle both enabled and disabled.
    - Measure OOBE time, TAP behaviour, and post‑provisioning compliance reporting before expanding.

  2. Image wisely
    - Deliver devices imaged with the June 2025 non‑security update (or a later servicing image) so the ESP setting is present without forcing a fresh download during OOBE. This reduces network load and time‑in‑OOBE variability.

  3. Extend temporary credential windows
    - Increase TAP validity during enrollment when ESP installs are enabled to avoid premature expiry during lengthy update installs.

  4. Staged rollout plan
    - Start with IT and pilot groups, then expand by business unit. Consider setting new ESP profiles to No for large, sensitive rollouts until confidence is built. Remember: new ESP profiles default to Yes, so don’t assume safe defaults.

  5. Monitor update health and known issues closely
    - August 2025 showed that even security updates can introduce regressions. Maintain telemetry and a rapid rollback plan (or Known Issue Rollbacks where Microsoft provides them). Coordinate with Windows release health notices.

  6. Validate non‑Intune MDM support
    - If using a third‑party MDM, confirm it supports ESP profile behaviour parity; otherwise you may lack the ability to toggle OOBE updates or honour tenant policies correctly.

Scenarios Where the Calculus Changes

  • Education labs and kiosks: Mass provisioning often demands speed. Enabling OOBE updates could dramatically increase setup time per device. A better approach is pre‑imaging with the required servicing payloads or using an internal distribution point to throttle bandwidth.
  • Retail or frontline deployments: High volume, low tolerance for downtime. Avoid enabling OOBE updates by default for large pushes until images include the necessary patches. When OOBE updates are unavoidable, schedule provisioning outside business hours and ensure robust local caching.
  • Highly regulated environments (finance, healthcare): The security case for applying updates at OOBE is strongest here, but change control remains paramount. Pilot, approve the specific update set for OOBE, and align with compliance processes before enabling ESP installs for production groups.

Cross‑Checking the Claims

What we can independently verify:

  • Microsoft’s Windows IT Pro blog officially announces the capability, the Intune ESP setting, eligibility, and the September 2025 availability window.
  • Message center notifications (MC891223) and Intune community posts detail the admin controls, deployment timeline, and the need to plan for longer OOBE durations.
  • Community discussion and independent reporting confirm the new ESP setting exists, that prerequisite servicing updates are needed, and that the feature lands in late summer/early fall 2025.
  • The August 2025 cumulative update incidents (KB5063878 and others) are publicly acknowledged by Microsoft and widely covered, demonstrating the risks of unvetted day‑one update application.

If any claim seems inconsistent with a specific environment—for instance, whether a particular image includes the June 2025 update—validate the KB numbers and build revisions on the image against Microsoft’s documented prerequisites. Published OOBE duration estimates are indicative; rely on pilot measurements for planning.

Conclusion: A Net Win, If You Do the Homework

Microsoft’s move to inject quality updates directly into the OOBE pipeline is a genuine improvement for enterprise provisioning. The promise of patched, compliant devices at first sign‑in addresses a perennial pain point for security teams and helpdesks alike. But the capability is a tool, not a magic wand. It demands that administrators plan for longer provisioning windows, safeguard temporary credentials, and respect the reality that being first to install a cumulative update can sometimes mean being first to discover a regression.

The August 2025 update cycle—with its recovery failures, streaming app issues, and emergency fixes—serves as a concrete illustration. Staged rollouts, pilot measurements, and rollback preparedness are not optional; they are the price of admission. For organizations that pair the new ESP toggle with disciplined imaging, updated credential policies, and close monitoring of update health, the result can be a measurably stronger security baseline and fewer day‑one fire drills.

For everyone else, the default “Yes” on new ESP profiles should give pause. Flip the switch when you’re confident—not before.