KB5094126 Breaks Microsoft Account Sign-In in Teams, OneDrive & Edge — Complete Fix Guide

Published 27 June 2026  ·  Windows Patching  ·  Estimated read: 10 min

If users on your fleet are reporting that Microsoft Teams, OneDrive, Edge, Word, Excel, or Microsoft 365 Copilot are suddenly showing the error "You'll need the Internet for this" — despite being fully connected — and the issue appeared after Patch Tuesday on June 9 2026, you are almost certainly hitting the MSA sign-in regression introduced in KB5094126. This post walks through every affected configuration, the exact scope of the issue, and step-by-step remediation for IT admins managing Windows endpoints at scale.

What Exactly Is Breaking?

KB5094126 introduced a regression in the Web Account Manager (WAM) component of Windows, which is the underlying authentication broker responsible for MSA-based (personal Microsoft account) sign-ins across the operating system shell and first-party Microsoft applications. When WAM attempts to silently re-authenticate an MSA session after the update, the token refresh flow fails with a network-not-available error even when network connectivity is fully functional.

The symptom surfaces as one or more of the following:

• Teams Free (personal) shows "You'll need the Internet for this" on launch or when sending messages
• OneDrive personal sync stops and prompts re-authentication that subsequently fails
• Microsoft Edge signed-in profile drops its MSA sign-in state and cannot re-authenticate
• Word, Excel, and other Microsoft 365 desktop apps lose their connected services association
• Microsoft 365 Copilot (consumer tier) fails to connect to backend services
• OneDrive File Explorer integration breaks — the OneDrive folder in Explorer may disappear from the navigation pane or show a perpetual sync error badge
• On a subset of devices — primarily those using BitLocker with TPM-bound keys — the update triggers a BitLocker recovery prompt on next boot

Affected Windows Versions

The following releases are confirmed affected by the MSA WAM regression introduced in KB5094126 (June 9) and KB5079473 (March 10):

Step 1 — Confirm the Affected Build Number

Before applying remediation, confirm that the device is actually running a patched build containing the regression. Run the following one-liner from an elevated PowerShell prompt or via Intune Proactive Remediations (detection script):

# Retrieve OS build and check for the problematic and fix KBs
$os = Get-CimInstance -ClassName Win32_OperatingSystem
$build = $os.BuildNumber
$caption = $os.Caption

Write-Host "OS: $caption"
Write-Host "Build: $build"

# Check installed hotfixes for the problematic KBs
$badKBs   = @('KB5094126', 'KB5079473')
$fixKB    = 'KB5095093'

$installed = Get-HotFix | Select-Object -ExpandProperty HotFixID

foreach ($kb in $badKBs) {
    if ($installed -contains $kb) {
        Write-Warning "PROBLEMATIC KB DETECTED: $kb is installed"
    }
}

if ($installed -contains $fixKB) {
    Write-Host "FIX KB $fixKB is already installed — device is remediated." -ForegroundColor Green
} else {
    Write-Warning "FIX KB $fixKB is NOT installed — update required."
}

If the script reports that KB5094126 or KB5079473 is present without KB5095093, the device is in the affected state and requires remediation.

Step 2 — Primary Fix: Install KB5095093 via Windows Update

Microsoft released KB5095093 on June 23 2026 as a cumulative update that supersedes KB5094126 and includes the WAM authentication broker fix. This is the recommended and permanent resolution for all affected Windows versions.

Managed devices (Intune / WSUS / ConfigMgr):

• If you manage updates through Microsoft Intune, ensure your Update Ring or Feature Update policies are not pausing or deferring quality updates beyond June 23. KB5095093 should be available in the Windows Update for Business channel. Expedite the update if your ring configuration introduced a deferral period — Rudy Ooms (Call4Cloud) has a thorough breakdown of expediting specific KBs through Intune Update Rings without disrupting your broader ring strategy.
• If you manage updates through WSUS, approve KB5095093 for the affected computer groups. The update will appear under Windows 11 / Windows 10 critical updates in the WSUS console.
• For ConfigMgr (MECM) environments, synchronise your Software Update Point, then create a Software Update Group targeting KB5095093 and deploy to affected collections.

