Quick answer: To enable passkeys in Salesforce, go to Setup → Identity Verification and turn on both “Let users verify their identity with a built-in authenticator” and “Let users verify their identity with a physical security key,” then save. Register a passkey per user from Setup → Users → open the user → Security Key (U2F or WebAuthn) → Register.
That is the short version. Below is the full guide, including the two problems admins hit most often: the Register link that never appears, and the user who lost the phone holding their only passkey.
A passkey is a cryptographic login credential stored on a user’s device instead of a password stored on a server. When a user registers one, their device creates a key pair. The private key never leaves the device. The public key is sent to Salesforce. At login, Salesforce issues a challenge, the device signs it after the user approves with a fingerprint, face scan, or device PIN, and returns the signature.
Passkeys in Salesforce are built on the FIDO2 and WebAuthn standards, the same open specifications used by Google, Apple, and Microsoft. They appear in the Salesforce UI in two forms:
| Type | What it means | Examples |
|---|---|---|
| Built-in authenticator | The platform authenticator inside the device itself | Touch ID, Face ID, Windows Hello |
| Physical security key | A separate hardware device | YubiKey, Titan Key, other FIDO2 security keys |
The registration path in Setup is the same for both.
Nothing reusable crosses the network. There is no password and no one time code for an attacker to intercept and replay.
Phishing does not work. A passkey is cryptographically bound to the domain it was registered for. A lookalike login page on a different domain cannot invoke it, because the browser refuses to release a credential registered to another origin. This is the single biggest practical difference from SMS codes or authenticator apps, both of which a user can be tricked into typing into a fake page.
Enable passkeys at the org level first, then register them per user. Doing it in the other order is why most admins find the Register link missing.
This is an org wide setting. Enabling it once applies to every user.
The Register link next to Security Key is hidden because the matching verification methods are disabled under Setup → Identity Verification. It is almost never a user permission or profile issue.
Salesforce only renders the registration path when the org actually permits that method. If both the built-in authenticator and physical security key checkboxes are off, there is nothing for the user to register, so the link is greyed out or absent entirely.
The fix:
The Register link will now be live, and it will be live for every user in the org, not only the one you were troubleshooting.
If the link is still missing after saving, confirm you are looking at the Security Key (U2F or WebAuthn) row specifically. It sits directly below the two App Registration rows and above Lightning Login, and it is easy to confuse with them.
Generate a temporary verification code from the user’s record in Setup. This is Salesforce’s supported recovery path and does not require resetting the user’s password or deleting their existing passkey.
Salesforce displays the code and its expiry timestamp.
Deliver it through a channel you trust. A phone call to a number already on file is safer than a chat message or email, because this code bypasses the passkey entirely. Verify who you are speaking to before you read it out.
Two properties matter:
The user logs in with their username and password as normal. Where the passkey prompt would appear, Salesforce instead asks for the temporary code from their admin. They paste it, click Verify, and they are in. Their existing passkey stays registered for when the device comes back.
Use the Built-in Authenticators related list on the user record. It sits in the row of related list links across the top of the detail page, an area most admins scroll straight past.
| Action | What it does | When to use it |
|---|---|---|
| Edit | Renames the authenticator | When a user has several and you need to tell them apart |
| Del | Revokes the passkey immediately | Offboarding, lost device, suspected compromise |
| Add | Registers an additional passkey | Giving a user a second device |
Yes, and they should. Click Add on the Built-in Authenticators list. Salesforce requires identity verification before adding one, and because a passkey already exists, it uses that: the browser offers the saved passkey, you click Continue, and the Create a Passkey screen appears with a Passkeys section listing what is already registered. That section is your confirmation you are adding rather than replacing.
Two passkeys per user, typically one on a laptop and one on a phone, costs about two minutes per person and meaningfully reduces lockout tickets. Losing one device no longer means losing access.
Knowing the end user view matters, because that is what generates support tickets.
When a passkey is required, the user enters their username and password as usual. Instead of the home page, they land on a screen stating that their account requires a passkey for enhanced security. There is no skip option. Until they enroll, they cannot proceed.
The screen offers a single Create Passkey button. Clicking it hands control to the browser, which asks where to save the credential. Choosing a phone produces a QR code. Scanning it pairs the devices over Bluetooth, the passkey is created on the phone, and a fingerprint approval completes the process. Salesforce then drops the user into the org.
From then on, subsequent logins either skip the password entirely, if passwordless login is enabled, or use the passkey as the verification step after the password.
Test in a sandbox first. The Identity Verification page controls several methods at once, and it is easy to change more than you intended. Run the full enrollment and recovery flow before touching production.
Decide on passwordless before you announce. Whether you enable “Allow passwordless login with passkeys” changes the user experience significantly. Communicate one story, not two.
Enroll two passkeys per user. One laptop, one phone.
Brief your help desk. Whoever answers the phone needs to know how to verify a caller’s identity, how to generate a temporary code, and to expire it afterwards.
Review this alongside your MFA policy, not instead of it. A passkey satisfies the identity verification step, but your MFA requirement, session security levels, and login IP ranges still govern the org’s overall posture.
Document who can generate temporary codes. This capability bypasses the passkey. Treat it like a spare key to the building.
Moving an org to passwordless authentication touches user management, security policy, and help desk process at the same time. Cloudespacio is a Salesforce partner working with orgs of every size on security, administration, and custom development.
Talk to our team about your passkey rollout
Watch the full video walkthrough: Salesforce Passkeys: Login Without a Password
Because the built-in authenticator and physical security key verification methods are disabled at the org level. Enable both under Setup → Identity Verification, save, then refresh the user record.
Turn on both passkey verification methods under Setup → Identity Verification, save, then register a passkey per user from Setup → Users → the user record → Security Key (U2F or WebAuthn) → Register.
On the device or password manager the user selected during creation. It is not stored in the browser session or on Salesforce servers. Salesforce holds only the public key.
A passkey satisfies the identity verification step, so users are not prompted for a separate code. Your org’s MFA requirement and related security policies still apply and should be reviewed as part of the rollout.
Yes. Use the Add button on the Built-in Authenticators related list on the user record. Two is a sensible default, one per device.
Generate a temporary verification code so they can log in, revoke the old authenticator with Del on the Built-in Authenticators list, and have them register a new passkey on their replacement device.
Not in the way passwords and one time codes can. A passkey is cryptographically bound to the domain it was registered for, so a lookalike login page cannot invoke it.
Yes. It remains valid for repeated use until its expiry time. Use the shortest practical window and click Expire Now once the user is back in.
Cloudespacio is a trusted Salesforce implementation partner headquartered in India, helping businesses transform sales, service, manufacturing, automotive, and customer operations with Salesforce.
Copyright © 2025 All Rights Reserved. Designed by Navpatra.
