Windows 11 OOBE Quality Updates: KB5065813, KB5065847, KB5065848 Explained

Microsoft has pushed targeted Out‑of‑Box Experience (OOBE) updates for Windows 11 in late August 2025—delivering KB5065813, KB5065847 and KB5065848—to change how new and freshly imaged devices handle day‑one servicing and enrollment during initial setup.

Background​

Microsoft has been reworking the Windows 11 setup flow to close the “day‑one patch gap” — the window between first boot and the first secured, compliant sign‑in — by introducing a managed OOBE update stage that can apply quality updates during the final OOBE page. This initiative is folded into Autopilot/Enrollment Status Page (ESP) controls and exposed to administrators via Intune and equivalent MDM/GPO surfaces.
The overall design is explicitly scoped: the OOBE step targets quality updates (LCU + SSU) and emergency zero‑day patches where necessary, but intentionally excludes feature updates and mass driver rollouts to limit risk during provisioning. Eligible devices must meet specific prerequisites such as running Windows 11 version 22H2 or later and being Microsoft Entra‑joined (Azure AD) or Entra hybrid‑joined with MDM management.
Administrators should note that new ESP profiles created after the relevant servicing payloads are present will default to enabling the OOBE quality‑update step; existing ESP profiles retain their previous settings and must be edited to opt in. This default behavior is an important deployment control to avoid accidental rollouts.

---

What Microsoft shipped: KB5065813, KB5065847, KB5065848​

KB5065813 — 22H2 / 23H2 OOBE servicing (published August 26, 2025)​

KB5065813 is an OOBE servicing package targeted at Windows 11 versions 22H2 and 23H2. It delivers two tightly related outcomes: first, it enables the capability for eligible managed devices to download and apply quality updates during OOBE; second, it supplies an emergency combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) package that corrects recovery and reset regressions introduced by August 2025 cumulative rollups. Administrators must match the OOB package to their exact OS build before deployment.
Key points:

• Enables OOBE quality‑update capability for 22H2/23H2 managed SKUs.
• Delivers an OOB SSU+LCU to repair reset/cloud reinstall/remote‑wipe regressions.

KB5065847 — 24H2 OOBE quality‑update rollout (published August 29, 2025)​

KB5065847 is the OOBE update that marks the broader roll‑out for Windows 11 24H2 and Windows Server 2025: it surfaces the OOBE quality‑update step in the final page of setup for eligible, managed devices and ties that behavior to Autopilot/ESP controls in Intune. The aim is to deliver devices to users that are already patched to the tenant's approved baseline at first sign‑in.
Important characteristics:

• Runs during final OOBE, may install combined SSU+LCU where applicable, and may require one or more reboots before first sign‑in.
• Only applies to eligible, managed SKUs and device states; consumer unmanaged devices are not the primary target.

KB5065848 — 24H2 OOBE enrollment & enrollment stack update (published August 29, 2025)​

KB5065848 is a targeted OOBE update for Windows 11 24H2 (and Windows Server 2025) that updates the enrollment and management components used during OOBE (for example, DeviceEnroller.exe, MdmDiagnosticsTool.exe and policy manager artifacts). The package is applied only during OOBE (when a network connection exists) and is intended to ensure enrollment flows and the OOBE state machine behave correctly for newer 24H2 images.
Takeaway: these three KBs are complementary — KB5065813 for the 22H2/23H2 branches, KB5065847 for the 24H2 OOBE quality‑update behavior, and KB5065848 to refresh the enrollment plumbing for 24H2. Together they enable day‑one quality updates while repairing known regressions.

---

How the OOBE update flow works (step‑by‑step)​

• Device boots into OOBE and proceeds through setup until it reaches the final screen where the new update check runs.
• If the device is eligible (Windows 11 22H2+; Entra‑joined or hybrid; MDM managed) and the tenant/ESP profile allows it, the device connects to Windows Update and checks for applicable quality updates (LCU) and any required SSU.
• The device downloads and installs the applicable packages while still in OOBE; because SSU+LCU combos may be applied, the process can require one or more automated reboots.
• Once installation completes, OOBE resumes and the first user signs in to a device that is ideally at the tenant’s approved patch baseline.

