This is Part 2 of our Phishing-Resistant MFA series.
Part 1 — MFA Isn't Enough: How AiTM Phishing Steals M365 Sessions After Authentication — explains why traditional MFA fails against modern attacks and why FIDO2 hardware keys are the right answer.
Part 3 — FIDO2 Broke Our FortiGate VPN — Diagnosing the CA Auth Strength Conflict — the auth strength conflict that surfaces in every FIDO2 rollout.
Part 4 — Real-World FIDO2 Coexistence: RDP, Legacy VPNs, TAP Misuse, and Recovery Flows — the second-order problems after enforcement goes live.

Executive Summary

  • The most common FIDO2 rollout mistake is flipping CA enforcement before users are enrolled — causing immediate lockouts
  • A staged wave approach (Wave 0 prerequisites → Wave 1 pilot → Wave 2 high-risk → Wave 3 general) eliminates that risk
  • TAP (Temporary Access Pass) is required for any user with no MFA method registered — without it, they cannot enroll
  • Build your service account exclusion group before you touch CA policies, not after
  • Never promote a CA policy from report-only to enforced until every user in scope shows REGISTERED in your enrollment status check

The Fear That Stops Every FIDO2 Project

We hear a version of this on almost every FIDO2 kickoff call:

"We want phishing-resistant MFA, but we're afraid of locking out the CEO at 7 AM on a Monday."

That fear is legitimate. It has happened. It happens because teams skip the prerequisites, flip the CA policy from report-only to enforced, and discover that 20% of their users never enrolled — because nobody told them to.

The fix is not moving slower. It is moving in the right order.

This post documents the exact wave plan we use in production FIDO2 rollouts: the pre-flight checks, the enrollment sequence, the gate criteria between waves, and the script we run before promoting any CA policy to enforcement.

If Part 1 answered why you need FIDO2, this answers how to get there without a support ticket storm.

Why Lockouts Happen

FIDO2 lockouts almost always trace to one of three mistakes:

1. The sequence is backwards. The CA policy goes to enforcement before users enroll. Users arrive at the sign-in page, are challenged for a FIDO2 key they don't have yet, and are blocked.

2. Service accounts are in scope. Automation accounts, scan agents, FSSO service accounts, and shared mailboxes don't have hardware keys. If they land in a FIDO2 CA policy, they fail — and the downstream effects (VPN auth, backup jobs, monitoring alerts) fail with them.

3. No-MFA users have no enrollment path. Users with zero MFA methods registered cannot complete the identity verification step at aka.ms/mysecurityinfo. They need a Temporary Access Pass first — and if TAP isn't enabled in the tenant, they're stuck.

All three are preventable. Here's how.

Phase 0: Prerequisites (Do Not Skip These)

Wave 0 has no user impact. It is all configuration and validation work done before a single CA policy is promoted.

1. Create Break-Glass Accounts

Two cloud-only accounts. Microsoft's official guidance (SC-300 / emergency access account documentation) is specific about how these must be configured — cutting corners here defeats the purpose.

Account requirements:

  • Cloud-only, not synced from on-premises AD. If AD Connect has an outage or your on-premises environment is unreachable, synced accounts may not be usable.
  • UPN must use the .onmicrosoft.com domain — not your custom domain. Custom domains are often federated. If federation fails or your ADFS/external IdP is unreachable, federated accounts cannot authenticate. The .onmicrosoft.com domain always resolves directly to Entra ID.
  • No license required. Break-glass accounts are excluded from all CA policies — P1 licensing applies to users subject to CA, not accounts that bypass it entirely. Do not let a missing spare license block this step.
  • Assign Global Administrator permanently — not through PIM. In an emergency, PIM may be unavailable (outage, MFA infrastructure failure, conditional access misconfiguration). Global Admin must be a direct role assignment, not an eligible one.

Authentication configuration:

  • Use a strong passphrase: 20+ characters, randomly generated.
  • Do not register Authenticator app, SMS, or any phone-based MFA method on these accounts. Phone-based MFA depends on infrastructure (phone, network, MFA service) that may be unavailable during the exact emergencies these accounts are meant to address.
  • Optionally register a FIDO2 hardware key for each account and store it physically with the account credentials. This gives you phishing-resistant MFA that doesn't depend on a phone.
  • Exclude these accounts from ALL Conditional Access policies via a dedicated group (BG-CA-Exclusion — separate from your service account exclusion group). This includes MFA registration policies, device compliance policies, sign-in risk policies, and your FIDO2 enforcement policies. If a CA policy can block a sign-in, the break-glass accounts must be excluded from it.

