Session and Token Control: Limit What a Stolen Sign-In Can Do

Published October 23, 2026 · Last reviewed October 23, 2026

How a session gets stolen

Microsoft’s token theft playbook describes the main routes: an adversary-in-the-middle page that sits between the user and the real sign-in, passes everything through, and keeps the resulting token; malware on a device that copies tokens from the browser; and re-use of tokens the attacker collected earlier. In all three the second factor was passed legitimately, by the real user, and the attacker holds what comes after it.

Controls that reduce the damage

Action

Use phishing-resistant MFA for administrators and finance staff. Passkeys and security keys defeat the relay page, because the credential only works on the genuine address.

Why it helps

It removes the most common way tokens are captured in the first place.

Verification

Check that the users who can move money or change settings appear in the report of phishing-resistant registrations.

Fallback if delayed

For everyone else, use number-matching prompts and train people to stop at unexpected sign-in requests.

Action

Set a sign-in frequency and require managed devices for sensitive apps. Profile A In the Microsoft Entra admin center, create Conditional Access policies with session controls (sign-in frequency) and, where licensing allows, a grant control requiring a compliant or hybrid-joined device. Use the What If tool to preview the effect before you enforce. Profile B In the Google Admin console, set session length under Security › Access and data control; device-based rules need an edition that supports context-aware access.

Why it helps

A stolen token that only works from a managed device, or that expires in hours, is much less useful to an attacker. Shorter sessions for administrators cost little.

Verification

Use the What If tool or a test account on an unmanaged laptop: access to the protected app should be refused or prompt a new sign-in.

Fallback if delayed

Where device rules are unavailable, limit administrator sign-ins to known locations and to specific people.

Action

Turn on the sign-in log alerts you have. Review sign-ins with new locations or devices, impossible travel and unusual applications. Look at the “authentication details” of a suspicious sign-in to see whether MFA was satisfied by an existing token rather than a fresh prompt.

Why it helps

Replayed sessions look like normal sign-ins unless you check where they came from and how they authenticated.

Verification

Pick one user, open their last week of sign-ins and be able to explain every location and device listed.

Fallback if delayed

Enable the free notification emails for risky or new-device sign-ins in your admin console.

Action

Rehearse the revoke procedure. When a takeover is suspected, do all of these in order: revoke the user’s sessions, reset the password, review and remove registered MFA methods you did not create, check the mailbox for forwarding and inbox rules, review third-party app consents, then review recent activity. In Microsoft Entra ID, use the user’s “Revoke sessions” action. Profile B In Google Workspace, use the user’s Security settings in the Admin console to reset sign-in cookies and sign them out.

Why it helps

Resetting only the password leaves stolen sessions, added MFA methods and granted app consents in place.

Verification

After the procedure, confirm that the old session fails when it is retried, and that the user can sign in with a new session.

Fallback if delayed

If you cannot do all steps at once, disable the account first, then work through the list.

Common failure mode

The typical mistake is responding to a suspected takeover with a password reset alone. The attacker’s session may stay valid until it expires, an MFA method they added keeps working, a mailbox rule keeps forwarding mail, and an app they were granted access to keeps its permission. The second mistake is applying session limits to everybody equally, getting complaints, and abandoning them; start with administrators and finance, and widen gradually.

How it works

A token is a signed statement from your identity provider that says “this client has been authenticated”. Services accept it until it expires or is revoked. Because the statement is the proof, whoever holds it is treated as the user. That is why the strongest defences are the ones that make the statement useless elsewhere: binding it to a device (token protection), expiring it quickly (sign-in frequency), and re-checking conditions during the session (continuous access evaluation, which lets some services react to events such as a disabled account without waiting for expiry).

Revoking sessions tells the provider to refuse the refresh tokens that mint new access tokens. Short-lived access tokens may remain usable for a brief time, so combine revocation with a password reset and with disabling the account if the situation is serious. Microsoft Learn covers the details and the limits for each product.

Worked example

This is a hypothetical example with invented figures. A bookkeeper reports that a document-sharing email led to a sign-in page, where she entered her password and approved the prompt. An hour later her manager gets a request from her mailbox to change a supplier’s bank details.

The administrator disables the account, revokes sessions, resets the password, finds a new MFA method she did not register, removes it, discovers an inbox rule that moves replies to an obscure folder, deletes it, and lists the connected apps. Only then is the account re-enabled. The sign-in log shows the attacker’s session came from a country the firm does not work in, and the firm adds a location condition for finance staff.