The Primary Refresh Token (PRT): How Entra ID SSO Actually Works Under the Hood

What Even Is a PRT?

Every time a user opens Outlook, Teams, or SharePoint on a Windows device and gets signed in silently — no password prompt, no MFA challenge — the Primary Refresh Token (PRT) is doing the work. It is the centrepiece of Microsoft's SSO architecture for Entra ID, and most admins have no idea what is actually inside it.

Here is the blunt answer: you cannot see its contents. The PRT is an opaque blob issued exclusively to Microsoft's first-party token brokers. It is not a JWT you can paste into jwt.io. What matters is understanding the mechanism behind it — because when SSO breaks, that mechanism is where you need to look.

The Two Types of PRT

Not all PRTs are equal. There are two distinct types, and which one a device gets depends on whether it has an Entra ID identity at all.

The PRT itself is valid for 90 days and is continuously renewed while the device is in active use. In practice, you will never see an expired PRT on a device that is used daily — renewal happens automatically every 4 hours via CloudAP, and WAM also triggers renewal during app token requests.

The Key Pairs: What Gets Generated at Registration

When a Windows device registers with Entra ID, two cryptographic key pairs are generated. Understanding these is non-negotiable for understanding PRT security.

Device key (dk):

• dkpub — the public half. Sent to Entra ID and stored against the device object.
• dkpriv — the private half. Secured by the TPM. Never leaves the device.

Transport key (tk):

• tkpub — the public half. Sent to Entra ID.
• tkpriv — the private half. Secured by the TPM. Used for exactly one thing: decrypting the session key.

The device key signs authentication requests, proving the request came from this specific device. The transport key's only job is protecting the session key — which is where the real security model lives.

The Session Key: The Most Important Concept in PRT Security

When Entra ID issues a PRT, it also issues an encrypted session key. This is not a separate artefact you store somewhere — it is embedded inside the PRT itself.

Here is what happens, step by step:

1. Entra ID generates the session key and encrypts it with tkpub — the transport key's public half that was uploaded at device registration.
2. Only tkpriv, locked inside the TPM, can decrypt it.
3. CloudAP passes the encrypted session key to the TPM. The TPM decrypts it using tkpriv, then immediately re-encrypts it with the TPM's own internal key.
4. The re-encrypted session key is stored in CloudAP's cache. At no point does the plaintext session key exist in addressable memory.

Every subsequent request — every app token request, every PRT renewal, every browser SSO cookie — must be signed with this session key. Entra ID validates that signature on every single request against the session key it embedded in the PRT.

PRT Issuance Flow: First Sign-In on an Entra Joined Device

Here is the exact sequence of events when a user signs into a freshly Entra-joined Windows device for the first time.

How Browser SSO Works

This is the mechanism behind that magical moment when you open a browser, navigate to portal.microsoft.com, and find yourself already signed in.

1. The browser loads a list of allowed Entra sign-in URLs from the registry.
2. When it hits an Entra sign-in URL, it calls a native client host.
3. The native client host asks the CloudAP plugin for a PRT cookie.
4. CloudAP signs the PRT cookie using the TPM-bound session key.
5. The browser sends the cookie in the x-ms-RefreshTokenCredential request header.
6. Entra ID validates the session key signature and issues a session cookie.

The session cookie is bound to the same session and device key. If an attacker intercepts the x-ms-RefreshTokenCredential header and tries to replay it from a different device, Entra ID rejects it — the session key signature will not validate without the TPM.

MFA Claims and Windows Hello for Business

The PRT carries MFA claims, and how those claims get in matters for Conditional Access.

With Windows Hello for Business, the MFA claim is granted at every PRT renewal. WHfB satisfies MFA by definition — the biometric or PIN unlock is a cryptographic operation against a TPM-bound key. Because PRT renewals happen every 4 hours, the MFA claim is continuously refreshed. Users with WHfB never hit an MFA re-prompt for Microsoft 365 apps.

