Executive Summary

  • FIDO2 hardware keys cannot satisfy RDP Network Level Authentication — a scoped auth strength or Windows Hello for Business is required for Windows logon scenarios
  • RADIUS-backed VPNs do not support FIDO2 natively; every generic MFA grant in your CA policies needs an audit after hardware key deployment
  • TAP is a bootstrap credential, not a help desk shortcut — misuse patterns create a phishable bypass in an otherwise phishing-resistant environment
  • Lost key recovery is a defined process, not an ad-hoc ticket — the response window between loss and key removal matters

Where Part 3 Left Off

Part 3 documented what happened when a FortiGate VPN started prompting for a hardware key after FIDO2 was deployed — and why: generic "Require MFA" Conditional Access grants silently escalate to the user's strongest registered method. Every app scoped with a generic grant gets the same behavior after FIDO2 enrollment.

The FortiGate was the first symptom. Part 4 is the longer tail.

This post covers the coexistence issues that surface after enforcement is live and the rollout is technically "done": RDP access, non-FortiGate VPNs, Windows Hello for Business interplay, TAP misuse patterns, new hire onboarding, and lost-key recovery. These are not edge cases. They surface in every production FIDO2 deployment within the first 30 days.

RDP: Why Hardware Keys Don't Work Here

The most common source of confusion after FIDO2 enforcement goes live is Remote Desktop.

FIDO2 hardware keys are WebAuthn credentials — they operate inside a browser-based authentication flow where the authenticator is cryptographically bound to the origin domain. Remote Desktop Protocol uses Network Level Authentication (NLA), which prompts for Windows credentials at the network layer before a session is established. NLA does not invoke a browser. There is no WebAuthn flow. A hardware key cannot satisfy an NLA credential prompt.

What this produces in practice:

A user tries to RDP to a server or cloud-joined workstation. Conditional Access evaluates the connection and demands phishing-resistant MFA. The RDP client prompts for a username and password. The user enters credentials. CA rejects it — password does not satisfy the FIDO2 auth strength. The connection fails with a generic access error. The user reports that RDP "stopped working after the key rollout."

The fix is the same pattern as Part 3: create a custom authentication strength for the RDP CA policy that excludes FIDO2 hardware keys.

For most environments, the right strength for RDP includes:

  • Windows Hello for Business (phishing-resistant, device-bound, works natively for Windows logon)
  • Microsoft Authenticator (passwordless phone sign-in)
  • Optionally certificate-based authentication if your PKI supports it

FIDO2 hardware keys should be explicitly excluded from any CA policy scoping RDP or Windows logon scenarios.

Windows Hello for Business: The One That Often Saves You

Before diagnosing every RDP break as a FIDO2 conflict, check whether your affected users have Windows Hello for Business enrolled.

Microsoft's Phishing-Resistant MFA authentication strength tier includes three methods:

  • FIDO2 security keys
  • Windows Hello for Business
  • Certificate-based authentication (hardware-bound)

A CA policy using "Phishing-resistant MFA" (the built-in strength) will be satisfied by any of these three. If users in your environment have WHfB enrolled on their primary device, they can satisfy a phishing-resistant MFA requirement without a hardware key — and RDP from that device to other resources works because WHfB is the credential Windows uses natively.

Where this breaks down:

  • Loaner devices without WHfB provisioned (WHfB requires the device to be Entra-joined and Intune-enrolled, with provisioning completed)
  • Shared workstations where WHfB is disabled or not applicable
  • RDP from a personal device, a Mac, or any machine where WHfB isn't available

Audit before assuming: After FIDO2 enforcement goes live, run a registration status check that includes WHfB, not just hardware keys. Users with WHfB may never notice the hardware key requirement because WHfB satisfies it automatically.

# Registration status including WHfB
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All", "User.Read.All"

$users = Get-MgUser -All -Filter "accountEnabled eq true" -Property "id,displayName,userPrincipalName"

