IT Best Practices

9 July 2026

Passkeys explained: what they are, how they work and why they matter

What passkeys are

Passkeys are a passwordless sign-in method built on FIDO standards. In simple terms, they replace the shared secret we call a password with a cryptographic credential created on a user’s device or in a credential manager. The UK’s National Cyber Security Centre now recommends using passkeys over passwords wherever they are available, and describes them as a more secure alternative that people do not need to remember. 

For most people, the everyday experience is refreshingly ordinary. Instead of typing a password and then a code from an app or text message, the user approves sign-in with the same local unlock they already use on their phone, laptop or security key, such as a fingerprint, face scan or PIN. Google, FIDO and Microsoft all describe this pattern in essentially the same way: the user unlocks the device locally, and that unlock authorises the passkey. 

That is why passkeys are easier to explain than they first appear. A passkey is not a magic new password, and it is not something the user has to invent, memorise or rotate every few months. It is a credential that your device creates and keeps for a specific website or app. In other words, it is less “type a secret and hope” and more “prove you hold the right key on the right device.” 

How passkeys work

The plain-English version

When a user creates a passkey, their device generates a unique public and private key pair for that account on that service. The private key stays with the authenticator or credential manager, while the public key is registered with the website or app. When the user signs in later, the service sends a random challenge, the user unlocks their device locally, and the device signs that challenge. The server then verifies the signature using the public key it already has on file. 

From a security point of view, that design solves several old password problems in one go. The server is not storing a reusable password for the attacker to steal. The private key is not sent across the network during sign-in. And because the credential is tied to the site it was created for, a fake lookalike site cannot successfully use the same passkey. The W3C WebAuthn specification states that the credential can only be accessed by origins belonging to that relying party, which is a major reason passkeys are resistant to phishing. 

The technical version without the headache

Under the bonnet, passkeys sit on top of FIDO2, which combines the W3C WebAuthn browser API with CTAP, the protocol used to talk to authenticators such as security keys and platform authenticators. FIDO describes passkeys as cryptographic key pairs used for passwordless authentication, while W3C defines WebAuthn as the web API for creating and using strong, scoped public-key credentials. 

It is also worth clearing up a very common misconception: using Face ID, Windows Hello or a fingerprint reader does not mean the website receives your biometric data. The biometric or PIN is used locally to unlock the private key on the user’s device. FIDO states that biometric information, if used, never leaves the device, and Apple says passkeys stored in iCloud Keychain are encrypted and not visible even to Apple. 

What users will actually see

On Apple devices, passkeys can be stored in iCloud Keychain and synchronised across approved Apple devices. Comparitavely Android and Chrome, Google Password Manager can store and synchronise passkeys across supported environments. On Windows, passkeys can be stored with Windows Hello, and Microsoft also supports cross-device sign-in scenarios. So while the cryptography is sophisticated, the user journey usually feels like a familiar system prompt asking them to confirm sign-in. 

Why passkeys matter for businesses

For businesses, passkeys are not just a security improvement. They are also a usability improvement. Google notes that developers store a public key on the server instead of a password. This means a breach of the authentication store is less valuable to an attacker. FIDO adds that passkeys are designed to reduce phishing, credential stuffing and password database risks. This is because there are no passwords to steal and no reusable shared secret to replay. 

They also remove a surprising amount of friction from the sign-in journey. Users do not need to remember, type or reset passwords, and organisations can reduce dependency on SMS-based authentication and the support burden around account lockouts and forgotten passwords. FIDO explicitly highlights lower costs around SMS, password resets and lockouts as one of the practical business benefits of passkeys. 

For a UK-based organisation, the strategic signal is now difficult to ignore. The NCSC recommends passkeys wherever a service supports them and has publicly stated that passkeys offer a more usable, secure replacement for passwords. That moves passkeys out of the “interesting future idea” category and into “worth planning for now.” 

Synced and device-bound passkeys