With interactive MFA through WAM, the claim is granted once and persists based on the directory's token lifetime policies. It does not renew automatically with each PRT renewal.

PRTs are also partitioned by credential type. A user who has both a password and WHfB gets separate PRTs — one per credential. Each carries its own claims based on how the authentication was performed.

How App Tokens Work — WAM Behaviour

Apps on Windows do not get direct access to the PRT. WAM (Web Account Manager) sits in the middle, and this is intentional.

When an app needs an access token:

1. WAM checks its cache. If a valid refresh token for that app exists, WAM uses it — signing the request with the session key — to get a new access token.
2. If no refresh token exists, WAM uses the PRT directly to acquire both an access token and a new refresh token for that app.
3. The app gets the access token only. Refresh tokens are stored in WAM's cache, encrypted by DPAPI.

Apps never see or store refresh tokens themselves. This is why token theft from application storage is significantly harder on Windows than on platforms without WAM.

Checking PRT Status with dsregcmd

The single most useful command for PRT troubleshooting is dsregcmd /status. Run it as the user whose PRT you want to inspect — not as admin.

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

         AzureAdPrt : YES
AzureAdPrtUpdateTime : 2026-07-07 08:14:33.000 UTC
AzureAdPrtExpiryTime : 2026-10-05 08:14:33.000 UTC
   DeviceAuthStatus : 0x0

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

       AzureAdJoined : YES
      EnterpriseJoined : NO
          DomainJoined : YES
        DomainName : CONTOSO
        TpmProtected : YES
         DeviceId : 4a7b3c2d-1e8f-4a6b-9c0d-2e3f4a5b6c7d
      Thumbprint : 3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9E0F1A2B

# Run as the signed-in user (not as admin) to get that user's PRT state
$output = & "$env:SystemRoot\System32\dsregcmd.exe" /status
$fields = @('AzureAdPrt', 'AzureAdPrtUpdateTime', 'AzureAdPrtExpiryTime',
             'DeviceAuthStatus', 'TpmProtected', 'AzureAdJoined')
$result = [ordered]@{}
foreach ($field in $fields) {
    $line = $output | Select-String "^\s*$field\s*:"
    if ($line) {
        $result[$field] = ($line.Line -split ':\s*', 2)[1].Trim()
    }
}
[PSCustomObject]$result
if ($result['AzureAdPrt'] -ne 'YES') {
    Write-Warning "No PRT found for current user. Check Entra join status and licensing."
}
if ($result['TpmProtected'] -ne 'YES') {
    Write-Warning "PRT is NOT TPM-protected. Keys are software-bound and extractable."
}

Checking TPM and Virtualisation-Based Security Status

