The Security Bridge™️- Identity Threat Protection in Microsoft 365 - Part 3: Conditional Access is a Gate, Not a Guard Dog

In July 2025, Proofpoint published research on a Microsoft OAuth app impersonation campaign it had been tracking since early that year. The numbers: nearly 3,000 attempted account compromises across more than 900 Microsoft 365 environments, with a confirmed success rate exceeding 50%. Almost all of it ran through Tycoon, an adversary-in-the-middle (AiTM) phishing-as-a-service platform built to intercept credentials and session cookies in real time.

These weren't organizations that skipped MFA. Microsoft's own Q1 2026 threat intelligence describes Tycoon2FA as built specifically to defeat non-phishing-resistant multifactor authentication, and by the time Microsoft's Digital Crimes Unit and Europol disrupted it in March 2026, it had run as one of the most widespread phishing-as-a-service platforms in the ecosystem for over two years.

Conditional Access didn't fail in any of these cases. It answered the question it's built to answer: does this sign-in meet the configured conditions? Yes. MFA satisfied, device checked, location fine, access granted. The question Conditional Access never asks is what happens to that access after it's granted.

Illustration demonstrating a security process where conditional access evaluates factors like MFA, device, and location once at sign-in. After issuing a token, the session continues without reevaluation until a critical event occurs.

What Conditional Access actually controls

Conditional Access evaluates signals at the moment of token issuance: user and group membership, device compliance, location, sign-in risk, and the application being accessed. Based on those signals, it grants, blocks, or adds a condition like requiring MFA. It evaluates those signals once, at the moment access is requested. Once it grants a token, its job for that token is done.

That's the design, and it's a sound one for what it covers. The problem shows up in what it doesn't cover.

Where the gate closes but the door doesn't

Session and refresh tokens stay valid for their lifetime no matter what happens after they're issued. If an attacker captures a token after a legitimate user completes both password and MFA, they're holding a token Conditional Access already approved. This is exactly what AiTM kits like Tycoon are built for: a real-time proxy sits between the user and the real sign-in page, the user completes MFA against the real service, and the attacker's proxy captures the session token the moment it's issued. The attacker never defeats MFA. They reuse the token that MFA just issued.

Not every MFA method is equally exposed here. Push notifications, SMS, and voice calls can all be relayed through a live proxy, because a human is completing them in real time against infrastructure the attacker controls. Phishing-resistant methods, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication, bind the credential to the specific origin and device, which is what actually stops a proxy in the middle.

A common misconfiguration compounds this. A Conditional Access policy set to "require multifactor authentication" is satisfied by any registered MFA method, phishing-resistant or not. The control that actually closes this gap is authentication strength, a separate grant control that lets a policy require a specific set of methods rather than accepting any MFA completion as equivalent. Authentication strength can't be layered onto an existing "require multifactor authentication" policy either, Conditional Access doesn't allow both grant controls in the same policy, so closing this gap means a separate or replacement policy, not an addition to one already in place.

Token Protection is a Conditional Access session control that addresses the AiTM mechanism directly: it binds a token to the device it was issued to, so a token relayed through an attacker's proxy on a different device gets rejected. It's generally available on Windows and still in preview for iOS, iPadOS, and macOS, and it currently covers native applications only, not browser-based sign-ins, against Exchange Online, SharePoint Online, and Teams.

Conditional Access policy configuration in Microsoft Entra admin center highlighting directory roles selection and the requirement for phishing-resistant multi-factor authentication.

Continuous Access Evaluation closes part of the gap, not all of it

Continuous Access Evaluation (CAE) lets Microsoft Entra revoke a token in near real time when a critical event occurs: a password reset, an account disable, a high user risk detection, instead of waiting for the token to expire naturally. It's a real improvement over static token lifetimes.

CAE-aware enforcement is effectively limited to Exchange Online, SharePoint Online, and Teams. Event propagation can take up to 15 minutes. Location-based enforcement only understands IP-based named locations, not country and region rules or MFA trusted IPs. A token being used in a session that hasn't triggered one of CAE's specific critical events keeps working, and a non-CAE-aware application honors that token for its full remaining lifetime regardless.