$results = foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
    $hasFido2 = $methods.AdditionalProperties.Values | Where-Object { $_.'@odata.type' -eq '#microsoft.graph.fido2AuthenticationMethod' }
    $hasWhfb = $methods.AdditionalProperties.Values | Where-Object { $_.'@odata.type' -eq '#microsoft.graph.windowsHelloForBusinessAuthenticationMethod' }

    [PSCustomObject]@{
        DisplayName = $user.DisplayName
        UPN         = $user.UserPrincipalName
        FIDO2       = if ($hasFido2) { "YES" } else { "no" }
        WHfB        = if ($hasWhfb) { "YES" } else { "no" }
        Either      = if ($hasFido2 -or $hasWhfb) { "YES" } else { "NO — RISK" }
    }
}

$results | Sort-Object Either | Format-Table -AutoSize

Users with Either = NO — RISK cannot satisfy a phishing-resistant MFA requirement by any method. They need a hardware key enrolled before enforcement reaches them.

Legacy VPNs: The FortiGate Pattern, Other Platforms

Part 3 covered FortiGate SAML VPN. The same root cause applies to any VPN that authenticates through Entra Conditional Access with a generic MFA grant — but the diagnosis path looks different on each platform.

RADIUS-backed VPNs (Cisco AnyConnect, GlobalProtect, Always On VPN)

RADIUS authentication does not support WebAuthn. VPNs using the NPS Extension for Azure MFA to enforce MFA via RADIUS will push an Authenticator notification — they cannot send a FIDO2 challenge. This means FIDO2 users connecting through a RADIUS-backed VPN will receive an Authenticator push, complete it, and be let through.

This sounds fine — until you look at what's happening in the CA layer.

If your VPN CA policy uses a generic "Require multifactor authentication" grant and the user has FIDO2 registered, CA now expects FIDO2. The RADIUS flow pushes Authenticator instead. Depending on how your NPS Extension is configured and how the CA token is evaluated, this can produce inconsistent authentication results — sometimes passing, sometimes failing — without a clear error message. Users report "VPN works sometimes."

Fix: Same as FortiGate. Create a custom authentication strength for the VPN CA policy that includes Authenticator push and excludes FIDO2 hardware keys. The RADIUS flow can satisfy Authenticator push. It cannot satisfy FIDO2.

Always On VPN (machine certificate + user MFA)

Always On VPN typically authenticates in two stages: machine certificate (computer tunnel) and user MFA (user tunnel). The machine cert tunnel is not affected by FIDO2 enrollment. The user tunnel goes through MFA — if it uses NPS Extension, the same RADIUS pattern applies.

Check your user tunnel MFA method and apply the same custom auth strength if needed.

Audit your full CA policy inventory

After FIDO2 deployment, run the same audit from Part 3 across all CA policies:

  1. Pull sign-in logs filtered by authentication method = FIDO2 security key
  2. Filter out apps that are explicitly scoped for FIDO2 (your M365 apps)
  3. Any remaining results = apps where FIDO2 was selected by a generic grant

Each result is a policy that needs a scoped custom authentication strength. The VPN is usually first because it's high-frequency. Device enrollment, admin portal access, and legacy federated apps follow within the first two weeks.

TAP: Bootstrap Credential, Not Help Desk Shortcut

Temporary Access Pass was the right answer in Part 2 for a specific problem: a user with zero MFA registered cannot enroll a hardware key without first authenticating. TAP provides a time-limited, single-use credential to get through that bootstrap.

That is the only correct use of TAP in an environment with FIDO2 enforcement. In production, we consistently see it used for three other things — each of which creates a phishable bypass in a nominally phishing-resistant environment.

Pattern 1: TAP issued via email

An administrator emails a TAP to the user because it is the fastest path.

The problem: email is the primary attack surface FIDO2 is designed to defend against. If a user's email is compromised — or if an attacker successfully phishes the user into an AiTM relay — the TAP lands in the attacker's hands. The attacker uses the TAP to authenticate and register their own FIDO2 key. The legitimate user is now locked out; the attacker has persistent phishing-resistant access.

