Passkeys vs passwords: why UK businesses need both for now

Passkeys vs passwords: the short answer

The short answer on passkeys vs passwords is that passkeys are safer for everyday sign-in. They cannot be reused, guessed or handed to a fake website in the way passwords can.

For most business websites, we recommend making passkeys the preferred option whilst retaining a tightly controlled password fallback during migration. Removing passwords immediately can lock out legitimate customers before support teams, recovery processes and cross-device behaviour have been properly tested.

That compromise has a security limit. An account with a password fallback is not fully phishing-resistant, because an attacker can ignore the passkey and target the weaker route. The same applies if account recovery relies on easily intercepted emails or weak identity checks.

Administrator accounts are different. Where an account can change billing details, export customer data or manage other users, mandatory passkeys or managed hardware security keys can be justified. The inconvenience is proportionate to the risk.

What a passkey login actually looks like

A typical passkey example is straightforward. A customer selects their account, confirms with their face, fingerprint or device PIN, and signs in without typing a secret into the website.

Behind that interaction is public-key authentication. The website stores a public key, which is safe to hold in its database. The corresponding private key remains protected by the customer’s device, password manager or hardware security key and is used to prove that the customer has the credential.

The private key is never disclosed to the website. A fake site also cannot request a valid response for the genuine site’s domain, which is what gives passkeys their strong resistance to phishing.

So, what is a passkey on a phone? It is a credential protected by the phone and usually available after the owner unlocks it. The phone’s face or fingerprint check happens locally; biometric information is not sent to the website.

A phone can also approve a login on another device. For example, a customer using a desktop computer may scan a QR code with their phone and approve the sign-in there. The browser and phone complete a cross-device authentication flow, often with a proximity check, without transferring a reusable password.

Google passkeys are one implementation of the same standard. Google Password Manager can store and synchronise passkeys, whilst Apple, Microsoft and dedicated credential managers provide their own storage options. The underlying website protocol remains compatible rather than belonging to one vendor.

Password vs passkey vs PIN vs password manager

These terms are often mixed together, but they describe different parts of authentication.

A password is a shared secret: the customer knows it and the website keeps information used to verify it. That model creates opportunities for phishing, reuse and offline attacks against stolen password hashes.

A PIN normally unlocks a particular device or local credential. When Windows or a phone asks for a PIN during passkey authentication, that PIN is not sent to the business website as its password.

Password managers make passwords substantially safer. They can generate unique credentials, avoid reuse and match saved logins to the correct domain. They do not, however, remove the shared-secret model underneath.

“Passkeys versus password managers” is therefore a false choice. Modern password managers can store and synchronise passkeys as well as passwords.

The main passkey advantages are phishing resistance, no reusable server-side secret and a quick sign-in experience on a familiar device. The disadvantages are less familiar recovery behaviour, inconsistent cross-device experiences and dependence on whichever device or provider holds the credential.

Why passkeys remain divisive

Discussions about passkeys vs passwords on Reddit and Hacker News tend to split along predictable lines. Supporters focus on the cryptographic protection against phishing; critics focus on account recovery, provider dependence and confusing prompts when several devices are involved. Both sides are identifying real properties of the system.

“Passkey” describes a standard, not one storage model. A credential may be:

• bound to one device;
• synchronised through a platform or credential-manager account; or
• stored on a portable hardware security key.

Losing a phone may be uneventful if its passkeys are synchronised and available on a replacement device. It can be serious if a device-bound passkey was the only credential and no recovery route exists.

Synchronisation also changes where trust sits. If a customer can recover their platform account and regain access to synchronised passkeys, that platform’s recovery process has become part of the security model. Risk has moved rather than disappeared.

Real products also have awkward edge cases. Shared computers need clear account selection and sign-out behaviour. Employees who leave must lose access independently of credentials retained on personal devices. People unable to use biometrics need device PINs or another accessible method.

Customers change from Android to iPhone, replace laptops and forget which provider holds a credential. A passkey deleted from a website may also remain listed on a device, where selecting it will produce a failed sign-in. The website cannot assume that revoking a server-side credential will tidy every provider’s interface.