Credential storage:

  • Store credentials in a fireproof safe — not only a password manager. Digital-only storage fails when the systems you're trying to recover are unavailable.
  • Distribute credentials to at least two separate administrators who each independently know the account UPN and passphrase. A break-glass credential known only to one person is a single point of failure.
  • Consider storing a sealed backup set in an offsite secure location (e.g., legal safe, bank vault, or secondary office).

Monitoring:

  • Configure a sign-in alert for any authentication event from either break-glass UPN. Use Entra Diagnostic Settings → Log Analytics Workspace → create an alert rule on the SigninLogs table filtered by UPN. Any sign-in outside a scheduled monthly test is a security incident and should trigger an immediate investigation.

Testing:

  • Test at minimum monthly. Sign in as the break-glass account, verify access to the Entra Admin Center and Azure Portal, then sign out. A break-glass account you test quarterly may fail when you need it most due to an expired password, a license change, or a CA policy that was accidentally added without the exclusion group.
  • Log every test with date, who tested, and result.

Do not proceed past Wave 0 until break-glass accounts exist, are confirmed working, and credentials are stored per the above requirements.

2. Build Your Service Account Exclusion Group

Create an Entra security group — we use SA-CA-Exclusion — and explicitly exclude it from all FIDO2 enforcement CA policies.

Every organization underestimates how many accounts need to be in this group. Walk your app sign-in logs before finalizing the list. Common ones we find:

  • FSSO/LDAP service accounts for firewall integration (FortiGate, Palo Alto)
  • RMM and monitoring platform service accounts
  • Backup platform accounts (Veeam, Metallic, Datto)
  • Scan/automation accounts (LANsweeper, PRTG, vulnerability scanners)
  • Shared mailboxes and kiosk accounts
  • SCIM provisioning accounts

Add these accounts to SA-CA-Exclusion before you build the CA policy. It is much harder to clean up afterward.

Entra Connect sync accounts are handled automatically — they never appear in user CA scope. External guest accounts are similarly out of scope. You do not need to list those.

Review SA-CA-Exclusion membership quarterly.

3. Enable FIDO2 in Authentication Methods Policy

This step is often confused with enforcement. It is not.

Enabling FIDO2 in Entra ID → Protection → Authentication Methods → Policies → FIDO2 Security Key simply allows users to register a FIDO2 key at aka.ms/mysecurityinfo. It does not require them to use it. It does not change any sign-in behavior.

Scope it to a group initially (your Wave 1 pilot group), then expand as you move through waves.

If you want to restrict which hardware keys are accepted — which we always recommend — configure the AAGUID allow-list. YubiKey AAGUIDs are published by Yubico. Restricting to your specific hardware model prevents users from registering phone passkeys or unauthorized keys to satisfy the policy. This matters most in regulated environments.

4. Enable TAP (Temporary Access Pass)

Go to Authentication Methods → Policies → Temporary Access Pass → Enable.

Recommended settings for an enrollment rollout:

  • Minimum lifetime: 60 minutes
  • Maximum lifetime: 480 minutes (covers a full group enrollment session)
  • One-time use: Yes

TAP is not optional if any of your users have zero MFA methods registered. We typically find that 20–30% of tenant users fall into this category, especially in environments that migrated from per-user MFA without enforcing registration.

A user with no MFA cannot verify their identity at mysecurityinfo. TAP bypasses that — the user signs in with their username + TAP code and can immediately register their FIDO2 key in the same session. The TAP is consumed on use and cannot be reused.

Do not email TAP codes to users. Deliver them by phone or Teams message at the start of an enrollment session.

5. Build CA Policy in Report-Only Mode

Create your FIDO2 enforcement CA policy in report-only, not enforced. A report-only policy evaluates against every sign-in and logs the outcome — it does not block anyone.

Basic policy shape:

  • Users: Start with your Wave 1 pilot group
  • Cloud apps: Microsoft 365 apps (Exchange, SharePoint, Teams, M365 Apps)
  • Grant: Require authentication strength → Phishing-resistant MFA (or a custom auth strength scoped to FIDO2 only)
  • Exclude: Your BG-CA-Exclusion group and SA-CA-Exclusion group

