{ "id": "83e3a36c-3e80-494a-bb33-94288181b593", "created_at": "2026-04-06T01:29:08.69955Z", "updated_at": "2026-04-10T03:30:33.17619Z", "deleted_at": null, "sha1_hash": "b23a02f27f8cfab7420536585f1dcb2668a7cd27", "title": "Understanding Primary Refresh Token (PRT) in Microsoft Entra ID - Microsoft Entra ID", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 290382, "plain_text": "Understanding Primary Refresh Token (PRT) in Microsoft Entra\r\nID - Microsoft Entra ID\r\nBy OWinfreyATL\r\nArchived: 2026-04-06 00:17:31 UTC\r\nA Primary Refresh Token (PRT) is a key artifact of Microsoft Entra authentication in supported versions of\r\nWindows, iOS/macOS, Android, and Linux. A PRT is a secure artifact specially issued to Microsoft first party\r\ntoken brokers to enable single sign-on (SSO) across the applications used on those devices. This article explains\r\nhow a PRT is issued, used, and protected, enhancing your security and enabling single sign-on (SSO) across\r\napplications.\r\nThis article assumes that you already understand the different device states available in Microsoft Entra ID and\r\nhow single sign-on works in Windows. For more information about devices in Microsoft Entra ID, see What is\r\ndevice management in Microsoft Entra ID?.\r\nThe following Windows components play a key role in requesting and using a Primary Refresh Token (PRT):\r\nTerm Description\r\nbroker\r\nAn identity broker is a service that acts as an intermediary between an identity\r\nproviders (IdPs) and service providers (SPs), simplifying authentication and\r\nauthorization . Web Account Manager is an example of an identity broker.\r\nCloud Authentication\r\nProvider (CloudAP)\r\nCloudAP is the modern authentication provider for Windows sign in, that verifies\r\nusers logging to a Windows 10 or newer device. CloudAP provides a plugin\r\nframework that identity providers can build on to enable authentication to\r\nWindows using that identity provider's credentials.\r\nWeb Account\r\nManager (WAM)\r\nWAM is the default token broker on Windows 10 or newer devices. WAM also\r\nprovides a plugin framework that identity providers can build on and enable SSO\r\nto their applications relying on that identity provider.\r\nMicrosoft Entra\r\nCloudAP plugin\r\nA Microsoft Entra specific plugin built on the CloudAP framework that verifies\r\nuser credentials with Microsoft Entra ID during Windows sign in.\r\nMicrosoft Entra\r\nWAM plugin\r\nA Microsoft Entra specific plugin built on the WAM framework that enables SSO\r\nto applications that rely on Microsoft Entra ID for authentication.\r\nDsreg\r\nA Microsoft Entra specific component on Windows 10 or newer, that handles the\r\ndevice registration process for all device states.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 1 of 15\n\nTerm Description\r\nTrusted Platform\r\nModule (TPM)\r\nA TPM is a hardware component built into a device that provides hardware-based\r\nsecurity functions for user and device secrets. More details can be found in the\r\narticle Trusted Platform Module Technology Overview.\r\nSingle Sign-On (SSO) - Once a user signs into their device, the PRT allows them to access Microsoft 365,\r\nAzure, and other cloud apps without requiring the user to reenter their credentials. Apps like Office,\r\nMicrosoft Edge, and Teams use the PRT via a broker to silently authenticate users, improving the user\r\nexperience, reducing the need for multiple sign-ins, and enhancing productivity.\r\nToken Acquisition - The PRT is used to request access tokens and refresh tokens for various services (like\r\nOutlook, Teams, SharePoint, etc.) via the Windows Web Account Manager (WAM) or Broker plug-ins on\r\nother platforms.\r\nConditional Access Compliance - It carries device and user claims, which are evaluated by Microsoft\r\nEntra ID to enforce Conditional Access policies (for example, requiring compliant devices, MFA, etc.).\r\nAt a high level, there are two different types of PRT artifacts.\r\nRegistered device PRTs are bound to a device that has an associated Microsoft Entra identity.\r\nUnregistered device PRTs are bound to a device that doesn't have a Microsoft Entra identity, which is\r\nassociated with an on-device cryptographic key pair generated by the client.\r\nClients always attempt to use \"registered device PRTs\" whenever possible. PRTs only satisfy device registration\r\npolicies if they're issued for registered devices. Unregistered device PRTs are used in scenarios where the device\r\ndoesn't have a Microsoft Entra identity, such as when a user signs in to a browser on a personal device or when a\r\nuser signs in to an app that doesn't support device registration.\r\nA PRT is an opaque blob sent from Microsoft Entra whose contents aren't known to any client components. You\r\ncan't see what’s inside a PRT.\r\nFor Registered device PRTs, the PRT is issued to users on registered devices. For more in-depth details on device\r\nregistration, see the article Windows Hello for Business and Device Registration. During device registration, the\r\ndsreg component generates two sets of cryptographic key pairs:\r\nDevice key (dkpub/dkpriv)\r\nTransport key (tkpub/tkpriv)\r\nPRT can only be issued when a Microsoft Entra ID broker is present. Broker is a component distributed with the\r\nfollowing apps: Intune Company Portal on macOS and Linux, Authenticator on iOS, Authenticator, Link to\r\nWindows, and Company portal on Android. On Mac, Mobile Device Management (MDM) is required to activate\r\nthe broker alongside the SSO extension profile: Apple SSO Plugin\r\nWindows\r\nmacOS\r\niOS and Android\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 2 of 15\n\nLinux\r\nIf the device has a valid and functioning TPM/Secure Hardware Storage, the private keys are bound to the\r\ndevice’s Secure Storage on supported platforms. The public keys are sent to Microsoft Entra ID during the device\r\nregistration process in order to validate the device state during PRT requests.\r\nThe PRT is issued during user authentication on a Windows 10 or newer device in two scenarios:\r\nMicrosoft Entra joined or Microsoft Entra hybrid joined: A PRT is issued during Windows sign-in\r\nwhen a user signs in with their organization credentials. A PRT is issued with all Windows 10 or newer\r\nsupported credentials, for example, password and Windows Hello for Business. In this scenario, Microsoft\r\nEntra CloudAP plugin is the primary authority for the PRT\r\nMicrosoft Entra registered device: A PRT is issued when a user adds a secondary work account to their\r\nWindows 10 or newer device. Users can add an account to Windows 10 or newer in two different ways:\r\nAdding an account via the Allow my organization to manage my device prompt after signing in to\r\nan app (for example, Outlook)\r\nAdding an account from Settings \u003e Accounts \u003e Access Work or School \u003e Connect\r\nIn Microsoft Entra registered device scenarios, the Microsoft Entra WAM plugin is the primary authority for the\r\nPRT since Windows sign in isn't happening with this Microsoft Entra account.\r\nBrowsers gain access to the PRT in multiple ways, depending on the operating system:\r\nWindows\r\nAndroid\r\niOS and macOS\r\nLinux\r\nWindows - Will pull the PRT from the broker into the browser on the following browsers:\r\nMicrosoft Edge\r\nFirefox\r\nChrome\r\nThe list of supported browsers is available here: Supported Browsers\r\nNote\r\nCustomers who enable Entra federation with non-Microsoft Identity Providers must configure those Identity\r\nProviders to support WS-Trust protocol to enable PRT issuance on Windows 10 or newer devices. Without WS-Trust for federation cases, a PRT can't be issued to users on Microsoft Entra hybrid joined or Microsoft Entra\r\njoined devices.\r\nNote\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 3 of 15\n\nFor ADFS, usernamemixed endpoints are required. If Smartcard/certificate is used during Windows sign-in,\r\nthen certificatemixed endpoints need to be configured on ADFS. windowstransport should be enabled as\r\nintranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web\r\nApplication Proxy.\r\nNote\r\nMicrosoft Entra Conditional Access policies aren't evaluated when PRTs are issued.\r\nNote\r\nWe don't support non-Microsoft credential providers for issuance and renewal of Microsoft Entra PRTs.\r\nWindows\r\nmacOS\r\niOS\r\nAndroid\r\nLinux\r\nA PRT is used by two key components in Windows:\r\nMicrosoft Entra CloudAP plugin: During Windows sign in, the Microsoft Entra CloudAP plugin requests\r\na PRT from Microsoft Entra ID using the credentials provided by the user. It also caches the PRT to enable\r\ncached sign in when the user doesn't have access to an internet connection.\r\nMicrosoft Entra WAM plugin: When users try to access applications, the Microsoft Entra WAM plugin\r\nuses the PRT to enable SSO on Windows 10 or newer. Microsoft Entra WAM plugin uses the PRT to\r\nrequest refresh and access tokens for applications that rely on WAM for token requests. It also enables SSO\r\non browsers by injecting the PRT into browser requests. Browser SSO in Windows 10 or newer is\r\nsupported on Microsoft Edge (natively), Chrome (via the Windows 10 Accounts extension) and Mozilla\r\nFirefox v91+ (Firefox Windows SSO setting).\r\nNote\r\nIn instances where a user has two accounts from the same Microsoft Entra tenant signed in to a browser\r\napplication, the device authentication provided by the PRT of the primary account is automatically applied\r\nto the second account as well. As a result, the second account also satisfies any device-based Conditional\r\nAccess policy on the tenant.\r\nOnce issued, a PRT is valid for 90 days and is continuously renewed as long as the user actively uses the device.\r\nOrganizations can require users re-authenticate in order to access resources using the Sign-in frequency session\r\ncontrol.\r\nWindows\r\nmacOS\r\niOS\r\nLinux\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 4 of 15\n\nAndroid\r\nA PRT is renewed in two different ways:\r\nMicrosoft Entra CloudAP plugin every 4 hours: The CloudAP plugin renews the PRT every 4 hours\r\nduring Windows sign in. If the user doesn't have internet connection during that time, CloudAP plugin will\r\nrenew the PRT after the device is connected to the internet and a new Windows sign in is done.\r\nMicrosoft Entra WAM plugin during app token requests: The WAM plugin enables SSO on Windows\r\n10 or newer devices by enabling silent token requests for applications. The WAM plugin can renew the\r\nPRT during these token requests in two different ways:\r\nAn app requests WAM for an access token silently but there's no refresh token available for that\r\napp. In this case, WAM uses the PRT to request a token for the app and gets back a new PRT in the\r\nresponse.\r\nAn app requests WAM for an access token but the PRT is invalid or Microsoft Entra ID requires\r\nextra authorization (for example, Microsoft Entra multifactor authentication). In this scenario,\r\nWAM initiates an interactive sign-in requiring the user to reauthenticate or provide extra\r\nverification and a new PRT is issued on successful authentication.\r\nIn an ADFS environment, direct line of sight to the domain controller isn't required to renew the PRT. PRT\r\nrenewal requires only /adfs/services/trust/2005/usernamemixed and\r\n/adfs/services/trust/13/usernamemixed endpoints enabled on proxy by using WS-Trust protocol.\r\nWindows transport endpoints are required for password authentication only when a password is changed, not for\r\nPRT renewal.\r\nIn Microsoft Entra joined and Microsoft Entra hybrid joined devices, the CloudAP plugin is the primary\r\nauthority for a PRT. If a PRT is renewed during a WAM-based token request, the PRT is sent back to\r\nCloudAP plugin, which verifies the validity of the PRT with Microsoft Entra ID before accepting it.\r\nNote\r\nMicrosoft Entra Conditional Access policies aren't evaluated when PRTs are renewed.\r\nWindows\r\nmacOS\r\nOther operating systems\r\nA PRT is protected by binding it to the device the user has signed in to, where it will use hardware binding when\r\navailable and supported.\r\nMicrosoft Entra ID and Windows 10 or newer enable PRT protection through the following methods:\r\nDuring first sign in: During first sign in, a PRT is issued by signing requests using the device key\r\ncryptographically generated during device registration. On a device with a valid and functioning TPM, the\r\ndevice key is secured by the TPM preventing any malicious access. A PRT isn't issued if the corresponding\r\ndevice key signature can't be validated.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 5 of 15\n\nDuring token requests and renewal: When a PRT is issued, Microsoft Entra ID also issues an encrypted\r\nsession key to the device. It's encrypted with the public transport key (tkpub) generated and sent to\r\nMicrosoft Entra ID as part of device registration. This session key can only be decrypted by the private\r\ntransport key (tkpriv) secured by the TPM. The session key is the Proof-of-Possession (POP) key for any\r\nrequests sent to Microsoft Entra ID. The session key is also protected by the TPM and no other OS\r\ncomponent can access it. Token requests or PRT renewal requests are securely signed by this session key\r\nthrough the TPM and hence, can't be tampered with. Microsoft Entra invalidates any requests from the\r\ndevice that aren't signed by the corresponding session key.\r\nBy securing these keys with the TPM, we enhance the security for PRT from malicious actors trying to steal the\r\nkeys or replay the PRT. So, using a TPM greatly enhances the security of Microsoft Entra joined, Microsoft Entra\r\nhybrid joined, and Microsoft Entra registered devices against credential theft. For performance and reliability,\r\nTPM 2.0 is the recommended version for all Microsoft Entra device registration scenarios on Windows 10 or\r\nnewer. After the Windows 10, 1903 update, Microsoft Entra ID doesn't use TPM 1.2 for any of the above keys due\r\nto reliability issues.\r\nFor an overview of how tokens are protected in general, refer to Protecting tokens in Microsoft Entra ID\r\nWindows\r\nmacOS \u0026 iOS\r\nAndroid\r\nLinux\r\nWhen an app requests token through WAM, Microsoft Entra ID issues an access token and, in some types\r\nof the requests, a refresh token. However, WAM only returns the access token to the app and secures the\r\nrefresh token:\r\nIf it is a refresh token for an SSO user, then this refresh token is bound to the device, with a session\r\nkey (the same as PRT) or the device key.\r\nIf it is a refresh token for a non-SSO user, then this refresh token is not bound to the device.\r\nAll refresh tokens are encrypted by the DPAPI.\r\nWindows\r\niOS and Mac\r\nAndroid\r\nLinux\r\nIn Windows 10 or newer, Microsoft Entra ID supports browser SSO in Microsoft Edge natively, in Google\r\nChrome via native support or extension and in Mozilla Firefox v91+ via a browser setting.\r\nWhen a user initiates a browser interaction, the browser (or the extension) invokes a platform API. The\r\nextension calls this API via a native messaging host. The API ensures that the page is from one of the\r\nallowed domains. The browser sends full query string, which includes a nonce. The platform API creates a\r\nPRT and device header, which are signed with the TPM-protected keys. The PRT-header is signed by the\r\nsession key, the device header by device key, thus it's difficult to tamper with. These headers are included\r\nin all requests for Microsoft Entra ID to validate the device it's originating from and the user. Once\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 6 of 15\n\nMicrosoft Entra ID validates those headers, it issues a session cookie to the browser. This session cookie\r\nalso contains the same session or device key used to sign the request. During subsequent requests, the\r\nsession key is validated effectively binding the cookie to the device and preventing replays from elsewhere.\r\nA PRT can get a multifactor authentication claim in specific scenarios. When an MFA-based PRT is used to\r\nrequest tokens for applications, the MFA claim is transferred to those app tokens. This functionality provides a\r\nseamless experience to users by preventing MFA challenge for every app that requires it. A PRT can get an MFA\r\nclaim in the following ways:\r\nWindows\r\niOS/Mac/Android/Linux\r\nSign in with Windows Hello for Business: Windows Hello for Business replaces passwords and uses\r\ncryptographic keys to provide strong two-factor authentication. Windows Hello for Business is specific to a\r\nuser on a device, and itself requires MFA to provision. When a user logs in with Windows Hello for\r\nBusiness, the user's PRT gets an MFA claim. This scenario also applies to users logging in with smart cards\r\nif Smartcard authentication produces an MFA claim from ADFS.\r\nAs Windows Hello for Business is considered multifactor authentication, the MFA claim is updated\r\nwhen the PRT itself is refreshed, so the MFA duration will continually extend when users sign in\r\nwith Windows Hello for Business.\r\nMFA during WAM interactive sign in: During a token request through WAM, if a user is required to do\r\nMFA to access the app, the PRT that is renewed during this interaction is imprinted with an MFA claim.\r\nIn this case, the MFA claim isn't updated continuously, so the MFA duration is based on the lifetime\r\nset on the directory.\r\nWhen a previous existing PRT and RT are used for access to an app, the PRT and RT are regarded as\r\nthe first proof of authentication. A new RT is required with a second proof and an imprinted MFA\r\nclaim. This process also issues a new PRT and RT.\r\nWindows 10 or newer maintain a partitioned list of PRTs for each credential. So, there's a PRT for each of\r\nWindows Hello for Business, password, or smart card. This partitioning ensures that MFA claims are\r\nisolated based on the credential used, and not mixed up during token requests.\r\nNote\r\nWhen using password to sign into Windows 10 or newer Microsoft Entra joined or Microsoft Entra hybrid joined\r\ndevice, MFA during WAM interactive sign in might be required after session key associated with PRT is rolled -\r\ndepending on if the user passed 2FA process within that session.\r\nA PRT is invalidated in the following scenarios:\r\nInvalid user: If a user is deleted or disabled in Microsoft Entra ID, their PRT is invalidated and can't be\r\nused to obtain tokens for applications. If a deleted or disabled user already signed in to a device before,\r\ncached sign-in would log them in, until CloudAP is aware of their invalid state. Once CloudAP determines\r\nthat the user is invalid, it blocks subsequent logons. An invalid user is automatically blocked from sign in\r\nto new devices that don't have their credentials cached.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 7 of 15\n\nInvalid device: If a device is deleted or disabled in Microsoft Entra ID, the PRT obtained on that device is\r\ninvalidated and can't be used to obtain tokens for other applications. If a user is already signed in to an\r\ninvalid device, they can continue to do so. But all tokens on the device are invalidated and the user doesn't\r\nhave SSO to any resources from that device.\r\nPassword change: If a user obtained the PRT with their password, the PRT is invalidated by Microsoft\r\nEntra ID when the user changes their password. Password change results in the user getting a new PRT.\r\nThis invalidation can happen in two different ways:\r\nIf user signs in to Windows with their new password, CloudAP discards the old PRT and requests\r\nMicrosoft Entra ID to issue a new PRT with their new password. If user doesn't have an internet\r\nconnection, the new password can't be validated, Windows might require the user to enter their old\r\npassword.\r\nIf a user has logged in with their old password or changed their password after signing in to\r\nWindows, the old PRT is used for any WAM-based token requests. In this scenario, the user is\r\nprompted to reauthenticate during the WAM token request and a new PRT is issued.\r\nTPM issues: Sometimes, a device's TPM can falter or fail, leading to inaccessibility of keys secured by the\r\nTPM. In this case, the device is incapable of getting a PRT or requesting tokens using an existing PRT as it\r\ncan't prove possession of the cryptographic keys. As a result, any existing PRT is invalidated by Microsoft\r\nEntra ID. When Windows 10 detects a failure, it initiates a recovery flow to reregister the device with new\r\ncryptographic keys. With Microsoft Entra hybrid join, just like the initial registration, the recovery happens\r\nsilently without user input. For Microsoft Entra joined or Microsoft Entra registered devices, the recovery\r\nneeds to be performed by a user who has administrator privileges on the device. In this scenario, the\r\nrecovery flow is initiated by a Windows prompt that guides the user to successfully recover the device.\r\nThe following diagrams illustrate the underlying details in issuing, renewing, and using a PRT to request an access\r\ntoken for an application. In addition, these steps also describe how the previously mentioned security mechanisms\r\nare applied during these interactions.\r\nBelow are the detailed flows specific for the Windows operating system.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 8 of 15\n\nNote\r\nIn Microsoft Entra joined devices, Microsoft Entra PRT issuance (steps A-F) happens synchronously before the\r\nuser can sign in to Windows. In Microsoft Entra hybrid joined devices, on-premises Active Directory is the\r\nprimary authority. So, the user is able to sign in Microsoft Entra hybrid joined Windows after they can acquire a\r\nTGT to sign-in, while the PRT issuance happens asynchronously. This scenario doesn't apply to Microsoft Entra\r\nregistered devices as sign in doesn't use Microsoft Entra credentials.\r\nNote\r\nIn a Microsoft Entra hybrid joined Windows environment, the issuance of the PRT occurs asynchronously. The\r\nissuance of the PRT might fail due to issues with the federation provider. This failure can result in sign-on issues\r\nwhen users try to access cloud resources. It's important to troubleshoot this scenario with the federation provider.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 9 of 15\n\nStep Description\r\nA\r\nUser enters their password in the sign in UI. LogonUI passes the credentials in an auth buffer to LSA,\r\nwhich in turns passes it internally to CloudAP. CloudAP forwards this request to the CloudAP plugin.\r\nB\r\nCloudAP plugin initiates a realm discovery request to identify the identity provider for the user. If\r\nuser's tenant has a federation provider setup, Microsoft Entra ID returns the federation provider's\r\nMetadata Exchange endpoint (MEX) endpoint. If not, Microsoft Entra ID returns that the user is\r\nmanaged indicating that user can authenticate with Microsoft Entra ID.\r\nC\r\nIf the user is managed, CloudAP gets the nonce from Microsoft Entra ID. If the user is federated,\r\nCloudAP plugin requests a Security Assertion Markup Language (SAML) token from the federation\r\nprovider with the user's credentials. Nonce is requested before the SAML token is sent to Microsoft\r\nEntra ID.\r\nD\r\nCloudAP plugin constructs the authentication request with the user's credentials, nonce, and a broker\r\nscope, signs the request with the Device key (dkpriv) and sends it to Microsoft Entra ID. In a\r\nfederated environment, CloudAP plugin uses the SAML token returned by the federation provider\r\ninstead of the user's credentials.\r\nE\r\nMicrosoft Entra ID validates the user credentials, the nonce, and device signature, verifies that the\r\ndevice is valid in the tenant and issues the encrypted PRT. Along with the PRT, Microsoft Entra ID\r\nalso issues a symmetric key, called the Session key encrypted by Microsoft Entra ID using the\r\nTransport key (tkpub). In addition, the Session key is also embedded in the PRT. This Session key\r\nacts as the Proof-of-possession (PoP) key for subsequent requests with the PRT.\r\nF\r\nCloudAP plugin passes the encrypted PRT and Session key to CloudAP. CloudAP request the TPM to\r\ndecrypt the Session key using the Transport key (tkpriv) and reencrypt it using the TPM's own key.\r\nCloudAP stores the encrypted Session key in its cache along with the PRT.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 10 of 15\n\nStep Description\r\nA\r\nUser enters their password in the sign in UI. LogonUI passes the credentials in an auth buffer to LSA,\r\nwhich in turns passes it internally to CloudAP. CloudAP forwards this request to the CloudAP plugin.\r\nB\r\nIf the user has previously signed in to the session, Windows initiates cached sign in and validates\r\ncredentials to log the user in. Every 4 hours, the CloudAP plugin initiates PRT renewal\r\nasynchronously.\r\nC\r\nCloudAP plugin initiates a realm discovery request to identify the identity provider for the user. If the\r\nuser's tenant has a federation provider setup, Microsoft Entra ID returns the federation provider's\r\nMetadata Exchange endpoint (MEX) endpoint. If not, Microsoft Entra ID returns that the user is\r\nmanaged indicating that user can authenticate with Microsoft Entra ID.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 11 of 15\n\nStep Description\r\nD\r\nIf the user is federated, CloudAP plugin requests a SAML token from the federation provider with the\r\nuser's credentials. Nonce is requested before the SAML token is sent to Microsoft Entra ID. If the user\r\nis managed, CloudAP will directly get the nonce from Microsoft Entra ID.\r\nE\r\nCloudAP plugin constructs the authentication request with the user's credentials, nonce, and the\r\nexisting PRT, signs the request with the Session key and sends it to Microsoft Entra ID. In a federated\r\nenvironment, CloudAP plugin uses the SAML token returned by the federation provider instead of the\r\nuser's credentials.\r\nF\r\nMicrosoft Entra ID validates the Session key signature by comparing it against the Session key\r\nembedded in the PRT, validates the nonce and verifies that the device is valid in the tenant and issues\r\na new PRT. As seen before, the PRT is again accompanied with the Session key encrypted by\r\nTransport key (tkpub).\r\nG\r\nCloudAP plugin passes the encrypted PRT and Session key to CloudAP. CloudAP requests the TPM\r\nto decrypt the Session key using the Transport key (tkpriv) and reencrypt it using the TPM's own key.\r\nCloudAP stores the encrypted Session key in its cache along with the PRT.\r\nNote\r\nA PRT can be renewed externally without the need of a VPN connection when usernamemixed endpoints are\r\nenabled externally.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 12 of 15\n\nStep Description\r\nA\r\nAn application, like Microsoft Outlook, initiates a token request to WAM. WAM, in turn, asks the\r\nMicrosoft Entra WAM plugin to service the token request.\r\nB\r\nIf a Refresh token for the application is already available, Microsoft Entra WAM plugin uses it to\r\nrequest an access token. To provide proof of device binding, WAM plugin signs the request with the\r\nSession key. Microsoft Entra ID validates the Session key and issues an access token and a new\r\nrefresh token for the app, encrypted by the Session key. WAM plugin requests CloudAP plugin to\r\ndecrypt the tokens, which, in turn, requests the TPM to decrypt using the Session key, resulting in\r\nWAM plugin getting both the tokens. Next, WAM plugin provides only the access token to the\r\napplication, while it reencrypts the refresh token with DPAPI and stores it in its own cache\r\nC If a refresh token for the application isn't available, Microsoft Entra WAM plugin uses the PRT to\r\nrequest an access token. To provide proof of possession, WAM plugin signs the request containing the\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 13 of 15\n\nStep Description\r\nPRT with the Session key. Microsoft Entra ID validates the Session key signature by comparing it\r\nagainst the Session key embedded in the PRT, verifies that the device is valid and issues an access\r\ntoken and a refresh token for the application. In addition, Microsoft Entra ID can issue a new PRT\r\n(based on refresh cycle), all of them encrypted by the Session key.\r\nD\r\nWAM plugin requests CloudAP plugin to decrypt the tokens, which, in turn, requests the TPM to\r\ndecrypt using the Session key, resulting in WAM plugin getting both the tokens. Next, WAM plugin\r\nprovides only the access token to the application, while it reencrypts the refresh token with DPAPI\r\nand stores it in its own cache. WAM plugin uses the refresh token going forward for this application.\r\nWAM plugin also gives back the new PRT to CloudAP plugin, which validates the PRT with\r\nMicrosoft Entra ID before updating it in its own cache. CloudAP plugin uses the new PRT going\r\nforward.\r\nE WAM provides the newly issued access token to the calling application.\r\nStep Description\r\nA\r\nUser logs in to Windows with their credentials to get a PRT. Once user opens the browser, browser (or\r\nextension) loads the URLs from the registry.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 14 of 15\n\nStep Description\r\nB\r\nWhen a user opens a Microsoft Entra sign in URL, the browser or extension validates the URL with\r\nthe ones obtained from the registry. If they match, the browser invokes the native client host for\r\ngetting a token.\r\nC\r\nThe native client host validates that the URLs belong to the Microsoft identity providers (Microsoft\r\naccount or Microsoft Entra ID), extracts a nonce sent from the URL and makes a call to CloudAP\r\nplugin to get a PRT cookie.\r\nD\r\nThe CloudAP plugin creates the PRT cookie, signs it with the TPM-bound session key and sends it\r\nback to the native client host.\r\nE\r\nThe native client host returns this PRT cookie to the browser, which includes it as part of the request\r\nheader called x-ms-RefreshTokenCredential and requests tokens from Microsoft Entra ID.\r\nF\r\nMicrosoft Entra ID validates the Session key signature on the PRT cookie, validates the nonce,\r\nverifies that the device is valid in the tenant, and issues an ID token for the web page and an\r\nencrypted session cookie for the browser.\r\nNote\r\nThe Browser SSO flow described in the previous steps doesn't apply for sessions in private modes such as\r\nInPrivate in Microsoft Edge, Incognito in Google Chrome (when using the Microsoft Accounts extension) or in\r\nprivate mode in Mozilla Firefox v91+\r\nFor more information on troubleshooting PRT-related issues, see the article Troubleshooting Microsoft Entra\r\nhybrid joined Windows 10 or newer and Windows Server 2016 devices.\r\nSource: https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token\r\nPage 15 of 15\n\n https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token \nUnderstanding Primary Refresh Token (PRT) in Microsoft Entra\nID- Microsoft Entra ID \nBy OWinfreyATL \nArchived: 2026-04-06 00:17:31 UTC \nA Primary Refresh Token (PRT) is a key artifact of Microsoft Entra authentication in supported versions of\nWindows, iOS/macOS, Android, and Linux. A PRT is a secure artifact specially issued to Microsoft first party\ntoken brokers to enable single sign-on (SSO) across the applications used on those devices. This article explains\nhow a PRT is issued, used, and protected, enhancing your security and enabling single sign-on (SSO) across\napplications. \nThis article assumes that you already understand the different device states available in Microsoft Entra ID and\nhow single sign-on works in Windows. For more information about devices in Microsoft Entra ID, see What is\ndevice management in Microsoft Entra ID?. \nThe following Windows components play a key role in requesting and using a Primary Refresh Token (PRT):\nTerm Description \n An identity broker is a service that acts as an intermediary between an identity\nbroker providers (IdPs) and service providers (SPs), simplifying authentication and\n authorization . Web Account Manager is an example of an identity broker.\n CloudAP is the modern authentication provider for Windows sign in, that verifies\nCloud Authentication users logging to a Windows 10 or newer device. CloudAP provides a plugin\nProvider (CloudAP) framework that identity providers can build on to enable authentication to\n Windows using that identity provider's credentials. \n WAM is the default token broker on Windows 10 or newer devices. WAM also\nWeb Account \n provides a plugin framework that identity providers can build on and enable SSO\nManager (WAM) \n to their applications relying on that identity provider. \nMicrosoft Entra A Microsoft Entra specific plugin built on the CloudAP framework that verifies\nCloudAP plugin user credentials with Microsoft Entra ID during Windows sign in.\nMicrosoft Entra A Microsoft Entra specific plugin built on the WAM framework that enables SSO\nWAM plugin to applications that rely on Microsoft Entra ID for authentication. \n A Microsoft Entra specific component on Windows 10 or newer, that handles the\nDsreg \n device registration process for all device states. \n Page 1 of 15", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token" ], "report_names": [ "concept-primary-refresh-token" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775438948, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b23a02f27f8cfab7420536585f1dcb2668a7cd27.pdf", "text": "https://archive.orkl.eu/b23a02f27f8cfab7420536585f1dcb2668a7cd27.txt", "img": "https://archive.orkl.eu/b23a02f27f8cfab7420536585f1dcb2668a7cd27.jpg" } }