← Back to home

Pillar guide

Passkey rollout best practices: a 2026 playbook for Microsoft Entra ID admins

Seven things experienced Entra admins do differently from first-time rollout teams. Five pitfalls that derail most first attempts. The order matters more than the individual tactics — most failed rollouts get the steps right but the sequence wrong.

Last updated 30 April 2026 21-minute read

Why so many passkey rollouts stall at 60%

Microsoft has spent the last three years making passkey enrolment objectively easier: Authentication methods policy is one toggle, the Microsoft Authenticator app handles attestation, and modern browsers ship WebAuthn out of the box. The technology is solved. And yet the rollouts that hit the 90%+ enrolment number IT teams promised their CISOs are the exception, not the rule. Most stall in the 50-65% band — enough to satisfy a compliance auditor in a good mood, but not enough to actually retire password sign-in or enforce phishing-resistant Conditional Access.

The reason isn't user resistance. It's that passkeys are an identity infrastructure change being run as if it were a password reset campaign. The technical primitives are well-documented; the rollout primitives — device coverage, comms cadence, helpdesk readiness, enforcement timing — are not. This guide is the rollout-side playbook, written for the IT or identity admin who has been handed the project and wants to know what experienced teams do differently.

The seven practices below are sequenced. Most pitfalls trace back not to skipping a step but to running them out of order. The most common mistake we see is enabling Conditional Access enforcement before broad enrolment completes, which then locks the unenrolled tail out of the very portal they need to enrol — a self-inflicted DoS that ends with a frantic Friday-night policy rollback. Sequence matters.

Practice 1 — lead with policy, not enrolment

First instinct on most rollouts: start enrolling pilot users. Wrong order. Before the first user clicks anything, get the Authentication methods policy right. The most common mistake here is leaving the legacy MFA / SSPR registration policy enabled alongside the modern Authentication methods policy, which produces a confused state where some users see the new passkey option in mysignins.microsoft.com and others don't. Microsoft's migration guide explains the cutover; do it before pilot.

Specifically, in the Entra admin centre → Protection → Authentication methods → Policies, you want:

Equally important — what not to do at this stage:

See the Entra ID passkey rollout guide for the policy work in more detail.

Practice 2 — pilot deliberately, not casually

The default pilot is "let me ask 20 IT colleagues to try it for a few days." That produces useless data. IT staff own a uniform set of devices (recent iPhones, Pixels, managed Windows laptops) and they're sufficiently technical to brute-force their way through any UX rough edge they encounter. Their success rate is irrelevant to your broad-rollout success rate.

A pilot worth running has three properties:

  1. Device-family coverage. Pick 30-50 users that span every phone OS your fleet contains. If you have any Samsung users at all, include 5-10 of them. Same for Xiaomi, Huawei, OPPO, vivo if your fleet has them. iPhone users on iOS 17 and iOS 18 (different default credential routing). Windows users on Windows 11 22H2 and 24H2 (different Hello defaults).
  2. Non-technical user mix. 60-70% of pilot users should be drawn from functions outside IT — sales, finance, ops, HR. They struggle with things IT staff don't notice, and that's where the helpdesk runbook gets written.
  3. Failure capture. Tag every pilot ticket by device family, OS version, and the specific failure mode. By the end of two weeks you'll have a ranked list of the issues that will dominate broad rollout. This list is your runbook for practice 3.

Run the pilot for 10-14 days. Shorter than that and you miss the cross-device sign-in failures (people enrol on their phone Tuesday and try to sign in from their laptop Friday — that's the failure shape that two-day pilots miss). Longer than two weeks and you're delaying broad rollout for diminishing returns.

At pilot end, the deliverables are:

Practice 3 — pre-document the device-specific quirks

Microsoft's documentation describes the canonical Authenticator passkey flow. Real fleets have a long tail of devices that don't follow that flow. The fix for each is usually trivial once you know about it; the rollout cost comes from discovering each one in production via 50 helpdesk tickets. Pre-document them.

Five quirks account for ~80% of the device-specific helpdesk volume:

Samsung Pass intercept (Galaxy)

Samsung One UI promotes Samsung Pass as the default credential service. WebAuthn registration requests are silently routed there instead of Microsoft Authenticator, which means the passkey is created in Samsung's vault but Entra never sees it on sign-in. Users don't know anything is wrong until they try to sign in days later. Fix: change Settings → General management → Passwords, passkeys and autofill → Choose default passkey service to Microsoft Authenticator before enrolment. Three-tap fix; takes 30 seconds. The Samsung Pass + Entra passkeys guide has the screenshot-by-screenshot version.

Xiaomi Mi Autofill device-only behaviour (HyperOS / MIUI)

Xiaomi devices ship Mi Autofill as the default credential service. Passkeys created through Mi Autofill are device-bound only — they don't sync to other devices the user owns. China-region Xiaomi firmware has no Google Mobile Services at all, so Google Password Manager isn't available as an alternative. Communicate explicitly to Xiaomi users that they need a backup method (a second passkey on a work laptop, or Authenticator on a backup phone). Don't assume the cross-device "sign in from a new device by approving on phone" flow will work for them — it won't.

Post-2019 Huawei (no Google Mobile Services)

Huawei devices shipped after May 2019 have no Google Mobile Services. Microsoft Authenticator does work — sideloaded or installed via Huawei AppGallery — but the resulting passkey is device-bound only. If the user loses the phone, the credential is gone. Pair every Huawei user with a registered hardware key (YubiKey or similar) or require them to enrol on a second device. This is one of the few cases where a hardware-key budget request is justified.

iCloud Keychain default routing on iPhone

iOS automatically routes WebAuthn registrations to iCloud Keychain unless the user explicitly switches the default. This is fine if your tenant accepts synced passkeys — the credential ends up in iCloud, syncs across the user's Apple devices, and signs in cleanly to Entra. If your policy requires Microsoft Authenticator-attested credentials, users must open Authenticator first, sign in to their work account, and start enrolment from inside the app — otherwise iOS captures the credential before Authenticator sees it.

Microsoft Authenticator vs platform passkey on the same device

Modern OS pickers offer "Microsoft Authenticator" and the platform passkey vault as two separate choices on the same screen. Users default to whichever is highlighted first, which varies by OS version. The result: in a fleet running mixed iOS versions, you get passkeys spread across iCloud Keychain and Authenticator haphazardly — no consistency for the helpdesk. Fix: communicate explicitly which one users should pick, with a screenshot for the OS version they're most likely on.

The pattern: every quirk is a 30-second fix once you know about it. The cost is discovery time. A pre-built per-device-family runbook collapses that cost from "first 50 tickets" to zero. The mixed-device fleet rollout guide documents the full set.

Practice 4 — roll out in waves, not big-bang

The tempting plan: announce on Monday, deadline by Friday, everyone enrolled. This plan does not survive contact with reality, because the binding constraint on rollout speed is not user willingness — it's helpdesk capacity. A 1,000-person org triggering 200 helpdesk tickets in a single morning lands every one in a multi-hour queue, support quality drops, and the rollout's reputation tanks before week 1 finishes.

Wave-based rollout solves this. The shape that works:

For a 1,000-person org, that's typically 4-5 waves over 8-10 weeks. Slower than big-bang sounds painful but compresses the ticket volume into manageable batches and produces a much higher final enrolment rate than a chaotic two-week sprint. The majority of stalled rollouts we see are big-bang attempts that ran out of helpdesk capacity in week 1 and never recovered momentum.

Practice 5 — treat the communications cadence as the rollout

IT teams systematically underweight the comms side because it feels like marketing work. It isn't. Comms is the single biggest determinant of enrolment rate after helpdesk readiness. The minimum-viable cadence is three emails:

  1. T-7 days announcement. "Passkey rollout is happening for [your group] on [date]. Here's why (phishing-resistant MFA, regulatory requirement, etc.), here's what you need to do (15 minutes, here's a link), here's where to get help (Slack channel + email)." One screen of body copy, one button. Do not bury the enrolment link below 6 paragraphs of compliance copy.
  2. T-0 day-of email. "Today's the day. Click here to enrol [branded link]. Should take 5-10 minutes. Reply to this email if you hit any issues." Subject line: "Passkey enrolment opens today — 5 minutes". Stop trying to make the email "professional" — make it scannable. Mobile-first formatting (short paragraphs, big buttons).
  3. T+7 days reminder for stragglers. Sent only to users who haven't enrolled yet (filter via the Entra userRegistrationDetails report). CC their direct manager. Subject line: "You're in the late group — please enrol this week". Manager CC roughly doubles completion rate within 72 hours based on every campaign we've watched.

Subject lines outperform body copy by a wide margin. Test 2-3 variants in pilot if you have the patience. The variants that consistently win:

Variants that consistently lose:

Channel mix: email is primary. Teams or Slack for follow-up reminders during the wave. Town hall / all-hands mention only as a kickoff signal — don't expect anyone to actually enrol from a Zoom call.

Practice 6 — stand up helpdesk readiness before wave 1

First 48 hours of every wave generate 70-80% of the wave's tickets. If your helpdesk isn't ready when the announcement email goes out, the rollout's reputation is damaged before it begins. Helpdesk readiness has four parts:

  1. A pre-built FAQ document covering the top 10 errors. Pull these from the pilot data. The Top 10 typically includes:
    • "My phone says passkey saved but I can't sign in" (Samsung Pass intercept)
    • "It's asking me to use Touch ID and won't let me use Authenticator" (iOS routing)
    • "The passkey expired" (it didn't — passkeys don't expire; this is usually conditional access)
    • "I lost my phone, I'm locked out"
    • "I have two phones, do I need to enrol both?"
    • "I work on multiple computers — does my passkey work on all of them?"
    • "I don't have Authenticator installed and the link doesn't tell me how to get it"
    • "Microsoft says my session has expired and I can't enrol"
    • "My company's branded link doesn't work" (DNS / cache issue)
    • "I'm on Huawei / Xiaomi — none of the steps match my phone"
    The passkey troubleshooting reference covers each of these in detail.
  2. A dedicated channel. A Slack/Teams channel — never just "email IT@" — where users can post questions and get answers visible to the whole wave. Most users with a question will recognise their issue when someone else posted the same one 20 minutes earlier. This collapses ticket volume by ~30%.
  3. An escalation path. Most tickets are L1-resolvable from the FAQ. 5-10% need L2 (someone with Entra admin access). 1-2% need L3 (the rollout owner). Document the escalation path explicitly so an L1 helpdesk agent knows when and how to escalate without sitting on a stuck ticket for hours.
  4. A documented break-glass / recovery flow. The user who lost their phone, locked themselves out, and is now panicking needs a 5-minute recovery path. Usually: TAP (Temporary Access Pass) generated by an admin, valid for 1 hour, delivered out-of-band (manager confirms identity over phone). Document who can issue a TAP, how to confirm identity, and how long the TAP lives.

Optional but high-leverage: an AI screenshot diagnosis tool that lets stuck users take a photo of their screen and get instant guidance, reducing the number of tickets that hit L1 at all. SetupPasskeys ships this as part of every branded rollout.

Practice 7 — tighten Conditional Access only at 95%+ enrolment

The single biggest cause of stalled, frustrated, rolled-back passkey rollouts. The scenario: rollout looks great, 80% enrolled, leadership wants to "lock it in" by flipping Conditional Access to require phishing-resistant authentication strength. Result: the unenrolled 20% can no longer sign in to enrol — because Conditional Access is now blocking their password sign-in to mysignins.microsoft.com. Helpdesk explodes, executive escalations hit, IT rolls the policy back, the rollout loses credibility, and the unenrolled tail never closes.

The right sequence:

  1. Wait for 95%+ enrolment in the wave's scope. Track via the userRegistrationDetails report. The remaining 5% are typically out-of-office, on parental leave, or a small set of edge-case devices. Don't enforce until they're back or rerouted.
  2. Send a 7-day enforcement warning. Email to the unenrolled tail: "Phishing-resistant MFA enforcement starts on [date]. After this date, password sign-in to admin and high-risk apps will be blocked. Please enrol now or contact IT for a recovery TAP."
  3. Flip Conditional Access in report-only mode for 48 hours. Watch the report-only log for users who would be blocked. Reach out to each one individually to enrol them or issue a TAP.
  4. Flip to enforce. By the time you do, the report-only sweep has confirmed nobody legitimate will be blocked. Block-rate post-enforce should be essentially zero except for genuinely-anomalous sign-ins (which is exactly what the policy is meant to catch).

Privileged accounts get a stricter version of this — phishing-resistant strength and a tighter scope (admin centres, financial systems, source-code repositories). Some teams enforce attested-only credentials for these scopes; others accept any FIDO2 passkey. Match the policy to your risk model.

Once enforcement is live and stable, the final policy work is to start removing password-based authentication from the methods policy entirely. That's the goal — passwords retained only for break-glass accounts. Most orgs reach this state 3-6 months after the initial rollout completes.

Five pitfalls that derail first-time rollouts

Beyond the seven practices above, five specific anti-patterns show up in nearly every stalled rollout:

Pitfall 1 — running password expiry alongside passkey rollout

Common manager instinct: "let's force passkey adoption by making passwords annoying." Counterproductive. Users hit a password expiry prompt, reset their password (with all the failure modes that already had), and never even click the passkey enrolment link. Worse, password resets generate their own ticket volume that competes with passkey rollout for helpdesk capacity. Disable any short-cycle password expiry while rollout is in flight. NIST has been recommending no-expiry policies since 2017 anyway; this is the right time to align.

Pitfall 2 — treating Microsoft Authenticator as the only option

For privileged accounts, Authenticator-attested credentials make sense. For general staff, requiring Authenticator alienates the substantial fraction who already have iCloud Keychain or Google Password Manager working smoothly. Each user has to download a new app, sign in, navigate the cross-device flow — friction that drives enrolment rate down. Accept all three vault options for general users; restrict attested-only to privileged scopes.

Pitfall 3 — not tracking enrolment by device family

The Entra registration report tells you who enrolled, not what device they enrolled on. Without device-family tracking you can't see that your Samsung users are stuck at 45% while iPhone users hit 92% — and you can't intervene where you need to. Tag enrolments with device hints (User-Agent during the rollout campaign, or a dedicated click-through query parameter on the branded enrolment link). Re-cut your enrolment-rate dashboard by device family every Monday during rollout. Where the rate's lowest, that's where your runbook needs work.

Pitfall 4 — treating rollout as one-and-done

New employees join. Existing employees swap phones every 18-30 months. iOS and Android ship major releases that change OS-level credential routing every September / October. The steady-state work after rollout is at least:

Pitfall 5 — forgetting break-glass accounts

Phishing-resistant MFA enforcement breaks everything, including the emergency-access path your team needs when Entra itself is having a bad day. Microsoft's recommended pattern is two break-glass accounts, both excluded from all Conditional Access policies, both with credentials physically stored offline. If you don't already have these set up, Practice 7's CA enforcement is a hard prerequisite gate — set up break-glass first, then enforce. Test the break-glass sign-in before enforcement, not during the outage where you actually need it.

The role of branded walkthroughs

We build SetupPasskeys, so this section is unavoidably opinionated — but the underlying principle is generic, and applies to anything you build in-house too.

The friction in passkey rollouts is concentrated at the moment of enrolment. The gap between "user reads enrolment email" and "user has a working passkey" is where the rollout is won or lost. Microsoft's generic mysignins.microsoft.com page works for users on a vanilla iPhone or Pixel. For users on Samsung, Xiaomi, Huawei, OPPO, vivo — the long tail you ignore at your peril — the generic page asks "tap the right button" without explaining which button is "right" on their specific device.

A branded walkthrough closes that gap. The user lands on a single URL — branded as your tenant, with your logo and accent — that detects their device family and renders the exact taps for that device, with screenshots. Samsung users see the Samsung Pass intercept fix inline. iPhone users see the iCloud Keychain default explanation. Huawei users see the device-bound caveat. The walkthrough doesn't replace Microsoft's enrolment endpoint — it hands the user off at the right step, having pre-cleared the device-specific obstacles.

You can build this in-house if you have the patience and the device coverage. Most teams don't — there are 17+ device flows worth supporting, each requiring its own screenshots and updates as OS versions ship. SetupPasskeys ships them all out of the box, branded as your tenant. The mixed-device fleet rollout guide shows what the walkthrough looks like end-to-end.

See the branded walkthrough for your tenant

Type your work domain on the home page — within seconds you'll see what your employees would land on, branded with your real logo and accent colour, with the device-specific flows for Samsung, iPhone, Pixel, Windows, Mac all live.

Try the branded demo → Talk to us

Frequently asked questions

How long does a passkey rollout actually take for a 1,000-person org?

Realistic timeline is 8-12 weeks end-to-end: 2 weeks policy work + pilot, 6-8 weeks of waves at ~200 users / 2 weeks each, plus 1-2 weeks at the end to tighten Conditional Access. Orgs that promise "two weeks" typically slip to four months because they skip the pilot, discover device-specific issues in production, and have to backfill the runbook under pressure.

Should I require Microsoft Authenticator-attested passkeys, or accept iCloud Keychain and Google Password Manager too?

For general staff, accept all three. iCloud Keychain and Google Password Manager produce valid FIDO2 credentials and the user experience is dramatically smoother because users already have those vaults configured. For privileged accounts (admins, finance, legal), require attested device-bound credentials — Authenticator, Windows Hello for Business, or hardware keys. Two policies, scoped by group, achieves both outcomes.

What's the single biggest cause of stalled passkey rollouts?

Enabling Conditional Access enforcement before broad enrolment completes. The unenrolled users can no longer sign in via password to enrol, support tickets explode, and the IT team rolls the policy back — at which point the rollout has lost credibility and momentum. Always enforce after you've hit 95%+ enrolment for the wave's scope, never before.

Do users need to enrol multiple devices?

Yes — best practice is two passkeys minimum per user. One on their primary phone, one on their work laptop. This means a lost phone doesn't lock them out, and the cross-device flow works in both directions when they sign in from a new browser. The Microsoft Authenticator passkey setup guide covers the cross-device part in detail.

Does a passkey rollout reduce helpdesk ticket volume long-term?

Yes, materially. Once enrolment completes, password-reset and OTP-related tickets drop sharply because there are fewer passwords to forget and no SMS codes to mistype. The first six weeks generate elevated tickets (registration friction); months 3+ run at significantly lower steady-state volume than the password baseline.

Is a passkey rollout enough to satisfy NIS2 / CISA / EO-14028 phishing-resistant MFA requirements?

Yes. FIDO2 passkeys (whether platform-bound, synced, or hardware-key-backed) are the canonical "phishing-resistant authentication" Microsoft ships against the NIS2 Article 21 mandate, the CISA Zero Trust Maturity Model, and US Executive Order 14028. The Conditional Access "phishing-resistant" authentication strength explicitly maps to this. Verify with your compliance team that your tenant configuration meets their interpretation, but the underlying credential is right.

Can we keep passwords as a fallback during rollout?

Yes — and you should, until enrolment hits 95%+. Disable password sign-in only after the broad rollout completes and Conditional Access is enforcing phishing-resistant strength. Until then, passwords remain a recovery path for unenrolled users. Long-term, the goal is phasing them out entirely (or restricting to break-glass accounts only).

Last updated 30 April 2026. Microsoft Entra and Microsoft Authenticator both ship material UX changes on a quarterly cadence; verify against Microsoft Learn for the most current screen flows before finalising your wave-1 communications. The rollout sequencing above is stable across versions — it's the screenshots that age.