Why MFA Is No Longer the Architectural Anchor It Was

MFA was designed as a second factor to compensate for password weakness. The implicit model: an attacker has your password but not your phone. That model held when the attack surface was brute force and phishing was manual.

The attack surface has shifted in two critical directions. First, token replay attacks — specifically adversary-in-the-middle (AiTM) phishing frameworks like Evilginx and Modlishka — capture session tokens post-authentication, bypassing MFA entirely because the authentication already completed. The attacker doesn't need your password or your second factor; they need the session artifact that proves you already authenticated. Second, AI-assisted credential stuffing now synthesizes credential pairs from multiple breach datasets, enriches them with behavioral signals scraped from public sources, and submits them in patterns that mimic legitimate user behavior closely enough to score low on risk engines.

Microsoft's own Entra ID Protection risk scoring is a strong control — but it was trained on historical attack patterns. AI-generated attack traffic is specifically optimized to fall below the risk thresholds that trigger step-up authentication or block policies.

The compliance frameworks haven't caught up. SOC 2 Type II, FedRAMP Moderate, and HIPAA Security Rule all reference MFA as a primary authentication control. None of them currently mandate phishing-resistant MFA as a baseline — meaning an organization can be fully compliant on paper while running an authentication architecture that AiTM attacks bypass trivially. That's not a theoretical audit gap. It's a breach liability that your current policy language doesn't address.

---

The Token Replay Surface: What Entra ID Logs Actually Show You

Before you can fix the architecture, you need visibility into what's happening in your token issuance pipeline. Most organizations are not querying their Entra ID sign-in logs at the depth required to detect token replay patterns.

The following KQL query runs against Microsoft Sentinel (or the Log Analytics workspace backing your Entra ID diagnostic logs) and surfaces sign-in events where the same refresh token is being used from multiple distinct IP addresses within a short window — a strong indicator of token theft and replay:

// Detect refresh token reuse from multiple IPs — potential token replay
let lookback = 1h;
SigninLogs
| where TimeGenerated > ago(lookback)
| where TokenProtection == "None"
| where ResultType == 0
| summarize
    IPCount = dcount(IPAddress),
    IPs = make_set(IPAddress),
    Countries = make_set(LocationDetails.countryOrRegion),
    SessionIds = make_set(CorrelationId)
    by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 15m)
| where IPCount > 1
| where array_length(Countries) > 1
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPCount, IPs, Countries, SessionIds
| order by IPCount desc

This query is not a finished detection rule — it's a starting point for baselining. In a clean environment, you should see near-zero results. If you're seeing consistent hits, you have an active token replay problem, not a theoretical one.

The second query identifies accounts where Entra ID Protection fired a risk signal but Conditional Access did not enforce a remediation action — the gap between detection and enforcement:

// Risk detected but no CA enforcement — policy gap visibility
AADRiskyUsers
| where RiskLevel in ("high", "medium")
| where RiskState == "atRisk"
| join kind=leftouter (
    SigninLogs
    | where ConditionalAccessStatus == "success"
    | where AuthenticationRequirement == "singleFactorAuthentication"
    | project UserPrincipalName, TimeGenerated, ConditionalAccessStatus
) on UserPrincipalName
| where isnotempty(UserPrincipalName1)
| project UserPrincipalName, RiskLevel, RiskState, TimeGenerated, ConditionalAccessStatus
| order by TimeGenerated desc

If this query returns results, your Conditional Access policies have a coverage gap for risky users — they're being flagged by the risk engine but still completing single-factor authentication. That's a policy misconfiguration, not a detection failure.

---

Continuous Validation: Moving Past Point-in-Time Authentication

The architectural shift required here is from authentication as a gate to authentication as a continuous signal. Microsoft has built the infrastructure for this — most enterprises haven't deployed it.

Token Protection (formerly Token Binding) in Entra ID cryptographically binds a token to the specific device and session that requested it. A stolen token cannot be replayed from a different device because the cryptographic proof-of-possession check fails. As of 2024, Token Protection is available for Conditional Access in preview for specific application scenarios. It is not enabled by default. It requires compliant devices with TPM 2.0 and the Microsoft Authenticator app or Windows Hello for Business as the authentication method.

Enabling Token Protection via Conditional Access requires a policy targeting your highest-risk application set first:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Policy.Read.All"

