Rolling Out FIDO2 Passwordless Authentication in Entra ID: Security Keys, Passkeys, and Windows Hello for Business

Your tenant has 100% MFA coverage and you are still getting phished. Adversary-in-the-middle (AiTM) kits proxy the real Entra sign-in page, relay the password and the OTP or push approval in real time, and walk away with the session cookie. Every MFA method where the user tells the system a secret — a code, an approval, a number match — can be relayed. The only methods that cannot are the ones where the protocol itself verifies the site: FIDO2/WebAuthn credentials (security keys and passkeys), Windows Hello for Business (WHfB), and multifactor certificate-based authentication.

This article is the rollout program: taking a hybrid Entra ID estate from “passwords plus MFA” to “phishing-resistant credential as the primary sign-in, passwords demoted to a measured, shrinking fallback.” That means the whole machine: the authentication methods policy and passkey profiles with AAGUID restrictions, WHfB trust-model selection and Intune deployment, Temporary Access Pass (TAP) bootstrapping, the Entra Kerberos object that opens file shares without a password, wave-by-wave enforcement via Conditional Access authentication strengths, and the reporting that gates every wave. The security-side design — threat model, attestation tiers, break-glass architecture — lives in the companion Rolling Out Phishing-Resistant Passwordless Auth: FIDO2, Passkeys, and Break-Glass Design; this is the identity team’s execution manual.

Scope is a hybrid estate — Entra ID plus on-prem AD synced by Entra Connect — because that is where passwordless programs stall (the file-share question kills more rollouts than user resistance). Cloud-only tenants simply skip the Kerberos-object sections. By the end you can run this as a 90-day program with personas, waves, exit criteria, and the exact Graph, PowerShell, Intune, and Terraform configuration for each step.

What problem this solves

Three production pains converge here. First, credential phishing survives OTP-era MFA: an AiTM proxy captures the session token after the user “successfully” completes MFA, so your logs show a compliant session — from the attacker’s infrastructure. Second, passwords are your most expensive credential: reset tickets routinely run 20–40% of service-desk volume. Third, partial rollouts create false progress: registering passkeys without enforcement produces shelfware, while enforcing without measured registration produces a lockout event with your CISO’s name on it.

The credential you deploy determines which attacks simply stop working:

Who hits this: every Microsoft 365 enterprise, most acutely those with hybrid AD (on-prem SSO fear), frontline populations (shared devices, no corporate phone), heavy admin tiers, and cyber-insurance or regulatory language that now says “phishing-resistant MFA” explicitly. This program turns that compliance sentence into enforced configuration.

Learning objectives

By the end of this article you can:

• Compare the three passwordless method families — WHfB, FIDO2 security keys, Authenticator passkeys (device-bound and synced) — and assign each to the right persona.
• Choose the correct WHfB trust model, deploy it via Intune Settings Catalog or the PassportForWork CSP, and verify provisioning with dsregcmd and event logs.
• Configure the Passkey (FIDO2) policy with profiles, attestation enforcement, and AAGUID allow-lists — and explain why tightening an allow-list is a revocation event.
• Run TAP-based onboarding at service-desk scale: policy tuning, Graph issuance, and the exact scenarios TAP does and does not satisfy.
• Stand up cloud Kerberos trust so WHfB and FIDO2 users reach on-prem file shares and Kerberos apps without a password.
• Sequence a wave-based rollout — pilot personas, registration campaign, report-only, block — with measurable exit criteria per wave.
• Enforce phishing-resistant MFA with built-in and custom (AAGUID-scoped) authentication strengths without locking out unregistered users.
• Demote passwords deliberately — system-preferred MFA, Windows passwordless experience, never-expiring scrambled passwords — and prove usage is trending to zero.

Prerequisites & where this fits

You should be fluent in Conditional Access design (assignments, grants, report-only), know what Entra Connect syncs, and be comfortable with Microsoft Graph PowerShell; Intune familiarity helps for WHfB. This article assumes the sync design from Microsoft Entra Connect Sync Deep Dive: Designing Hybrid Identity with PHS, PTA, and Seamless SSO and the policy framework from Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters, and it feeds the privileged-access designs in Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale.

What you need in place before wave 0:

Break-glass design is its own discipline, covered in Engineering Break-Glass Emergency Access Accounts in Entra ID: Exclusions, Hardening, and Tamper-Evident Monitoring — do not start wave 1 without it.

Core concepts

Origin binding is the whole trick. A FIDO2/WebAuthn credential is an asymmetric key pair scoped to a relying party ID (RP ID) — for Entra ID, login.microsoft.com. Registration (the attestation ceremony) mints a key pair for that RP ID and proves the authenticator’s make/model; sign-in (the assertion ceremony) signs a challenge only if the origin the browser is actually talking to matches that RP ID. An AiTM proxy on login-micros0ft.evil.example fails the origin check before any secret exists to steal — and the user is never asked to override it.

One gesture is already MFA. A passkey combines possession (the authenticator) with user verification — a PIN or biometric checked locally. Entra treats a user-verified WebAuthn assertion as full MFA in one step: two stronger factors with less ceremony, not one factor instead of two.

Device-bound vs synced changes your assurance, not your phishing resistance. A device-bound passkey (security key, Authenticator passkey, WHfB) never leaves its hardware. A synced passkey (iCloud Keychain, Google Password Manager) is replicated through the provider’s cloud — still origin-bound, but you no longer know how many copies exist, and sync providers present no attestation. Treat synced passkeys as convenience-tier and keep privileged roles on attested, device-bound hardware.

