Taming Microsoft Authenticator's Passkey Prompts: Architecting Granular FIDO2 & Device Biometric Enrollment Control in Entra ID

Architectural Premise & The Real-World Challenge

Uncontrolled passkey prompts from Microsoft Authenticator are a silent operational friction point for many enterprises today. While the push for phishing-resistant authentication is paramount, an unmanaged rollout of FIDO2 security keys or Microsoft Authenticator passkeys creates a security and compliance blind spot. Users, presented with a seemingly innocuous "Do you want to save your passkey?" prompt, will often accept, inadvertently enrolling a new authentication method without IT governance. This bypasses established onboarding workflows, potentially binds a critical credential to an unmanaged personal device, and creates a support burden when users inevitably lose or replace that device.

The core architectural trade-off here is balancing user experience convenience with stringent IT control over authentication methods. Entra ID offers robust capabilities for managing authentication, but the default "enabled" state for FIDO2 and Microsoft Authenticator passkeys often leads to this shadow IT scenario. For organizations with strict compliance requirements (e.g., CMMC, NIST, HIPAA), allowing any user to register a device-bound passkey without prior approval, device attestation, or specific policy enforcement is a non-starter. Our objective is to design and implement a framework that gates these enrollments, ensuring only authorized users on compliant devices can provision these advanced credentials.

Under the Hood: Execution Engine & Mechanics

Understanding how these prompts manifest and how credentials are registered is critical. At its core, both FIDO2 security keys and Microsoft Authenticator passkeys leverage the WebAuthn standard. When a user authenticates to an Entra ID-protected resource via a compatible browser or application, and if the Entra ID tenant's authentication methods policy permits, the client-side WebAuthn API can initiate a credential registration flow.

For Microsoft Authenticator, the app registers itself as a platform authenticator on the mobile OS (iOS/Android). When a user signs into an Entra ID-connected app on their device, the Authenticator app detects the opportunity to offer a passkey enrollment if configured in Entra ID. This isn't a direct Intune Management Extension (IME) or OMA-DM CSP channel pushing a policy; rather, it's a client-side capability that interacts with Entra ID's authentication service during a sign-in event, subject to policy evaluation.

Windows Hello for Business (WHfB) acts as a platform authenticator for Windows devices, intrinsically supporting FIDO2. When WHfB is provisioned, it creates a FIDO2-compatible credential. The primary control surfaces in Entra ID for managing these phishing-resistant methods are:

1. Authentication Methods Policy (AMP): This is the explicit control for enabling or disabling specific authentication methods, including FIDO2 Security Keys and Microsoft Authenticator (Passkey). Located under Entra Admin Center > Protection > Authentication methods > Policies. Each method policy has a global "Enable" toggle and the ability to target specific users or groups. This is the first line of defense against uncontrolled enrollment. When disabled, the Entra ID authentication service will not allow registration of the credential type, regardless of client capabilities.
2. Conditional Access (CA) Policies: While CA policies don't directly control enrollment, they are crucial for controlling usage and enforcing device posture. A CA policy requiring "Require FIDO2 Strong Authentication" or "Require compliant device" can indirectly gate the utility of an unmanaged passkey. If a user enrolls a passkey on a non-compliant personal device, a CA policy can block sign-ins from that device, rendering the passkey useless for enterprise access and thus discouraging unmanaged enrollment.
3. Microsoft Graph API: All management of Authentication Methods Policies can be automated via the Graph API. The relevant endpoints are within the /beta/policies/authenticationMethodPolicy path. For FIDO2, it's /beta/policies/authenticationMethodPolicy/fido2Methods, and for Microsoft Authenticator passkeys, /beta/policies/authenticationMethodPolicy/microsoftAuthenticatorMethods. These endpoints allow granular configuration of inclusion/exclusion groups programmatically, which is essential for scaled deployments and auditability.

Enterprise Edge Cases & Scale Gotchas

Managing FIDO2 and Authenticator passkeys at enterprise scale introduces several complexities:

A common gotcha involves the user experience. If users are accustomed to Authenticator for MFA push notifications, they might confuse the passkey prompt with their existing MFA setup. Clear communication and user training are essential to differentiate between a one-time MFA registration and a permanent device-bound passkey. Furthermore, for hybrid-joined environments, ensuring WHfB provisioning aligns with FIDO2 policy can be complex, especially with certificate-based trust deployments versus key-trust.

