Primary Refresh Token (PRT) explained: fixing SSO and repeated sign-in prompts

When users on Microsoft Entra joined or hybrid joined Windows devices are asked to sign in again and again in Outlook, Teams or the browser, the Primary Refresh Token (PRT) is the first thing I check. In this post I'll explain what the PRT does, how to read its state, and how to fix the usual reasons it goes missing or stale.

How it works#

The PRT is an artifact that Microsoft Entra ID issues to Microsoft's own token brokers so they can get tokens for apps without prompting. On Windows, two components handle it:

• Microsoft Entra CloudAP plugin: requests the PRT during Windows sign-in on Entra joined and hybrid joined devices, and caches it.
• Microsoft Entra WAM plugin: uses the PRT when apps ask Web Account Manager for tokens, and injects it into supported browsers for SSO.

A few properties explain most of the behavior you'll see:

• Bound to the device. Requests are signed with keys created at device registration, protected by the TPM where available. If those keys become unusable, the PRT can't be used.
• Long-lived, constantly renewed. A PRT is valid for 90 days and keeps renewing while the device is in use. CloudAP renews it every four hours during Windows sign-in, and WAM can renew it during app token requests.
• Asynchronous on hybrid joined devices. On-premises AD stays the primary authority, so the user reaches the desktop first and the PRT is acquired in the background. That's why a hybrid user can sign in fine and still have no SSO.
• MFA claim. Signing in with Windows Hello for Business gives the PRT an MFA claim. After a password sign-in, an app may prompt for MFA and the renewed PRT then carries the claim.
• Conditional Access isn't evaluated when the PRT is issued or renewed; it's evaluated when apps request tokens with it.
• Invalidated when the user or the device is deleted or disabled, when the password behind a password-based PRT changes, or when TPM keys become inaccessible.

In browsers on Windows, Microsoft Edge uses the PRT natively (with the user signed in to the profile), Chrome via the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy, and Firefox 91+ once "Allow Windows single sign-on for Microsoft, work, and school accounts" is on. Private browsing windows don't use it.

Step-by-step: check and fix the PRT#

1. Check the SSO state as the user#

Open a normal, non-elevated prompt in the affected user's session:

dsregcmd /status

In the SSO State section, AzureAdPrt : YES means a PRT exists. Then look at AzureAdPrtUpdateTime (UTC). If it's more than four hours old, renewal is failing: lock and unlock the device to force a refresh and check whether the time moves.

2. Read the PRT diagnostics#

On Windows 10 21H1 and later, a failed attempt since the last successful update is reported under AzureAdPrt:

AzureAdPrt               : NO
AcquirePrtDiagnostics    : PRESENT
Attempt Status           : 0xc000006d
Credential Type          : Password
HTTP status              : 400
Server Error Code        : invalid_grant
Server Error Description : AADSTS50126: Error validating credentials due to invalid username or password.

Combine the attempt status with the server error:

In federated tenants, the identity provider must support WS-Trust; with AD FS, the usernamemixed endpoints must be enabled, otherwise the PRT can't be issued or renewed.

3. Dig into the AAD event logs#

The CloudAP plugin logs errors to Applications and Services Logs › Microsoft › Windows › AAD › Operational and informational events to the Analytic log beside it. To see the Analytic log, select View › Show Analytic and Debug Logs in Event Viewer, then enable the log. Events worth knowing:

• 1006 and 1007 (Analytic): start and end of a PRT acquisition; 1007 holds the final error code.
• 1081 and 1088 (Operational): server errors from Entra ID or the WS-Trust endpoint.
• 1022 (Analytic) and 1084 (Operational): the URL being called and the network sub-error.
• 1144 (Analytic): the UPN that was sent, useful for UPN problems.

Get-WinEvent -LogName "Microsoft-Windows-AAD/Operational" -MaxEvents 100 |
    Where-Object { $_.Id -in 1081, 1084, 1088 } |
    Format-List TimeCreated, Id, Message

4. Fix the browser path#

If apps work but the browser keeps prompting, confirm the user is signed in to their Edge profile with the work account, or deploy the Chrome extension or policy and Firefox's WindowsSSO policy through Intune.

Verify#

• dsregcmd /status shows AzureAdPrt : YES, a recent AzureAdPrtUpdateTime and an AzureAdPrtExpiryTime in the future.
• After a lock and unlock, the update time changes.
• In the sign-in logs, the user's browser sign-ins show the device ID and join type on the Device info tab, and apps open without prompting.

Tips & gotchas#

• Run dsregcmd /status as the user, not elevated. The SSO State reflects the account running the command, and some user fields can show errors from an elevated prompt.
• On shared devices, the PRT diagnostics may come from another user's attempt.
• If DeviceAuthStatus isn't SUCCESS, fix the device first. A deleted or disabled device can't get a PRT.
• Non-Microsoft credential providers aren't supported for PRT issuance and renewal.
• A Conditional Access sign-in frequency control forces re-authentication by design, so those prompts aren't a PRT fault.

References#

• Understanding Primary Refresh Token (PRT) in Microsoft Entra ID
• Troubleshoot Microsoft Entra hybrid joined devices (includes PRT troubleshooting)
• Troubleshoot devices by using the dsregcmd command