TAP must be delivered out-of-band. Acceptable delivery methods: phone call to a known number to read it aloud, verified in-person hand-off, secure channel that is not email and not the same device being enrolled. Never email.

Pattern 2: Validity extended beyond the enrollment window

TAP defaults to a one-hour validity. Administrators extend it to 8 or 24 hours "so the user has time."

A TAP with 24-hour validity is a 24-hour window for an attacker to use it. If the delivery channel had any exposure — forwarded text, screenshot shared in Teams, written on a Post-it — that window matters.

Validity should match the task. For FIDO2 enrollment at mysecurityinfo: one hour is enough. The user registers the key in under five minutes. There is no legitimate reason for a 24-hour TAP in this scenario.

Pattern 3: TAP as recurring MFA bypass

A user reports that their key "doesn't work" or that they forgot it at home. The help desk issues a TAP to let them work today. This repeats weekly.

A user receiving regular TAPs is not covered by FIDO2 enforcement. They are covered by TAP-based enforcement, which is phishable. If this pattern is happening, the root cause is an unresolved enrollment or usability issue — not a TAP supply problem.

TAP issuance should require a ticket with documented reason. If the same user is requesting TAPs more than once, that is a signal to investigate — not to issue another TAP.

Pattern 4: Reusable TAP

TAP can be configured as reusable (multiple sign-ins within the validity window) or one-time (single use, consumed on first sign-in). One-time-use is the default.

Reusable TAP is appropriate only in specific break-glass and administrative scenarios — not for end-user enrollment. Verify your TAP authentication method policy has one-time-use enforced for standard issuance.

Monitoring TAP issuance

Any TAP activity in your environment should be visible. Entra audit logs capture TAP creation under Authentication Methods → Temporary Access Pass. Set an alert for TAP issuance volume — more than a handful per week in a post-rollout environment warrants investigation.

New Device and New Hire Onboarding Under Enforcement

FIDO2 enforcement creates a bootstrap problem for users with no MFA registered: they can't sign in to enroll, and they can't enroll without signing in. TAP is the solution — but it requires the process to be defined before the new hire arrives, not discovered on their first day.

The onboarding sequence under FIDO2 enforcement:

  1. IT generates a TAP before the user's start date (validity: 2 hours, one-time-use)
  2. TAP is delivered via verified out-of-band channel (phone, in-person, HR secure channel)
  3. User signs in on day one using TAP
  4. User immediately navigates to mysecurityinfo.microsoft.com and registers their hardware key
  5. TAP is consumed; FIDO2 key is now the active credential
  6. IT verifies enrollment in Entra before the end of day one

If the hardware key hasn't arrived yet: issue TAP as above, but defer FIDO2 registration to when the key arrives. User authenticates with TAP for initial setup, switches to FIDO2 key when it's in hand. Keep the window short — do not leave a user in "TAP mode" for more than a day.

Loaner devices: FIDO2 hardware keys are not tied to a device — they travel with the user. A user on a loaner device with their key in hand can satisfy FIDO2 enforcement with no changes. The exception is if your CA policy also requires device compliance and the loaner is not yet enrolled or compliant. In that case, the user can authenticate (FIDO2 satisfied) but CA may still block (device compliance not satisfied). Resolve the device compliance issue; do not work around it with TAP.

Shared workstations: FIDO2 hardware keys do not work well on shared workstations where multiple users sit at the same machine throughout the day. Each user's key must be physically inserted, which is not practical for shared environments. Options: Windows Hello for Business with PIN (requires Entra join), certificate-based authentication, or scope the FIDO2 enforcement policy to exclude shared workstation users and accept a lower auth strength for that population.

Recovery Flows: When a User Loses Their Key

Lost key is not an edge case. It happens in the first 60 days of any hardware key deployment. The response should be a defined process, not a judgment call at the help desk.

Immediate response (within the hour of report)

Step 1: Remove the FIDO2 key from the account.

Entra Admin Center → Users → [User] → Authentication methods → locate the FIDO2 security key → Delete.