Production Implementation & Automation

The recommended approach is to disable FIDO2 Security Keys and Microsoft Authenticator Passkeys globally, then enable them explicitly for pilot or authorized groups. This "deny-by-default, allow-by-exception" model ensures tight control.

Phase 1: Disable Globally (Deny-by-Default)

1. Review Existing FIDO2 Policy: Before making changes, understand the current state.
   🔐 Cloud Authentication Tip: Use Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.

   # Required Scopes: Policy.Read.All
   Connect-MgGraph -Scopes "Policy.Read.All"
   
   Get-MgPolicyAuthenticationMethodPolicyFido2Configuration | Format-List -Property "State", "Is  Enabled", "IncludeTargets", "ExcludeTargets"
   Get-MgPolicyAuthenticationMethodPolicyMicrosoftAuthenticatorConfiguration | Format-List -Property "State", "Is  Enabled", "IncludeTargets", "ExcludeTargets"
   🐛 Debug / Fix

   Copy
2. Disable FIDO2 Security Keys for All Users: This ensures no new FIDO2 keys can be registered unless explicitly allowed.
   🔐 Cloud Authentication Tip: Use Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.

   # Required Scopes: Policy.ReadWrite.AuthenticationMethod
   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   
   $fido2Policy = Get-MgPolicyAuthenticationMethodPolicyFido2Configuration
   $fido2PolicyParams = @{
       "State" = "Disabled"
       "IsSelfServiceRegistrationAllowed" = $false # Explicitly disable self-service
       "IncludeTargets" = @() # Ensure no groups are included
       "ExcludeTargets" = @() # No exclusions needed if globally disabled
   }
   
   Update-MgPolicyAuthenticationMethodPolicyFido2Configuration -BodyParameter $fido2PolicyParams -WhatIf
   # Remove -WhatIf for production execution.
   🐛 Debug / Fix

   Copy
3. Disable Microsoft Authenticator Passkeys for All Users: This prevents new Authenticator app passkey registrations.
   🔐 Cloud Authentication Tip: Use Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.

   # Required Scopes: Policy.ReadWrite.AuthenticationMethod
   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   
   $authAppPolicy = Get-MgPolicyAuthenticationMethodPolicyMicrosoftAuthenticatorConfiguration
   $authAppPolicyParams = @{
       "State" = "Disabled"
       "IncludeTargets" = @() # Ensure no groups are included
       "ExcludeTargets" = @() # No exclusions needed if globally disabled
   }
   
   Update-MgPolicyAuthenticationMethodPolicyMicrosoftAuthenticatorConfiguration -BodyParameter $authAppPolicyParams -WhatIf
   # Remove -WhatIf for production execution.
   🐛 Debug / Fix

   Copy

Phase 2: Enable for Specific Groups (Allow-by-Exception)

Create a security group (e.g., SG-Contoso-FIDO2-Pilot) in Entra ID and add authorized users to it. Obtain its Object ID.

1. Enable FIDO2 Security Keys for Pilot Group:
   🔐 Cloud Authentication Tip: Use Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.

   # Required Scopes: Policy.ReadWrite.AuthenticationMethod
   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   
   $fido2PilotGroupId = "a1b2c3d4-e5f6-7890-1234-567890abcdef" # Replace with your pilot group's Object ID
   
   $fido2PolicyParams = @{
       "State" = "Enabled"
       "IsSelfServiceRegistrationAllowed" = $true # Allow self-service for pilot group
       "IncludeTargets" = @(
           @{
               "TargetType" = "group"
               "Id" = $fido2PilotGroupId
               "Is  Enabled" = $true
           }
       )
       "ExcludeTargets" = @()
   }
   
   Update-MgPolicyAuthenticationMethodPolicyFido2Configuration -BodyParameter $fido2PolicyParams -WhatIf
   # Remove -WhatIf for production execution.
   🐛 Debug / Fix

   Copy