Microsoft Entra Admin Center displays the setup for the "CA-SIG007-Internal-TokenProtection" policy under Conditional Access. The policy includes customized continuous access evaluation and enforced token protection for sign-in sessions, aiming to enhance security by controlling access based on session controls and organizational policies.

Workload identities see even less of this. Conditional Access policies targeting service principals and managed identities exist but are far less commonly deployed, and app-only authentication doesn't go through the same interactive sign-in conditions a user does. A stolen service principal credential, the exact scenario Part 2 of this series covered, authenticates without presenting a device, a location a policy would evaluate, or an MFA prompt to intercept in the first place.

What this looks like in production

I worked with a client where some administrators had already moved to phishing-resistant authentication, while the rest of the admin population used a mix of methods, including SMS and voice call. The Conditional Access policies in place did require MFA. What they didn't do was enforce authentication strength, so a policy-compliant sign-in for a privileged account could still be satisfied by a method an AiTM proxy could relay. We reconfigured the privileged-access policies to require an authentication strength of phishing-resistant MFA specifically, closing the gap between requiring MFA and requiring MFA that actually resists this attack.

It's a common pattern industry-wide for organizations that enable Continuous Access Evaluation to assume it means real-time, tenant-wide session revocation, without verifying which of their line-of-business applications are actually CAE-aware. A third-party app that isn't CAE-aware keeps honoring a cached token for its full remaining lifetime after a password reset or a disable event, regardless of what the admin center implies about tenant coverage.

Another client had a genuinely solid Conditional Access baseline: phishing-resistant MFA for admins, device compliance, sensible location policies. What they'd skipped was an operational maturity step: continuous monitoring and historical event handling. Sign-in events weren't being retained or reviewed anywhere beyond the Entra portal's default 30 days. We configured diagnostic settings to stream sign-in logs to a Log Analytics workspace with retention extended to 180 days, which gave the team both a monitoring surface going forward and enough history to investigate anything discovered well after the fact.

Business case

Proofpoint's own data puts a number on the assumption gap: a confirmed success rate exceeding 50% against Microsoft 365 environments, in campaigns specifically built to operate after MFA succeeds. Conditional Access spend and MFA enrollment numbers show whether sign-in policies are configured. They don't show whether a session was ever misused after sign-in. Treating policy compliance as finished work has a cost, and it shows up at the worst possible time: the investigation that has to establish how long a session was active, what it touched, and whether it was ever detected versus discovered after the fact.

What to validate this week

• Confirm Conditional Access policies use authentication strength to require phishing-resistant MFA for privileged and role-assignable group members, not just "require MFA" satisfied by any registered method

• Enable Token Protection in Conditional Access session controls for Exchange Online and SharePoint Online sign-ins, binding tokens to the issuing device (GA on Windows, still preview on Apple platforms, native apps only)

• Verify which line-of-business apps are actually CAE-aware rather than assuming tenant-wide coverage

• Confirm Conditional Access location policies use IP-based named locations, not country/region or MFA trusted IP rules, since CAE can't enforce real-time revocation against the latter

• Configure diagnostic settings to stream sign-in logs to a Log Analytics workspace with retention beyond the Entra portal's 30-day default, and build alerting for anomalous token use rather than relying on Conditional Access denial rates as a health signal

• Extend Conditional Access and Identity Protection risk policies to workload identities where supported, and treat unmanaged service principal authentication as an explicit gap

The takeaway

Conditional Access controls entry. It does not replace detection, investigation, or response. Conditional Access can be configured correctly and still not be the thing standing between an organization and a bad week, because it was never designed to watch what happens after access is granted. Part 4 turns to that question directly: whether Defender XDR can actually see an identity attack once a session is already underway, or whether "deployed" and "monitored" have quietly become the same word in a tenant that's never tested the difference.