Operational constraints to note:

• The OOBE update only applies when the device has a network connection during setup.
• Feature updates and broad driver rollouts are excluded from the OOBE quality step; only quality updates and critical ZDPs are targeted.

---

What this means for IT: benefits, tradeoffs, and immediate actions​

Benefits​

• Day‑one security: Devices that meet eligibility and are configured correctly will arrive to the user already patched, shrinking the exposure window for new hardware and improving compliance reporting from minute zero.
• Reduced first‑week churn: Applying quality updates during OOBE reduces the common pattern of multiple post‑enrollment reboots and help‑desk tickets in the first days of device ownership.

Tradeoffs and operational risks​

• Longer provisioning times: Field reports and Microsoft guidance suggest OOBE can add tens of minutes to setup (an average of ~20 minutes is commonly cited), with times varying by update size, network speed, and device hardware. Plan deployment runbooks accordingly.
• Network and bandwidth planning: Large batches of new devices performing OOBE updates simultaneously will place load on distribution points and Internet egress. Design staged rollouts or local caching strategies.
• Authentication timing issues: Short‑lived enrollment credentials (Temporary Access Pass codes or other TAP-like tokens) may expire before the user reaches the desktop if OOBE provisioning runs long. Administrators should extend TAP validity or adjust enrollment timing to avoid stranded devices.
• Servicing permanence: Because SSUs are combined into OOB packages, once applied they are effectively permanent and cannot be removed via wusa; administrators should treat SSU deployment as a one‑way operation.

Immediate actions (recommended)​

• Validate that images include the June 2025 non‑security servicing payload or vendor OOBE packages so the ESP option appears as expected. Test in lab before production.
• Review and update Autopilot/ESP profiles: new profiles may default to enabling OOBE quality updates, while existing profiles remain off and must be edited to opt in. Confirm the intended default in each tenant.
• Extend TAP or enrollment token lifetimes where appropriate and test the end‑to‑end enrollment flow to avoid timeouts.
• Plan bandwidth: use distribution points, pre‑staging, or staged enrollment to avoid congestion and failed provisioning.
• Update deployment runbooks to include OOBE durations and potential reboots; communicate expected provisioning time to help‑desk and business owners.

---

Deep dive: technical details and notable implementation notes​

• The KB manifests for KB5065848 show updated enrollment and MDM binaries (DeviceEnroller.exe, MdmDiagnosticsTool.exe, policymanager.dll, and multiple MDM/diagnostic DLLs), confirming that the patch targets the enrollment stack and OOBE orchestration rather than the broader servicing pipeline. These file manifest entries are visible in the official KB materials.
• The OOBE logic respects Windows Update for Business (WUfB) deferrals and tenant policies; Microsoft documented that the OOBE quality‑update step will honor configured deferrals and pause periods so it does not silently override tenant update rings. This is important for organizations using ring‑based deployments.
• For certain older devices the OOBE servicing path also modifies how enrollment signals are reported: Microsoft documented an enrollment request behavior where the ApplicationVersion is incremented by +1 relative to the BuildVersion to indicate that the device is restore‑capable after the OOBE package is applied. This subtle versioning change exists so MDM controllers can detect restore capability and respond accordingly. Administrators and MDM vendors should be aware of this change since it can affect enrollment validation logic.
• The OOBE packages that repair August 2025 recovery regressions are combined SSU+LCU payloads; administrators must ensure they deploy the correct OOB package that matches each device’s exact build number. Failure to match the build can leave devices in an inconsistent state or prevent recovery functions.

---

Consumer experience and the retail channel​

