Passwordless sign-in for Salesforce

The authorization model is untouched. Role hierarchy, profiles, permission sets and sharing rules go on deciding record access exactly as your administrators configured them. Only the act of proving identity, before the org opens at all, is different.

The reason to change that particular step is the population performing it. Field sales and support staff authenticate from hotel lobbies, customer offices, airport lounges and machines belonging to somebody else, usually in a hurry and often mid-call. Those are the conditions under which a password and a verification code end up with whoever asked most convincingly.

External single sign-on has been part of Salesforce for many years, so this connection is made on the standard single sign-on screens rather than through anything deployed into the org.

Both are supported, and the choice usually follows your team's habits. Most Salesforce administrators have configured SAML 2.0 before, and picking it keeps this connection indistinguishable in shape from the ones already in production.

OpenID Connect is the stronger foundation for a new build. PKCE (RFC 7636) removes the value of an authorization code lifted in transit, and pushed authorization requests (RFC 9126) submit the request server to server instead of through the address bar. Whichever you choose, the response carries a signature and Salesforce verifies it before reading an attribute out of it.

The ceremony does not vary with the protocol. What the user sees on their phone is the same whichever envelope was selected in the console.

This is console work rather than an engineering project. Field mapping is the part that decides whether the rollout is quiet: if the identifier arriving from SenseCrypt does not correspond to what the org expects, a user will pass authentication cleanly and still arrive nowhere useful.

Keep the current login route live until one test user has completed a sign in on a real phone from beginning to end. Move a team rather than a company, and give the first group two weeks before widening the change.

1. In the SenseCrypt console, create a relying party record for the Salesforce org.
2. Collect the discovery URL for OIDC, or the metadata file for SAML 2.0.
3. Import that configuration into the Salesforce single sign-on settings.
4. Line the claims up with the Salesforce user fields, roles attribute included.
5. Point the group you are moving first at the new sign-in route.
6. Switch on SCIM 2.0 if accounts should be opened and closed automatically.
7. Enroll one test user and complete a face login before anybody else is routed.

A Salesforce org holds pipeline, pricing, contracts and the contact history of every customer relationship you have. That makes its sign-in page a standing target, and the credential in front of it the cheapest thing an attacker can buy.

Social engineering has also moved past email. In February 2024 a finance employee at the engineering firm Arup authorized transfers of roughly US$25M after a video call in which colleagues had been convincingly deepfaked. The lesson is not that video calls are unsafe; it is that a persuasive impression of a known person is now inexpensive, so any control resting on a human recognizing a face or a voice on a screen is weaker than it looks.

SenseCrypt does not make that judgment on anyone's behalf. It moves the presence check from human impression to a measured liveness test at the camera, bound to a device enrolled to a specific person, with a signed and single-purpose result at the end of it. Where an org needs a stronger statement than the absence of a secret, the passkey path adds origin binding through FIDO2/WebAuthn, and that path is the one we call phishing-resistant. Phone sign-in also combines a live face check with a key bound to the enrolled device.