2. Enable Microsoft Authenticator Passkeys for Pilot Group:
   🔐 Cloud Authentication Tip: Use Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.

   # Required Scopes: Policy.ReadWrite.AuthenticationMethod
   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   
   $authAppPilotGroupId = "b2c3d4e5-f6a7-8901-2345-67890abcdef0" # Replace with your pilot group's Object ID
   
   $authAppPolicyParams = @{
       "State" = "Enabled"
       "IncludeTargets" = @(
           @{
               "TargetType" = "group"
               "Id" = $authAppPilotGroupId
               "Is  Enabled" = $true
           }
       )
       "ExcludeTargets" = @()
   }
   
   Update-MgPolicyAuthenticationMethodPolicyMicrosoftAuthenticatorConfiguration -BodyParameter $authAppPolicyParams -WhatIf
   # Remove -WhatIf for production execution.
   🐛 Debug / Fix

   Copy

Phase 3: Audit Existing Registrations

For a complete picture, audit existing FIDO2 and Authenticator Passkey registrations for users in your tenant. This identifies any credentials registered before the "deny-by-default" policy was applied.

# Required Scopes: User.Read.All, UserAuthenticationMethod.Read.All
Connect-MgGraph -Scopes "User.Read.All", "UserAuthenticationMethod.Read.All"

$users = Get-MgUser -All

$registeredFidoMethods = @()
$registeredAuthAppPasskeys = @()

foreach ($user in $users) {
    try {
        $fido2Methods = Get-MgUserAuthenticationFido2Method -UserId $user.Id
        $fido2Methods | ForEach-Object {
            $_ | Add-Member -NotePropertyName "UserPrincipalName" -NotePropertyValue $user.UserPrincipalName -PassThru
            $_ | Add-Member -NotePropertyName "MethodType" -NotePropertyValue "FIDO2 Security Key" -PassThru | Add-Member -NotePropertyName "DisplayName" -NotePropertyValue $_.DisplayName -PassThru
            $registeredFidoMethods += $_
        }
    } catch {
        Write-Warning "Could not retrieve FIDO2 methods for $($user.UserPrincipalName): $($_.Exception.Message)"
    }

    try {
        $authMethods = Get-MgUserAuthenticationMethod -UserId $user.Id
        $authAppPasskeys = $authMethods | Where-Object -Property "Odata__odata_type" -EQ "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod" | Where-Object -Property "IsDeviceBound" -EQ $true # Filter for device-bound passkeys

        $authAppPasskeys | ForEach-Object {
            $_ | Add-Member -NotePropertyName "UserPrincipalName" -NotePropertyValue $user.UserPrincipalName -PassThru
            $_ | Add-Member -NotePropertyName "MethodType" -NotePropertyValue "Authenticator Passkey" -PassThru | Add-Member -NotePropertyName "DisplayName" -NotePropertyValue $_.DisplayName -PassThru
            $registeredAuthAppPasskeys += $_
        }
    } catch {
        Write-Warning "Could not retrieve Authenticator methods for $($user.UserPrincipalName): $($_.Exception.Message)"
    }
}

Write-Host "`n--- Registered FIDO2 Security Keys ---`n"
$registeredFidoMethods | Select-Object UserPrincipalName, DisplayName, CreationDateTime, AttestationLevel, AaGuid | Format-Table -AutoSize

Write-Host "`n--- Registered Authenticator Passkeys (Device-Bound) ---`n"
$registeredAuthAppPasskeys | Select-Object UserPrincipalName, DisplayName, CreatedDateTime, DeviceTag, ClientAppName | Format-Table -AutoSize
🐛 Debug / Fix

Architectural Takeaways & Decision Matrix

Effective management of Microsoft Authenticator passkey prompts and FIDO2 enrollment is a multi-layered architectural challenge. It demands a proactive, policy-driven approach rather than reactive troubleshooting. The fundamental decision matrix revolves around the primary control plane:

• Authentication Methods Policy (AMP): Your primary instrument for controlling enrollment. Use it to explicitly permit or deny the ability for users to register FIDO2 security keys and Microsoft Authenticator passkeys. This is where you implement your "deny-by-default, allow-by-exception" strategy.
• Conditional Access (CA): Your primary instrument for controlling usage and enforcing device compliance. While it doesn't prevent enrollment, it ensures that even if an unauthorized credential is registered, it cannot be used to access corporate resources unless strict device posture requirements are met.

The synergy between AMP and CA is crucial. AMP prevents the proliferation of unmanaged credentials, while CA acts as a safety net, ensuring only compliant devices can leverage these strong authentication methods. Neglecting either component leaves a significant gap in your enterprise authentication security posture.