Do not wait to verify the key is truly lost. Remove it immediately on report. If it turns up later, the user re-enrolls — this takes five minutes. An unrevoked key on a lost device is the risk.

Step 2: Revoke active sessions.

Entra Admin Center → Users → [User] → Revoke sessions.

If the key was stolen rather than lost, an attacker may already have an active session. Revocation ends it.

Step 3: Check sign-in logs for recent activity.

Pull the user's sign-in logs for the last 24 hours. Flag any authentication events after the reported loss time. If you see post-loss activity, treat it as a potential compromise — escalate to incident response.

Re-enrollment

Issue a TAP (one-time, one hour) via verified out-of-band channel. User registers the replacement key at mysecurityinfo. Verify enrollment before closing the ticket.

If the user does not yet have a replacement key: issue TAP, but set a specific date (within 5 business days) by which they must register the replacement. Do not leave them in an ongoing TAP pattern while waiting for hardware to arrive.

Spare key strategy

For users in privileged roles (Global Admin, Security Admin, Identity Admin, any break-glass adjacent role): deploy two keys at enrollment time. One on-person, one stored in a secure location they control (office drawer, home safe). A privileged user with a lost key and no spare has no phishing-resistant path back in — TAP for a privileged user is a significantly higher-risk event.

For standard users: two keys is ideal but not always practical for cost or logistics reasons. Make a risk-based call. Users who travel frequently or who are in high-risk roles should get two.

When a user has WHfB as a fallback

If the user has Windows Hello for Business enrolled on their primary device, they can still satisfy phishing-resistant MFA while waiting for a replacement key. This is the practical reason to encourage WHfB enrollment alongside hardware key deployment — it provides a recovery path that doesn't involve TAP.

The Checklist That Didn't Exist Before You Deployed

Looking back at a FIDO2 rollout, most of the coexistence issues in this post were predictable — they just weren't in scope during the wave planning phase. The next time:

Pre-deployment:
☐ Audit ALL CA policies for generic "Require MFA" grants — categorize each by RDP/VPN/cloud app
☐ Identify RADIUS-backed VPNs and confirm NPS Extension version
☐ Check WHfB enrollment baseline — who already has it, who doesn't
☐ Define TAP issuance policy (validity, delivery, approval required)
☐ Define lost-key response process before go-live

During rollout:
☐ Enable TAP before Wave 1 (not after someone gets locked out)
☐ Issue two keys to all admin-tier users at enrollment
☐ Run sign-in log audit after each wave — filter for FIDO2 on non-scoped apps

Post-enforcement:
☐ Monitor TAP issuance volume — more than 10% of users per month is a signal
☐ Review RDP-connected resources for auth strength conflicts
☐ Run registration status check at 30 days — catch anyone who missed enrollment
☐ Confirm spare keys are stored, not just procured

The Architecture Point

Every issue in this series — AiTM bypassing MFA, VPN auth strength conflicts, RDP failures, TAP misuse — comes back to the same architectural question: what can a credential do, from what context, authenticated through what flow?

FIDO2 hardware keys are the right answer to phishing-resistant MFA. They are not magic. Deploying them into an environment with generic CA grants, RADIUS-backed VPNs, and no defined recovery process produces friction that erodes adoption — and often produces workarounds (repeated TAP issuance, FIDO2 enforcement exceptions) that defeat the protection you deployed the keys to provide.

The coexistence work is not optional. It is the deployment.

If You're Still Working Through This

Most of the configurations in this series come from production deployments we support. The patterns are consistent: the wave model works, the auth strength conflicts are predictable, and the TAP misuse patterns appear in almost every environment within the first month.

If you're mid-rollout and hitting issues not covered here — or if enforcement is stalled because your environment has more legacy dependencies than the wave model assumed — that's typically where we get brought in.

→ itccinc.com

For organizations that need verified evidence of security posture — not just policy documentation:

→ verifiedclosure.com

Tags: #FIDO2 #PhishingResistantMFA #ConditionalAccess #TAP #WindowsHelloForBusiness #RDP #YubiKey #EntraID #IdentitySecurity #VerifiedClosure

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 →