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.
01Conversion
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. No face images or templates are retained in the documented phone flow. Applications connect through standard identity protocols.
No password or code 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.
02Account 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. 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.
The stored token is single use
Each successful face ceremony 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 needs a fresh one-time PIN sent to the enrolled mailbox, with an SMS copy when a mobile number is on file, plus proof of the new device key; the enrolled face is still required at sign-in. If the mailbox or the original enrollment reference is unavailable, the supported administrator recovery process applies.
03Integration 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: $1/user/month, 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
A signing key held in a managed key service is $20/key/month. Keys in that custody are non-exportable. Three tenants and three custom domains are included; each additional tenant or custom domain is $10/month.
Try it without a payment card
A 30-day full-feature trial, no card required, so you can price the real integration before a budget line exists.
04Enrollment
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.
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
Binding uses the same mailbox PIN described under recovery; liveness and face capture then run on the device itself, and the PIN never appears at sign-in.
05Step-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.
Each request starts a live face check
A CIBA request reaches the enrolled person by an emailed sign-in QR and a best-effort push to the enrolled phone; either opens a live face check. The 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.
06Privacy
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 (where the tenant enables session persistence), 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. The licensed on-premises webcam method processes captures inside the customer deployment and does not add an enrolled-phone possession factor. Run it on secure terminals: unsecured terminals expose webcam capture to injection attacks, such as virtual-camera or video-stream injection. 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. Our face recognition has been evaluated in NIST FRTE under Seventh Sense's own name since 2021. 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 injection attacks such as a virtual camera or an injected video stream; those are handled by separate controls: app attestation and device checks on the phone methods, and secure terminals for the webcam method. Capture is 2D RGB, so there is no depth sensor in the story.