Passkeys for business applications: how they work and how to roll them out

A passkey is a sign-in credential made of a public and private key pair: your application stores only the public key, and the user's device signs a fresh challenge with the private key after the user unlocks it with a fingerprint, face or PIN. Because the browser and operating system will only use a passkey on the website or app it was created for, a fake login page cannot collect anything useful, which makes passkeys resistant to phishing in a way that passwords, SMS codes and push approvals are not. For most business applications the question is no longer whether to support passkeys but how to roll them out without breaking sign-in, recovery or compliance.

This write-up is for the product, engineering and security leads who have to make that happen. It draws on the specifications and on public guidance from NIST, CISA and the UK's NCSC, not on experiments of our own.

How a passkey works

Passkeys are the consumer-friendly name for discoverable FIDO2 credentials. Two specifications do the work. The browser-facing API is the W3C's Web Authentication (WebAuthn) standard, which lets a web page ask the browser to create or use a credential. Behind the browser, the FIDO Alliance's Client to Authenticator Protocol (CTAP) lets the browser talk to an authenticator: the phone or laptop's built-in secure hardware, a password manager, or a hardware security key. The FIDO Alliance describes passkeys as a password replacement that users unlock the same way they unlock their device.

Registration and sign-in are both short exchanges between your server, the browser and the authenticator:

