Nothing to remember
A returning customer has no password to recall and no reset mail to chase. The reset funnel that quietly leaks customers mid-purchase stops existing, because there is no credential that can be forgotten.
CIAM
Customer identity that verifies the person.
SenseCrypt IdPLaunchedMake customer sign-in simpler without relying on passwords. SenseCrypt verifies the customer with a live face check on their enrolled phone.
01 / Conversion
Sign-in friction is a revenue problem
Every step you put between a customer and a purchase costs you a share of that purchase. Baymard Institute’s checkout research keeps finding that roughly one in five shoppers abandons because the process is too long or too complicated, and account friction is a steady part of that number. A forgotten password at checkout is not a support ticket. It is a basket you never see again.
Phone sign-in replaces the shared sign-in secret with a live face check and a key bound to the enrolled device. The passkey method adds FIDO2/WebAuthn origin binding and live face proof for phishing resistance. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Applications connect through standard identity protocols.
Nothing to type
The customer scans the code on your sign-in page and looks at their own phone. Sign-in asks for no password and no shared code. Simple QR is not origin-bound; use the passkey path for origin-bound phishing resistance.
No enrollment on the target device
A laptop, a kiosk or a borrowed tablet only shows the code. The cryptography and the face check happen on the phone the customer already enrolled, so the same ceremony works on every surface you put a sign-in page on.
02 / Account security
Account takeover is a trust problem
Verizon’s Data Breach Investigations Report still finds stolen credentials in more than a quarter of breaches, and consumer accounts are where stuffing lists get spent. One password your customer reused elsewhere turns somebody else’s breach into your incident, and IBM’s Cost of a Data Breach research supplies the rest of the story: customer personal data is the record type most often lost.
Face sign-in removes the password from routine authentication. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Recovery and account access need their own controls.
No password and no shared code
A SenseCrypt customer account holds neither. Credential stuffing has no password to test against it. QR sign-in is not origin-bound; phishing resistance requires the passkey path.
The stored token is single use
Each sign-in spends one sealed face token and mints the next. Replay protection depends on token rotation and protocol freshness checks; transport remains protected, and the tokenization is patent-pending.
Recovery requires verified checks
There is no security-question interview for an attacker to talk their way through. Re-binding a device uses a one-time PIN sent to the enrolled mailbox, and by SMS when a mobile number is on file, plus proof of the new device key, followed by a face check against the original enrollment reference on the new phone. An unavailable mailbox or reference requires the supported administrator recovery process.
03 / Integration and pricing
A complete identity provider for your customer apps
SenseCrypt is not a widget you drop in front of your login form. It is the identity provider your applications point at, so the integration is the same OIDC or SAML work your team has done before, and the sign-in surface carries your brand, your logo and your own custom domains rather than ours.
Price it before you plan it. The list rate is the starting point and not the whole invoice; the three numbers below are the ones that decide it.
One dollar per user per month
List price, with a 20-seat minimum. Customer identities bill as monthly active users, so an account that does not sign in that month does not bill.
Key custody, tenants and domains
Signing keys held in non-exportable KMS custody add twenty dollars per key per month. Each tenant or custom domain past the three included in every account costs ten dollars per month.
Try it without a payment card
Thirty days with the full feature set, so you can price the real integration before a budget line exists.
04 / Enrollment
How customers enroll
You choose the door per application. Where you already hold a verified photo, such as a KYC file, accounts are minted from it in bulk, so coverage exists before a single customer does anything. Where you do not, customers enroll themselves and you keep control of who is admitted.
Both enrollment paths create quantum-safe, sealed, biometric-free, disposable face tokens. Administrator photo provisioning processes the photo in memory and discards it when the token is minted; mobile self-enrollment creates the token on the phone. No face images or templates are retained in the documented phone flow.
Bulk minting from a photo on file
Import the records and the tokens are minted for you. Nobody schedules an enrollment week and nobody chases the last fifteen percent of the list.
Control self-signup by email domain
Turn it on per application, land every new account in a group you scoped in advance, and restrict admissions to email domains you approve. The group gate is default-closed at sign-in rather than a filter applied afterwards.
Binding the phone
A one-time PIN proves the mailbox when binding or replacing a device, emailed and also sent by SMS when a mobile number is on file. Liveness and face capture then run on the device itself. That PIN belongs to binding and never appears at sign-in.
05 / Step-up approval
Step-up for the moments that matter
Request a fresh face check for sensitive customer actions such as changing payout details or raising a limit. SenseCrypt supports FAPI-CIBA for financial-grade backchannel authentication; your application validates the result and enforces the action.
Push requests start a live face check
The enrolled phone does not ask the customer to press approve. It runs the same device-bound face check as a sign-in, so possession of an unlocked phone alone does not satisfy the configured face check.
Verify the signed operation details
A device signature protects the fields actually signed. IdP supports FAPI 2.0 Message Signing and FAPI-CIBA for financial-grade flows; your integration must still present and validate the intended operation, amount and payee where applicable.
Verify the caller with a face check
An agent on a call can start the same request instead of reading security questions off a screen. The result is a signed answer, so nothing rests on how convincing the caller sounds.
06 / Privacy
Explain exactly what data is retained
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. The phone performs the live face check locally; the server verifies the device-signed result against its stored challenge. Licensed on-premises webcam processing stays within the customer deployment.
No face images or templates are retained in the documented phone flow. Biometric-free, disposable face tokens and related account records remain part of the privacy review.
iBeta-tested liveness. NIST-evaluated underlying ML face verification technology.
iBeta tested the liveness to ISO/IEC 30107-3 at Level 1 and Level 2. Those levels are iBeta program tiers rather than ISO grades: ISO/IEC 30107-1 holds the taxonomy, and 30107-3 specifies how presentation-attack detection is tested and reported. Face recognition entered the NIST evaluation in 2021, then FRVT and later split into FRTE and FATE, and is maintained through our latest submissions. We say evaluated on purpose, because NIST does not certify face recognition.
What the liveness tests do not cover
Level 1 and Level 2 cover presentation attacks at the camera, such as a printed photo, a screen replay or a mask. They do not cover virtual-camera or SDK injection attacks, which is a separate problem with separate defenses, and capture is 2D RGB, so there is no depth sensor in the story.