Discoverable credentials enable usernameless sign-in — and consume key slots. Entra sign-in uses discoverable credentials (resident keys) stored on the authenticator, letting a user tap “Sign in with a passkey” without typing a UPN. Slots are finite — YubiKey firmware 5.2/5.4 holds 25, firmware 5.7 holds 100 — so check your vendor’s number before assuming one key covers everything.

Passwordless is NOT password-free. Enabling passkeys deletes nobody’s password — it still exists in Entra and AD, still syncs, still works anywhere you have not blocked it. A real program has two halves: make the strong credential primary, then actively shrink the password’s usable surface while measuring residual password usage down to zero. This article does both.

Three policy layers, three questions. The authentication methods policy: what can this user register and use? Conditional Access authentication strengths: what must they present for this access? Intune/GPO: what does the device provision? Rollouts fail when teams treat these as one switch.

The ladder your program climbs — where each Entra method sits:

Note the trap in row six: Authenticator phone sign-in (approve + number match, no password) is passwordless but not phishing-resistant — an AiTM page can still drive it. Authenticator passkeys, a different credential in the same app, are. Comms and CA strengths must distinguish the two; Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks covers the client side.

The passwordless method landscape: pick per persona

Get the taxonomy right first: the options have materially different security postures, costs, and operational models — and you will deploy at least three.

Two program-level calls fall straight out of this table. WHfB is your volume play, keys are your assurance play: WHfB covers the ~90% case (a user at their managed Windows PC) at zero marginal cost; keys cover what WHfB cannot — roaming admins, shared workstations, disabled TPMs. And synced passkeys are unattested: you get zero provenance guarantees, so keep them off privileged accounts entirely.

The persona map the program executes against:

B2B guests are the exception: guests cannot register passkeys in your resource tenant. They bring home-tenant credentials — configure cross-tenant access settings to trust home-tenant MFA and push the requirement upstream.

Platform coverage determines the edges of the map:

Cross-device authentication (the QR-code flow) requires Bluetooth proximity plus internet on both devices — the BLE check is an anti-phishing proximity proof and cannot be disabled or proxied. Fleets that block BLE have effectively blocked phone-passkey sign-in; issue keys there instead.

Windows Hello for Business: trust models, TPM, and gestures

WHfB replaces the device password with a per-user, per-device asymmetric key pair, unlocked by a local gesture and (ideally) sealed in the TPM. At first sign-in on a capable device, provisioning runs: MFA is verified, a key pair is generated, the public key registers to the user object, and the user sets a PIN and optional biometrics. Keys live in the WHfB container — one per user per device, which is why WHfB fits one-user-one-PC populations and kiosks badly.

Trust models: cloud Kerberos trust vs key trust vs certificate trust

Entra sign-in works identically in all three models; the trust model only decides how the device gets Kerberos tickets for on-prem AD resources.

The decision compresses to this:

That last row is a production foot-gun: if Use certificate for on-premises authentication is enabled anywhere in scope, it overrides cloud Kerberos trust with no error surfaced. Leave it not configured unless you deliberately run certificate trust.

TPM, PIN, and biometrics: why the gesture is not a password

The WHfB private key should be generated inside the TPM 2.0 chip — non-exportable, protected by hardware anti-hammering (progressive lockout on wrong-PIN attempts). Without a TPM, Windows falls back to software-protected keys, which is why Require security device = true belongs in your baseline and no-TPM machines route to security keys in the persona map.

A 6-digit PIN protected by TPM anti-hammering is materially stronger than a 14-character password typed into whatever webpage asks — the single most effective line in your user comms. Force enhanced anti-spoofing (IR liveness) for face-unlock fleets; multi-factor device unlock can require PIN plus biometric or phone proximity for high-assurance desks; dynamic lock locks the PC when the paired phone’s Bluetooth walks away.

Enable non-destructive PIN reset (the Microsoft PIN Reset Service): consent to the PIN Reset Service and Client applications in your tenant, then set Enable PIN recovery = true. Without it, PIN reset is destructive — the container is discarded and the user re-provisions from scratch.

PIN policy reference (PassportForWork CSP, ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/...):

Do not port password thinking into PIN policy: forced expiry and alphanumeric complexity add friction with negligible gain against a TPM-throttled local secret — and PIN friction is the top driver of WHfB grumbling.

Deploying via Intune

Two Intune surfaces configure WHfB and they interact: the tenant-wide enrollment page (Devices → Windows → Windows Hello for Business) applies at enrollment time to every enrolling device, while Settings Catalog / Account protection profiles apply to groups on your schedule. The clean pattern: set the enrollment page to Disabled and drive everything through a Settings Catalog profile assigned to device rings.

Prefer raw OMA-URI? The PassportForWork CSP paths are verbatim ({TenantId} is your directory GUID):

./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork         bool  True
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth bool  True
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice      bool  True
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/MinimumPINLength           int   6
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/EnablePinRecovery          bool  True

If any GPO also configures WHfB (Computer Configuration → Administrative Templates → Windows Components → Windows Hello for Business), GPO wins and the Intune policy is silently ignored on hybrid-joined devices. Pick exactly one channel per device population and audit for strays before the pilot. For fleets provisioned through Autopilot, WHfB enrollment lands during OOBE — sequence the enrollment-page setting with your Autopilot profile design, as covered in Zero-Touch Windows Provisioning with Intune and Windows Autopilot.

Verifying provisioning

Every WHfB pilot needs a per-device verification script. The checkpoints, in the order they fail:

C:\> dsregcmd /status
+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
             AzureAdJoined : YES
              DomainJoined : YES
                DeviceName : IN-LT-04821
+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
                AzureAdPrt : YES
                 OnPremTgt : YES     <- cloud Kerberos trust is working
                  CloudTgt : YES

