Passkeys & FIDO2 WebAuthn Architecture: The Enterprise Guide to Phishing-Resistant Authentication

In production environments today, traditional passphrases, SMS codes, Time-based One-Time Passwords (TOTP), and even mobile MFA push notifications are systematically bypassed in real time. Attackers deploying automated Adversary-in-the-Middle (AitM) reverse proxies—such as Evilginx3, Muraena, or Modlishka—routinely stand up proxy infrastructure that mirrors legitimate Identity Provider (IdP) login portals, intercepts push approvals, and extracts live post-authentication session cookies (ESTSAuth, ESTSAUTHPERSISTENT, SignInStateCookie). Armed with the stolen session cookie, the attacker bypasses the entire credential stack in under 30 seconds without ever needing to crack a password.

Yet the #1 operational mistake engineering teams make when deploying FIDO2 passkeys is assuming that simply registering a passkey makes an account immune. If you configure passkeys in Entra ID or Okta but leave the “Other ways to sign in → Use your password instead” fallback wide open in Conditional Access, your users remain just as vulnerable to AitM phishing as they were before.

graph LR
    User["User Browser"] -- "1. Sends Credentials + Push Code" --> Proxy["Evilginx3 Reverse Proxy"]
    Proxy -- "2. Relays to Real IdP" --> IdP["Microsoft Entra ID / Okta"]
    IdP -- "3. Issues Session Token / Cookie" --> Proxy
    Proxy -- "4. Steals Session Token (ESTSAuth)" --> Hacker["Adversary Terminal"]
    Proxy -- "5. Relays User to Real Portal" --> User

[!IMPORTANT] Executive Summary & Key Takeaways (BLUF):

1. Origin Binding: Passkeys mathematically bind cryptographic assertions to the exact browser URL (origin). Even if a user is tricked into navigating to an AitM phishing proxy, the authenticator refuses to sign the challenge, stopping credential theft at the hardware layer.
2. Device-Bound vs. Synced Credentials: Microsoft Authenticator passkeys for Entra ID are strictly Device-Bound (stored in hardware-backed isolated key storage and explicitly excluded from iCloud Keychain and Google Drive backups). Consumer synced passkeys must not be confused with enterprise FIDO2 implementations.
3. AAGUID Whitelisting: Using Authenticator Attestation GUID (AAGUID) filtering, administrators can enforce that Tier-0 and Tier-1 admins authenticate exclusively using FIPS-certified hardware keys (such as the YubiKey 5 Series).
4. Close the Password Fallback Trap: Registering a passkey does not disable password login. You must enforce Conditional Access Authentication Strengths set to Phishing-resistant MFA to block password fallback and throw Entra ID Error 53003 when untrusted methods are attempted.

---

1. Cryptographic Foundations: WebAuthn, CTAP2 & The Asymmetric Handshake

Passkey authentication relies on public-key cryptography orchestrated across two open protocols:

1. W3C Web Authentication (WebAuthn): Standardized browser JavaScript APIs (navigator.credentials.create() and navigator.credentials.get()) that allow Relying Parties (RPs) to interface with authenticators.
2. FIDO Alliance CTAP2 (Client-to-Authenticator Protocol 2): Transports credential requests across USB, NFC, or BLE between the browser/OS and hardware tokens (YubiKey) or internal cryptographic processors (TPM 2.0, Apple Secure Enclave).

1.1 The Registration Ceremony

During registration, the relying party initiates keypair generation. The private key is minted locally inside the authenticator’s secure element and never leaves the hardware boundary:

sequenceDiagram
    autonumber
    actor User as User / Client
    participant Browser as Browser (WebAuthn API)
    participant Auth as Authenticator (TPM / YubiKey)
    participant RP as Relying Party (Entra ID / Okta)

    RP->>Browser: Send challenge nonce + rp.id ("login.microsoft.com")
    Browser->>Auth: Request credential creation (via CTAP2)
    Auth->>User: Request User Verification (Biometric / PIN)
    User->>Auth: Touch capacitive sensor + enter PIN / Face ID
    Auth->>Auth: Generate unique Asymmetric Key Pair (ES256 / Ed25519)
    Auth->>Auth: Burn Private Key into tamper-resistant storage
    Auth->>Browser: Return Public Key + Signed Attestation Object
    Browser->>RP: Transmit Public Key + ClientDataJSON
    RP->>RP: Verify challenge & store Public Key with User Account

