Copilot Refresh-Token Error After Unlocking Windows: Diagnose Before Resetting

Official documentation checked October 14, 2026.

If organizational Copilot asks you to sign in after Windows wakes or unlocks, record the exact error before changing anything. The timing does not prove that locking the screen revoked a token. A browser session, an app refresh token, and Windows single sign-on can fail for different reasons.

1. Distinguish a revoked grant from a wake-up symptom

Compare the full message with Microsoft’s authentication error reference. For example, AADSTS50173 concerns a revoked grant requiring fresh authentication; AADSTS70043 concerns Conditional Access sign-in frequency; AADSTS70008 concerns inactivity expiry. Do not treat every “refresh token” message as the same condition.

On Microsoft Entra joined or hybrid-joined Windows devices, lock/unlock and Windows sign-in can participate in background Primary Refresh Token renewal. Microsoft’s PRT troubleshooting guide describes a four-hour renewal interval. This is not a rule that locking Windows revokes the token. A network failure can prevent renewal without itself being server-side revocation.

Write down whether the problem follows a short screen lock, actual sleep, a network or VPN change, or a password reset. Confirm that this is the work-account Copilot experience; pressing a Copilot key does not by itself identify which account or app opened.

2. Restore the connection and try one fresh app sign-in

1. Wait for the approved network and any required work VPN to reconnect. Confirm that another normal work service can be reached; keep security software and proxy policies enabled.
2. Save your work. Reopen the affected app or tab, then complete its sign-in prompt using the correct work account and required MFA.
3. If it keeps presenting the same revoked-grant error, use the affected app’s sign-out/sign-in option where available. Microsoft’s 50173 recovery guidance recommends app-level reauthentication.
4. Repeat the original action, then compare one normal lock/unlock cycle with the earlier failure. Record the result rather than assuming one successful prompt permanently fixed it.

A Windows sign-out or restart may interrupt unsaved work and is not guaranteed to refresh every app token. Do not disconnect the work account or leave and rejoin Microsoft Entra ID as routine wake-up troubleshooting.

3. Capture Windows evidence without changing registration

If the problem recurs on a joined or hybrid-joined device, open a normal Command Prompt while signed in as the affected user and run:

dsregcmd /status

For IT, retain the relevant join state and the SSO fields AzureAdPrt, AzureAdPrtUpdateTime, and AzureAdPrtExpiryTime. If acquisition or refresh diagnostics are present, record the attempt time, status, server error, and correlation ID. Compare before and after a controlled reproduction.

Interpret the output using Microsoft’s dsregcmd reference: user-context fields can mislead when run as another user or elevated, and these SSO checks are not universal health tests for merely registered devices. On shared devices, confirm whose failed attempt the diagnostics describe. Send identifying details only through the organization’s support channel.

If more evidence is needed, IT can collect the AAD Operational/Analytic events around the same attempt using the PRT guide. A pair of event numbers alone is not a reason to run registration-reset commands.

4. Fix the evidenced cause while retaining protection

Ask IT to correlate the failure with Entra sign-in logs, checking the client, resource, device state, and authentication result. A failure on several devices might reflect an account or policy event; it does not prove a single corrupt local cache. Conversely, a failure confined to one device warrants client, network, and Windows SSO investigation.

For a verified sign-in-frequency issue, an authorized administrator should evaluate the intended policy and test any approved adjustment. Do not exempt Copilot or lengthen sessions automatically. Microsoft’s current lifetime documentation says refresh/session-token lifetimes cannot be changed through the retired token-lifetime policy settings.

Do not enable wake timers as a token repair, disable security controls, or revoke every session merely to clear a prompt. Session revocation is itself a security action that can force fresh authentication elsewhere. Resolve the documented cause and retest the same wake scenario, preserving a record of what changed and whether the error returned.