Enterprise passkeys are the strongest of the three common B2B sign-in methods against phishing, magic links are the easiest to ship but only as strong as the customer’s mailbox, and passwords are the weakest but still the method most recovery paths end up leaning on. When an enterprise customer asks for “passkey support” in a security questionnaire, they usually mean one or both of two things: synced passkeys that employees use on their own phones and laptops, and hardware security keys that the customer’s IT team issues and controls. The practical answer is to offer passkeys and to design the fallback so that it cannot bypass the passkey for privileged users such as administrators and owners, while each customer’s policy decides which method applies to their people.
What do enterprise customers mean by passkeys?
A passkey is a credential built on WebAuthn, the W3C Web Authentication standard that lets a browser create and use a public and private key pair for a specific website. The private key never leaves the user’s authenticator in readable form: it stays on a security key, or is synced end-to-end encrypted between the user’s own devices by their platform or password manager, and your server only stores the public key. That leaves no shared secret to leak from your database or to type into a fake page. The FIDO Alliance describes passkeys as FIDO credentials that replace passwords, and signing in works the same way as unlocking the device (a fingerprint, a face scan, or a PIN).
In enterprise conversations the word covers two different things, and it helps to ask which one the customer has in mind.
- Synced passkeys. The credential is stored by a platform or a password manager (iCloud Keychain, Google Password Manager, and similar) and is available on the user’s other devices. These suit employees who sign in from a personal or managed laptop and a phone, and they need no hardware purchase.
- Hardware security keys. The credential lives on a physical device, such as a YubiKey, and cannot be copied off it. Customers in regulated industries or with strict policies often require these, at least for the people who administer your product.
Questionnaires usually anchor on two primary sources. The CISA fact sheet “Implementing Phishing-Resistant MFA” names FIDO/WebAuthn and PKI-based authentication as the phishing-resistant options, and the NIST digital identity guidelines (SP 800-63B-4) define phishing resistance in a way those methods meet. The part that matters for passkeys is the assurance level: AAL2 allows synced passkeys that meet NIST’s syncable-authenticator requirements, and AAL3 requires authenticators with non-exportable keys, which rules out synced passkeys and in practice means device-bound keys, most often hardware security keys. If a customer cites a level, read it in the NIST text, since it decides whether a synced passkey is enough for them. Our post on phishing-resistant MFA goes deeper on the definitions, and what security questionnaires ask about login shows how these questions tend to be phrased.
Passkeys vs magic links vs passwords for a B2B product
The three methods differ most in what an attacker gets after tricking a user once, and in what the method assumes about the user’s email account.
| Passkey | Magic link | Password | |
|---|---|---|---|
| Phishing resistance | Strong: bound to the real site’s domain | Weak to moderate: a phishing page can ask the user to paste the link, and a forwarded link works for whoever opens it | Weak: typed secret can be captured and replayed |
| Depends on email security | No | Yes, entirely | Only for resets |
| Shared inboxes and aliases | Not affected | Problem: anyone who can read the inbox can sign in | Reset flow has the same problem |
| Contractors and external users | Works if they can register a device | Works without enrollment but ties access to a mailbox the customer may not control | Works, but adds another credential to manage |
| Breach of your database | Public keys only | Nothing reusable stored, provided tokens are single-use, short-lived, and stored hashed | Hashes can be attacked offline |
| Customer IT control | Possible with hardware keys and policy | Little | Minimum length, breached-password blocklists, forced reset on evidence of compromise |
Three points in that table matter more than the others for enterprise buyers.
Email becomes a single factor. A magic link turns the user’s mailbox into the only thing standing between an attacker and the account. If the mailbox has a weak password or weak MFA, or if the mail is forwarded to a personal address, the product inherits that weakness without the customer’s security team seeing it. For consumer products this is an acceptable trade for convenience, but enterprise security reviews often ask directly whether email alone can grant access. We looked at where this confusion tends to appear in magic links and OAuth in Better Auth.
Shared inboxes and contractors need an owner. Enterprises frequently use shared mailboxes such as a finance or support alias, and contractors often use addresses on a domain that the customer does not administer. A magic link sent to either one grants access to everyone who can read that mail, or to a person the customer cannot easily offboard. A passkey, by contrast, belongs to one person on one set of devices, which makes offboarding a matter of removing the credential or the user.
A look-alike page cannot capture a passkey, because the browser only offers it to the exact domain it was created for. With a password or a one-time code, a convincing fake page can collect what it needs and replay it. That property is why CISA and NIST both point to FIDO-based methods in their phishing-resistance guidance. Attackers still go after enrollment, recovery, and fallback paths, a pattern we describe in device-code phishing and passkey lures.
How do passkeys and passwords compare to run day to day?
The security gap between passkeys and passwords is clear from the table above, so this section is about what each costs a team that owns a B2B product.
| Area | Passkey | Password |
|---|---|---|
| User sign-in | One gesture (biometric or PIN) on a device | Typing, a password manager, or both |
| Credential stuffing | Not applicable, since credentials are unique per site | Common, because users reuse passwords |
| Support load | Lost-device and new-device recovery | Forgotten-password resets |
| Browser and device coverage | Broad on current browsers and phones, uneven on older or shared machines | Universal |
| Regulatory story | Maps to phishing-resistant MFA requirements | Needs a second factor to meet most MFA requirements |
The main cost of passkeys is recovery, because a user who loses every device has no secret to fall back on. Passwords are cheaper to support at the start and more expensive in incidents, which is why most products run both for a while.
A recent survey shows how common the mixed situation is. In the 2026 Global State of Authentication report that Yubico and Okta released on 7 October 2026, based on a Talker Research survey of 1,890 professionals at organizations of 500 or more people, 43% said they still rely on passwords at work. The authors frame the gap as operational friction and outdated onboarding defaults, which matches what most B2B teams see: the passkey option exists, but the password path is still the default one. The figures come from Yubico’s announcement of the report.
What do you still need beside passkeys?
Offering passkeys is the easy part, and most of the security work moves to the paths around them.
A fallback that cannot bypass the passkey for privileged users. Some users will be on a device that does not support passkeys, or will lose theirs. Password plus a one-time code is the common fallback, and it is phishable, so it is only tolerable for low-risk members. Administrators and owners should be barred from using it. For them the real fallback is a second passkey or a hardware key registered in advance. The same applies to an emailed code, which brings back the mailbox-as-single-factor problem.
Step-up for sensitive admin actions. Signing in with a passkey is one event, and what an application does after that deserves a separate check. Actions such as changing the billing owner, exporting user data, creating API keys, or editing SSO settings should ask for a fresh strong factor even in an active session, which limits what a stolen session cookie can do. In Keycloak this is covered in the step-up authentication guide.
Recovery as strong as the credential it replaces. Account recovery is where passkey rollouts are usually weakened. If a password reset by email can bypass the passkey, an attacker can skip the passkey entirely by taking over the mailbox. Better options are to let users register more than one passkey (a phone and a security key), to let customer admins approve recovery inside their own organization, and to require verification that an attacker cannot find online for any helpdesk-initiated reset. Adding a new authenticator to an account should itself require a recent strong sign-in.
Password rules that match current guidance. Where passwords remain, NIST SP 800-63B-4 says verifiers must not (SHALL NOT) impose composition rules or require periodic password changes. Use minimum length, breached-password blocklists, and forced reset on evidence of compromise.
An audit trail. Enterprise reviewers want to see who registered or removed a credential and when, so log those events and make them available to customer admins.
How do passkeys work with enterprise SSO and per-customer policy?
In a multi-tenant B2B product, there is rarely one correct method for everyone. One customer’s IT team may require passkeys or hardware keys for all staff. Another customer will route every employee through their own identity provider with SAML or OpenID Connect, where their IdP decides how people authenticate, and your product should not add a second prompt on top. A third customer may have no identity provider at all and just want email and a passkey for a small team.
The design that holds up is to attach the sign-in policy to the customer organization, not to the whole product. For each tenant, decide which methods are allowed, whether enterprise SSO is mandatory, and whether administrators need stronger factors than other members. Our SSO feature page, the passwordless feature page and the B2B SaaS solution page describe how that looks in practice, and the SAML decoder helps when you are debugging a customer’s assertions. For routing people to the right customer’s login, see home realm discovery with Keycloak Organizations.
If you build on Keycloak, the Organizations feature is the natural unit for this. According to the Keycloak 26.0 release notes, Organizations has been fully supported since Keycloak 26. We cover the multi-tenant model in multitenancy with Keycloak Organizations. The limit to plan around is that Keycloak’s WebAuthn and passkey policy, including authenticator attachment and acceptable AAGUIDs, is realm-wide, and authentication flows have no organization condition. The conditions available include User Role, User Attribute, User Configured, sub-flow executed, client scope and credential. A per-organization hardware-key rule therefore means mapping that organization’s members to a role, group or attribute and using Condition – User Role or User Attribute in the flow, or giving that customer a separate realm.
Where do you start with Keycloak and passkeys?
This post is the decision guide, and the implementation detail lives elsewhere. According to the Keycloak 26.4 release notes, passkeys are integrated into the login forms with both conditional and modal interfaces, and a realm administrator turns them on with the Enable Passkeys switch. For the configuration, policies, and flows, read our Keycloak passkeys and WebAuthn guide, and for wiring it into a front end, passkeys in React and Next.js.
For background on why passwordless is spreading, see why everyone is talking about passwordless authentication and FIDO2 as a passwordless option. If your trigger is the end of SMS codes at an identity provider, moving off SMS MFA to passkeys covers that path, and is Keycloak right for B2B SaaS helps with the build-or-buy question.
We run Skycloak as managed Keycloak, so everything in the guides above applies, including the need to design per-organization rules with roles, groups or attributes in your flows.
Frequently asked questions
How different are passkeys and passwords for security?
They differ a great deal. A password is a shared secret that can be typed into a fake page, guessed, reused, or cracked from a leaked database, while a passkey is a key pair bound to your domain, with only the public key stored on your side. Passwords still make sense as a low-risk fallback, but they should not be the way into an administrator account.
What is the difference between a passkey and a password in an enterprise setting?
Beyond security, the difference is control. Password policy lets a customer set minimum length, breached-password blocklists, and forced reset on evidence of compromise, while passkeys, especially on hardware keys, let their IT team decide which devices are allowed to authenticate and remove access by removing the credential.
Is a magic link more secure than a password?
A magic link removes password reuse and cracking from the picture, so it is better in those respects. It is not phishing-resistant, and it is only as strong as the mailbox that receives it, which is a concern for shared inboxes, forwarding rules, and contractor addresses.
Do synced passkeys meet enterprise requirements?
Synced passkeys often meet them, but it depends on the customer’s policy. NIST SP 800-63B-4 allows synced passkeys at AAL2 when its syncable-authenticator requirements are met and keeps AAL3 for non-exportable keys, so customers who cite AAL3 will want device-bound authenticators, usually hardware security keys, at least for administrators.
Can one customer require passkeys while another uses SAML SSO?
Yes, and a B2B product should support both. Attach the allowed methods to the customer organization, and skip your own prompts when the customer’s identity provider already handles authentication.
What happens when a user loses their passkey?
They need another registered authenticator or a recovery path that is as strong as the credential it replaces. Encourage users to register two passkeys, and avoid recovery flows where a single email link bypasses everything.