Not every passkey works in exactly the same way behind the scenes, and this matters for IT teams. Microsoft distinguishes between synced passkeys and device-bound passkeys. Synced passkeys are encrypted and made available across a user’s devices through a passkey provider such as Apple iCloud Keychain or Google Password Manager. Device-bound passkeys stay on one physical device or security key and never leave it. 

That difference matters when you choose an authentication strategy. Microsoft recommends device-bound options such as FIDO2 security keys for highly regulated industries or elevated-privilege users. Synced passkeys are positioned as a convenient, lower-cost option for most users. For many organisations, that points to a sensible split: broad adoption with synced passkeys, and tighter controls for admin or high-risk roles. 

What passkeys do not solve

Passkeys are strong, but they are not magic fairy dust for a messy identity stack. Adoption is improving quickly, but there are still real challenges around inconsistent platform support, confusing terminology, migration between vendors, device-loss scenarios, and account recovery. Some services support synced passkeys, while others still only support device-bound ones, which can create friction for both users and developers. 

The biggest practical caveat is fallback. If you offer passkeys but still allow a weak password, a phishable SMS code or an overly permissive recovery process, attackers may simply target the weaker route instead. NCSC research says many attacks should be prevented if only passkeys are used with no weaker password or traditional MFA fallback, and its public guidance warns that attackers are likely to shift their focus to recovery and reset processes as passkeys frustrate old attack paths. 

There is also an inclusion and accessibility angle. Passkey use assumes a person has private access to an account or device and that this is not always true. Some people share devices, some do not have a personal device, and biometrics do not work equally well for everyone. The good news is that passkeys do not require biometrics, because PINs and other local unlock methods are supported too. But organisations still need to design for different user circumstances rather than assuming one perfect device per person. 

How to roll them out properly

Start with sensible use cases

A common starting point is to let existing users create a passkey after they sign in with their current method. Passkey registration is typically happening after the user signs in to the account with an existing authentication method. That approach reduces identity-proofing complexity and gives the user an immediate benefit the next time they return. 

For workforce access, choose the passkey type to match the risk. Synced passkeys can make adoption easier at scale because they work across a user’s devices and reduce re-enrolment friction. For privileged administrators, tightly controlled environments or scenarios where attestation matters, device-bound passkeys or security keys deserve serious consideration. Microsoft’s own guidance draws exactly this distinction. 

Offer passkeys as an added option before removing older methods

FIDO’s Passkey Central recommends rolling passkeys out as an additional sign-in option first, and its communications guidance recommends phased rollouts to likely early adopters so teams can gather feedback and refine the experience before wider deployment. That is good security advice and good product advice. Authentication projects succeed or fail at the point where normal users meet new wording and unfamiliar prompts. 

Design recovery and cross-device journeys properly

Recovery deserves as much attention as sign-in. The NCSC warns that attackers may pivot to recovery and reset routes, and also stresses that users need help understanding what to do if they lose a device. Passkey Central makes the same point from a UX angle, recommending education around lost-device scenarios and noting that users should ensure another device or recovery path is set up if they rely on synced passkeys. 

Cross-device sign-in matters too. Google documents a flow where a user can sign in on one device using a passkey stored on another, such as using an iPhone to authenticate on an Android device or laptop via a QR-based flow. Passkey Central also treats cross-device sign-in as a first-class design pattern. If your users move between phones, laptops and tablets, this is not a nice-to-have detail; it is part of the core experience. 

Explain passkeys like a human being

FIDO’s design guidance says organisations should associate the unfamiliar concept of passkeys with familiar experiences. That is exactly right. In practical copy, that usually means explaining passkeys as “sign in with the fingerprint, face or PIN you already use to unlock your device,” not “deploy discoverable public-key credentials via WebAuthn ceremonies.” The second sentence is technically respectable. The first one gets adopted. 

The best passkey projects treat security, UX, support, communications and recovery as one joined-up piece of work. The cryptography is already strong. The real differentiator is whether your users understand what is happening, trust it, and can recover when real life happens. 

Sources

Primary references used for this article were all official or standards-based sources:

Get in Contact