Leave it in report-only until Wave 1 enrollment is complete and you have validated clean sign-in logs. The gate to enforcement is clean logs — not a calendar date.

6. Run the Enrollment Readiness Assessment

Pull the User Registration Details report from Entra Admin → Protection → Authentication Methods → User registration details. Export the full list.

Segment your users into four buckets:

Bucket Path
Has Authenticator push (verified app registered) Can enroll FIDO2 key directly at mysecurityinfo
SMS only — no Authenticator SMS satisfies identity proof; can enroll directly
FIDO2 already enrolled Done — confirm key is the right hardware
No MFA at all Needs TAP before enrollment

This segmentation drives your TAP generation list for Wave 3. Complete it before you begin Wave 1.

The Enrollment Sequence (This Order Matters)

This is the single most important operational pattern in a FIDO2 rollout:

1. Enable FIDO2 in Authentication Methods policy (scoped to pilot group)
2. Users self-enroll at aka.ms/mysecurityinfo
3. Verify enrollment (run status check script — see below)
4. THEN add users to the CA enforcement group

The CA policy does not move to enforcement until step 3 is confirmed clean. Never invert steps 2 and 4.

The Wave Model

Wave 1 — IT Admins (Pilot)

Who: Your IT administrators and security team. The people who can troubleshoot a lockout if one occurs.

Enrollment: Live session. Walk each person through aka.ms/mysecurityinfo → Add method → Security key → USB → touch key → set PIN. Verify they can authenticate to Exchange, SharePoint, and Teams using the key before leaving the session.

Gate to enforcement: Run the enrollment status check script against every Wave 1 user. All must show REGISTERED before you promote the CA policy from report-only to enforced for this group.

Break-glass drill: Before you enforce for any wave, test your break-glass accounts. Sign in as a break-glass account and verify access to Entra Admin Center. This confirms your emergency access path is functional.

Gate to Wave 2: Zero auth failures for 24 hours in the enforced CA sign-in logs.

Wave 2 — High-Risk Users

Who: Finance, executives, and anyone with access to sensitive data, elevated permissions, or systems that would be high-value to an attacker.

Enrollment: Same live session approach as Wave 1. These users are often less technical — budget more time per person and have a runbook ready for the enrollment guide to send in advance.

Gate to enforcement: Same as Wave 1. Run the script. All users in scope must show REGISTERED.

Gate to Wave 3: Zero auth failures for 24 hours.

Wave 3 — General Population

Who: All remaining users who are not service accounts.

Enrollment split:

  • Users with Authenticator or SMS registered → standard self-service enrollment via aka.ms/mysecurityinfo
  • Users with no MFA registered → TAP delivery required before enrollment

For large Wave 3 populations, group enrollment sessions (virtual or in-person) with a support line open are the most efficient approach. Plan for 10–15 minutes per user for the key registration itself.

Tracking Enrollment Status

Before promoting any wave from report-only to enforced, run this against your user list:

#Requires -Modules Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Identity.SignIns

param(
    [string]$UserListPath,   # CSV with column header "UPN"
    [string]$ExportPath
)

$Users = @(
    # Add UPNs here, or pass -UserListPath "wave1-users.csv"
)

if (-not (Get-MgContext -ErrorAction SilentlyContinue)) {
    Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All" -NoWelcome
}

if ($UserListPath) {
    $Users = (Import-Csv $UserListPath).UPN
}

$results = foreach ($upn in $Users) {
    try {
        $keys = Get-MgUserAuthenticationFido2Method -UserId $upn -ErrorAction Stop
        if ($keys.Count -gt 0) {
            $keys | ForEach-Object {
                [PSCustomObject]@{
                    UPN            = $upn
                    Status         = "REGISTERED"
                    KeyCount       = $keys.Count
                    RegisteredDate = $_.CreatedDateTime?.ToString("yyyy-MM-dd HH:mm")
                    Model          = $_.Model
                }
            }
        } else {
            [PSCustomObject]@{ UPN = $upn; Status = "NOT REGISTERED"; KeyCount = 0 }
        }
    } catch {
        [PSCustomObject]@{ UPN = $upn; Status = "ERROR"; KeyCount = 0 }
    }
}

$results | Group-Object Status | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count)" -ForegroundColor $(if ($_.Name -eq 'REGISTERED') {'Green'} elseif ($_.Name -eq 'ERROR') {'Red'} else {'Yellow'})
}

