Token theft and session security in Microsoft 365

Multifactor authentication (MFA) makes stolen passwords much less useful. But Microsoft’s documentation describes a type of attack that targets what happens after someone has signed in successfully: the theft of the token that keeps them signed in. This page explains, at a general level, how Microsoft describes token theft in Microsoft 365 and adversary-in-the-middle (AiTM) phishing, and the protections Microsoft documents against them.

What a token is

When someone signs in to Microsoft 365, Microsoft Entra ID checks their password and any MFA, then issues tokens. The person’s apps and browser present those tokens to services like Outlook or SharePoint, so they don’t have to sign in again for every request.

A token stands in for the completed sign-in: it records who the person is and what they’ve been allowed to access. A token issued to a highly privileged account carries those privileges with it, which is why admin sessions are a particular target.

How Microsoft describes token theft

Microsoft’s token theft playbook defines it this way: “A token theft attack occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication. Because authentication requirements are met, the threat actor is granted access to organizational resources by using the stolen token.”

That’s why MFA alone may not stop it: the MFA check has already been passed by the real user before the token is taken.

Microsoft describes two broad ways this happens:

• Adversary-in-the-middle (AiTM) phishing. Microsoft’s Defender documentation describes an intermediate phishing site “working as a proxy connection between the user and the legitimate website that the attacker is impersonating”, which lets the attacker “steal the target’s password and session cookie”. To the user, it can look like a normal sign-in.
• Theft from a device. Session cookies and tokens are stored on the devices people sign in from. Microsoft’s passwordless deployment guide notes that once credentials can’t easily be phished, “attackers may move on to try to exfiltrate tokens from user devices”.

Microsoft’s playbook notes that a suspicious email can be the start of an AiTM attack. The guide to phishing, smishing and vishing covers phishing more broadly.

The protections Microsoft describes

Phishing-resistant MFA

Microsoft’s passwordless deployment guide lists phishing-resistant credentials including synced passkeys, passkeys in Microsoft Authenticator, FIDO2 security keys, Windows Hello for Business, Microsoft Entra passkeys on Windows, Platform SSO for Mac and certificate-based authentication. It describes piloting with admins first, then deploying more widely. The guide to hardware security keys and how they differ explains FIDO2 keys in more detail.

In Australia, ASD’s Implementing multi-factor authentication publication says phishing-resistant MFA “is not as susceptible to brute force attacks and machine-in-the-middle attacks” as passphrase-only logins or SMS- and voice-based MFA, and recommends applying phishing-resistant MFA broadly.

Microsoft’s guide states that “the primary mechanism” to enforce these is Conditional Access authentication strengths, using the “Phishing-resistant MFA” strength in its examples. The same guide notes that as credentials become harder to phish, “attackers may move on to try to exfiltrate tokens from user devices”, which is where token protection comes in. The guide to phishing-resistant MFA methods in Microsoft 365 covers the methods in more detail.

Conditional Access session controls

Microsoft describes sign-in frequency as how long a user can access a resource “before being asked to sign in again”, and a persistent browser session as letting users stay signed in after closing the browser. Microsoft says the default sign-in frequency is “a rolling window of 90 days.” A shorter session means a stolen session is useful for less time, and Microsoft’s session lifetime page describes it as a Conditional Access capability needing an Entra ID P1 or P2 licence.

Microsoft also cautions against overdoing it: “Triggering reauthentication too frequently can increase security friction to a point that it causes users to experience MFA fatigue and open the door to phishing.”

Microsoft’s token protection deployment guide also describes pairing token protection with policies that block access from unknown platforms and require device compliance for all known platforms. The guide to security defaults vs Conditional Access explains how Conditional Access policies work.

Token protection

Microsoft describes token protection as “a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens… are accepted.” Microsoft explains that the token is cryptographically bound to the device it was issued to, so “even if a threat actor steals the token, it can’t be used from another device.”

Microsoft’s platform table, as checked on 21 October 2026, lists native apps (Exchange Online, SharePoint Online and Microsoft Teams) as generally available on Windows, macOS and iOS/iPadOS. Browser-based support is in preview only for selected web apps that access Azure Resource Manager on Windows and macOS. Its Windows deployment guide lists clients and devices that aren’t supported (for example, Office perpetual clients and Surface Hub), and describes starting with a pilot group and a policy in report-only mode.

Based on Microsoft’s Windows deployment guide (checked October 2026), the policy is created in the Microsoft Entra admin center under Entra ID > Conditional Access > Policies > New policy, by at least a Conditional Access Administrator, targeting Exchange Online, SharePoint Online and Microsoft Teams Services, and using the session control Require token protection for sign-in sessions with Enable policy set to Report-only at first. Microsoft’s guide has the full settings. Microsoft’s deployment guide states token protection requires Microsoft Entra ID P1. The Microsoft 365 licensing and security features reference lists which plans Microsoft says include Entra ID P1 and P2.