These are manageable product and support problems, but they cannot be solved by adding a “Sign in with a passkey” button and considering the work finished.

The login model we recommend for business websites

We make passkey enrolment prominent after registration and successful password sign-in. We do not force every customer to enrol until recovery, accessibility and support processes have been proven with real account behaviour.

Each user should be able to register multiple passkeys. The account area should let them give each credential a recognisable name, see its recent use and revoke it independently. A customer might keep one on their phone, another in a password manager and a hardware key as a backup.

Adding or removing a passkey is a sensitive action. It should require recent authentication, trigger a notification and, where risk warrants it, request an additional step. Otherwise, somebody with a stolen authenticated session could quietly register their own credential and take over the account.

Any remaining password fallback needs its own controls:

• rate limiting and protection against automated guessing;
• screening against known breached passwords;
• appropriate multi-factor authentication;
• notifications for suspicious or material account changes; and
• stricter recovery checks than simply knowing personal information.

A product should not claim that its accounts are phishing-resistant whilst customers can still bypass passkeys through a phishable password or weak reset email.

Policies should reflect consequences. A low-risk customer account may justify a forgiving fallback during adoption. Staff, administrators and users approving sensitive actions should face stronger requirements, including mandatory passkeys, managed security keys or step-up authentication.

This risk-led approach is part of how we plan custom websites and web applications: authentication is a product system, not an isolated login screen.

How to change from passwords to passkeys safely

Changing from a password to a passkey should begin with account mapping, not interface design. Identify customer types, administrator roles, regulated or commercially sensitive data, shared accounts and every existing recovery channel.

Next, offer optional passkey enrolment to users who are already authenticated. This creates a safer path than asking an unknown visitor to establish a new credential during a reset or support interaction.

Provide controls for adding, naming and deleting passkeys. Depending on the risk model, users may also need one-time recovery codes, a second registered passkey or support-assisted recovery with documented identity checks.

Run password and passkey sign-in in parallel during migration. Measure enrolment, failed authentication, abandoned prompts, recovery requests and support contacts. Those signals show where instructions or platform behaviour are failing and when fallback rules can reasonably be tightened.

Explain what happens if a device is lost, replaced or moved to another ecosystem. Platform prompts cannot explain the website’s own fallback and recovery policy, so that responsibility remains with the product team.

For administrator accounts, migration can be more direct. Enrol multiple approved credentials, verify that backups work, remove password access and document an emergency recovery process that requires more than one trusted person where appropriate.

What developers must get right with WebAuthn

Passkeys use WebAuthn and the wider FIDO2 standards. Production implementations require HTTPS, the correct relying-party ID and strict validation of the calling origin. A mistake in those boundaries can undermine the protection the interface appears to provide.

The server must generate a cryptographically random, one-time challenge for each registration or authentication ceremony. When the browser responds, the server must verify the challenge, origin, relying-party binding, signature and required user-verification state. Challenges should expire and must not be reusable.

For each credential, the application stores its credential ID, public key and relevant metadata needed for future verification. It does not receive or store the customer’s face, fingerprint or private key.

Registration must also be bound to the intended signed-in account. Session theft and account confusion matter here: valid WebAuthn cryptography does not help if the application attaches an attacker’s passkey to the wrong user.

We use a mature WebAuthn library or established authentication provider rather than implementing cryptography from scratch. Outsourcing the protocol does not outsource decisions about recovery, enrolment, account notifications or support UX; the business still owns those.

Testing must cover registration, sign-in, cancellation, revocation and recovery across current iOS, Android, Windows and macOS devices, major browsers, cross-device QR flows and accessibility tools. It must also include lost devices, stale credentials, locked platform accounts and users with only one available device.

The decisive security boundary is rarely the polished passkey prompt. It is the least protected route through which somebody can register a new credential, reset access or persuade support to hand an account back.

If you are planning an authentication migration or a new application, talk to us about the build. We can help design the login and recovery model before it becomes expensive to change.