On this page
What this integration does
Salesforce keeps your profiles, permission sets and sharing rules. None of that moves. What changes is how a user proves who they are before Salesforce lets them in: instead of a password and a verification code, Salesforce hands the user to SenseCrypt and the user looks at the camera.
There is no AppExchange package to install. Salesforce has supported external single sign-on for years, and this is a standard federation configured on those screens.
Salesforce stays the system of record
Profiles, permission sets and record access rules are untouched. Federation changes the sign in, not the authorization model inside your org.
SenseCrypt proves the person
Salesforce sends the user to SenseCrypt, the face ceremony runs on their enrolled device, and Salesforce receives a signed assertion or token naming the enrolled user.
Aimed at the users who are hardest to protect
Sales and service teams sign in from airports, customer sites and borrowed machines. Those are exactly the conditions where a password and a verification code get handed to the wrong person.
Staff and customers on one platform
The same federation covers internal users and customer-facing logins. Customer identities bill as monthly active users rather than as seats, so a dormant account costs nothing that month.
Choose SAML 2.0 or OIDC
Salesforce speaks both. SAML 2.0 is the well-trodden path for Salesforce single sign-on and most admins have done it before, so pick it if you want this connection to look like the ones you already run. OIDC is the better foundation for anything new, because PKCE binds the authorization code to the client that started the flow and pushed authorization requests keep the request parameters out of the browser.
Whichever you pick, SenseCrypt signs what it returns and Salesforce validates that signature before it trusts a single attribute inside.
SAML 2.0: exchange metadata
SenseCrypt publishes IdP metadata with the sign in URL and signing certificate. Salesforce imports it in its single sign-on settings and hands its own metadata back.
OIDC: one discovery URL
Salesforce reads the SenseCrypt discovery document and takes the endpoints and signing keys from it, which leaves you less certificate handling to remember at renewal time.
The face never leaves the device
Matching runs on the user's own phone. What travels is a single-use face token, and the tokenization is patent-pending. The server keeps no face image and no face template.
Attributes decide what users see
SenseCrypt emits roles and permissions and you map them onto the Salesforce fields your org already keys off. Salesforce enforces them exactly as it does today.
How you set it up
This is admin work in two consoles, not a development project. The step that decides whether it goes smoothly is field mapping: the identifier SenseCrypt sends has to match what your org expects, or a user will authenticate successfully and still land nowhere.
Leave your existing login route enabled until a test user has signed in end to end with a real phone. Do not move everyone at once.
- Register Salesforce as a relying party in the SenseCrypt console.
- Copy the SenseCrypt discovery URL, or download the SAML 2.0 metadata file.
- Add SenseCrypt in the Salesforce single sign-on settings.
- Map the SenseCrypt claims onto the Salesforce user fields.
- Make SenseCrypt the sign in option for the users you are moving.
- Turn on SCIM 2.0 if you want users and groups provisioned automatically.
- Enroll a test user and run one face login end to end.
What you get
A Salesforce org holds pipeline, contracts and customer records, which makes its login page a standing target. Take away the password and the one-time code and a phishing campaign has no payload left: nothing for a fake page to collect, nothing for a caller to talk a rep into reading out.
What you keep is everything Salesforce already does with permissions and audit.
No secret to steal at sign in
Users type nothing and read nothing out. The face token is spent on use, so an intercepted copy is worth nothing to whoever holds it.
Liveness is certified, recognition is evaluated
Liveness holds iBeta ISO 30107-3 certification at Level 1 and Level 2, which covers presentation attacks at the camera such as a printed photo or a mask. Face recognition entered the NIST evaluation in 2021, then FRVT and later split into FRTE and FATE, and we maintain it through our latest submissions.
Workforce and customer identity together
One directory, one set of roles and one audit trail cover staff single sign-on and customer-facing sign in, with multi-tenant isolation between them.
What it costs
One dollar per user per month with a 20-seat minimum, and customer identities bill as monthly active users. KMS signing-key custody adds twenty dollars per key per month, and each tenant or custom domain past the first three is ten dollars per month. The 30-day trial takes no card.
Frequently asked questions
Does SenseCrypt have a Salesforce AppExchange connector?
No. SenseCrypt connects to Salesforce through open standards only. You use SAML 2.0 or OIDC with metadata and a discovery URL.
Where does SenseCrypt store biometric data?
SenseCrypt keeps no face image and no face template on the server. Face matching runs on-device. SenseCrypt uses patent-pending face tokenization. A face becomes a single-use face token.
Does SenseCrypt do KYC or identity proofing?
No. SenseCrypt authenticates the enrolled person. It signs in the user who enrolled from a photo on file.
Can SenseCrypt provision Salesforce users?
Yes. SenseCrypt supports SCIM 2.0. You can sync users and groups with Salesforce.
Related