OnPremTgt : NO with everything else green is the classic signature of a missing or unhealthy Entra Kerberos object — see the on-prem verification cmdlet.

FIDO2 security keys and passkeys: policy, AAGUIDs, provisioning

The Passkey (FIDO2) authentication method governs security keys and passkeys in Authenticator (and synced passkeys where allowed). Since the March 2026 GA, the method uses passkey profiles: named, group-scoped rule sets for attestation, passkey type, and AAGUID restrictions. Existing settings migrate into a Default passkey profile on opt-in, and the opt-in is one-way. Hard limits: a 20 KB policy ceiling and at most three profiles including Default — budget AAGUID lists accordingly.

The policy settings that matter

Three rows cause production incidents, so read them twice. Key restrictions apply to authentication, not just registration: remove an AAGUID users already registered and they can no longer sign in with that key — sequence allow-list changes like the revocation events they are. Excluded beats included: one exclusion membership silently kills FIDO2 for a user regardless of profiles. And any-one-profile acceptance means a permissive Frontline profile can undermine a strict Admin profile if memberships overlap — keep profile target groups disjoint.

The three-profile model that fits inside the limits:

Configure it as code with Graph (the same body works in Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -BodyParameter):

# PATCH the Passkey (FIDO2) method configuration (Graph v1.0)
PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2

{
  "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration",
  "state": "enabled",
  "isSelfServiceRegistrationAllowed": true,
  "isAttestationEnforced": true,
  "keyRestrictions": {
    "isEnforced": true,
    "enforcementType": "allow",
    "aaGuids": [
      "2fc0579f-8113-47ea-b116-bb5a8db9202a",
      "ee882879-721c-4913-9775-3dfcce97072a",
      "de1e552d-db1d-4423-a619-566b625cdc84",
      "90a3ccdf-635c-4729-a248-9b709135078f"
    ]
  },
  "includeTargets": [
    { "targetType": "group", "id": "<sg-passwordless-pilot-object-id>", "isRegistrationRequired": false }
  ]
}

There is no Terraform resource for the authentication methods policy in the azuread provider — manage this object via Graph in your pipeline (the JSON above, under version control) and reserve Terraform for the Conditional Access layer.

AAGUIDs: pinning make and model

An AAGUID is the FIDO2-mandated 128-bit identifier for an authenticator model; attestation makes it trustworthy (unenforced, it is a self-reported claim). Combined — allow-list plus attestation — they turn “only company-issued keys for Tier-0” from wiki aspiration into cryptographic policy.

Inventory what is already registered before you enforce anything:

# Enumerate registered FIDO2 credentials and group by model across the fleet
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
Get-MgUserAuthenticationFido2Method -UserId "ada@contoso.com" |
  Select-Object DisplayName, AaGuid, Model, AttestationLevel, CreatedDateTime

Windows desktop sign-in with a security key

Signing into Windows itself with a FIDO2 key — the kiosk and shared-PC scenario — is a separate switch. Enable it via Intune (Account protection → “Use security keys for sign-in”) or the CSP:

./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin   int   1

Windows 10 1903+ is required; hybrid-joined on-prem SSO rides the same Entra Kerberos object as WHfB. For frontline shared PCs, pair this with key-per-user issuance — the key is the badge.

Provisioning at scale: five paths

The Graph on-behalf flow (beta as of this writing) is the interesting one for bulk staging — request WebAuthn creation options for the user, perform the ceremony against the physical key with vendor tooling, then POST the resulting credential back:

# 1) Get WebAuthn creation options for the target user
GET https://graph.microsoft.com/beta/users/{userId}/authentication/fido2Methods/creationOptions(challengeTimeoutInMinutes=10)

# 2) Register the attested credential produced by the key ceremony
POST https://graph.microsoft.com/beta/users/{userId}/authentication/fido2Methods

Whichever path provisions it, the two-credential rule applies from day one: two independent phishing-resistant credentials per user (WHfB + key, key + Authenticator passkey, or two keys for Tier-0). One registered credential plus an enforced strength equals a helpdesk call the day the key meets the washing machine.

Temporary Access Pass: the bootstrap credential

The chicken-and-egg problem is structural: registering a strong credential requires proving identity strongly, which a new hire (or a user whose only key just died) cannot do. A Temporary Access Pass breaks the loop — a time-boxed, optionally single-use code that satisfies strong authentication so the user can enroll the real credential. TAP is a bridge, never a destination: it is a typed code, phishable during its lifetime, so keep lifetimes in minutes and onboarding passes one-time.

Enable the method scoped to an onboarding group (sg-passwordless-onboarding), then issue at the desk:

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

