Protecting Microsoft 365 from Primary Refresh Token Theft

For most organizations, the Primary Refresh Token is invisible. Users sign in to Windows, open Outlook or Teams, and access Microsoft 365 without authenticating again. That familiar experience depends heavily on the Primary Refresh Token, commonly called the PRT.

The PRT is also valuable to an attacker because it sits close to the trust relationship between a user, a device, and Microsoft Entra ID. If an attacker can steal or abuse that context, they may reach cloud resources without repeating the original sign-in or satisfying another MFA prompt.

Protecting against this attack requires more than stronger authentication. Organizations need to protect the endpoint, restrict where sessions can be used, detect unusual token and cloud activity, and revoke access quickly when compromise is suspected.

The role of the Primary Refresh Token

A PRT is an authentication artifact issued by Microsoft Entra ID to a supported token broker on a device. On Windows, the Cloud Authentication Provider and Web Account Manager use it to provide single sign-on.

The PRT is not the access token that Outlook presents to Exchange Online or Teams presents to its services. It sits earlier in the process. The broker uses it to request access and refresh tokens for applications. It also carries user and device claims so Conditional Access can evaluate requirements such as registration, compliance, and multifactor authentication.

A person can sign in to a trusted device once and use approved applications without repeatedly entering a password. A PRT is normally valid for 90 days, is renewed while the device remains active, and can contain an MFA claim. An attacker who controls it is using a context Microsoft Entra ID already trusts.

Supporting reference: Understanding Primary Refresh Token (PRT) in Microsoft Entra ID - Microsoft Entra ID ↗

A recent example from CISA

CISA's August 2026 advisory, A Tale of Two SOCs, provides a useful example because the red team did not stop after compromising the on-premises environment. At Organization A, it identified an Entra application with Mail.ReadWrite permissions, found the application's owner, moved laterally to that person's computer, and obtained the user's PRT.

The red team used the PRT to request access and refresh tokens as the application owner. It then added a client secret to the over-permissioned application and used Microsoft Graph to read email, including messages belonging to the security team. This let the red team check whether defenders had noticed the intrusion.

The organization generated alerts, but thousands of false positives obscured useful signals. Multiple SOCs and endpoint platforms lacked shared visibility, and one genuine alert was closed after analysts could not identify the system owner. Endpoint compromise, excessive application permissions, and weak SOC coordination combined into cloud access.

Organization B detected the payloads and isolated affected workstations within minutes. CISA had to provide an assumed-breach foothold to continue the exercise.

Supporting reference: Aa26 237a ↗

PRT theft is often used too broadly

Security teams sometimes describe any stolen Microsoft 365 session as PRT theft. The distinction matters.

On a properly configured Windows device, a registered-device PRT is cryptographically bound to that device. Microsoft Entra ID issues an encrypted session key with the PRT. When supported, the private transport key and session key are protected by the Trusted Platform Module. Requests must include proof generated with the protected key, so copying a PRT from a TPM-backed device and replaying it elsewhere should fail.

That protection does not remove the wider session theft problem. An attacker may steal a browser cookie, obtain an unbound application refresh token, or operate from a compromised endpoint where the trusted session already exists. Malware may also access PRT-related artifacts or invoke the local broker rather than replaying a raw PRT elsewhere.

The threat model must therefore include the PRT, refresh tokens, browser cookies, application sessions, and the endpoint itself. Device binding helps with off-device replay. It does much less when the attacker controls the original device.

How a stolen session can be used

A usable session may access Exchange Online, SharePoint Online, Teams, Microsoft Graph, or another connected application. A successful MFA event may already be represented in the token, so another prompt is not guaranteed.

Attackers can search mail and files, establish forwarding rules, collect SharePoint data, or use Microsoft Graph within the user's permissions. They may also register an authentication method, grant application consent, or abuse an existing OAuth application. An over-permissioned application, as CISA found, can provide access to much broader data.

A password change alone may not end the activity. Active sessions must be revoked and persistence removed.

Reducing the chance of token theft

Identity controls cannot compensate for an unhealthy endpoint holding a trusted session. Windows devices should use TPM 2.0, Secure Boot, current updates, and Microsoft Defender for Endpoint or an equivalent platform. Limit local administrator rights and apply Credential Guard, attack surface reduction rules, and tamper protection where appropriate.

