The Key You Can't Lose: Rolling Out Passkeys Without a Monday Morning Lockout

Passkeys are having a moment. Microsoft, Google and Apple have spent the past couple of years nudging people towards them, and by late 2026 it is getting harder to buy a new phone or sign into a major account without being offered one. For a UK small business, the pitch is attractive: no more password reuse, fewer 'I forgot it again' tickets, and phishing links that simply do not work.

Except 'passwordless' is a slightly misleading phrase. The password may disappear from the login box, but the support work does not. A passkey is still an account credential. It can be lost, mis-enrolled, copied onto the wrong device or tied to a member of staff who left in March. Roll it out without a helpdesk plan and you have not removed a problem. You have moved it to Monday morning.

The login screen changes; the support burden does not

A passkey uses public-key cryptography. The private key stays on a device and is unlocked by a fingerprint, face scan or PIN. The service only holds the public half, so a fake login page has nothing useful to steal. That is a genuine improvement over passwords, especially for small teams where one reused password can expose email, payroll and the accounts system.

It is also device-shaped and platform-shaped. A passkey created on a Windows laptop may not be available on an Android phone unless the service supports cross-device sign-in. A member of staff who uses a shop-floor tablet in the morning and a back-office PC in the afternoon now has two devices to think about. For most people the daily change is small: they tap a fingerprint instead of typing. For IT, the change is bigger. You need to know which devices are trusted, who can reset what, and how someone proves who they are when their phone is at the bottom of a canal.

Shared devices are where the wheels come off

A passkey is designed to prove that a particular person is present. That makes it a poor fit for a shared login. If three people use the same 'shop@' account on a stockroom tablet, enrolling one person's passkey on that tablet either locks out the other two or turns the passkey into a shared secret with extra steps.

For shared devices, keep named accounts and use the tools built for shift work: web sign-in with conditional access, temporary access passes, or a managed device with a clear sign-in and sign-out routine. Do not enrol a passkey on a kiosk and hope for the best. If you have service accounts for printers, scanners or line-of-business apps, leave them alone until you have checked with the supplier. Passwordless for humans does not mean passwordless for everything.

Recovery and MFA resets need a script

The question that decides whether your rollout works is not 'does the fingerprint reader work?' It is 'what happens when the phone is lost?'

Staff will accept a new login method if they believe they can get back in after a mishap. They will quietly work around it if they think a lost phone means a lost week. That workaround usually involves personal email, a shared password or a Post-it note, which defeats the point.

Write the recovery script before you enforce anything. Decide how a person proves their identity to the helpdesk: manager confirmation plus a video call, an in-person visit with staff ID, or a temporary access pass sent to a verified phone number. A five-minute phone call to someone who sounds like the managing director is not verification.

MFA resets deserve their own line in the script. If passkeys become the only method and the helpdesk cannot reset them, people will find a way around you. Make sure at least two named administrators can issue a reset, log every reset, and test the process with someone who is not technical. Keep SMS or an authenticator app as a temporary fallback during the transition, but do not treat it as the permanent answer.

A phased rollout that survives Monday

1. Inventory first. List the accounts people actually use: Microsoft 365, Google Workspace, the CRM, the accounts package, remote access and any supplier portals. Note which are shared, which are personal and which are admin accounts.
2. Pick a mixed pilot group. Include an iPhone user, an Android user, a Windows laptop user, a Mac user and one remote worker. Ten people is plenty. Do not pilot with the whole company on the same afternoon.
3. Write the recovery script before you enforce anything. Include the lost-phone scenario, the new-starter scenario and the leaver scenario. Give the helpdesk a one-page decision tree.
4. Test the lost-phone scenario for real. Hand someone a spare device, remove their passkey and time how long it takes to get them back in. If it takes an hour, fix the process before rollout.
5. Enable passkeys, but do not delete passwords yet. Let people enrol at their own pace while the old method still works. Rushing to remove the fallback is how you create a lockout queue.
6. Run enrolment sessions, not a Friday email. Book twenty minutes per person, in person or on a video call. Monday to Thursday is kinder to everyone. Have a spare security key available for the person whose phone will not cooperate.
7. Keep a break-glass admin account. One tightly controlled admin account with a strong password and a hardware security key, stored in a safe or password manager, is not a weakness. It is the thing that stops a bad rollout becoming a business outage.
8. Review the logs, then widen. Check enrolment success, reset requests and failed sign-ins after two weeks. Expand by team, not by company-wide decree. Keep the helpdesk informed about what is coming next.

The promise of passkeys is real, but it is a promise about phishing resistance, not about removing support. Treat the rollout as an identity project with a helpdesk plan attached. Your staff will barely notice the fingerprint. They will definitely notice if nobody can get into their email on Monday morning.