$policyParams = @{
    DisplayName = "Require Token Protection - Exchange Online - Pilot"
    State = "enabledForReportingButNotEnforced"  # Start in report-only
    Conditions = @{
        Users = @{
            IncludeGroups = @("YOUR-PILOT-GROUP-OBJECT-ID")
        }
        Applications = @{
            IncludeApplications = @("00000002-0000-0ff1-ce00-000000000000")  # Exchange Online
        }
        Platforms = @{
            IncludePlatforms = @("windows")
        }
    }
    SessionControls = @{
        TokenProtection = @{
            IsEnabled = $true
        }
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("compliantDevice")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams

Start this policy in report-only mode. Pull the Conditional Access insights workbook after 14 days to understand the blast radius before enforcing. Accounts that fail the compliant device check will surface — those are your remediation targets before you flip to enforcement.

Windows Hello for Business is the other half of this architecture. WHfB uses asymmetric key pairs stored in the device TPM — the private key never leaves the hardware. Authentication is a cryptographic proof-of-possession operation, not a credential transmission. An AiTM proxy cannot intercept what is never transmitted. Deploying WHfB at scale via Intune is a separate operational workstream, but it is the single highest-impact control for eliminating phishing-capable authentication on Windows endpoints.

---

Behavioral Continuity as a Detection Layer

Cryptographic controls address the token surface. They don't address the scenario where an attacker authenticates legitimately — using credentials purchased from a breach market, enriched with behavioral data, and submitted from an IP address that scores clean on threat intelligence feeds.

This is where Continuous Access Evaluation (CAE) and behavioral anomaly detection need to work together. CAE is already enabled by default in Entra ID for supported applications. It means that when a user's risk level changes — account compromised signal, location anomaly, session revocation — the application receives a real-time signal to re-evaluate access rather than waiting for the token to expire. For a one-hour access token, that's the difference between 59 minutes of unauthorized access and near-immediate revocation.

CAE alone is not sufficient for AI-driven attacks that establish a clean baseline before pivoting. The behavioral layer requires you to define what "normal" looks like for your user population and alert on deviations that fall below the threshold Entra ID Protection would flag independently.

Microsoft Defender for Cloud Apps (MDA) provides the UEBA layer here. The key configuration decision is whether you're running MDA in discovery mode or with session policies enforced through Conditional Access App Control. For high-risk user populations — privileged accounts, finance, legal, executive assistants — session policies that proxy traffic through MDA and apply real-time inspection are the appropriate control. This is not a default configuration. It requires Conditional Access policies that route sessions through the MDA reverse proxy and session policies defined in the MDA portal.

---

Governance Posture: Closing the Compliance Framework Gap

Your auditors are checking for MFA. Your policy says MFA is required. Your Conditional Access logs show MFA completions. And none of that tells you whether those MFA completions were subsequently bypassed by token theft.

The compliance gap is real and it requires proactive remediation before an incident surfaces it. Three specific actions close the most critical gaps:

First, update your authentication policy documentation to distinguish between phishing-resistant MFA (WHfB, FIDO2, certificate-based authentication) and phishing-capable MFA (TOTP, push notifications, SMS). SOC 2 and FedRAMP auditors increasingly accept this distinction, and CISA's phishing-resistant MFA guidance provides the reference framework for justifying the control differentiation in your audit evidence package.

Second, implement a Privileged Authentication Workstation (PAW) policy for all accounts with Entra ID roles at the level of Global Administrator, Privileged Role Administrator, and Security Administrator. These accounts should authenticate exclusively from dedicated, Intune-managed devices with WHfB enforced and no browser-based authentication permitted to production tenants. Conditional Access device filters can enforce this:

$filterCondition = @{
    Mode = "include"
    Rule = 'device.extensionAttribute1 -eq "PAW"'
}

$updateParams = @{
    Conditions = @{
        Devices = @{
            DeviceFilter = $filterCondition
        }
    }
}

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "YOUR-POLICY-ID" -BodyParameter $updateParams

Third, establish a quarterly Token Protection Coverage Review as a formal governance artifact. This review should document: which applications have Token Protection enforced, which user populations are excluded and why, what percentage of sign-ins are completing with phishing-resistant vs. phishing-capable methods, and what the current CAE coverage rate is across your application portfolio. This review doesn't exist in any compliance framework today — but it will, and having the operational muscle to produce it before it's mandated is the difference between a mature security program and a reactive one.

---

Recommendations for Production Deployment

The sequence matters. Don't attempt to deploy all of this simultaneously.

Phase one is visibility. Deploy the KQL queries above. Run them for 30 days. Understand your current token replay exposure and your Conditional Access coverage gaps before changing any enforcement policy. Changing policy without baseline visibility creates outages and erodes trust in the security program.

Phase two is phishing-resistant authentication for privileged accounts. Every account holding a privileged Entra ID role should be on WHfB or FIDO2 within 90 days. This is a finite population — typically under 50 accounts in most enterprises — and the operational lift is manageable. The risk reduction is disproportionate to the effort.

Phase three is Token Protection rollout in report-only mode for your highest-value application set. Exchange Online, SharePoint Online, and any application handling regulated data are the starting targets. Run report-only for 14-30 days, remediate non-compliant devices, then enforce.

Phase four is behavioral continuity. Deploy MDA session policies for privileged and high-risk user populations. Define your UEBA baselines. Integrate MDA alerts into your SIEM with defined response playbooks — an alert without a playbook is noise.

Phase five is governance formalization. Document the phishing-resistant vs. phishing-capable distinction in your control library. Schedule the quarterly Token Protection Coverage Review. Update your audit evidence package to reflect the architectural controls, not just the MFA checkbox.

---