Your Passkey Rollout Won't Fail on the Cryptography. It'll Fail on Recovery.

Passkeys are the right destination. The cryptography is genuinely solved: a passkey is a FIDO2/WebAuthn credential, the private half never leaves the device, and there's nothing to type into a fake login page. That part works. Major identity platforms all treat passkeys as phishing-resistant authentication, so yes, they satisfy a FIDO2-style requirement out of the box.

So why do enterprise rollouts keep going sideways?

Because almost every problem worth worrying about sits downstream of the maths. Recovery. Mixed device fleets. Getting users enrolled without flooding the helpdesk. A 2023 usability study of FIDO2 in real enterprises found account recovery was the single most challenging part of the whole identity lifecycle, called out by 62% of respondents. Lost authenticator came next at 64% of the hard use cases, then authenticator migration at 49%. None of that is about the cryptography. It's about what happens to a person when their one good factor disappears.

The biggest mistake we see is treating passkeys like an MFA toggle. It isn't a toggle. It's an identity-change programme. Get that framing right and the rest follows.

The crypto is the easy part

Quick recap, because it matters for everything below. A passkey is two halves of a key pair. The public half goes to the service. The private half stays on your device, locked behind Touch ID, Face ID, or a device passcode. Sign-in is a challenge the device signs locally. No shared secret travels anywhere, so there's nothing to phish, reuse, or leak in a breach.

If you want the full primer on how this plays out across Mac, iPhone, and iPad, we wrote that already in passkeys for business. This piece is about the part that comes after you've decided passkeys are the answer: making the rollout survive contact with a real company.

Where it really breaks

Here's the honest list of failure modes, in roughly the order they bite.

One device, then it's gone. A user enrols a passkey on a single device and loses it. No backup factor, no synced copy, no tested recovery path. They're locked out, and now the helpdesk is improvising under pressure. This is the recovery problem the study put top of the list, and it's the one people consistently under-plan for.

Mac passkey, Windows login. Someone creates a passkey on their Mac, then tries to sign in from a Windows laptop, or the other way round. If the passkey only lives in iCloud Keychain and they're on a non-Apple machine, the smooth path isn't there. Cross-device flows exist, but "scan a QR code with your phone every morning" is not a rollout, it's a support ticket waiting to happen.

iCloud isn't always available. Mixed personal-device setups, people without iPhones, or managed devices where iCloud is restricted all break the Apple-only sync assumption. For a Mac-first business this is easy to miss, because it works perfectly for the founders and then falls over for the contractor on a Windows box.

The old MFA is still on. This one is quiet and lethal. You roll out passkeys, but the legacy SMS or authenticator-app methods linger in the policy. Now there's an easy path around your shiny new phishing-resistant requirement, and attackers will take it before your users do. If the weak method still works, you haven't raised the bar, you've added a bypass.

Two weeks, no pilot. Compress migration into a fortnight and the service desk drowns. "Just use a passkey" is not self-explanatory to most people. Enrollment confusion at scale, with no staged group to learn from, is how a good security upgrade earns a bad reputation internally.

There's also the awkward middle ground: shared and contractor accounts (a poor fit for passkeys), legacy apps and non-browser sign-ins that don't support the flow yet, and device replacement. Worth being precise on that last one. Device-bound passkeys do need re-enrolling on a new laptop. Synced passkeys, whether through iCloud Keychain or a manager like 1Password, come straight down to the new device. Knowing which kind you've deployed tells you whether a new starter's laptop is a five-minute job or a re-enrollment.

1Password is the bridge, not a nice-to-have

For a fully Apple business, iCloud Keychain is the convenient default and it's already there. But the second your people live across macOS, iOS, and Windows, a single-vendor consumer sync stack starts creating avoidable lockouts.

A cross-platform manager fixes the day-to-day. 1Password syncs the same passkeys across macOS, iOS, Windows, Android, and every major browser, so the user who works on a Mac at home and a Windows machine in the office isn't carrying two separate sets of credentials in their head. The FIDO Alliance's Credential Exchange work is also making it possible to move passkeys between managers without re-enrolling on every site, which kills the old lock-in worry.

The catch: a manager doesn't write your policy for you. You still need to decide who's allowed a synced passkey, who needs a hardware key, and what the fallback is when the manager itself is unavailable. 1Password makes a mixed fleet workable. It doesn't make the decisions.

Okta is the place to enforce it, not a shortcut

If Okta is your control plane, it earns its keep here. You can make phishing-resistant authentication a required step in the sign-in policy rather than an optional extra each app team has to remember. That's the difference between a real standard and a hopeful one. As of the 2026.04 release Okta even renamed the authenticator to Passkey (FIDO2 WebAuthn) and lets you require a phishing-resistant factor both for sign-in and, importantly, for enrolling new factors. Same logic applies to Microsoft Entra ID and Google if that's your IdP instead.

What Okta won't do is the hard part for you. It gives you a good place to enforce the standard. You still decide whether users enrol on the org-managed device, in a manager, or on a hardware key, and you still own the recovery process for the day a device or browser dies. If you're still choosing an identity platform, we compared the main ones for UK businesses in our identity management showdown.

Hardware keys and break-glass for the accounts that matter

Synced passkeys are right for most of the team. They're strong and they're convenient, and convenience is what gets you adoption. But for the accounts where a breach is a catastrophe, raise the bar.

Admins, finance, and exec accounts should be on hardware security keys, or attested passkeys created on managed hardware, plus a break-glass recovery method held for genuine emergencies. The point of attestation is that a relying party can verify, cryptographically, that the passkey was created on your managed fleet, so a phisher who tricks an admin into making one on a personal device still can't get in. That's the kind of control worth the extra friction for ten accounts, not five hundred.

A rollout plan that doesn't strand people

The order matters more than the speed. This is the sequence we use:

1. Inventory every sign-in path, not just the obvious ones. Google or Microsoft is the front door, but the legacy app and the VPN and the non-browser tool are where rollouts trip.
2. Decide the factor per group. Who gets synced passkeys, who gets a hardware key, who needs both. Map it before you touch a policy.
3. Keep a break-glass method for admins and support. Tested, documented, and locked down. This is the safety net the recovery data says you'll need.
4. Pilot on Mac, Windows, and mobile. A small group across all three platforms surfaces the device-diversity problems before they're company-wide problems.
5. Enforce only after recovery is tested end to end. Turn off the old weak methods at the same time you switch on the requirement, so there's no bypass left behind.

That beats a blanket two-week deadline every time. The failure mode isn't users refusing passkeys. It's users getting stranded when their one good factor disappears and nobody planned for it.

What we recommend for a Mac-first org

Passkeys are the right destination, and enterprise success comes down to orchestration, not policy on its own. Anyone can write "everyone must use a passkey by Friday." Making it stick without a wave of lockouts is the actual work.

For a Mac-first UK business, the pattern that holds up is usually a combination: Okta (or your IdP) enforcing phishing-resistant authentication so the standard is real, passkeys stored in iCloud Keychain for the all-Apple users and 1Password for anyone who crosses into Windows, and hardware keys plus break-glass for admins and high-risk roles. Pilot it, test recovery, then enforce.

We've rolled this out across Mac, iPhone, and iPad fleets for clients in finance, film, and creative agencies, and the recovery planning is always the part that separates a calm migration from a fire drill. If you want a second pair of hands on yours, get in touch and we'll map the right path for your team.