Unmanaged / standalone devices: Open Settings > Windows Update > Check for updates. KB5095093 should appear as a required quality update. Install and restart.

Step 3 — Temporary Workaround (When Immediate Update Is Not Possible)

In environments where deploying KB5095093 immediately is not feasible — for example, due to change-freeze windows, ring-based deferral policies, or WSUS approval delays — the following workarounds can restore MSA sign-in functionality without removing the problematic update.

Workaround A: Remove and Re-Add the Microsoft Account

The WAM token cache for the affected MSA becomes corrupt after the regression hits. Removing and re-adding the account forces WAM to issue a fresh token through the browser-based authentication flow, which bypasses the broken silent-refresh path.

1. Open Settings > Accounts > Email & accounts
2. Locate the personal Microsoft Account entry and select Remove
3. Confirm removal — this does not delete any data, it only removes the local credential cache
4. Select Add a Microsoft account and complete the sign-in flow in the browser window that opens
5. Relaunch the affected application (Teams, OneDrive, etc.)

Workaround B: Use Browser-Based Sign-In for Teams and OneDrive

As an interim measure, users can access Teams and OneDrive through the browser at teams.microsoft.com and onedrive.live.com. The browser-based authentication path is not affected by the WAM regression because Edge's MSA sign-in for web properties uses a separate authentication path that does not go through the broken WAM silent-refresh flow.

Workaround C: Scripted WAM Token Cache Flush (Advanced)

For IT admins who want to automate the token cache flush across a fleet without waiting for KB5095093 approval, the following script clears the WAM token cache for all user profiles on a device. This is equivalent to the manual remove-and-re-add flow but can be deployed silently via Intune Proactive Remediations or a ConfigMgr script.

# Flush WAM MSA token cache to work around KB5094126 sign-in regression
# Requires: Run as SYSTEM or local administrator
# Effect:   Users will re-authenticate on next app launch (browser flow, not silent WAM)
# Ref:      https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-11-25h2

$ErrorActionPreference = 'Stop'

# Stop apps that hold WAM token handles
$appsToStop = @('Teams', 'OneDrive', 'msedge', 'WINWORD', 'EXCEL')
foreach ($app in $appsToStop) {
    Get-Process -Name $app -ErrorAction SilentlyContinue | Stop-Process -Force
}

# Enumerate all user profiles on this device
$profiles = Get-CimInstance -ClassName Win32_UserProfile |
    Where-Object { -not $_.Special -and $_.LocalPath -notlike '*systemprofile*' }

foreach ($profile in $profiles) {
    $wamPath = Join-Path $profile.LocalPath 'AppData\Local\Microsoft\TokenBroker\Cache'
    if (Test-Path $wamPath) {
        Write-Host "Clearing WAM cache for: $($profile.LocalPath)"
        Remove-Item -Path "$wamPath\*" -Recurse -Force -ErrorAction SilentlyContinue
    }
}

Write-Host "WAM token cache flushed. Users will be prompted to re-authenticate on next app launch." -ForegroundColor Green

Peter van der Woude's blog (petervanderwoude.nl) is an excellent resource for packaging this as an Intune Proactive Remediation with a detection script that checks for the fix KB before running — avoiding unnecessary token cache flushes on already-remediated devices.

Step 4 — Resolving the BitLocker Recovery Trigger

A secondary issue introduced by KB5094126 affects a subset of devices using BitLocker with TPM-bound encryption keys. The update modifies boot measurements in a way that causes the TPM PCR (Platform Configuration Register) values to change, invalidating the sealed BitLocker key and triggering a recovery key prompt on the next boot.

This is distinct from the MSA sign-in issue and affects both MSA and Entra ID users. It is most commonly observed on:

• Devices with TPM 2.0 and Secure Boot enabled where PCR 7 is used for key sealing
• Surface devices and certain HP / Dell models with specific UEFI firmware versions
• Devices where the BitLocker policy uses PCR validation profiles that include boot manager measurements

Immediate steps if a device enters BitLocker recovery:

1. Retrieve the BitLocker recovery key from Microsoft Entra ID (for Entra-joined devices: Entra admin center > Devices > [Device name] > Recovery keys) or from Active Directory (for domain-joined devices: use Active Directory Users and Computers > right-click computer object > BitLocker Recovery)
2. Enter the 48-digit recovery key at the boot screen
3. Once booted, open an elevated PowerShell prompt and run manage-bde -protectors -adbackup C: -id {KeyID} to ensure the recovery key is backed up after the fix KB is applied
4. Install KB5095093, which includes the corrected boot measurement handling, then reboot — the TPM PCR values stabilise and BitLocker should not re-trigger recovery on subsequent boots

Step 5 — Fixing the OneDrive File Explorer Integration

Beyond the sign-in failure, KB5094126 breaks the OneDrive shell namespace extension on some configurations, causing the OneDrive folder to disappear from the File Explorer navigation pane or show a persistent error badge. This is related to a separate OneDrive shell handler registration that is disrupted by the WAM token failure. Installing KB5095093 resolves this automatically for most devices, but if the File Explorer entry does not reappear after the fix update and reboot, the following will force a re-registration:

# Re-register OneDrive shell namespace extension after KB5094126 disruption
# Run as the affected user (not SYSTEM) — shell registration is per-user

# Kill OneDrive if running
Get-Process -Name 'OneDrive' -ErrorAction SilentlyContinue | Stop-Process -Force

# Locate OneDrive executable (handles both per-user and machine-wide installs)
$oneDrivePaths = @(
    "$env:LOCALAPPDATA\Microsoft\OneDrive\OneDrive.exe",
    "$env:ProgramFiles\Microsoft OneDrive\OneDrive.exe",
    "${env:ProgramFiles(x86)}\Microsoft OneDrive\OneDrive.exe"
)

$oneDriveExe = $oneDrivePaths | Where-Object { Test-Path $_ } | Select-Object -First 1

if ($oneDriveExe) {
    Write-Host "Found OneDrive at: $oneDriveExe"
    # Reset shell integration and re-register namespace extension
    Start-Process -FilePath $oneDriveExe -ArgumentList '/reset' -Wait
    Start-Sleep -Seconds 5
    Start-Process -FilePath $oneDriveExe
    Write-Host "OneDrive reset and restarted. File Explorer integration should restore within 30 seconds."
} else {
    Write-Warning "OneDrive executable not found. Verify OneDrive is installed."
}

Verification After Remediation

Once KB5095093 is installed and the device has rebooted, verify the fix using the detection script from Step 1. Additionally, confirm end-to-end MSA sign-in by checking that:

• Teams launches without the "You'll need the Internet for this" error
• OneDrive shows a green tick in the system tray with sync active
• The OneDrive folder appears in File Explorer with proper icons
• Edge shows the signed-in profile avatar in the top-right corner
• Microsoft 365 desktop apps show the user account name in File > Account

Summary

The KB5094126 / KB5079473 MSA sign-in regression is a well-scoped issue: it affects personal Microsoft Accounts only, it is fixed by KB5095093 (June 23 2026), and it has no impact on Entra ID managed identities. The secondary BitLocker recovery trigger is broader and affects all BitLocker-enabled devices regardless of account type. For most managed environments the remediation path is straightforward — expedite KB5095093 approval and deploy. For organisations under change freeze, the WAM token cache flush script provides a usable interim workaround with minimal user impact. Michael Niehaus (oofhours.com) has noted in the Autopilot community that new Autopilot enrollments on affected builds may also exhibit MSA-linked provisioning issues during the out-of-box experience phase — another reason to prioritise KB5095093 deployment promptly.