1. Registration. Your server generates a random challenge and sends it with the user's identifier and your relying party ID (normally your registrable domain, such as example.com). The authenticator asks the user to unlock it, creates a new key pair scoped to that relying party ID, and returns the public key, a credential ID and, optionally, an attestation statement describing the authenticator. Your server stores both against the account.
2. Sign-in. Your server sends a fresh challenge. The browser finds passkeys for your relying party ID, the user picks one and unlocks the device, and the authenticator signs the challenge together with data describing where the request came from. Your server checks the signature with the stored public key, checks that the challenge is the one it issued, and checks that the origin and relying party ID are its own.
3. Nothing reusable crosses the network. The private key never leaves the authenticator (or, for synced passkeys, leaves it only in encrypted form for the user's own sync account). A database breach exposes public keys, which are useless to an attacker.

The authenticator also reports flags with every response. User Present (UP) means someone touched or confirmed the device. User Verified (UV) means the device checked a biometric or PIN, which is what turns a passkey into a multi-factor credential: something you have, unlocked by something you are or know. The WebAuthn Level 3 specification adds two flags that matter for business policy: Backup Eligible (BE), set when the credential is created and never changed, which says whether it may be synced, and Backup State (BS), which says whether it currently is.

Why passkeys resist phishing

Most attacks that defeat multi-factor authentication trick the user into handing a secret to the wrong party: a one-time code typed into a fake page is relayed to the real site in seconds. Push approvals can be defeated by flooding the user with prompts until they tap accept. SMS codes add exposure to SIM swaps and weaknesses in the phone network itself. CISA's fact sheet on phishing-resistant MFA ranks these methods and puts FIDO/WebAuthn and PKI smart cards at the top, describing phishing-resistant MFA as the gold standard and calling FIDO/WebAuthn the only widely available phishing-resistant option.

The protection comes from origin binding. The browser, not the user, decides which site is asking, and it will only offer a passkey whose relying party ID matches the domain of the page. The signed response also includes the origin the browser saw, so even a proxy that relays traffic produces a signature your server will reject. NIST SP 800-63B-4 calls this verifier name binding and lists WebAuthn as the example; passwords, look-up codes, one-time passwords and out-of-band methods do not qualify as phishing-resistant under that guidance.

A user can be fooled by a lookalike domain. The browser cannot: it compares the page's origin with the credential's relying party ID, and a passkey for your domain simply does not appear on anyone else's.

The UK's National Cyber Security Centre reached the same conclusion from a different direction. In April 2026 it announced that it will recommend passkeys wherever a service supports them, and two-step verification where it does not, after judging that traditional MFA methods are inherently phishable and that FIDO2 credentials are as secure or more secure against common real-world attacks.

Passkeys protect the sign-in itself. An attacker who steals a session cookie, or talks a help desk into resetting the account, bypasses them entirely.

The standards and guidance that matter

For day-to-day engineering, passkeys.dev is the most useful single reference: it keeps a device support matrix, implementation guides and a list of server-side libraries by language. The FIDO Alliance's credential exchange specifications address one of the long-standing objections to synced passkeys, that users were locked into one provider's ecosystem; Apple's passkeys developer page now describes importing and exporting passkeys between password managers.

Synced versus device-bound passkeys

The single most important policy decision is which kind of passkey you accept. A synced passkey is backed up to the user's passkey provider (Apple Passwords, Google Password Manager, or a third-party manager such as 1Password or Bitwarden) and is available on every device signed in to that account. A device-bound passkey lives on one authenticator, usually a hardware security key or an authenticator app, and its private key cannot be exported.

Microsoft's Entra ID documentation puts the trade-off plainly: treat synced passkeys as phishing-resistant credentials, but with the same security posture as other unattested authenticators. That is the right mental model for business applications. Synced passkeys are a large improvement over passwords plus codes; they are not the same as a managed hardware key.

What NIST SP 800-63-4 says about synced passkeys

NIST finalised the fourth revision of its digital identity guidelines in July 2025, and SP 800-63B-4 supersedes the 2020 version of SP 800-63B. Although it is written for US federal systems, it is the most detailed public framework for authentication assurance, and regulated industries elsewhere often use it as a reference point. Four parts of it matter for passkeys.

• Phishing resistance must be on offer. At AAL2, the guideline requires verifiers to offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for their staff, contractors and partners.
• Syncable authenticators are allowed up to AAL2. The guideline introduces syncable authenticators as a named category and permits them at AAL2 provided the sync fabric encrypts the keys, private-key operations happen on the local device, access to the sync account is itself protected by multi-factor authentication, and the provider documents these protections publicly.
• AAL3 requires a non-exportable key. Syncable authenticators shall not be used at AAL3, because the private key must be exportable to sync. AAL3 means device-bound keys on hardware.
• Enterprise use carries extra expectations. For federal enterprise deployments NIST expects managed devices that prevent syncing to unauthorised fabrics, agency-controlled sync accounts and support for enterprise attestation. It also says that verifiers may use the backup flags to restrict syncable authenticators, but that public-facing applications should not base acceptance on the backup state.

The guideline also says services for the public should assume any syncable authenticator may be shared. For a customer-facing product, that argues for step-up checks on high-risk actions (changing payout details, adding an administrator, exporting data), not for refusing synced passkeys.

Platform support today

Support is broad enough that a business application can treat passkeys as a mainstream sign-in method rather than an experiment. The table summarises the passkeys.dev device support matrix at the time of writing; check it before you commit to a support policy, because it changes with every major operating system release.

Two consequences follow. Windows users without a phone or password manager are the most likely to end up with passkeys that stay on one laptop, so prompt them to register a second one. And cross-device sign-in (scanning a QR code with a phone, called hybrid transport in the specifications) fills most remaining gaps, but it needs Bluetooth on both devices and is slower than a local passkey: a fallback, not the main path.

The evidence on adoption and outcomes

The most comprehensive public data comes from the FIDO Alliance, the industry body that develops the standards and promotes passkeys, so read it as advocacy backed by member data rather than independent research. Its Passkey Index for October 2026 aggregates confidential, unweighted figures from 15 large consumer services, including Amazon, Google, Microsoft, PayPal and Shopify. Across participants that reported each figure, 90% of active accounts were eligible for passkeys, 42% of eligible accounts had one enrolled, and 36% of successful sign-ins used a passkey, up from 26% in the 2025 Index (the participant group grew from 9 to 15, so the comparison is directional).

The same FIDO Alliance report puts the passkey sign-in success rate at 93%, against 78% for passwords and traditional MFA such as SMS codes and authenticator apps, and reports passkey sign-ins as 2.8 times faster on average. All eight participants that measure phishing reported fewer successful attacks since deploying passkeys. One finding is especially useful for product teams: two participants said their sign-in flow still showed a password or code before offering the passkey, even to users who had one, and one estimated that offering the passkey first would roughly double its passkey sign-in share.

These are very large consumer services with dedicated identity teams, so a business application should expect the direction of these results, not the figures. The lesson that transfers best is the gap between enrolment and use: measure both from day one.

Rollout patterns that work

CISA's advice for phasing a migration is a sensible frame even outside government: start with the systems that already support phishing-resistant MFA and with the users whose compromise would hurt most, such as administrators and help desk staff, then widen the rollout using what the first phase taught you. For a product, the stages usually look like this.

1. Add passkeys alongside existing sign-in

Let signed-in users create a passkey from their security settings, and keep passwords and existing MFA working. This stage is about getting the server side right: challenge generation and expiry, credential storage, verification, and a settings page that lists each passkey with where it was created and when it was last used, as Google's passkey UX guidance recommends. Users must be able to rename and remove passkeys, and removing one should require a recent, strong sign-in.

2. Offer passkeys in the username field

Conditional mediation, usually called passkey autofill, shows available passkeys in the browser's autofill menu when the user focuses the username field, next to saved passwords. The page marks the field with an autocomplete value of username webauthn and starts a pending WebAuthn request with conditional mediation and an empty list of allowed credentials, so the browser can offer any passkey for your domain. Google's web.dev guide covers the details, including feature detection and cancelling the pending request if the user chooses a password. One form then serves both groups of users, which removes the need for a separate passkey button that few people notice.

3. Prompt for a passkey after a password sign-in

The best moment to create a passkey is straight after the user has proved who they are, with a short interstitial after a successful password and MFA sign-in. Browsers can now do this almost invisibly: Chrome's conditional create lets a site request a passkey with no user action when the user has just signed in with a password saved in their password manager, and Apple describes the same idea as automatic passkey upgrades. Expect these requests to fail silently when preconditions are not met, and note that the registration response reports both presence and verification flags as false, so your server must not reject it for that reason.

4. Make the passkey the default path

Once a user has a passkey, sign-in should start with it. Remember on the device that this account has a passkey, offer it first, and keep the password behind a less prominent link. This is where the enrolment-to-use gap closes.

5. Remove passwords, carefully

Going fully passwordless means removing the password from accounts that have at least two passkeys or a passkey plus a strong recovery method. Do it per account and with the user's agreement before doing it by default. Leaving an SMS code as a permanent fallback keeps the phishing risk you were trying to remove, so decide early what the fallback is and how strong it must be.

Account recovery is where deployments succeed or fail

A passkey makes the front door much harder to pick, so attackers go to the side door: the recovery process. The pattern is well documented. CISA's advisory on the Scattered Spider group, updated in July 2025, describes attackers posing as employees to persuade help desk staff to reset passwords and move MFA to devices the attackers control. If your recovery path accepts a convincing phone call or a code sent to a phone number, your effective security is that of the phone call or the phone number.

SP 800-63B-4 sets out a recovery model that works well beyond government. It requires services to allow more than one authenticator per account and encourages users to keep at least two, recognises four recovery methods (saved recovery codes, issued recovery codes sent to a registered address, trusted recovery contacts, and repeating identity proofing), and requires a notification to the user after every recovery event and every new authenticator binding.

• Encourage a second passkey. Synced passkeys already survive a lost phone; a second passkey on a different provider or a hardware key covers the loss of the whole provider account. Prompt for it after the first one is created.
• Offer saved recovery codes for high-value accounts. Generated at enrolment, high in randomness, single use, and replaced once used. Users who lose them fall back to the slower path.
• Make the slow path deliberately slow. For accounts with no remaining authenticator, re-verify identity with the evidence you collected at onboarding (a document check, a call-back to a number on file, or an approval by the customer's own administrator for business accounts), and add a waiting period before the new credential becomes active.
• Notify on every change. Email and in-app notices when a passkey is added or removed or recovery is used, with a one-click way to report that it was not the user.
• Script the help desk. Agents should never be able to bypass verification because a caller is persuasive or senior. For workforce accounts, route recovery through the identity provider's verified-identity flow and log every reset for review.
• Re-check after recovery. Treat a recovered session as lower trust for a period: limit payout changes, administrator additions and bulk exports until the user has re-established a passkey.

Enterprise considerations

Workforce deployments add requirements that consumer services can ignore. Most of them are handled by the identity provider rather than by each application, which is a strong argument for putting business applications behind single sign-on before adding passkeys app by app. CISA makes the same point: MFA for business applications can often be added through integration with enterprise identity and single sign-on systems.

• Attestation. During registration an authenticator can provide an attestation statement that proves its make and model. Entra ID warns that if attestation is not enforced it cannot guarantee any attribute of a passkey, including whether it is synced or device-bound. Enforce it for privileged groups; expect synced passkeys not to provide it.
• AAGUID allow and block lists. Each authenticator model reports a 128-bit identifier, the AAGUID. Entra ID's passkey profiles and Okta's authenticator settings both let administrators allow or block specific models, for example only approved security keys for administrators. Without enforced attestation the AAGUID is self-reported, so treat such lists as policy guidance rather than a hard control.
• Synced passkeys for staff. Decide per role. Entra ID lets administrators enable synced passkeys for some groups and require device-bound keys for others. Okta's documentation warns that blocking syncable passkeys stops some Apple devices from using its passkey authenticator at all, so test the policy on your real device fleet first.
• Shared and kiosk devices. Warehouse terminals, clinic workstations and shop tills do not suit synced passkeys tied to one person's account. Hardware security keys or phones used for cross-device sign-in let staff authenticate on a shared device without leaving credentials on it.
• Guests and contractors. Identity providers do not always support passkey registration for external guest accounts; Entra ID, for instance, lists this as a known limitation. Check before you promise contractors passwordless access.
• Compliance mapping. Map each user group to an assurance level and authenticator type, and record why. It is the document an auditor will ask for.

If you sell a multi-tenant SaaS product to businesses, larger customers will ask for these controls inside your product, or to federate sign-in to their own identity provider, which is why SSO belongs early on a B2B roadmap, as our guide to building a SaaS product explains.

Implementation notes for engineering teams

• Use a maintained library. Do not parse authenticator data and verify signatures by hand. passkeys.dev lists server libraries for most languages, such as SimpleWebAuthn for TypeScript, py_webauthn for Python and WebAuthn4J for Java.
• Choose the relying party ID once. Passkeys are bound to it permanently. Using the registrable domain (example.com) rather than a subdomain lets the same passkey work across app.example.com and login.example.com. Changing it later means every user re-registers. Native mobile apps also need the platform's association files so the app can use passkeys for your domain.
• Treat challenges as single-use secrets. Generate them randomly on the server, store them with a short expiry, bind them to the session, and invalidate them after one attempt.
• Verify everything the specification asks you to. The expected origin (including your mobile app origins), the relying party ID hash, the challenge, the signature, and the user verification flag when your policy requires it. If you request verification as preferred, check the flag and step up when it is missing.
• Do not rely on the signature counter. WebAuthn defines a counter for detecting cloned authenticators, but synced passkeys commonly report zero, so treat a counter anomaly as a signal to investigate rather than an automatic block.
• Keep provider lists in sync. When a user deletes a passkey on your side it still appears in their password manager until you tell it otherwise. The WebAuthn Signal API lets you report unknown credentials, the current list of accepted credentials and updated user details, which avoids users being offered passkeys that no longer work.
• Protect the session, not just the sign-in. Short-lived, rotated session tokens, re-authentication for sensitive actions and device-aware session revocation matter more once the password is gone, because session theft becomes the cheaper attack.
• Test on real devices. Cover iOS, Android, macOS, Windows, a third-party password manager, a hardware key and cross-device sign-in. Virtual authenticators in browser automation tools help, but do not replace real hardware.

When passkeys are not the whole answer

Passkeys are the right default for new sign-in flows, but there are cases where they should not be the first project, or not the only control.

• Legacy applications without modern identity. If an internal system only understands local passwords, adding WebAuthn to it directly is usually the wrong move. Put it behind an identity provider or access proxy that supports passkeys, or plan its modernisation; our legacy modernisation guide covers the options.
• Very small internal tools. A handful of staff on managed devices are better served by single sign-on with the organisation's existing phishing-resistant MFA than by a bespoke passkey implementation in every tool.
• Users without suitable devices. Some populations rely on old phones, shared computers or assisted access. Keep a strong, rate-limited alternative and offer hardware keys where the risk justifies the cost.
• Threats after sign-in. Malware that steals session tokens, insiders and compromised third-party integrations are untouched by passkeys. They need monitoring, least-privilege access and sound session design, which is part of a broader cybersecurity programme.

How Authect approaches passkey projects

We start with the risk model rather than the technology: which user groups exist, what an attacker gains from each kind of account, and which assurance level each needs. That decides whether synced passkeys are acceptable, where device-bound keys and attestation are required, and how recovery must work. Recovery and help desk procedures are designed alongside the sign-in flow, not after it.

Every project is led by a senior engineer, and you talk directly to the founders who build it, never a salesperson. We use AI-accelerated delivery with an engineer reviewing every line, which matters for authentication code, where a small verification mistake undoes the whole design. You own the code, infrastructure and configuration from day one. If you are planning passkeys for a customer portal, a SaaS product or internal tools, our cyber security services cover the assessment and implementation, and you can talk to us about your own case.