# Check Virtualisation-Based Security status
# 0 = Disabled  |  1 = Enabled, not running  |  2 = Running
$vbs = (Get-CimInstance -ClassName Win32_DeviceGuard `
         -Namespace 'root\Microsoft\Windows\DeviceGuard').VirtualizationBasedSecurityStatus
Write-Host "VBS Status: $vbs" -ForegroundColor (if ($vbs -eq 2) { 'Green' } else { 'Red' })

$tpm = Get-CimInstance -ClassName Win32_Tpm `
         -Namespace 'root\CIMv2\Security\MicrosoftTpm' -ErrorAction SilentlyContinue
if ($null -eq $tpm) {
    Write-Warning "No TPM found. PRT private keys will be software-bound."
} else {
    Write-Host "TPM Version : $($tpm.SpecVersion)"
    Write-Host "TPM Enabled : $($tpm.IsEnabled_InitialValue)"
    Write-Host "TPM Activated: $($tpm.IsActivated_InitialValue)"
}

Reading PRT Events from the AAD Event Log

When you need to see exactly when a PRT was issued, renewed, or why it failed, the AAD operational log is your source.

# Requires admin rights to read the AAD Operational log
$logName = 'Microsoft-Windows-AAD/Operational'
$events = Get-WinEvent -LogName $logName -MaxEvents 200 -ErrorAction SilentlyContinue |
           Where-Object { $_.Id -eq 1098 } |
           Select-Object TimeCreated, LevelDisplayName, Message -First 50
if ($null -eq $events) {
    Write-Warning "No events found. Enable with: wevtutil sl Microsoft-Windows-AAD/Operational /e:true"
} else {
    $events | Format-List
}

PRT Invalidation — When a PRT Stops Working

Common Issues and Their Root Causes

AzureAdPrt: NO

The device has no PRT. Most common causes: the device is not Entra joined at all, the user account is not licensed, or there is a federation issue preventing the initial auth request from completing. Check AzureAdJoined: YES first. If the device is joined but the PRT is still missing, look at the AAD Operational log for errors around Event ID 1098.

DeviceAuthStatus: 0x1

Device key validation failed. This almost always means the device was deleted from Entra ID and re-registered, but the old PRT was not cleared. The PRT on the device references a device key that no longer exists in Entra ID. Unjoin and rejoin the device to generate fresh keys.

PRT Present but SSO Not Working

The device has a valid PRT, but apps still prompt for credentials. The most likely culprit is a session key mismatch — the session key embedded in the PRT does not match what the TPM can produce. This happens after a device re-registration where the TPM generated new keys but the old PRT was not replaced. Force a new PRT by running dsregcmd /leave followed by dsregcmd /join, or by signing out and back in.

Non-Microsoft Credential Providers

Third-party credential providers are not supported for PRT issuance or renewal. CloudAP only processes credentials from Microsoft's own credential providers. If you are deploying third-party credential providers, verify that Windows Hello for Business or standard Microsoft password/PIN providers remain available and are used for at least one sign-in session to establish the PRT.

ADFS and Hybrid Renewal — No VPN Required

PRT renewal for ADFS-federated users does not require VPN or direct line-of-sight to a domain controller. Renewal only needs access to two ADFS endpoints:

• /adfs/services/trust/2005/usernamemixed
• /adfs/services/trust/13/usernamemixed

These endpoints are accessible over the internet via the Web Application Proxy. PRT renewal for remote users works without any VPN infrastructure — worth noting when justifying the removal of always-on VPN in hybrid configurations.

Device Registration Key Visualisation

What Stealing a PRT Actually Gets You

On a TPM-equipped device: nothing useful. Every request made with the PRT must be signed with the session key, and the session key is re-encrypted by the TPM using its own internal key. You cannot produce a valid session key signature without the TPM. An attacker who extracts the PRT blob from memory has a token they cannot use.

On a device without TPM: full account compromise. The keys are stored in software. The session key can be reconstructed. An attacker with the PRT blob and the session key material can forge signed requests and achieve SSO for every Microsoft 365 service the user has access to, from any machine, for up to 90 days.

This is why TPM 2.0 is non-negotiable in a Zero Trust device posture. The device compliance claim in your Conditional Access policies is worth far less without the cryptographic binding the TPM provides.

Conditional Access and the PRT — The Exact Interaction

The device compliance claim and MFA claim that your CA policies rely on come from the PRT. When a user signs in and the PRT is issued, CA policies are not evaluated. The PRT accumulates claims — device compliance status, MFA from WHfB or interactive MFA, registered device status. When WAM subsequently requests an access token for an app, Entra ID evaluates the CA policy at that moment against the claims in the PRT.

This is the mechanism behind seamless CA enforcement on managed devices: the user gets access tokens silently because the TPM-bound PRT carries the claims that satisfy the policy, and WAM handles the token exchange entirely in the background.

References

• Microsoft Learn — What is a Primary Refresh Token?
• Microsoft Learn — How device registration works in Entra ID
• Microsoft Learn — Conditional Access conditions