On this page
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.
The usual response makes it worse. Teams bolt a one-time code or a tap-to-approve prompt on top of the password, which adds a step in order to protect a secret that should not have existed. Face sign-in takes the step away instead of stacking another one on top of it.
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.
Nothing to type
The customer scans the code on your sign-in page and looks at their own phone. A look-alike page has no field to harvest, because sign-in asks for no password and no shared code.
The device in front of them needs no setup
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.
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.
So the structural fix is not a stronger secret. It is not holding one. That changes what a stolen database is worth, and it changes recovery, which is where takeover actually happens most often: a support agent can be talked into things that a cryptographic check cannot.
No password and no shared code
A SenseCrypt customer account holds neither. Credential stuffing has nothing to test against it, and a phishing page has nothing to collect.
The stored token is single use
Each sign-in spends one sealed face token and mints the next. A copy captured in transit is already dead, and the tokenization is patent-pending.
Recovery is not a conversation
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, followed by the face ceremony on the new phone.
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. List is one dollar per user per month with a 20-seat minimum, and customer identities bill as monthly active users, so an account that does not sign in that month does not bill. That is the list price and not the whole invoice: signing keys held in non-exportable KMS custody add twenty dollars per key per month, and each tenant or custom domain past the three included in every account costs ten dollars per month. The 30-day trial takes no card.
- OIDC and OAuth 2.0, with PKCE and pushed authorization requests.
- SAML 2.0 for the applications that federate that way.
- SCIM 2.0 for user and group provisioning.
- CIBA, where the backchannel push starts a device-bound face ceremony.
- Role-based access control, multi-tenant isolation, and audit logs.
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 doors end in the same place. The photo is forwarded in memory to a firewalled minting service and dropped the moment the token exists, and what the server keeps is a sealed face token: no face image and no face template.
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.
Self-signup, gated
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 once, 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.
Step-up for the moments that matter
Most customer actions deserve no friction at all. A few deserve proof: raising a limit, changing a payout account, releasing a large order. SenseCrypt exposes those as backchannel CIBA checks your application starts mid-flow, and the answer comes back as a cryptographic pass or fail instead of a code the customer read out to somebody.
The push is a face ceremony, not a tap
The enrolled phone does not ask the customer to press approve. It runs the same device-bound face check as a sign-in, so a thief holding an unlocked phone still fails.
The action is named inside the signature
What is being approved travels inside the signed device payload, where nothing in the path can edit it. The customer approves the operation you named, not a blank prompt.
Support gets a check it can trust
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.
Privacy that sells itself
Say exactly what you store, because your compliance team will ask and your customers deserve the precise answer. SenseCrypt keeps no face image and no face template. What it persists is a sealed, single-use face token that cannot be reversed into a face or linked across services, and face matching and liveness both run on the customer's own device.
That is a much smaller surface to govern, and it changes the shape of a GDPR, CCPA or BIPA conversation, because there is no gallery of faces to breach, disclose or delete. It is still not the same as saying we hold nothing derived from a face, and nobody on your team should say that on our behalf. The sealed token is persisted, and it is the honest thing to put in front of a regulator.
Liveness is certified
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.
Recognition is evaluated, not certified
Seventh Sense entered the NIST evaluation in 2021, then FRVT and later split into FRTE and FATE, and has maintained it through our latest submissions. We say evaluated on purpose, because NIST does not certify face recognition.
What the certification does 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.
What each customer sign-in method leaves for an attacker
| Method | What the customer does | What is left to steal |
|---|---|---|
| Password + OTP | Remembers, types, retrieves a code | A reusable secret plus a phishable code |
| Social login | Delegates to a big-tech account | Whatever that upstream account exposes |
| Device passkey | Unlocks a device that holds a key | The synced credential, person assumed |
| SenseCrypt face sign-in | Glances at their own phone | A sealed single-use token nobody can open |
Frequently asked questions
Does SenseCrypt store customer face images?
No. Face matching runs on-device. Patent-pending face tokenization turns a face into a sealed, single-use face token, and SenseCrypt stores no face image and no face template.
Do customers need to install an app?
Yes. Verification happens in the companion app on the customer's enrolled phone, which is the trust anchor: hardware-backed keys and app attestation on every call. The device they sign in on, such as a laptop or kiosk, needs no enrollment at all.
What happens when a customer gets a new phone?
They re-establish access by presenting the same face on the new device. There is no security-question interview and no reset email for an attacker to intercept.
Is SenseCrypt an identity-proofing or KYC service?
No. SenseCrypt authenticates the enrolled person by face login. It is not KYC, identity-proofing, or age verification.
How does face login resist phishing?
A customer enters no password and no shared code at sign-in. The proof is a live face plus a device-bound signature, so a look-alike page has nothing to capture or replay.
What does SenseCrypt cost for CIAM?
One dollar per monthly active customer, flat. A 30-day free trial needs no card.
Related