Beyond the Password Reset: A Measured Passkey Rollout for UK Small Firms

Passkeys are having a practical moment. In 2026, Microsoft 365 and Google Workspace both support them across common devices, and the NCSC continues to recommend phishing-resistant multi-factor authentication. For a UK small or medium-sized enterprise, however, technical availability is the easy part. The harder part is changing daily habits without creating a support queue, locking out a director before a client meeting, or leaving a legacy finance system as the weak link. The sensible approach is not a password amnesty. It is a controlled service change.

Treat passkeys as a service change, not a security lecture

A passkey replaces a password with a cryptographic key pair. One part stays on the user's device or in a synced account, and the other is held by the service. The user unlocks the key with a device biometric, PIN or security key. Because there is no reusable password to type into a fake login page, passkeys are resistant to the most common phishing and credential-stuffing attacks. That is the benefit. The implementation risk is operational: people need to know what changes, what stays the same, and where to go when a device is lost.

Start by writing a one-page service description for staff. It should explain that passkeys are an additional sign-in method, not a new app to manage. It should name the systems in scope first, such as Microsoft 365 email and Teams or Google Workspace accounts. It should also state the recovery route. Keep the language practical: 'You will sign in with your face, fingerprint or PIN on your usual device. Your password remains available as a fallback during the transition.' That single paragraph removes much of the anxiety.

Phase one: baseline and a small pilot

Before enabling anything, check the current authentication estate. Are all users already on multi-factor authentication? Are recovery email addresses and phone numbers current? Are administrator accounts separated from day-to-day accounts? A passkey rollout on top of weak recovery details will simply move the failure point.

Choose a pilot group of five to ten people. Include a mix of laptop and mobile users, at least one person who travels, and one representative from finance or operations. Avoid making the entire leadership team the first cohort; if something goes wrong, you want a calm escalation path rather than a board-level incident. Enable passkeys in Microsoft Entra ID or Google Workspace for the pilot only. Test Windows Hello, Touch ID, Android biometrics and a hardware security key where shared or high-risk access is needed.

Set simple success criteria for the pilot: users can register a passkey without a desk visit, sign-in success is at least as good as before, and the helpdesk receives no more than a handful of confused calls. Record every issue in a shared log. The pilot is not a demonstration of technical elegance; it is a rehearsal for the wider firm.

Phase two: guided expansion by team

Roll out in cohorts rather than by a single company-wide announcement. A finance team may need more support because of banking and payroll systems, while a sales team may adapt quickly on mobile. Give each cohort a short briefing, a one-page guide and a named contact. Offer a fifteen-minute drop-in session, either in person or on video, in the first week.

During this phase, keep passwords and existing multi-factor methods available. Use conditional access or sign-in prompts to encourage passkey registration, but do not block access overnight. The aim is confidence, not compliance theatre. New starters should register a passkey during onboarding, before they accumulate months of password habits. Existing staff should be given a clear deadline for registration, with a support route for exceptions.

Training that sticks

Most passkey training fails because it explains the cryptography and skips the daily reality. Staff do not need a lecture on public-key infrastructure. They need to know three things: how to register a passkey on their main device, how to sign in on a replacement device, and what to do if they lose the device. Demonstrate those three tasks on the actual systems people use. Use plain language: the biometric data stays on the device; the service receives a cryptographic proof, not a fingerprint image.

Recruit a small group of departmental champions. They do not need to be IT experts. They need to be trusted colleagues who can show someone how to add a passkey on a phone and who can escalate unusual errors. Publish a short FAQ that covers lost devices, shared computers, temporary staff and the legacy systems that still require a password. Review the FAQ after each cohort and update it with real questions.

Fallbacks and legacy systems

Passkeys will not cover every application in a UK SME. Legacy finance, practice management or sector-specific systems may still rely on passwords. Do not pretend otherwise. Create an exception register that lists systems without passkey support, the compensating controls in place, and the review date. Compensating controls might include a password manager, strong multi-factor authentication, restricted network access or a managed device requirement. Where possible, remove shared accounts altogether.

For high-risk or shared access, hardware security keys can provide a strong fallback. For everyday users, keep a secure recovery method and make sure it is tested. A passkey that cannot be recovered after a lost phone is not a security win; it is a productivity incident waiting to happen.

Measure adoption, not enthusiasm

Track registration rates by team, sign-in success rates, password-reset volumes and helpdesk tickets tagged to passkeys. Compare the first month after each cohort with the month before. A falling reset volume is a good sign, but so is a stable ticket count during the transition. Ask users one simple question after two weeks: what almost stopped you? The answers will tell you more than a satisfaction score.

Review the rollout monthly with IT, operations and a business representative. Adjust the pace if a team is struggling. The goal for 2026 is not to eliminate every password by a fixed date. It is to reduce the number of password moments that expose the firm to phishing, while keeping everyday work moving. A measured rollout, backed by clear support and honest fallbacks, is the practical route.