Intune compliance gives Conditional Access a current signal about encryption, operating system health, threat level, and other settings. Requiring a compliant device for Microsoft 365 prevents many unmanaged systems from receiving the same access as a corporate endpoint. Compliance must be enforced. Reporting noncompliance without restricting access does not stop an attacker.

Authentication should resist phishing. Windows Hello for Business, FIDO2 security keys, passkeys, and certificate-based authentication are harder to proxy than push notifications or one-time codes. Administrators should use hardened devices and keep privileged accounts separate from routine email and browsing.

Application permissions also require regular review. Owners of applications with broad Microsoft Graph permissions should be treated as high-value users. Unused applications, stale owners, unnecessary permissions, and long-lived credentials create paths that Conditional Access policies for users may not address.

Binding supported sessions with Token Protection

Microsoft Entra Token Protection requires supported applications to use sign-in session tokens cryptographically bound to the device. If a bound token is copied elsewhere, Microsoft Entra ID cannot validate the required proof and rejects it.

Microsoft's current documentation lists Token Protection as generally available for native applications on Windows, iOS, iPadOS, and macOS. Supported Microsoft 365 resources include Exchange Online, SharePoint Online, and Teams. Windows also supports Azure Virtual Desktop and Windows 365.

Browser support remains much narrower. It is currently in preview for selected web applications that access Azure Resource Manager. Enabling Token Protection does not provide blanket coverage for Microsoft 365 browser sessions.

Start in report-only mode and review interactive and non-interactive sign-ins before enforcement. The `TokenProtectionStatusDetails` field in Entra sign-in logs shows whether a session was bound. Global Secure Access can also add a compliant network condition where tighter restrictions are needed.

Supporting reference: Continuous access evaluation in Microsoft Entra - Microsoft Entra ID ↗

Supporting reference: How Token Protection Enhances Conditional Access Policies - Microsoft Entra ID ↗

Detecting suspicious token use

No single event proves a PRT was stolen. Detection needs to connect activity on the endpoint, the identity sign-in, and what the session did afterward.

Defender for Endpoint can identify suspicious attempts to access a PRT and related artifacts. Analysts should correlate this with unusual processes, browser extensions, outbound connections, credential access, and command-and-control activity.

Microsoft Entra ID Protection can detect anomalous token characteristics or use from an unfamiliar location. Related signals include adversary-in-the-middle activity, atypical travel, suspicious IP addresses, and unusual non-interactive sign-ins.

Sign-in analysis should include the application, network and device details, compliance state, Conditional Access result, risk, session identifier, and token protection status. An unbound token is not automatically malicious because some applications do not support binding. It becomes more useful when binding should work and another risk signal is present.

Analysts should then look for mailbox rules, authentication changes, new devices, OAuth consent, new application secrets, unusual Graph activity, mass downloads, and administrative changes. Defender XDR and Microsoft Sentinel can bring these events into the same incident instead of leaving analysts to reconstruct it across portals.

Supporting reference: Investigate risk with Microsoft Entra ID Protection - Microsoft Entra ID Protection ↗

Supporting reference: Azure Monitor Logs reference - SigninLogs - Azure Monitor ↗

Containing the compromise

The response must address the identity, device, and persistence. The security team should isolate the endpoint, block the account when business impact permits, revoke active sessions, confirm the user as compromised, and reset credentials from a known-good device.

Review authentication methods, registered devices, application consent and secrets, mailbox rules, external sharing, and administrative changes. Determine what data was accessed and whether other users or devices were affected.

Continuous Access Evaluation helps supported Microsoft 365 services respond to revocation, account disablement, elevated risk, and policy changes before the token's normal expiration. Support varies, so responders should not assume every session ends at the same moment.

Supporting reference: Token theft playbook ↗

Building a practical readiness program

Most organizations already own several controls needed to reduce this risk. The common gap is that endpoint, identity, application governance, and monitoring controls were deployed by different teams without testing how they work together.

A practical review should confirm that TPM protection is healthy, endpoint security is reporting, Intune compliance is enforced, phishing-resistant authentication is required for high-value users, application permissions are governed, and Token Protection is enabled wherever supported. It should also confirm that identity risk reaches the SOC and responders can connect an endpoint alert to Microsoft 365 activity, revoke sessions, isolate the device, identify affected data, and remove persistence.