The RP generates a cryptographically random, high-entropy challenge nonce to prevent replay attacks. The authenticator burns the private key into local hardware silicon (never accessible to the host OS or cloud) and returns only the public key and attestation object to the RP directory.

1.2 The Authentication Ceremony & Domain Origin Binding

During authentication, the server never asks for or verifies a shared secret. It requests mathematical proof of private key possession:

sequenceDiagram
    autonumber
    actor User as User / Client
    participant Browser as Browser (WebAuthn API)
    participant Auth as Authenticator (TPM / YubiKey)
    participant RP as Relying Party (Entra ID / Okta)

    RP->>Browser: Send login challenge nonce + allowedCredentials
    Browser->>Browser: Assemble ClientDataJSON (captures exact URL origin)
    Browser->>Auth: Request assertion (challenge hash + rp.id)
    Auth->>User: Enforce User Verification (Biometric / PIN)
    User->>Auth: Scan fingerprint / Enter local device PIN
    Auth->>Auth: Sign (ClientDataHash + AuthenticatorData) with Private Key
    Auth->>Browser: Return cryptographic assertion signature
    Browser->>RP: Send signature + AuthenticatorData
    RP->>RP: Verify mathematical signature against stored Public Key
    RP-->>Browser: Issue authenticated session tokens

1.3 The Secret Weapon: Domain Origin Binding

