Token theft detection and Continuous Access Evaluation

Everyone’s proud of their MFA rollout. Every tenant I touch has it on now. Good.

But here’s the thing almost nobody checks: MFA only protects the front door. It proves who you are when you sign in. After that, you get a token, and that token is what actually keeps you logged in.

Steal the password? MFA stops you. Steal the token? You walk straight past it.

That’s the attack that’s quietly winning right now. Adversary-in-the-middle phishing kits don’t bother cracking your second factor. They sit between you and Microsoft, let you complete MFA, and pocket the session token on the way through. Now they’re you — no prompt, no challenge, no trace.

So the question isn’t “have I turned on MFA?” It’s “what happens after the token is issued?” And for most tenants, the honest answer is: nothing, for up to an hour.

What is CAE, really?

A Microsoft 365 access token lasts one hour by default. For that hour, the token is trusted. If you disable a compromised account at minute three, the attacker keeps working until minute sixty.

Continuous Access Evaluation closes that gap.

Instead of waiting for the token to expire, Entra and the app — Exchange, SharePoint, Teams — hold an open conversation. The moment something critical changes, Entra tells the app to stop trusting that token now. Account disabled, password reset, admin revokes sessions, ID Protection flags high risk — the session dies in near real time.

Here’s the part most people miss. CAE is already on. Critical-event evaluation runs in every tenant, no Conditional Access policy required. You don’t switch it on. You just need to not switch it off.

Step-by-Step: lock down the token, not just the login

Confirm CAE is still on

Go to the Entra admin centre → Entra ID → Conditional Access → Policies. Open any policy you’ve built, then look under Session → Customize continuous access evaluation.

If someone’s ticked Disable in there, untick it. That toggle exists for edge cases, and I’ve walked into tenants where it was flipped off years ago and forgotten. Microsoft documents the disable path — read it so you know what you’re looking at.

Stand up a Token Protection policy

CAE kills the session after a known event. Token Protection stops the stolen token being usable in the first place. It cryptographically binds the sign-in token to the device it was issued on. Steal it, move it to your machine, and it’s a dead key.

Create a new Conditional Access policy. Scope it to a pilot group first. Target Exchange Online, SharePoint Online, and Teams. Under Session, tick Require token protection for sign-in sessions.

Set it to report-only

Do not go straight to On. Set the policy to Report-only and let it run. Watch your sign-in logs for “Token Protection – Sign In Session” and look for Bound versus Unbound. The deployment guidance says the same thing, and it’s right — you want to see what breaks before it breaks for a client.

Here’s the session control you’re actually setting:

Session controls:
  Require token protection for sign-in sessions: ON
  Target resources: Exchange Online, SharePoint Online, Teams
  Device requirement: Entra joined / hybrid joined / registered
  Client apps: native desktop + mobile only

Notice what’s missing? Browsers. Token Protection covers native client apps today, not browser sessions. So an attacker who lifts a token through a browser can still replay it. This isn’t the finish line — it’s one layer in a stack that also needs phishing-resistant MFA and compliant devices.

Why this actually changes behaviour

Once you internalise that the token is the credential, your whole threat model shifts.

“We’re fully MFA’d, we’re fine.” No. You’re protected at sign-in. You’re exposed for every minute after it.

CAE shrinks that exposure window from an hour to near-zero. Token Protection makes the stolen token worthless on the wrong machine. Together they move you from “we hope nobody phishes a session” to “even if they do, it dies fast and travels nowhere.”

And it costs you nothing extra to start. CAE ships in the box. Token Protection now needs only Entra ID P1 — which your Business Premium clients already have.

MFA was the conversation three years ago. Token theft is the conversation now. If you’re still selling clients on the front door while attackers climb through the session, you’re protecting the wrong thing.

MFA proves who walked in. CAE and Token Protection make sure they can’t stay in once you’ve shown them the door.

Intune compliance policies + Conditional Access integration

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

Your Conditional Access Is Stuck in 2018

You get a phone call from a client one Sunday morning in February. One of their bookkeepers had clicked an invoice link the previous Friday afternoon, signed in like normal, and gone home for the weekend. By Monday, the attacker had set up an inbox rule, watched a fortnight of email traffic, and sent a payment-redirect note to a supplier — from the bookkeeper’s actual mailbox. Eighty thousand dollars walked out the door before anyone noticed the wire details had quietly changed.

The tenant had MFA enforced. It had a Conditional Access policy. It had cyber insurance, renewed in January on the strength of those two things. None of that mattered.

The attack moved. The configuration didn’t.

Adversary-in-the-middle phishing kits don’t try to beat the MFA prompt anymore. They wait for the user to complete it, then steal the session token and replay it from somewhere else. Microsoft’s threat intel team disclosed an April campaign that hit thirty-five thousand users across thirteen thousand organisations in twenty-six countries — a single month, a single operator. Every one of those users had MFA. None of them had session controls tuned to actually defend the session.

This is the bit MSPs need to sit with. Conditional Access in Entra was never built as an MFA tickbox. It is the session control surface — the place where you decide what a signed-in user can do, from where, on what device, for how long. The grant and session controls in that same blade — the ones most SMB tenants have never opened — are what break this attack. We have spent five years building a defence for 2018 and leaving it deployed in 2026.

Four switches, all in the same blade

There are four controls inside Conditional Access that meaningfully change the outcome of a token theft, and most Business Premium tenants pay for all of them and use none.

Sign-In Frequency, set deliberately rather than left at its sliding ninety-day default, collapses the lifetime of a stolen token. Most tenants I look at have it set backwards — managed users get prompted constantly while unmanaged sessions ride for weeks.
Require-compliant-device on Exchange Online forces the attacker’s browser session to fail at the grant, not the prompt.
Phishing-resistant authentication strength — passkeys, FIDO2, Windows Hello — closes off the credential path to begin with.
Token Protection, even in report-only on Windows native apps, gives you the telemetry to spot a session being replayed from a country your user has never visited.

None of this is theoretical. Microsoft auto-rolled Conditional Access into more than half a million tenants in late 2023 specifically because tenants were not configuring it themselves. That auto-rollout sets the floor. The four controls above sit above the floor, and they are the ones that change the renewal conversation with your insurer.

The unit economics finally work

The honest reason most MSPs haven’t retuned their CA baseline is that per-tenant identity work used to be uneconomic. That changed. With GDAP and Microsoft Lighthouse, an MSP can review CA policy, push report-only changes, and watch sign-in telemetry across every client tenant from one pane. Pair that with a Loop page or a Teams channel for your security pod and the review cadence stops being a heroics exercise.

The bookkeeper followed her training to the letter. What let her down was a tenant configured for the threat landscape we had four years ago. When the next breach lands in one of your tenants, it will not be the MFA prompt that failed. It will be the session controls nobody touched. That is where the work is now.

End to End email protection with Microsoft 365–Part 4

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.

For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.

A range of hardware device protection is available and recommended including:

and should already be in place to protect the device.

We will also assume that the Windows device is fully up to date

How to keep your Windows computer up to date

The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):

Azure AD joined devices

Join your work device to your organization’s network

Tutorial: Join a new Windows 10 device with Azure AD during a first run

When that device is turned on we want it to complete the:

Secure Windows boot process

Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:

Manage device security with endpoint security policies in Microsoft Intune

Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.

Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:

Use compliance policies to set rules for devices you manage

All of this is achieved via:

Microsoft Endpoint Manager

which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:

Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10

Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.

The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.

Windows Hello for Business Overview

Windows Hello addresses the following problems with passwords:

Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.
Server breaches can expose symmetric network credentials (passwords).
Passwords are subject to replay attacks.
Users can inadvertently expose their passwords due to phishing attacks.

Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.

Why a PIN is better than a password

How Windows Hello for Business works

These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Your Pa$$word doesn’t matter

All your creds are belong to us!

So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.

Five steps to securing your identity infrastructure

Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:

Multifactor Unlock

It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.

Enable multi-factor authentication for free

Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.

It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.

Conceptual Conditional signal plus decision to get enforcement

What is Conditional Access?

For example, user account access can be blocked if it comes from outside a specific country or region.

Conditional Access: Block access by location

and enforcing MFA

Conditional Access: Require MFA for all users

Conditional Access: Require MFA for administrators

Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.

Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.

End to End email protection with Microsoft 365–Part 5

Need to Know podcast–Episode 262

Security is big this week and you’ll get it all here. Our cloud news will provide you with all the latest information you’ll need to understand the Solar Winds attack. in this episode we also speak with Daniel Chronlund around Conditional Access. Daniel shares his extensive knowledge around this service and how it can improve your security posture. He also has some great scripts available on his Github repository, so check them out!

I take this opportunity to wish listeners happy holidays. Stay safe and thanks for all your support in 2020. Onwards to 2021 we go, hi ho, hi ho.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-262-daniel-chronlund/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@danielchronlund