if (($results | Where-Object Status -ne 'REGISTERED').Count -eq 0) {
    Write-Host "`n✅ All users registered. Wave is ready for CA enforcement." -ForegroundColor Green
} else {
    Write-Host "`n⚠️  Enrollment incomplete. Do NOT enable CA enforcement." -ForegroundColor Yellow
    $results | Where-Object Status -ne 'REGISTERED' | ForEach-Object {
        Write-Host "   Needs enrollment: $($_.UPN)" -ForegroundColor Yellow
    }
}

if ($ExportPath) { $results | Export-Csv $ExportPath -NoTypeInformation -Encoding UTF8 }

The enforcement readiness check at the end is not cosmetic — it is your go/no-go gate. If any user shows NOT REGISTERED, the wave does not move to enforcement. Find out why, resolve it (TAP, hardware issue, missed session), and run the script again.

Monitoring Enrollment Adoption

Once users are enrolled and CA is enforced, track adoption via two Entra views:

User registration details — Entra Admin → Protection → Authentication Methods → User registration details
Filter by FIDO2 security key registration. This shows who has registered, when, and how many keys.

Authentication methods activity report — Entra Admin → Protection → Authentication Methods → Activity
Shows registration events vs. actual sign-in usage by method. If users registered but are still signing in with push notifications, something is wrong with the CA policy scope.

The gap between "registered" and "actively using" is usually a CA policy scoping issue. Check that enrolled users are actually in the enforcement group.

Re-Authentication Interval

A common question during FIDO2 rollouts: how often should we force re-authentication?

The answer depends on your mitigating controls, but our baseline recommendation is 30 days for standard users. Here is the reasoning:

Phishing-resistant MFA is already resistant to session token theft — the key is cryptographically bound to the origin and cannot be replayed by an attacker even if they intercept the authentication flow. That is the whole point. Requiring daily or weekly re-authentication has a low security return and a high friction cost.

If your environment has additional controls — VPN-based Conditional Access, device compliance requirements, or network-based location policies — a longer interval (up to 90 days) is defensible.

Do not let the re-auth interval conversation delay the rollout. Pick 30 days, document the rationale, and revisit after Wave 3 is complete.

Before You Flip to Enforcement: The Checklist

Run this before promoting any CA policy from report-only to enforced:

☐ Break-glass accounts created (.onmicrosoft.com UPN, no license required, permanent Global Admin — not PIM, no phone MFA registered, BG-CA-Exclusion group applied, credentials in fireproof safe split between two admins), signed in to verify access this month
☐ SA-CA-Exclusion group populated and excluded from FIDO2 CA policy
☐ TAP enabled and tested (generate a test TAP, use it, confirm it is consumed)
☐ Enrollment status script: all users in wave scope show REGISTERED
☐ Report-only sign-in logs reviewed: no unexpected failures
☐ Break-glass drill completed (verified admin access using break-glass account)
☐ Support channel open for the enforcement window (Teams channel, help desk)

If any item is unchecked, the policy does not move to enforcement.

What Breaks Next

We said at the start that FIDO2 rollouts surface non-obvious failures. We were not being abstract.

On a recent rollout, the week after enforcement went live, we got a ticket: "Users are being prompted for their YubiKey when connecting to the VPN, but VPN is supposed to use Authenticator."

That is Part 3 of this series. The short version: a generic MFA grant on a VPN Conditional Access policy defaults to the strongest registered method. The moment your users have FIDO2 keys registered, "strongest registered method" means FIDO2 — even for resources that were never supposed to require it.

The fix requires building a custom authentication strength that explicitly excludes FIDO2 for the VPN policy. It is a 20-minute fix once you know what to look for. It is a multi-hour mystery if you do not.

Part 3 covers the diagnosis and the exact policy configuration to resolve it.

This post documents patterns from production FIDO2 rollouts across multiple M365 environments. Environment details have been generalized. Your configuration may differ — validate in report-only mode before enforcing.

The Get-FIDO2EnrollmentStatus script requires the Microsoft.Graph PowerShell module and UserAuthenticationMethod.Read.All permission (delegated or application).

Series navigation:

Want more patterns like this?

Get the full 6-part guide — what Intune doesn't tell you, but you'll hit in production.

Running into this in production? 30 minutes — I will tell you directly if it is worth fixing.

Book a Fit Call →