$body = @{
  isUsableOnce      = $true                                   # single-use bootstrap
  lifetimeInMinutes = 60                                      # within policy min/max
  startDateTime     = (Get-Date).ToUniversalTime().ToString("o")
}
New-MgUserAuthenticationTemporaryAccessPassMethod `
  -UserId "newhire@contoso.com" -BodyParameter $body |
  Select-Object TemporaryAccessPass, LifetimeInMinutes, IsUsableOnce, StartDateTime

# TemporaryAccessPass LifetimeInMinutes IsUsableOnce StartDateTime
# ------------------- ----------------- ------------ -------------
# w8k+P2vq                           60         True 2026-06-08T05:31:00Z

The user takes the code to https://aka.ms/mysecurityinfo, signs in, and registers a passkey — a TAP sign-in counts as fresh strong auth, satisfying the 5-minute MFA-freshness gate. What TAP does and does not cover:

Two operational rules keep TAP from becoming your new weakest link: audit every issuance (alert when a TAP is created for any privileged user — that is exactly what an attacker with a hijacked helpdesk session would do), and verify identity out-of-band before issuing (video + manager confirmation, in-person for Tier-0). The TAP desk is now your de facto identity-proofing function; helpdesk social engineering took down household-name companies precisely here.

On-prem resource access: cloud Kerberos trust end to end

The rollout-stalling question: “with no password, how does the user open \\files.corp.contoso.com\finance?” Answer: cloud Kerberos trust. Entra ID holds a key pair for your AD domain and mints a partial TGT at sign-in; the Windows client exchanges it at a domain controller for a full TGT, and Kerberos proceeds normally — service tickets, SMB, IIS Windows auth — with no password anywhere in the chain. One Set-AzureADKerberosServer run powers both WHfB cloud Kerberos trust and FIDO2 security-key on-prem SSO.

Create the object once per domain that contains synced users, from a box with the Entra Connect RPC DLLs:

[Net.ServicePointManager]::SecurityProtocol = `
  [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

$domain = $env:USERDNSDOMAIN
$upn    = "kerbadmin@contoso.onmicrosoft.com"    # Hybrid Identity Administrator
$domainCred = Get-Credential                     # Domain Admin / Enterprise Admin

# Creates CN=AzureADKerberos in OU=Domain Controllers and publishes it to Entra ID
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred

# Verify: KeyVersion must equal CloudKeyVersion, Id must equal CloudId
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred |
  Select-Object Id, CloudId, KeyVersion, CloudKeyVersion, DomainDnsName

# Rotate on your krbtgt cadence — ONLY with this cmdlet, so AD and Entra stay in sync
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn `
  -DomainCredential $domainCred -RotateServerKey

The object is strictly one per domain and tenant-bound: running the cmdlet for a second tenant in the same domain overwrites the first — there is no shared-domain, two-tenant configuration. And the RODC-style Password Replication Policy denies privileged built-in groups (Domain Admins et al.) from redeeming partial TGTs. That is not a bug to relax; it is the control that stops an Entra compromise from minting Tier-0 Kerberos tickets. Privileged AD work happens from privileged access workstations with separate on-prem-mastered accounts.

Edge cases to pre-map before any enforcement wave:

That last row deserves its own sentence in the program charter: do not let one POP3 app hold 28,000 users on passwords. Give every legacy carve-out the tightest compensating control you can, an owner, and a decommission date.

The rollout program: personas, waves, and the registration campaign

Passwordless fails as a big-bang and succeeds as a program. The sequencing logic is fixed: register before you enforce, enforce per cohort, gate each wave on data.

Wave 1 goes first and hardest for a reason: admins are the highest-value targets, the smallest blast radius, and walkable to a desk. Block-mode on Tier-0 in week 3 forces every operational gap — TAP flow, key logistics, break-glass drill — to surface while the audience is IT itself.

The registration campaign (Authentication methods → Registration campaign) is the wave-3 scale lever — it interrupts eligible sign-ins with a guided setup flow:

Around the mechanics, run it like a product launch: named champions per department, a two-minute registration video recorded on your tenant (the number-one user fear is “is this prompt a phish?” — a healthy instinct to encourage), a TAP desk capacity plan sized to wave-3 volume, and a standing dashboard reviewed in a weekly wave-gate meeting. The wave does not flip to block because the calendar says so; it flips because the registration report says so.

Enforcement: authentication strengths and killing the password fallback

Enabling methods requires nothing of anyone. The enforcement lever is a Conditional Access policy with the Require authentication strength grant control. Three built-in strengths exist, immutable, with well-known IDs:

Pull them rather than guessing, then bind in report-only:

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"
$pr = Get-MgPolicyAuthenticationStrengthPolicy |
  Where-Object { $_.PolicyType -eq 'builtIn' -and $_.DisplayName -eq 'Phishing-resistant MFA' }

$params = @{
  DisplayName   = "CA04 - Phishing-resistant MFA - wave 3 cohort"
  State         = "enabledForReportingButNotEnforced"        # flip to 'enabled' at wave gate
  Conditions    = @{
    Users        = @{
      IncludeGroups = @("<sg-wave3-object-id>")
      ExcludeUsers  = @("<break-glass-1-id>", "<break-glass-2-id>")
    }
    Applications = @{ IncludeApplications = @("All") }
  }
  GrantControls = @{
    Operator               = "OR"
    AuthenticationStrength = @{ Id = $pr.Id }
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

The same layer as code, where Terraform does have first-class resources:

resource "azuread_authentication_strength_policy" "pr_company_keys" {
  display_name         = "PR - phishing-resistant (company methods)"
  description          = "WHfB + FIDO2 only; CBA excluded (no smart-card estate)"
  allowed_combinations = ["windowsHelloForBusiness", "fido2"]
}

resource "azuread_conditional_access_policy" "ca02_admins_pr" {
  display_name = "CA02 - Phishing-resistant MFA - privileged roles"
  state        = "enabled"

  conditions {
    client_app_types = ["all"]
    applications { included_applications = ["All"] }
    users {
      included_roles = ["62e90394-69f5-4237-9190-012177145e10"] # Global Administrator template ID
      excluded_users = var.break_glass_object_ids
    }
  }

  grant_controls {
    operator                          = "OR"
    authentication_strength_policy_id = azuread_authentication_strength_policy.pr_company_keys.id
  }
}

Custom strengths go further: the FIDO2 combination accepts advanced configuration restricting acceptable AAGUIDs, so “phishing-resistant with a company-issued key” becomes an enforceable requirement for crown-jewel apps:

# Add an AAGUID-scoped combination configuration to a custom strength
POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/authenticationStrength/policies/{policyId}/combinationConfigurations

{
  "@odata.type": "#microsoft.graph.fido2CombinationConfiguration",
  "appliesToCombinations": ["fido2"],
  "allowedAAGUIDs": ["2fc0579f-8113-47ea-b116-bb5a8db9202a", "ee882879-721c-4913-9775-3dfcce97072a"]
}

Two rules protect you from self-inflicted outages. You cannot combine Require MFA and Require authentication strength in one policy — the MFA built-in strength is Require MFA; run separate policies per concern. And CA evaluates after primary authentication: a strength does not remove the password prompt; it refuses tokens until a qualifying method is presented. Killing the prompt is the demotion work below.

The policy set, as a family:

CA01 matters more than it looks: the security-info registration flow is exactly what an AiTM attacker uses to enroll their authenticator on a hijacked session. Locking registration to compliant devices or trusted networks (see Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement) closes the hole TAP onboarding would otherwise widen.

Killing the password fallback

“Passwordless” with a fully live password is a UX project, not a security one. The demotion levers, in deployment order:

# Never-expire at the domain level (stops forced rotation for everyone on the domain)
Update-MgDomain -DomainId "contoso.com" -PasswordValidityPeriodInDays 2147483647

# Or per user, for cohort-by-cohort demotion
Update-MgUser -UserId "ada@contoso.com" -PasswordPolicies "DisablePasswordExpiration"

The honest footnote: you cannot delete a cloud user’s password today, and hybrid users always have one in AD. “Password-free” is an asymptote — the measurable endpoint is zero password usage, enforced strengths everywhere that matters, and a scrambled secret nobody knows guarding the rest.

Reporting and registration insights: gate every wave on data

Every wave-gate decision is a query, not a vibe. Where each answer lives:

The Graph pull that produces each wave’s remediation list:

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

# Everyone in scope who is NOT yet passwordless-capable, with what they do have
Get-MgReportAuthenticationMethodUserRegistrationDetail `
  -Filter "isPasswordlessCapable eq false" -All |
  Select-Object UserPrincipalName, IsMfaRegistered, MethodsRegistered |
  Export-Csv wave3-remediation.csv -NoTypeInformation

And the two KQL views on the standing dashboard (Log Analytics, SigninLogs diagnostic setting required):

// Method mix trend — the program's single most important chart
SigninLogs
| where TimeGenerated > ago(30d) and ResultType == 0
| mv-expand ad = AuthenticationDetails
| extend method = tostring(ad.authenticationMethod)
| where isnotempty(method)
| summarize signins = count() by method, bin(TimeGenerated, 1d)
| render timechart

// Who still types passwords, and when they last did — wave-5 demotion gate
SigninLogs
| where TimeGenerated > ago(14d) and ResultType == 0
| mv-expand ad = AuthenticationDetails
| where tostring(ad.authenticationMethod) == "Password"
| summarize passwordSignins = count(), lastPasswordUse = max(TimeGenerated)
          by UserPrincipalName, AppDisplayName
| order by passwordSignins desc

The sign-in logs’ authentication details carry the method names verbatim — Windows Hello for Business, FIDO2 security key, Passkey (device-bound), Passwordless phone sign-in, Temporary Access Pass — exactly the granularity CA-strength debugging needs. Wire the audit-log “User registered security info” events into alerting for privileged accounts: a new method on a Global Admin that the TAP desk did not create is an incident, full stop.

Architecture at a glance

Picture the estate in two planes. The data plane is a single sign-in, end to end: a user at a hybrid-joined laptop touches a fingerprint reader (WHfB) or taps a security key. The gesture unlocks a private key in the TPM or key hardware; the platform performs the WebAuthn assertion against login.microsoft.com, the origin check making any proxied page cryptographically inert. Entra ID validates the assertion against the Passkey (FIDO2) policy and matching profile (AAGUID allowed, attestation on file), Conditional Access confirms the method satisfies the wave’s phishing-resistant strength, and token issuance follows: access/refresh tokens for the app, a Primary Refresh Token for device-wide SSO, and — because the tenant has an Entra Kerberos object — a partial TGT alongside. When the user opens \\files.corp\finance, Windows silently exchanges that partial TGT at the nearest domain controller for a full TGT and an SMB service ticket. The share opens. No password existed at any hop.

The control plane wraps that flow: Intune (or GPO) pushes WHfB and security-key sign-in settings to device rings; the authentication methods policy and its three passkey profiles define what each persona may register; the TAP desk and Graph automation mint bootstrap credentials; Conditional Access policies CA01–CA11 gate registration and enforce strengths per wave, break-glass excluded everywhere; and the telemetry loop — sign-in and audit logs in Log Analytics, registration details from Graph — decides when each wave flips from report-only to block. Every object is code-manageable (Graph JSON, Terraform, Settings Catalog values, PowerShell for the Kerberos object); treat the set as one versioned system, because drift in any layer surfaces as “user can’t sign in” three layers away.

Real-world scenario

A global manufacturer — ~28,000 staff, single AD forest with two child domains, Entra hybrid join, number-matching MFA fully deployed — lost three finance mailboxes in one quarter to an AiTM kit that relayed the number match in real time. The CISO’s mandate: phishing-resistant primary authentication for everyone in 90 days. Week one’s hardware audit surfaced the constraint that nearly sank it: roughly 1,400 shop-floor PCs had TPMs disabled in OEM firmware, so WHfB with RequireSecurityDevice=true could not provision there, and BIOS-touring 1,400 machines was not happening inside the window.

The platform team split by capability instead of forcing one credential: ~24,000 TPM-capable PCs got WHfB cloud Kerberos trust via Settings Catalog in four device rings; the 1,400 no-TPM machines plus all 240 Tier-0/IT-ops admins got company-issued FIDO2 keys under an allow-listed, attestation-enforced profile; ~2,300 field staff got Authenticator passkeys through the registration campaign. Wave 1 enforced block-mode on admins in week 3 — promptly catching a real gap: two RDP jump hosts refused the new credentials, and the fix (Entra-joined replacements with enablerdsaadauth:i:1 plus WebAuthn redirection) landed while the blast radius was 240 people who all knew the project lead’s number.

The make-or-break detail was the on-prem SSO gate on the no-TPM fleet: those PCs ran a Kerberos-authenticated MES web app, and a passwordless sign-in that could not reach it would have stopped the line. The team gated wave 2 on Get-AzureADKerberosServer health (KeyVersion == CloudKeyVersion in both child domains) and a scripted klist check across 40 pilot machines per site. One self-inflicted incident made the retro: in week 8, security tightened the admin profile’s AAGUID allow-list after 43 early adopters had registered an older key model — locking them out overnight, because key restrictions apply to authentication, not just registration. Recovery was TAP reissuance plus re-registration, and allow-list changes moved into change management with a registered-credential impact query as a mandatory pre-check.

Final numbers: phishing-resistant coverage 0 → 96% in 71 days, the residual 4% being three legacy apps on named exclusions with signed deprecation dates. Password sign-in share fell from 71% to 3.8% by day 90, TAP desk load peaked at 340/day in wave 3 (five agents), reset tickets dropped 38% quarter-over-quarter, and credential-phishing incidents since enforcement: zero.

Advantages and disadvantages

The disadvantages column is a project-plan checklist, not a rebuttal — every row has a section above that neutralizes it. One strategic caution: the registration campaign, TAP desk, and comms are 60% of the effort and 90% of the user experience.

Hands-on lab: pilot group to enforced phishing-resistant MFA

Runs in any Entra tenant where you hold the Global Administrator role (use a free developer/trial tenant; Conditional Access needs a P1 trial). Cost: ₹0 plus optionally one FIDO2 key — Authenticator passkeys work keyless.

1. Connect and create the pilot group.

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

$grp = New-MgGroup -DisplayName "sg-passwordless-pilot" -MailEnabled:$false `
  -MailNickname "sg-passwordless-pilot" -SecurityEnabled:$true
$user = Get-MgUser -UserId "pilot1@yourtenant.onmicrosoft.com"
New-MgGroupMember -GroupId $grp.Id -DirectoryObjectId $user.Id
$grp.Id     # note the object ID

2. Enable Passkey (FIDO2) for the pilot group with attestation on.

$fido2 = @{
  "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
  state = "enabled"
  isSelfServiceRegistrationAllowed = $true
  isAttestationEnforced = $true
  includeTargets = @(@{ targetType = "group"; id = $grp.Id; isRegistrationRequired = $false })
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "Fido2" -BodyParameter $fido2

3. Enable TAP for the same group (portal: Protection → Authentication methods → Temporary Access Pass → enable for sg-passwordless-pilot; or PATCH the TemporaryAccessPass configuration as in step 2).

4. Issue a one-time TAP for the pilot user.

$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $user.Id -BodyParameter @{
  isUsableOnce = $true; lifetimeInMinutes = 60
}
$tap.TemporaryAccessPass    # e.g. "hx8k+r2m" — hand this to the "user"

5. Register a passkey as the user. In a private window, open https://aka.ms/mysecurityinfo, sign in as pilot1 with the TAP, then Add sign-in method → Passkey. Physical key: insert, touch, set the key PIN. Keyless: choose the iPhone/Android option and complete the QR + Bluetooth flow into Authenticator. Expected: a new method row (“Passkey” with the device/model name).

6. Sign in passwordless and verify the log. New private window → https://myapps.microsoft.com → Sign-in options → Face, fingerprint, PIN or security key. Then check Sign-in logs → your sign-in → Authentication details: the method shows FIDO2 security key or Passkey (device-bound), with MFA satisfied in one step.

7. Create the report-only phishing-resistant CA policy.

$pr = Get-MgPolicyAuthenticationStrengthPolicy |
  Where-Object { $_.DisplayName -eq 'Phishing-resistant MFA' }

New-MgIdentityConditionalAccessPolicy -BodyParameter @{
  DisplayName   = "LAB - PR strength - pilot (report-only)"
  State         = "enabledForReportingButNotEnforced"
  Conditions    = @{
    Users        = @{ IncludeGroups = @($grp.Id) }
    Applications = @{ IncludeApplications = @("All") }
  }
  GrantControls = @{ Operator = "OR"; AuthenticationStrength = @{ Id = $pr.Id } }
} | Select-Object Id, DisplayName, State
# Id                                   DisplayName                          State
# --                                   -----------                          -----
# 3f2a…                                LAB - PR strength - pilot (report-…  enabledForReportingButNotEnforced

8. Confirm report-only evaluation. Sign in again as the pilot user; that sign-in’s Report-only tab shows the LAB policy as Success. Sign in from an account without a passkey and the tab shows Failure — a would-be lockout caught safely, which is the entire argument for report-only gating.

9. Pull the registration report.

Get-MgReportAuthenticationMethodUserRegistrationDetail `
  -Filter "userPrincipalName eq 'pilot1@yourtenant.onmicrosoft.com'" |
  Select-Object UserPrincipalName, IsPasswordlessCapable, MethodsRegistered
# UserPrincipalName            IsPasswordlessCapable MethodsRegistered
# -----------------            --------------------- -----------------
# pilot1@yourtenant.onmicro…                    True {passKeyDeviceBound}

10. Teardown.

Get-MgIdentityConditionalAccessPolicy -Filter "startswith(displayName,'LAB - PR')" |
  ForEach-Object { Remove-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $_.Id }
Get-MgUserAuthenticationFido2Method -UserId $user.Id |
  ForEach-Object { Remove-MgUserAuthenticationFido2Method -UserId $user.Id -Fido2AuthenticationMethodId $_.Id }
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "Fido2" -BodyParameter @{ state = "disabled" }
Remove-MgGroup -GroupId $grp.Id

Common mistakes & troubleshooting

The playbook, in the order the desk will meet them:

The error and event reference for the entries above:

Best practices

• Two phishing-resistant credentials per human, from day one. WHfB + key, or two keys for Tier-0. One credential plus enforcement equals a lockout ticket with interest.
• Enforce attestation and AAGUID allow-lists for privileged users; keep Default permissive-but-device-bound. Assurance where it pays.
• Treat allow-list edits as change-managed revocation events. Query registered credentials by AAGUID before tightening; notify affected users; sequence a re-registration window.
• Report-only for two weeks before every block flip, gated on the registration report. The would-fail count in the CA insights workbook is your go/no-go number.
• Never expire PINs, never complexity-load them. TPM anti-hammering already does the work; friction here poisons adoption.
• Gate on-prem-dependent waves on Kerberos-object health. KeyVersion == CloudKeyVersion is a pre-cutover check; rotation goes on the krbtgt calendar.
• Run the TAP desk like an identity-proofing function. Out-of-band verification scripts, one-time short TAPs, issuance audit alerts on privileged targets.
• Exclude break-glass and the Entra Connect sync account from every strength policy, and drill the break-glass sign-in quarterly.
• Put every exclusion on a clock. Legacy carve-outs get an owner, a compensating control, and an expiry date.
• Instrument before you enforce. The method-mix timechart and password-straggler query exist from wave 0, or you are flying blind.

Security notes

The rollout machinery is itself an attack surface. An attacker who social-engineers your helpdesk into minting a TAP has bypassed every passkey you deployed — TAP creation for privileged accounts needs out-of-band verification and real-time alerting. The security-info registration flow is the second hole: an AiTM session that reaches registration can enroll the attacker’s authenticator, which is why CA01 ships in wave 0 and registration alerts on admin accounts are non-negotiable. Guard the control plane with PIM: Authentication Policy Administrator can rewrite your AAGUID lists, Privileged Authentication Administrator can mint TAPs for Global Admins — both deserve approval-gated activation, as designed in Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale.

Do not weaken the deliberate boundaries. The AzureADKerberos object’s PRP denial of privileged groups is the firewall between “Entra tenant compromised” and “AD forest compromised” — relaxing it for an admin’s file-share convenience reopens the escalation path cloud Kerberos trust exists to close; keep tier-0 AD administration on separate on-prem-mastered accounts and privileged access workstations. Break-glass accounts stay excluded from every strength policy, hold their own FIDO2 keys in dual-controlled storage, and alert on every use — full design in Engineering Break-Glass Emergency Access Accounts in Entra ID: Exclusions, Hardening, and Tamper-Evident Monitoring.

Residual password surface stays a live wire until wave 5 completes. Keep smart lockout, Entra password protection, and the legacy-auth block active while any password can authenticate anywhere, and pair enforcement with risk-based response from Operationalizing Entra ID Protection: Risk-Based Conditional Access, Detection Tuning, and Risk Investigation. Revocation must be a five-minute runbook: delete the lost credential’s method object, Revoke-MgUserSignInSession to kill refresh tokens, issue a one-time TAP for re-registration — a found-in-a-taxi key deleted from the user object is inert hardware.

Cost & sizing

The methods are free; the money is in hardware, licensing you mostly already own, and desk time — offset by the password-reset tickets you stop paying for.

Sizing a 5,000-user program: keys for ~12% (admins, no-TPM, frontline, execs) = 600 × ₹4,300 ≈ ₹25.8 lakh plus 15% spares; WHfB covers ~3,800 users at ₹0 marginal; Authenticator passkeys the rest. Against that, price the run-rate you retire: at 0.5–1.0 password-reset tickets per user per year and ₹800–1,200 fully loaded per ticket, a 5,000-user org spends roughly ₹20–60 lakh/year on resets — a 35–40% reduction pays for the key fleet inside year one, before counting a single avoided phishing incident. Right-size the desk too: wave-3 TAP throughput (≈60–80/agent/day) is the real bottleneck.

Interview & exam questions

Mapped to SC-300, SC-100, AZ-500, and MS-102 where WHfB/Intune surfaces.

1. Why is a FIDO2 passkey phishing-resistant when number-matching push is not? The WebAuthn assertion is origin-bound: the authenticator signs only if the browser’s actual origin matches the credential’s RP ID, so an AiTM proxy’s domain fails cryptographically with no user judgment involved. Number matching still relies on the user approving a session an attacker initiated — a relay defeats it.

2. Compare the three WHfB trust models and justify a default. Cloud Kerberos trust: Entra mints a partial TGT, no PKI or AD FS, immediate SSO — the default. Key trust: DCs validate the synced public key; needs DC certificates and waits on Entra Connect sync. Certificate trust: user certificates via AD FS + PKI — heaviest, but native RDP. Pick cloud Kerberos trust unless certificates are a hard requirement.

3. Walk the flow from fingerprint touch to an open on-prem file share. Gesture unlocks the TPM-held key → WebAuthn assertion to Entra → tokens + PRT + partial TGT (encrypted to the krbtgt_AzureAD keys) → partial exchanged for a full TGT at a DC → SMB service ticket → share opens. No password at any hop.

4. What do attestation enforcement and key restrictions each guarantee, and what does neither guarantee? Attestation cryptographically proves authenticator make/model at registration; key restrictions allow/block specific AAGUIDs at registration and authentication. Neither says anything about which individual key or its custody — serial-level tracking is your asset process.

5. Design TAP for onboarding without creating a new weak link. One-time, 60-minute passes with the policy maximum capped low; issuance restricted to PIM-activated Authentication Admins (Privileged Auth Admin for admin targets); out-of-band identity verification; audit alerts on privileged-target TAPs; registration gated by a CA policy on the security-info user action.

6. Why can’t Require MFA and Require authentication strength combine in one CA policy, and what’s the design consequence? The built-in MFA strength is the Require MFA control — combining them is redundant/contradictory, so the API forbids it. Consequence: run separate policies per concern (baseline MFA for all, strengths per cohort/app) rather than piling grants into one mega-policy.

7. A privileged admin reports no on-prem SSO after passwordless sign-in. Bug or design? Design. The AzureADKerberos object behaves like an RODC whose Password Replication Policy denies privileged built-in groups, blocking partial-TGT redemption — deliberately breaking Entra-to-AD escalation. The answer is a separate tier-0 on-prem admin flow, never relaxing the PRP.

8. “Passwordless is not password-free” — name the levers that actually shrink password usage. Enforced strengths per wave; system-preferred MFA; Windows passwordless experience; never-expiring then scrambled passwords for converted cohorts; disabling SMS/voice; blocking legacy auth; SSPR scope-down — all measured by the password-usage KQL trending to zero.

9. Synced vs device-bound passkeys: where is each acceptable? Both are origin-bound and phishing-resistant. Synced passkeys replicate through consumer clouds with no attestation — provenance and copy-count unverifiable — so they fit low-privilege convenience only; privileged roles get attested device-bound hardware enforced via profile + attestation + AAGUID list.

10. Which reports gate a wave flip from report-only to enforced? Graph userRegistrationDetails filtered isPasswordlessCapable eq false against the wave group (the remediation list), the CA report-only insights workbook (would-block count), and the sign-in-log method mix confirming actual passkey usage — flip when registration ≥ target and would-fail < threshold.

Quick check

1. A user registered a YubiKey last month; today security removed its AAGUID from the allow-list. What happens at their next sign-in?
2. Which single dsregcmd /status field tells you cloud Kerberos trust delivered a partial TGT?
3. Your Intune WHfB profile reports success but devices don’t enroll, and the fleet is hybrid-joined. First suspect?
4. Why does the phishing-resistant strength policy still allow the password prompt to appear at sign-in?
5. Name the two hard limits on passkey profiles.

Answers

1. The sign-in fails — key restrictions apply to authentication as well as registration; the change was a de facto revocation of that credential.
2. OnPremTgt : YES in the SSO State section (with CloudTgt : YES alongside).
3. A GPO also configuring WHfB — Group Policy silently wins over MDM for WHfB on hybrid-joined devices; check gpresult.
4. CA evaluates after primary authentication — the strength refuses tokens until a qualifying method is presented but does not alter the sign-in page. Removing the prompt is demotion work (passwordless experience policy, method disables).
5. Maximum three profiles (including Default) and a 20 KB policy-document ceiling.

Glossary

• AAGUID — Authenticator Attestation GUID; the 128-bit make/model identifier every FIDO2 authenticator reports, used in allow/block lists.
• Attestation — Cryptographic statement, verified at registration, proving an authenticator’s make/model; absent from synced passkeys.
• Cloud Kerberos trust — WHfB/FIDO2 hybrid model where Entra ID issues a partial TGT redeemed at on-prem DCs; no PKI or AD FS.
• Discoverable credential — FIDO2 credential stored on the authenticator, enabling usernameless sign-in; consumes finite key slots.
• Entra Kerberos object (AzureADKerberos) — RODC-style computer object + krbtgt_AzureAD account, one per AD domain, enabling partial-TGT exchange.
• Partial TGT — Kerberos ticket-granting ticket minted by Entra ID, exchanged at a DC for a full TGT during passwordless on-prem SSO.
• Passkey — Industry name for a FIDO2/WebAuthn discoverable credential, device-bound or synced.
• PRT (Primary Refresh Token) — Device-wide Entra SSO artifact issued at Windows sign-in; the anchor for silent app sign-ins.
• RP ID (relying party ID) — The domain a WebAuthn credential is scoped to (login.microsoft.com for Entra); the anchor of origin binding.
• TAP (Temporary Access Pass) — Time-boxed, optionally one-time code satisfying strong auth, used to bootstrap passwordless registration.
• WHfB container — Per-user, per-device store of Windows Hello keys, unlocked by the PIN/biometric gesture.

Next steps

• Pair this rollout manual with the security-side threat model, attestation tiers, and emergency access in Rolling Out Phishing-Resistant Passwordless Auth: FIDO2, Passkeys, and Break-Glass Design.
• Build the enforcement layer properly with Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters.
• Harden the accounts that survive every policy in Engineering Break-Glass Emergency Access Accounts in Entra ID: Exclusions, Hardening, and Tamper-Evident Monitoring.
• Verify the hybrid plumbing your partial TGTs depend on in Microsoft Entra Connect Sync Deep Dive: Designing Hybrid Identity with PHS, PTA, and Seamless SSO.
• Close the mobile flank with Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks.