← Back to home

Guide · Mixed fleets

Passkey rollout for mixed-device fleets: iPhone, Samsung, Pixel, Windows, Mac

Most Entra ID passkey rollouts fail not because the policy is wrong, but because the IT team wrote one set of instructions and the fleet has five different device families that each behave differently. Here is how to plan a rollout that survives first contact with a real mixed fleet.

Why mixed fleets break the standard guide

Microsoft's official passkey documentation is technically accurate, but it implicitly assumes the reader is on the device the screenshots were taken on. Internal IT documentation usually has the same problem in reverse: it was written from the author's Pixel and ships unchanged to the entire workforce.

The five families that matter:

• iPhone with Microsoft Authenticator. Cleanest mobile flow once Authenticator is installed and signed in.
• iPhone with iCloud Keychain. Synced passkey across the user's Apple devices. Good UX, may be blocked by tenant policy that requires attestation.
• Pixel and other Google-Android phones. Google Password Manager handles storage; the credential picker behaves predictably on Android 14+.
• Samsung Galaxy with One UI. Samsung Pass intercepts the credential picker. Without an explicit choice, registration lands in the wrong vault. See the Samsung Pass + Entra passkeys guide for the detail.
• Windows 11 with Windows Hello for Business. Often already in place. The desktop is passwordless; the rollout work is the user's phone.
• macOS. Use iCloud Keychain via Safari, or a security-key prompt in Chrome. Most enterprise Mac users will end up registering an Authenticator passkey on their phone instead and using that to sign in to Mac apps.

Each of these has a different "what you tap next" answer. A rollout that gives one answer to every user generates tickets equal to the number of users on the second- and third-most-common device.

The three rollout postures that work in mixed fleets

Posture A — Authenticator-first across mobile, WHfB on Windows

Recommended for any organisation larger than ~200 staff. Treat the user's phone passkey (in Microsoft Authenticator) as the universal mobile credential, and let Windows Hello for Business carry the desktop. Mac users register on their phone, same as everyone else, and authenticate to Mac apps via that.

Why it works: one mobile path, one desktop path, and they compose cleanly. End-user comms can say "register a passkey on your phone, then sign in to Microsoft 365 on every device". The Samsung-Pass detour is contained to the phone instructions and does not propagate.

Trade-off: requires Authenticator installed on every phone. Most orgs already have it for MFA, so this is rarely a blocker.

Posture B — Platform-native synced credentials

Allow each user's primary platform credential to do the work: iCloud Keychain on Apple, Google Password Manager on Pixel, Samsung Pass on Galaxy, Windows Hello on PC. Friendly UX; users do not need a separate Microsoft app.

Why it might be the right answer: very small organisations or BYOD- heavy environments where users are unlikely to install an additional app. The UX is as close to invisible as you will get.

Trade-off: tenant policy must allow synced passkeys (no attestation requirement), and the helpdesk runbook gets longer because each platform has its own set of failure modes. Most enterprise deployments rule this out for compliance reasons before they evaluate the UX.

Posture C — Hardware FIDO2 keys for privileged users only

Layer hardware keys (YubiKey, Feitian, Titan) on top of one of the postures above, scoped to administrators, finance, exec accounts, and break-glass credentials. Not a full-fleet posture — it is a complement, not a substitute, because the procurement and provisioning cost does not scale.

The communication template that actually lands

Whatever posture you pick, the announcement email is what determines registration rates. Three rules:

1. One link, device-aware on the other side. Send a single URL that renders the right walkthrough for whatever device the user opens it on. Conditional paragraphs ("if you're on iOS, ...") inside the email get skipped.
2. Lead with the user benefit. "Sign in without a password" beats "we're deploying phishing-resistant FIDO2 credentials". Keep the security framing for the helpdesk page, not the announcement.
3. Three sends, not one. Day 0, day 7, day 14. The third send targets only users who have not registered yet, scraped from the Entra authentication-methods report. Most rollouts hit ~70% on send 1, ~92% on send 2, and the long tail completes after send 3.

Helpdesk runbook for mixed fleets

First-contact triage:

1. "What device are you on right now?" — phone OS, model, OS version. Capture it; it routes the rest of the script.
2. "Have you opened the registration link, and what did you see?" — distinguishes "stalled at the OS prompt" from "didn't reach the prompt".
3. "Do you have Microsoft Authenticator installed and signed in?" — the most common precursor problem.
4. "Which credential picker did you choose?" — surfaces the Samsung-Pass-vs-Authenticator pattern explicitly.
5. "Can you try once more in Chrome (Android) or Safari (iOS)?" — eliminates browser-specific WebAuthn quirks.

Roughly 80% of mixed-fleet tickets resolve in those five steps. The remaining 20% usually need either an OS update, an MDM policy change (Knox-managed devices, mobile configuration profiles on iOS), or a tenant-side allowance the user cannot resolve from their phone.

Reporting and the "long tail" problem

At day 14 you will have a registration figure between 90% and 96%. The remaining 4-10% is the long tail — users on legacy devices, contractors with personal phones, leave- of-absence employees coming back next month, and the predictable handful who simply ignored every email.

The Entra "userRegistrationDetails" Graph endpoint is the source of truth. Pair it with sign-in logs to confirm registered users are actually using their passkey, not falling back to password+MFA. The gap between "registered" and "using" is where stale conditional access exemptions hide.

Plan for a fourth, manual outreach to the long tail at week 3. By week 4, anyone unregistered should be flagged for an in-person desk-side or Teams-call session, not another email.

How SetupPasskeys handles mixed fleets

SetupPasskeys is built around the one-link-device-aware pattern in posture A. The branded URL detects the visitor's device and serves the exact taps they need — iPhone-Authenticator, iPhone-iCloud-Keychain, Samsung-Authenticator, Samsung-Pass, Pixel, Windows Hello, macOS — without the user having to interpret a generic guide.

Each device branch is the same product, served from one URL, so the IT team maintains one piece of communication and the helpdesk has one set of screenshots to reference. Optional AI screenshot troubleshooting covers the long tail of "stuck on a screen the standard flow did not anticipate".

Last reviewed 25 April 2026. See also the Entra ID passkey rollout guide for policy / Conditional Access detail and the Samsung Pass guide for the most common single point of failure.