Token Protection in Conditional Access: stopping AiTM attacks that bypass MFA

Multi-factor authentication (MFA) has been considered the baseline for secure sign-in for years, and rightly so. But attackers have known this and adapted their tactics. The attack method that now dominates is called AiTM: Adversary-in-the-Middle. In this approach, the target is no longer the password — it is the session token created after the user has already successfully signed in, including the MFA step.

With a stolen token, an attacker can sign in completely as the user without ever knowing a password or verification code. Standard MFA provides no protection against this. Token Protection in Microsoft Entra Conditional Access closes exactly this gap — and activating it takes a single policy rule.

How an AiTM attack works

In a classic phishing attack, the attacker tries to obtain the user's password. In AiTM, it works differently. The user is directed to a fake website that acts as a transparent proxy for the real Microsoft sign-in page. The user sees a legitimate-looking login screen, completes the full sign-in process including the MFA step, and suspects nothing.

Meanwhile, the attacker relays the credentials and the MFA response to the real Microsoft service in real time. Microsoft sees a valid sign-in, generates a session token, and sends it back — also directly to the attacker via the proxy. With that token, the attacker signs in to Exchange Online, SharePoint, or Teams without the user ever noticing. MFA is fully bypassed because the attacker doesn't need a password or code: only the token.

AiTM kits are now available off-the-shelf and are actively used in phishing campaigns targeting Microsoft 365 environments. They are no longer the exclusive domain of sophisticated state actors — less skilled attackers use them as a standard tool.

What is Token Protection and how does it solve this?

Token Protection is a session control feature in Entra Conditional Access that cryptographically binds OAuth tokens to the device on which they were created. Concretely: when a user signs in on an Entra-joined Windows device, the Primary Refresh Token (PRT) that is subsequently created is locked to the TPM chip of that device.

If an attacker steals that token and tries to use it on another device, Entra ID refuses access. The token is cryptographically bound to the original hardware — a device that cannot prove this binding simply does not get in. The attack technically still succeeds, but delivers the attacker nothing usable.

Token Protection is therefore complementary to phishing-resistant MFA such as passkeys or FIDO2. Passkeys prevent the attacker from obtaining a valid token via the phishing proxy in the first place. Token Protection makes an already stolen token unusable outside the original device. Together, they address AiTM attacks from two angles.

Which licences and devices are required?

The licence requirement is minimal: Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. Organisations on Microsoft 365 Business Basic or Business Standard do not have Entra ID P1 by default — an upgrade or a separate Entra ID P1 licence is then needed.

Devices must be Windows and joined to Entra ID. This is possible in two ways: fully Entra-joined (cloud-joined, without Active Directory) or Hybrid Entra-joined (combined with on-premises Active Directory). Entra-registered devices, such as personal devices that only have a work account added, fall outside the support for Token Protection.

Devices must also have a TPM 2.0 chip, the standard for virtually every business device purchased in the last four years. Older hardware without TPM cannot participate in Token Protection and must be treated as an exception in the policy.

Which applications are protected?

Token Protection works for the core services of Microsoft 365: Exchange Online, SharePoint Online, and Microsoft Teams. These are the primary targets in AiTM campaigns directed at business environments, so coverage in practice is broad.

The protection is initially strongest for native desktop applications and mobile clients from Microsoft, such as the Teams desktop app, Outlook desktop, and OneDrive client. Support for browser-based access to these services has expanded and is growing, but depends on the browser and the device configuration in use. Check during deployment which combinations are actually covered in your environment.

Activating Token Protection in Conditional Access

Activating Token Protection is done via a new or existing Conditional Access policy in the Microsoft Entra portal. The setting is found under Session controls, which appears in every CA policy alongside the familiar options such as Sign-in frequency and Persistent browser session.

The recommended deployment process consists of three phases. In the first phase, create a Conditional Access policy in Report-only mode. Select a pilot group of users on compatible devices as the target, set the target applications to Exchange Online, SharePoint Online, and Teams, and enable Token Protection under Session controls. In report-only mode, there is no impact on end users — you only see in the sign-in logs how many sign-ins are in line with the policy.

In the second phase, analyse the reporting data in the Entra portal. Sign-ins from devices that do not meet the requirements — devices without TPM, non-Entra-joined, or BYOD devices — appear as 'not compliant'. Make sure to set up a separate flow for these exceptions so that those users are not blocked when the policy is activated.

In the third phase, switch the policy to Enabled for the pilot group, evaluate for issues over one to two weeks, and then expand to the entire organisation. A typical deployment of two to three weeks is achievable for most organisations.

What Token Protection does not do

Token Protection is a powerful measure, but not a complete solution in itself. There are three important limitations. First, it does not protect against attacks where the attacker has obtained direct code execution on the original device. If malware is running on the user's device, the attacker can act from that device using the bound token — the cryptographic binding does not help in that case.

Second, Token Protection does not cover all access paths. Legacy authentication protocols, applications that do not use modern OAuth flows, and some browser scenarios fall outside the current scope. A complete picture of which sign-in paths in your environment are actually covered can only be obtained through report-only mode.

Third, Token Protection is not a replacement for phishing-resistant MFA. The correct sequence is: first activate phishing-resistant MFA (passkeys, WHfB, or FIDO2 keys), then add Token Protection as an additional layer for scenarios where token theft is still possible despite strong authentication.

Token Protection as part of a layered security approach

Organisations serious about identity security build a layered approach. Conditional Access policy forms the foundation: you determine who gets access, to what, under which conditions. Token Protection is one of the session controls you can embed in that foundation, alongside Sign-in frequency, compliant device requirements, and Continuous Access Evaluation.

The combination currently most robust against AiTM attacks consists of three layers: phishing-resistant MFA as the sign-in method, Token Protection as a session control, and Continuous Access Evaluation through which Entra ID can terminate sessions in real time if a device or user no longer meets policy. Each layer closes a specific attack path.

Want to know whether your Conditional Access configuration provides adequate protection against AiTM attacks, or want help activating Token Protection in your Entra ID environment? Contact Zarioh for a concrete assessment of your identity security.