Tokens in Microsoft Entra ID: what they are, how long they last, and how to protect them

Two kinds of tokens

Microsoft splits tokens into two families. The difference decides what to protect first:

Token	What it’s for	How long it lasts	Can it be revoked?
Primary Refresh Token (PRT)	Requests tokens for any service, from a registered device	90 days, renewed with every use	Yes
Refresh token	Requests access tokens for one service	90 days, renewed with every use	Yes
Access token	Gives access to the service itself	60 to 90 minutes (75 on average)	Only if the service supports CAE

Microsoft’s own conclusion: protect the sign-in session tokens (PRT and refresh tokens) first. They live for weeks or months, and an attacker who steals them stays in for a long time.

How long an access token really lasts

By default: a random value between 60 and 90 minutes, to spread the load on Entra ID.
In a tenant without Conditional Access: access tokens for clients such as Teams and Microsoft 365 default to two hours.
In a CAE-aware session: the token can live up to 28 hours, because the service revokes it as soon as something changes. In that case a configured token lifetime doesn’t apply.

Worth knowing: you can no longer shorten refresh and session token lifetimes with a token lifetime policy. Microsoft retired that option in 2021. To force users to sign in again, use Conditional Access sign-in frequency.

What revoking sessions actually does

Revoking sessions and resetting the password invalidate the refresh token and the PRT. An access token that was already issued keeps working until it expires, unless the service supports CAE. So without CAE, an attacker can keep up to an hour and a half of access after you block them.

How to protect tokens: five layers

Control	What it does	License
Continuous access evaluation (CAE)	Exchange, Teams and SharePoint reject a token as soon as a user is blocked, changes password or moves to a disallowed location. Critical events are enforced within minutes, location changes at once	Entra ID P1 (Conditional Access)
Token Protection	Binds the session token to the device it was issued to. A token copied to another machine doesn’t work	Entra ID P1
Compliant device	A policy that requires an Intune-managed device. Even with a stolen token, the attacker’s device fails the check	Entra ID P1 and Intune
Phishing-resistant MFA	Passkeys or FIDO2 through authentication strengths. A phishing page gets nothing it can reuse	Entra ID P1
Risk-based policies	Block or require re-authentication when the sign-in or user looks risky	Entra ID P2

Two more policies close common ways to get a token, both in P1: block the device code flow (we wrote about an attack like this in our article on device code phishing), and block authentication transfer, which moves a sign-in from a computer to a phone.

Where to start

Make sure CAE is on and that no Conditional Access policy turns it off.
Require a compliant device for company data, at least from Windows and macOS.
Turn on Token Protection in report-only mode first, to see which apps don’t support it. Apple’s built-in Mail and Calendar apps, for example, don’t.
Move to phishing-resistant MFA, admins and finance first.
Block the device code flow and authentication transfer for everyone who doesn’t need them.
Set sign-in frequency for sensitive apps and roles, instead of trying to shorten tokens.

Want to see how attackers actually steal tokens, and why passkeys alone aren’t enough? We covered it in our article on phishing, token theft and CAE.

How Griffin31 helps

Griffin31 checks the security settings in your Microsoft 365 tenant continuously, including your Conditional Access policies, and shows you what to fix first, with the evidence behind the results.

Want to know which token protections are already set up in your tenant? Griffin31 checks your Microsoft 365 security settings continuously and shows you what to fix first.

Book a demo