From Reset Desk to Recovery Path: Making Passkeys Stick Across UK Organisations

Passkey programmes in the UK have reached an awkward stage. The pilot works: users enrol, authentication succeeds, and the security team can point to a modern, phishing-resistant sign-in. Then the rollout meets the service desk, the accessibility team, the legacy application owner and the assurance function. Progress slows. In many organisations the project is declared a success while password resets remain a daily habit.

That gap is not a cryptographic failure. It is a service-design failure. Passkeys change how people recover access, how support staff diagnose problems and how auditors see evidence. Treating the change as a security toggle is the quickest way to create a permanent exception process.

Pilot success is not rollout readiness

A pilot usually tests a narrow cohort on modern devices and a small set of applications. A rollout tests the organisation. It tests the person who has just replaced a phone, the contractor using a shared laptop, the administrator who needs a break-glass route and the service desk analyst working from a script written for passwords.

Before scaling, UK organisations should establish a baseline. How many password reset calls are logged each month, and for which systems? Which user groups rely on shared devices? Which applications still use forms-based authentication rather than SAML or OpenID Connect? Which staff have accessibility requirements that affect authentication? These questions define the rollout more accurately than a vendor demonstration.

Map the credential estate before choosing a model

The device-bound versus synced passkey debate is often framed as a binary security choice. In practice it is a population decision. Synced passkeys, held in a platform keychain and available across a user's devices, reduce lockout risk and suit general staff who work across phone, laptop and tablet. Device-bound passkeys, stored in a trusted platform module, secure enclave or hardware security key, provide tighter binding to a specific device and may be appropriate for privileged administrators, finance approvers and roles subject to higher assurance.

The trade-off is recovery. A synced passkey shifts recovery to the platform account, which must itself be governed. A device-bound passkey shifts recovery to the service desk and to spare hardware. Neither model removes the need for identity verification. Both need a registration policy that prevents a user from enrolling an unmanaged device without challenge.

A workable approach is to define cohorts. General staff may receive synced passkeys with platform recovery and a clear fallback. Privileged users may require device-bound credentials plus a documented break-glass procedure. Contractors and temporary staff may need time-limited credentials and a separate recovery path. The policy should be explicit, approved and reviewable.

Sequence the rollout around service dependencies

A practical sequence for 2026 looks less like a security deployment and more like a service change programme.

1. Inventory the applications, identity providers, MFA methods and recovery routes in scope.
2. Define credential policy by cohort, including device-bound and synced options.
3. Update identity provider registration flows, conditional access and device trust signals.
4. Rewrite helpdesk scripts and train analysts before the first wave.
5. Rehearse recovery scenarios with real users, including lost-device and new-phone cases.
6. Extend enrolment in waves, monitoring reset volumes, registration failures and exception requests.

This order matters. If helpdesk scripting follows the rollout, the service desk learns on live incidents. If legacy exceptions are not identified early, users create workarounds that undermine the programme.

Helpdesk scripting is the real cutover

The reset desk is a learned behaviour. Analysts have spent years resolving access problems by resetting a password. Passkeys require a different conversation: verifying identity, checking whether the credential is synced or device-bound, guiding the user through platform recovery, and escalating only when the recovery path is genuinely unavailable.

Scripts should cover the common failure modes: a new phone without the synced credential, a lost hardware key, a shared device where passkey registration is inappropriate, a user who cannot complete a biometric prompt, and a suspicious registration attempt. The script should also define what the service desk must not do, such as bypassing identity verification to restore access quickly.

Metrics should change with the service. Reset call volume remains useful, but it is not the only measure. Track passkey registration completion, time to recover access, repeat recovery requests, exception volume and user-reported friction. A programme that reduces resets but increases recovery incidents has not improved the service.

Accessibility and inclusion need design decisions

Passkeys can reduce cognitive burden, but they can also introduce new barriers. QR codes, device handoffs, biometric prompts and cross-platform registration may disadvantage some users. Under the Equality Act 2010, and for public sector bodies under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, accessibility is not an afterthought.

Organisations should test enrolment and recovery with assistive technology, offer assisted enrolment where appropriate, and provide clear guidance in plain English. A fallback method is not a failure of the programme if it is controlled, monitored and time-limited. The greater risk is a rigid rollout that forces users into workarounds or excludes them from digital services.

Legacy applications need an exception register, not a blind spot

Not every application will support WebAuthn or FIDO2 in the near term. Some will sit behind an identity provider that can broker authentication; others will require a local password. The difference should be documented.

An exception register should record the application, owner, user cohort, risk rating, compensating controls and review date. Exceptions should be approved, not inherited. Shared passkeys should be avoided because they weaken non-repudiation and make recovery difficult to audit. Where a legacy system cannot be integrated, the organisation should set a realistic exit plan rather than allowing the exception to become permanent.

Public-sector assurance requires evidence, not just enrolment

Public sector assurance frameworks, including GovAssure and Cyber Essentials, increasingly expect identity controls to be evidenced. A passkey rollout should generate evidence that recovery is controlled: who can reset access, how identity is verified, which exceptions are approved and how registration events are logged.

Assurance teams will also ask about supplier dependency. If synced passkeys rely on a platform account, the organisation needs to understand the recovery and support terms behind that platform. If device-bound credentials rely on hardware, the organisation needs spares, replacement logistics and a revocation process. The security story is stronger when the recovery story is documented.

Treat passkeys as a service, not a setting

The organisations that move beyond the pilot will be those that redesign the service around passkeys rather than bolting passkeys onto a password service. That means owning recovery, training the service desk, testing accessibility and managing exceptions with discipline. The cryptography is important, but it is not the part that stalls the rollout. The operating model is.