The OOBE quality‑update behavior is primarily targeted at managed enterprise scenarios, but some consumer devices may also observe additional update activity during setup if they connect to the internet during OOBE. Historically, consumer workarounds (for advanced users) such as bypassing network setup have been used to avoid OOBE online behavior; however, the enterprise feature set and Intune/ESP controls are not applicable to unmanaged Home devices. Expect consumer impact to be limited but visible on some retail hardware that was imaged with updated OOBE payloads.

---

Risks that deserve attention​

• Image hygiene: Organizations still relying on older offline images that lack the required OOBE servicing payloads will not see the ESP toggle and will be unable to benefit from the OOBE quality‑update path. Updating images ahead of mass deployment is essential.
• Enrollment failures and stuck OOBE: Mis‑aligned MDM logic, expired enrollment tokens, or mismatched OOB package builds can leave devices stuck in OOBE; documented community reports and Microsoft guidance call out this as an operational hazard. Test thoroughly and have recovery playbooks ready.
• SSU permanence and rollback complexity: Because servicing stack updates are effectively permanent once applied, accidental or premature deployment of an SSU-containing OOB package can complicate rollbacks. Treat OOB SSU+LCU rollouts with change‑control rigor.
• Bandwidth and user disruption: Large enrollments that hit the internet simultaneously may suffer slow downloads, failed installs, or extended provisioning windows—plan for staged rollouts and local caching to mitigate disruption.

---

Monitoring, telemetry and testing checklist​

• Validate images: Ensure all reference images contain the June 2025 servicing payload or vendor OOBE zero‑day package so ESP settings appear as expected.
• Lab test: Run Autopilot/ESP enrollments through your lab environment with TAP extension scenarios to validate token life and network behavior.
• Enrollment logs: Monitor Intune enrollment logs, device diagnostics output (MdmDiagnosticsTool), and Windows Update telemetry to detect partial installs or reboot loops.
• Network load: Simulate concurrent enrollments to measure bandwidth impact and tune staged provisioning or caching.

---

Balanced assessment: Why this matters and what to watch​

Strengths:

• The OOBE updates address a long‑standing operational weakness—freshly imaged or factory‑fresh devices arriving out of date—and improve security posture on day one for managed fleets. This will reduce early lifecycle help‑desk incidents and simplify compliance reporting.

Weaknesses and risks:

• The operational overhead around image updates, SSU permanence, enrollment token timing, and bandwidth planning means the change is not trivial for large deployments. Organizations without adequate lab testing, staging, and runbook updates risk user disruption and enrollment failures during rollout.

Watch for:

• Vendor guidance for OEM OOBE packages (some manufacturers will supply zero‑day OOBE payloads), Intune default behavior on new ESP profiles, and Microsoft’s continued refinement of the OOBE stage in subsequent servicing windows.

---

Final recommendations​

• Test before you roll: Validate images, ESP profiles, and enrollment token lifetimes in a lab that mirrors production scale.
• Stage your rollout: Avoid mass simultaneous provisioning to reduce network bottlenecks; leverage caching and staging where possible.
• Update runbooks: Add OOBE timing, expected reboots, and TAP extension guidance to help‑desk and deployment runbooks.
• Treat SSU deployments as irreversible: Apply change‑control rigor when deploying SSU+LCU OOB packages.
• Monitor closely: Use Intune and device telemetry to detect partial installs, enrollment timeouts, or devices stuck in OOBE and retain recovery procedures for those scenarios.

---

Microsoft’s OOBE servicing work represented by KB5065813, KB5065847 and KB5065848 is a pragmatic shift aimed at securing devices at first sign‑in and reducing early lifecycle support churn, but it raises meaningful operational questions for IT teams. With careful testing, staged deployment, and updated runbooks, organizations can gain the security benefits while avoiding the provisioning headaches this capability can introduce.

---

Source: Neowin Microsoft released KB5065848 KB5065847 OOBE (initial setup) updates for all Windows 11 PCs
Source: WinBuzzer Microsoft Releases OOBE Updates to Streamline Windows 11 Setup - WinBuzzer