The mathematical foundation that makes passkeys immune to reverse proxies like Evilginx3 is Origin Binding. When an attacker lures a target to a phishing site (https://login.microsoft.attacker-proxy.com), the browser inspects the address bar and populates ClientDataJSON with the attacker’s actual origin:

{
  "type": "webauthn.get",
  "challenge": "dGVzdC1jaGFsbGVuZ2Utbm9uY2UtOTg3NjU0MzIx",
  "origin": "https://login.microsoft.attacker-proxy.com",
  "crossOrigin": false
}

This causes the attack to collapse immediately across two independent layers:

1. Client-Side Rejection: The authenticator checks its internal storage for a credential linked to login.microsoft.attacker-proxy.com. Because the passkey was registered to login.microsoft.com, no matching key exists and the authenticator refuses to prompt or sign.
2. Server-Side Verification: Even if an assertion were generated, the authenticator signs the exact ClientDataHash. When relayed to Microsoft Entra ID, Entra detects that the signed origin covers attacker-proxy.com rather than login.microsoft.com and terminates the session immediately.

[!NOTE] Phishing Immunity Principle: Origin binding does not rely on human vigilance. A user cannot be tricked into submitting a passkey to a spoofed domain because the web browser and cryptographic hardware enforce the domain boundary at the protocol level.

---

2. Credential Typology: Device-Bound vs. Synced Passkeys

In technical discourse, the term “passkey” encompasses two distinct architectural implementations. Systems engineers and IT auditors must understand their differences in hardware confinement, compliance assurance, and disaster recovery:

graph TD
    PK["Passkey Implementation Paradigms"]
    
    PK --> DB["Device-Bound Passkeys (Hardware-Bound)"]
    PK --> SY["Synced Passkeys (Multi-Device Credentials)"]
    
    DB --> DB1["Dedicated Silicon: YubiKey / TPM 2.0 / Apple SE"]
    DB --> DB2["Private Key Flagged Non-Exportable"]
    DB --> DB3["NIST SP 800-63B Level: AAL3"]
    DB --> DB4["Recovery: Pre-enrolled Backup Key / Admin TAP"]
    
    SY --> SY1["E2EE Cloud Sync Fabric: iCloud / Google / 1Password"]
    SY --> SY2["Private Key Replicated Across User Devices"]
    SY --> SY3["NIST SP 800-63B Level: AAL2"]
    SY --> SY4["Recovery: Account Cloud Recovery Pathway"]

2.1 Architectural Comparison Matrix

Architectural Dimension	Device-Bound Passkeys (Hardware-Bound)	Synced Passkeys (Multi-Device Credentials)
Storage Substrate	Tamper-resistant physical hardware: External FIDO2 Key (YubiKey 5) or local TPM 2.0.	End-to-End Encrypted cloud fabric (Apple iCloud Keychain, Google Password Manager, Bitwarden).
Private Key Exportability	Strictly Non-Exportable. The raw private key bits can never leave the silicon.	Exportable across sync fabric. Replicated across all authenticated ecosystem endpoints.
NIST SP 800-63B Assurance	AAL3 (Authenticator Assurance Level 3). High-assurance hardware proof.	AAL2 (Authenticator Assurance Level 2). Phishing-resistant, but lacks hardware isolation proof.
Disaster Recovery Pathway	Physical replacement. User must pre-enroll a secondary key or receive an admin-issued Temporary Access Pass.	Automatic. Setting up a new phone or workstation and signing into the ecosystem restores all keys.
Primary Threat Vector	Physical token loss or physical theft of hardware.	Compromise of personal ecosystem account (Apple ID / Google account master credential).
Hardware Procurement Cost	$50 – $90 per seat (multiplied by 2 for primary + backup key).	$0 (leverages existing smartphones, laptops, and password managers).
Recommended Enterprise Tier	Tier-0 / Tier-1 Admins, C-Suite, Finance, Defense/FIPS Compliance.	General Workforce, Contractors, High-Volume Low-Privilege Tiers.

---

2.2 The Enterprise Authenticator App Paradox

A frequent technical question during enterprise zero-trust audits:

“If an employee creates a passkey inside the Microsoft Authenticator app on their mobile phone, is that credential Device-Bound or Synced?”

In Microsoft Entra ID (Work and School accounts), passkeys in Microsoft Authenticator are strictly DEVICE-BOUND.

Here is the underlying operating system and application architecture:

[ Microsoft Authenticator Enrollment (Entra ID) ]
                        │
                        ▼
       [ iOS Secure Enclave / Android StrongBox ]
                        │
                        ▼
      [ Private Key Marked Hardware-Bound ]
                        │
     ┌──────────────────┴──────────────────┐
     ▼                                     ▼
[ Standard App Cloud Backup ]      [ Passkey Private Key ]
• 6-digit TOTP seeds               • EXPLICITLY EXCLUDED
• Account metadata labels          • Silently dropped from backup
• Synced to iCloud/Google Drive    • Stays locked in physical silicon

When an employee enrolls a passkey in Microsoft Authenticator:

1. Microsoft Authenticator invokes the mobile OS hardware isolation module (the Apple Secure Enclave on iOS or KeyStore / StrongBox Keymaster on Android).
2. The key pair is minted with hardware non-exportability attributes.
3. If the employee enables Cloud Backup within Microsoft Authenticator—which backs up standard 6-digit TOTP software tokens to personal iCloud or Google Drive storage—Microsoft’s implementation explicitly excludes the passkey private key from that archive.
4. If the employee purchases a new phone and restores their device from a cloud backup, the account tiles appear, but the passkey is missing. The user must register a new passkey on the new hardware.

Contrast this with consumer password managers (1Password, Bitwarden, Dashlane): these applications store passkey private keys within their encrypted software vault databases, which synchronize across all client devices. While secure and phishing-resistant, they represent multi-device credentials rather than hardware-bound credentials.

---

3. AAGUID Architecture & Enterprise Hardware Attestation

How does an identity directory verify whether an incoming passkey registration originated from a validated enterprise-grade YubiKey 5 FIPS hardware key versus an unmanaged personal phone or a $5 uncertified USB token?

The answer is the AAGUID (Authenticator Attestation Globally Unique Identifier).

An AAGUID is a 16-byte (128-bit) identifier embedded inside the authenticator data (authData) structure during WebAuthn registration. It identifies the precise vendor, model, and hardware revision of the authenticator.

Example AAGUID (YubiKey 5 NFC):
2fc0579f-8113-47ea-b116-e82a8db84b5c
├── 2fc0579f (4 bytes: Vendor / Family)
├── 8113-47ea (4 bytes: Model Specification)
└── b116-e82a8db84b5c (8 bytes: Submodel & Interface)

3.1 Hardware Attestation vs. Privacy Masking

During the WebAuthn registration ceremony, authenticators handle AAGUIDs and attestation in two distinct ways:

• Hardware Attestation (Device-Bound Security Keys): Dedicated security key manufacturers burn model-specific AAGUIDs into firmware. Along with the AAGUID, the token sends an Attestation Statement containing an X.509 certificate chain rooted in the vendor’s certified Certificate Authority (e.g., Yubico Root CA). The relying party cryptographically verifies this certificate chain to ensure the token has not been tampered with and satisfies FIPS 140-2/3 validation.
• Privacy Masking (Synced Passkeys & Platform Authenticators): To prevent ad networks and third-party websites from fingerprinting users across the web based on their unique hardware revisions, platform authenticators (Apple, Google) frequently return an All-Zero AAGUID:

  00000000-0000-0000-0000-000000000000

  Synced passkeys utilize self-attestation (or surrogate attestation), providing no cryptographic proof of physical hardware custody.

3.2 Production AAGUID Reference Table

The following AAGUIDs are commonly leveraged when configuring Key Restriction Policies in Microsoft Entra ID or Okta:

Authenticator Model	Form Factor	AAGUID (UUID String)	Attestation Level
YubiKey 5 NFC	USB-A / NFC	2fc0579f-8113-47ea-b116-e82a8db84b5c	Enterprise X.509 Attestation
YubiKey 5 Series FIPS	USB / NFC (FIPS 140-2)	c06283ff-7888-4444-937b-9e497551bf30	FIPS Cryptographic Attestation
YubiKey 5C NFC	USB-C / NFC	f599988b-07b9-470a-b333-e18e80556272	Enterprise X.509 Attestation
YubiKey 5Ci	Lightning / USB-C	6d44ba9b-f6ec-2e49-b930-0c60aeeb7e20	Enterprise X.509 Attestation
Microsoft Authenticator	Android Device-Bound	de1e552c-dd1d-4431-a8c9-2d1b576f3001	Platform App Attestation
Microsoft Authenticator	iOS Device-Bound	90a3ccf8-1e70-4284-a15d-0541170d5767	Platform App Attestation
Google Titan Key	USB-C / NFC	0417937e-6156-43dd-b88a-a63e9f3b5840	FIDO Alliance Certified
Generic Synced Passkey	iCloud / Chrome Sync	00000000-0000-0000-0000-000000000000	Anonymized / Self-Attestation

---

4. The Dangerous Conditional Access Fallback Trap

An operational misconception is widespread among IT teams:

“Once an employee enrolls a passkey on their account, that account is automatically passwordless and safe from password spray attacks.”

This assumption is dangerously false.

4.1 The “Other Ways to Sign In” Escape Hatch

Consider an executive whose account has an enrolled passkey. When that user enters their User Principal Name (UPN) at login.microsoft.com, Entra ID inspects the registered methods and displays:

┌───────────────────────────────────────────────┐
│              Microsoft Entra ID               │
│                                               │
│  Sign in with Windows Hello or a security key │
│                                               │
│  [ Sign In ]                                  │
│                                               │
│  Other ways to sign in                        │
│  └── Use your password instead                │
└───────────────────────────────────────────────┘

If an attacker launches a credential-stuffing campaign using passwords harvested from a third-party breach:

1. The attacker clicks “Use your password instead”.
2. The attacker submits the stolen password.
3. Microsoft Entra ID validates the password hash against the directory.
4. Entra ID passes the authentication request to the Conditional Access policy engine.

If the tenant’s Conditional Access policy only enforces standard MFA (Require multifactor authentication grant control), or if the account is excluded from MFA policies during testing, the attacker successfully authenticates without ever encountering a passkey challenge!

Registering a passkey does not delete the user’s password or disable legacy authentication pathways.

flowchart TD
    Start["User / Attacker Enters UPN"] --> Prompt{"IdP Authentication Prompt"}
    
    Prompt -- "Clicks Passkey Prompt" --> PK["WebAuthn Challenge-Response"]
    PK --> AuthSuccess["Cryptographically Verified"]
    
    Prompt -- "Clicks 'Use password instead'" --> PW["Enters Stolen Password"]
    PW --> EvalCA{"Conditional Access Policy Evaluation"}
    
    EvalCA -- "Grant: Require MFA (Legacy)" --> LegacyMFA["Sends Push / SMS Prompt"]
    LegacyMFA -- "Attacker Proxies or Bypasses" --> Breach["Unauthorized Account Takeover"]
    
    EvalCA -- "Grant: Require Phishing-Resistant MFA" --> Block["Intercepted & Blocked: Password Rejected"]

4.2 Remediation: Enforcing Phishing-Resistant Authentication Strengths

To eliminate this vulnerability, security teams must transition from generic MFA grant controls to Authentication Strengths within Conditional Access.

Authentication Strengths allow administrators to specify precisely which authentication methods satisfy the access grant:

Entra ID Admin Center > Protection > Conditional Access > Policies > [Policy Name]
└── Access Controls > Grant
    └── Select: "Require authentication strength"
        └── Choose: "Phishing-resistant MFA"

The built-in Phishing-resistant MFA policy exclusively permits:

• Windows Hello for Business (TPM-backed)
• FIDO2 Security Keys & Device-Bound Passkeys
• Certificate-Based Authentication (CBA) (configured for hardware issuance)

When an attacker enters a stolen password and clicks submit, the Conditional Access engine evaluates the request and intercepts the transaction:

Status: Failure
Error Code: 53003
Failure Reason: Access has been blocked by Conditional Access policies. 
The authentication method used does not satisfy the required authentication strength: Phishing-resistant MFA.

The authentication session terminates before any access or refresh tokens are issued.

---

5. Advanced Passkey Engineering

Deploying passkeys across diverse enterprise environments requires mastering three advanced technical mechanics:

5.1 The WebAuthn PRF (Pseudo-Random Function) Extension

Historically, asymmetric keys generated via WebAuthn could only sign challenge nonces—they could not encrypt or decrypt client files.

The WebAuthn PRF Extension (hkdf-expand) bridges this architectural divide. It allows the authenticator to derive a deterministic 32-byte symmetric encryption key directly from its private key and a salt input:

[ Authenticator Private Key ] + [ App Salt Nonce ] 
                       │
                       ▼ (HMAC-SHA-256 / HKDF-Expand)
         [ 256-bit Symmetric Vault Key ]
                       │
                       ▼
    [ Decrypts Local Zero-Knowledge Vault ]

This extension allows zero-knowledge password vaults (such as 1Password and Bitwarden) to eliminate the traditional “Master Password.” A user unlocks and decrypts their entire local encrypted vault using their passkey hardware without transmitting raw secrets.

5.2 User Presence (UP) vs. User Verification (UV)

The CTAP2 specification differentiates between two distinct validation flags:

• User Presence (UP): Merely confirms that a physical human touched the authenticator’s capacitive sensor (e.g., tapping a YubiKey gold contact). It verifies presence, not identity.
• User Verification (UV): Confirms that the authorized human is unlocking the token via a local biometric scan (fingerprint, Face ID) or device PIN.

[!IMPORTANT] Enterprise Policy Rule: Enterprise relying parties must always configure userVerification: "required". Setting user verification to “discouraged” or “preferred” allows an attacker who physically steals a hardware token to authenticate without knowing the user’s PIN!

5.3 Cross-Device Authentication (CDA) & Hybrid Transport

When an employee sitting at a desktop workstation uses their mobile phone’s passkey to log in, WebAuthn utilizes Hybrid Transport (Cross-Device Authentication):

1. The desktop browser displays a dynamic QR code containing an ephemeral public key and a WebSocket relay URL.
2. The employee scans the QR code using their smartphone camera.
3. The phone and desktop establish an end-to-end encrypted WebSocket tunnel through a cloud relay service.
4. The Critical Security Check: Concurrently, the phone and desktop negotiate an out-of-band Bluetooth Low Energy (BLE) handshake.

[ Workstation Browser ] ───(Encrypted WebSocket Tunnel)───▶ [ Mobile Authenticator ]
           │                                                        │
           └──────────────(Bluetooth BLE Proximity)─────────────────┘
                      Must be within physical ~10m range

The BLE handshake does not transfer credentials; it acts as a physical proximity validator. If a remote attacker on a Zoom call or phishing website displays a passkey QR code to a victim, the victim scanning the QR code cannot complete authentication because the victim’s phone is not in physical Bluetooth radio range of the attacker’s computer.

---

6. The 6-Phase MSP & Enterprise Fleet Rollout Blueprint

Deploying passkeys across a distributed enterprise or multi-tenant MSP client base requires structured, phase-based execution:

graph LR
    P1["Phase 1: Compatibility Audit"] --> P2["Phase 2: Tiering Architecture"]
    P2 --> P3["Phase 3: Tenant Policy Setup"]
    P3 --> P4["Phase 4: Pilot Cohort"]
    P4 --> P5["Phase 5: Workforce Dual-Key"]
    P5 --> P6["Phase 6: Enforcement & Deprecate"]

Phase 1: Fleet Compatibility & Legacy Application Audit

• Operating System Baseline: Windows 10 20H2+ / Windows 11; macOS Ventura 13.0+; iOS 16+; Android 13+.
• Browser Standard: Microsoft Edge, Google Chrome, Safari, or Mozilla Firefox with native WebAuthn support.
• Legacy Application Audit: Identify applications relying on legacy protocols (POP3, IMAP, legacy PowerShell, NTLM/Kerberos desktop client-server apps). Publish legacy web applications through Microsoft Entra Application Proxy or modern SAML/OIDC gateways to inherit passkey protection.

Phase 2: Architectural Tiering

• Tier-0 Administrators & Executive Suite: Mandate physical YubiKey 5 Series tokens with enterprise AAGUID whitelisting + Windows Hello for Business on managed devices. Prohibit synced personal passkeys.
• General Workforce: Standardize on Windows Hello for Business (primary workstation) and Microsoft Authenticator Passkeys (mobile companion).

Phase 3: Tenant Policy Configuration & Temporary Access Pass (TAP) Engine

• Enable FIDO2 Security Keys in Entra ID authentication methods.
• Configure the Temporary Access Pass (TAP) policy.
• The Day-0 Bootstrap Solution: When onboarding a remote employee, never email a temporary password. Issue a one-time TAP (valid for 2–4 hours) via verified video call or SMS to an attested manager number. The user uses the TAP to register their primary hardware passkeys without ever creating or receiving a password.

Phase 4: Pilot Cohort & Conditional Access Report-Only Mode

• Deploy passkeys across IT engineers, Security Operations, and executive sponsors.
• Create a Conditional Access policy requiring Phishing-Resistant MFA and configure state to Report-Only.
• Monitor Entra ID sign-in logs for 14 days to identify non-compliant applications or unexpected authentication failures.

Phase 5: Workforce Dual-Key Registration

• Enforce a strict dual-authenticator mandate: every user must register at least two distinct authenticators (e.g., Primary Workstation Windows Hello + Secondary Mobile Microsoft Authenticator or backup hardware key).
• This eliminates 95% of helpdesk lockout tickets caused by damaged or lost devices.

Phase 6: Enforcement, Telephony Deprecation & Break-Glass Safeguards

• Switch the Conditional Access Phishing-Resistant policy from Report-Only to On (Enforced).
• Deprecate SMS and voice telephony authentication methods across the tenant.
• Break-Glass Safety Mandate: Maintain two emergency cloud-only Global Administrator accounts. Secure each account with a dedicated hardware FIDO2 key stored in a physical fireproof safe. These accounts must be explicitly excluded from standard Conditional Access policies to prevent accidental tenant lockouts during directory outages.

---

7. Production Runbook: Microsoft Graph PowerShell Automation

Below are production-ready PowerShell scripts for auditing, configuring, and provisioning passkey infrastructure via the Microsoft Graph PowerShell SDK.

7.1 Auditing User Registered Authentication Methods

Run this script to inspect passkey and FIDO2 adoption across all tenant users:

<#
.SYNOPSIS
    Audits registered authentication methods across all Entra ID users.
.DESCRIPTION
    Identifies which accounts possess FIDO2/Passkey credentials versus
    those still reliant on legacy SMS, Voice, or Password methods.
#>

[CmdletBinding()]
param (
    [Parameter(Mandatory = $false)]
    [string]$ExportPath = ".\Passkey_Adoption_Audit.csv"
)

# Verify required Graph modules
$requiredModules = @("Microsoft.Graph.Identity.SignIns", "Microsoft.Graph.Users")
foreach ($module in $requiredModules) {
    if (-not (Get-Module -ListAvailable -Name $module)) {
        Write-Error "Required module '$module' is missing. Install via: Install-Module $module -Scope CurrentUser"
        return
    }
}

# Connect with least-privilege audit scopes
Connect-MgGraph -Scopes "User.Read.All", "UserAuthenticationMethod.Read.All" -NoWelcome

Write-Host "[*] Querying Entra ID user directory..." -ForegroundColor Cyan
$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, AccountEnabled | 
    Where-Object { $_.AccountEnabled -eq $true }

$results = [System.Collections.Generic.List[PSCustomObject]]::new()

foreach ($user in $users) {
    Write-Verbose "Processing: $($user.UserPrincipalName)"
    
    # Query registered authentication methods
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id -ErrorAction SilentlyContinue
    
    $hasFIDO2 = $false
    $hasWindowsHello = $false
    $hasApp = $false
    $hasSMS = $false

    foreach ($method in $methods) {
        switch ($method.AdditionalProperties['@odata.type']) {
            '#microsoft.graph.fido2AuthenticationMethod' { $hasFIDO2 = $true }
            '#microsoft.graph.windowsHelloForBusinessAuthenticationMethod' { $hasWindowsHello = $true }
            '#microsoft.graph.microsoftAuthenticatorAuthenticationMethod' { $hasApp = $true }
            '#microsoft.graph.phoneAuthenticationMethod' { $hasSMS = $true }
        }
    }

    $isPhishingResistant = ($hasFIDO2 -or $hasWindowsHello)

    $results.Add([PSCustomObject]@{
        DisplayName          = $user.DisplayName
        UserPrincipalName    = $user.UserPrincipalName
        IsPhishingResistant  = $isPhishingResistant
        HasFIDO2Passkey      = $hasFIDO2
        HasWindowsHello      = $hasWindowsHello
        HasAuthenticatorApp  = $hasApp
        HasLegacyPhoneOrSMS  = $hasSMS
    })
}

$results | Export-Csv -Path $ExportPath -NoTypeInformation -Encoding utf8
Write-Host "[+] Audit complete. Report exported to: $ExportPath" -ForegroundColor Green

# Output executive summary metrics
$total = $results.Count
$phishResistantCount = ($results | Where-Object { $_.IsPhishingResistant -eq $true }).Count
$pct = [math]::Round(($phishResistantCount / $total) * 100, 2)

Write-Host "==========================================" -ForegroundColor Yellow
Write-Host "  PASSKEY & PHISHING RESISTANCE METRICS   " -ForegroundColor Yellow
Write-Host "==========================================" -ForegroundColor Yellow
Write-Host "Total Active Users:           $total"
Write-Host "Phishing-Resistant Ready:     $phishResistantCount ($pct%)"
Write-Host "Legacy SMS/Phone Reliant:     $(($results | Where-Object { $_.HasLegacyPhoneOrSMS -eq $true }).Count)"
Write-Host "==========================================" -ForegroundColor Yellow

---

7.2 Configuring FIDO2 Policy with AAGUID Whitelisting

This script activates FIDO2 authentication methods in Microsoft Entra ID and enforces an AAGUID whitelist to restrict registration to enterprise-certified YubiKey hardware:

<#
.SYNOPSIS
    Configures Entra ID FIDO2 Authentication Method Policy with AAGUID Whitelisting.
.DESCRIPTION
    Enforces Key Restriction Policies to block unapproved consumer tokens.
#>

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod" -NoWelcome

Write-Host "[*] Configuring FIDO2 Policy and Key Restrictions..." -ForegroundColor Cyan

# Define approved enterprise hardware AAGUIDs
$approvedAAGUIDs = @(
    "2fc0579f-8113-47ea-b116-e82a8db84b5c", # YubiKey 5 NFC
    "c06283ff-7888-4444-937b-9e497551bf30", # YubiKey 5 Series FIPS
    "f599988b-07b9-470a-b333-e18e80556272", # YubiKey 5C NFC
    "6d44ba9b-f6ec-2e49-b930-0c60aeeb7e20"  # YubiKey 5Ci
)

$policyParams = @{
    state = "enabled"
    isSelfServiceRegistrationAllowed = $true
    isAttestationEnforced = $true
    keyRestrictions = @{
        isEnforced = $true
        enforcementType = "allow"
        aaGuids = $approvedAAGUIDs
    }
}

Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "FIDO2" `
    -BodyParameter $policyParams

Write-Host "[+] FIDO2 policy successfully updated with AAGUID whitelist and attestation enforcement." -ForegroundColor Green

---

7.3 Issuing a Temporary Access Pass (TAP) for Zero-Password Onboarding

Use this script to issue a short-lived Temporary Access Pass to allow an employee to register their passkeys without creating a password:

<#
.SYNOPSIS
    Generates a secure, short-lived Temporary Access Pass (TAP) for onboarding.
#>

[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [string]$UserPrincipalName,
    
    [Parameter(Mandatory = $false)]
    [int]$LifetimeInMinutes = 120
)

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" -NoWelcome

$user = Get-MgUser -UserId $UserPrincipalName
if (-not $user) {
    Write-Error "User $UserPrincipalName not found in directory."
    return
}

$tapParams = @{
    lifetimeInMinutes = $LifetimeInMinutes
    isUsableOnce = $true
}

Write-Host "[*] Generating Temporary Access Pass for: $UserPrincipalName" -ForegroundColor Cyan
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $user.Id -BodyParameter $tapParams

Write-Host "==========================================================" -ForegroundColor Green
Write-Host "           TEMPORARY ACCESS PASS ISSUED                   " -ForegroundColor Green
Write-Host "==========================================================" -ForegroundColor Green
Write-Host "Target User:      $UserPrincipalName"
Write-Host "Passcode:         $($tap.TemporaryAccessPass)" -ForegroundColor Yellow
Write-Host "Lifetime:         $($tap.LifetimeInMinutes) minutes"
Write-Host "Single Use:       $($tap.IsUsableOnce)"
Write-Host "Expiration Time:  $($tap.StartDateTime.AddMinutes($tap.LifetimeInMinutes)) UTC"
Write-Host "==========================================================" -ForegroundColor Green
Write-Host "[!] Securely transmit this code via verified voice/video channel." -ForegroundColor Red

---

8. Enterprise Hardening Verification Checklist

Before certifying an enterprise environment as Phishing-Resistant Passwordless, security auditors must verify each of the following controls:

• W3C WebAuthn & CTAP2 Support: Client workstations run Windows 10 20H2+ / macOS Ventura 13.0+ with modern browser standards.
• FIDO2 Authentication Method Active: FIDO2 method enabled in Microsoft Entra ID with isAttestationEnforced = $true.
• AAGUID Whitelisting Enforced: Key restriction policies restrict passkey registration to verified corporate hardware UUIDs.
• Conditional Access Phishing-Resistant MFA Enforced: Grant controls updated from legacy MFA to Require authentication strength: Phishing-resistant MFA.
• “Other Ways to Sign In” Trap Closed: Verified that password-only or password+push logins are rejected by Conditional Access.
• Temporary Access Pass (TAP) Engine Deployed: Day-0 onboarding utilizes one-time TAPs; no temporary passwords sent over plaintext channels.
• Dual-Key Policy Mandated: All workforce accounts have enrolled a primary authenticator and a verified backup authenticator.
• Break-Glass Emergency Accounts Secured: Dedicated hardware FIDO2 keys locked in a physical safe, excluded from cloud sync and standard Conditional Access policies.
• Legacy Telephony Deprecated: SMS and Voice MFA methods disabled across all user cohorts.