Continuous access evaluation (CAE)

Microsoft explains that, by default, access tokens are valid for one hour. CAE lets supported services (Microsoft names Exchange, Teams and SharePoint Online) react to critical events without waiting for the token to expire. The events Microsoft lists include:

• a user account deleted or disabled
• a password changed or reset
• MFA enabled for the user
• an administrator revoking all refresh tokens for a user
• high user risk detected by Microsoft Entra ID Protection.

Microsoft says the aim is near real time, with “latency of up to 15 minutes”, and that IP-based location policies are enforced instantly. Microsoft states that critical event evaluation doesn’t rely on Conditional Access policies, “so it’s available in any tenant.” Microsoft also notes that in CAE sessions token lifetime increases to “up to 28 hours”, because services can act on events instead of waiting for expiry.

Sign-in risk and ID Protection

Microsoft Entra ID Protection flags risky sign-ins. Its detections include anomalous token, which Microsoft describes as abnormal token characteristics such as “an unusual lifetime or a token played from an unfamiliar location”, and attacker in the middle, which Microsoft says is triggered “when an authentication session is linked to a malicious reverse proxy.”

Microsoft states that full details on most detections require Entra ID P2; tenants without P2 see a generic “Additional risk detected”. Microsoft’s page marks both detections as premium, and for attacker in the middle its licence entry reads “Microsoft 365 E5 with Enterprise Mobility + Security E5”; Microsoft notes that its security research team uses Microsoft Defender for Cloud Apps to raise this risk. Risk-based Conditional Access policies, which Microsoft describes as a way to automate the response to risk, also require P2.

How Microsoft describes responding

Microsoft’s token theft playbook lists containment and recovery actions including changing passwords, blocking the user, revoking current tokens, marking accounts as compromised in ID Protection, disabling added credentials and devices, and disabling suspicious email rules. Microsoft’s Entra page on revoking access notes that by default “access tokens issued by Microsoft Entra ID last for 1 hour”, so apps can keep working until the token expires, and that CAE lets admins revoke tokens sooner for CAE-capable apps. The guides to responding to a compromised account and suspicious inbox rules cover these steps.

In Australia, the ACSC’s report and recover page explains how to report a cybercrime, incident or vulnerability. The guide to where to report scams and cybercrime in Australia lists the main reporting services.

Common questions

What is token theft in Microsoft 365?

Token theft is an attack on the token that keeps someone signed in, rather than on their password. Microsoft’s playbook says it “occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication”, which grants them access because authentication requirements are met. Microsoft describes two routes: adversary-in-the-middle phishing and theft from a device. How Microsoft describes token theft explains both.

Does MFA stop token theft?

Not on its own. Microsoft’s playbook describes token theft as replaying tokens “even if that user has satisfied multifactor authentication”, because the real user has already passed the MFA check before the token is taken. Phishing-resistant methods make the AiTM route harder, according to Microsoft, and token protection aims to stop a stolen token working on another device. The protections Microsoft describes covers each layer.

What is an AiTM phishing attack?

Microsoft’s Defender documentation describes an intermediate phishing site “working as a proxy connection between the user and the legitimate website that the attacker is impersonating”, which lets the attacker “steal the target’s password and session cookie”. To the user, it can look like a normal sign-in, and Microsoft’s playbook notes a suspicious email can be the start. How Microsoft describes token theft has the detail.

What is token protection in Conditional Access?

Microsoft describes it as a Conditional Access session control that only accepts sign-in session tokens bound to the device they were issued to, so “even if a threat actor steals the token, it can’t be used from another device.” Microsoft’s deployment guide states it requires Microsoft Entra ID P1 and describes starting in report-only mode with a pilot group. Token protection lists the supported platforms.

What do I do if I think a session token has been stolen?

Microsoft’s token theft playbook lists containment and recovery actions including changing passwords, blocking the user, revoking current tokens, marking accounts as compromised in ID Protection, disabling added credentials and devices, and disabling suspicious email rules. In Australia, the ACSC’s report and recover page explains how to report a cybercrime or incident. How Microsoft describes responding links to the full steps.

How quickly does revoking a user’s sessions take effect?

By default, Microsoft says access tokens last one hour, so apps can keep working until the token expires. Continuous access evaluation lets supported services, which Microsoft names as Exchange, Teams and SharePoint Online, react to events such as a password reset or revoked tokens, with “latency of up to 15 minutes”. Microsoft says this is available in any tenant. See continuous access evaluation (CAE).

Things that change

Token protection’s supported platforms and apps have expanded over time, and browser support remains in preview. This page reflects Microsoft’s documentation as checked on 21 October 2026.