01
What face login proves
Two facts are established at every phone-based sign-in. The first is that a living person, not a printed photo and not a screen angled toward the lens, put their face in front of a camera. The second is that the result was reported by the specific device that person bound during enrollment, because every call that device makes is signed by the key it created when the binding was made.
What face login does not establish is who that person is in the world. That was settled at enrollment, when your organization accepted a photo or approved a self-signup. Authentication repeats a decision you already made; it is not identity proofing, and it is neither KYC nor age verification.
The distinction is worth holding onto when you write policy around it. Face login answers whether this is the same person who enrolled. It does not answer whether that person was who they claimed to be at the time.
No sign-in secret to type or hand over
No password and no one-time code exists anywhere in the flow, so a page that copies our sign-in screen pixel for pixel still ends the visit empty-handed. There is no shared secret in the person's possession for it to ask after.
The device carries half the proof
A face by itself authenticates nothing here. The result of the check arrives over a request signed by the enrolled phone's device key, so an image scraped from a public profile has no device to be played back through.
The token records what happened
Interactive phone-based sign-ins emit an amr claim of face, mfa and pop: a fresh face match, more than one factor, and proof that the device key was used. Your application can read the ceremony rather than assume it.
One enrollment, every connected application
Register an application behind the tenant over OIDC or SAML and it inherits the enrollment your users already have. That leaves one sign-in motion to teach and one help page to maintain.
02
Three ways the face gets captured
The check itself is the same in all three methods: detection, liveness, and a match against the enrolled reference. What separates them is where the capture happens and what supplies the possession factor.
Two of the three run in an app on the user's own phone, which is where the comparison stays. The third, Simple Webcam, captures from the webcam in front of the user instead: it is the deviceless mode, with no phone involved, offered to enterprise customers rather than as a self-serve flow. 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.
Only the passkey method should be called phishing-resistant, and the reason is specific rather than promotional: WebAuthn binds each assertion to the origin that requested it, so an assertion produced for a lookalike domain is worthless against yours. Where that property is the requirement, require that method.
03
Stored data and its limits
SenseCrypt is biometric-blind. The enrolled phone performs the live face verification. 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 server-side check is deliberately dull. Inside the envelope is a secret in the sense of RFC 7636. The phone recovers it after a successful local match and reports it, and the service compares its hash against the stored challenge in constant time. That is the whole of the face verification on our side, structurally the same comparison any OAuth server makes when it checks PKCE.
Rotated on every success
The phone mints a fresh sealed token from the capture it just took and uploads it in the same signed call, and the stored token and its challenge are replaced in the transaction that authorizes the session. A recorded exchange replayed later matches nothing.
A quantum-safe, biometric-free, disposable face token
The face-token construction uses AES-256-GCM, HKDF-SHA256 and SHA-256; no proprietary primitives are used in that construction. There is no public-key assumption inside it for a future quantum computer to break.
Patent-pending face tokenization and Face PKI
Face tokenization and Face PKI are patent-pending. Face tokenization produces quantum-safe, protected, revocable and renewable tokens for face verification without retaining the face image or template.
Hybrid post-quantum TLS
Connections are protected with hybrid post-quantum TLS (X25519MLKEM768), where negotiated, to help protect traffic against future decryption; this does not make the full IdP stack post-quantum.
The enrollment photo is not kept
When an operator enrolls someone from a photo already on file, the image passes in memory through an isolated minting service and only the sealed token is persisted. It is not written to disk, to the database, or to logs.
04
Evidence and test boundaries
Independent evidence comes in two kinds here, and vendors are not always careful about which one they are showing you. A laboratory tests liveness detection against a published standard. NIST measures face recognition accuracy, publishes the result, and issues no certificate to anybody.
So the accurate word for the face recognition is NIST-evaluated. An evaluation is not a certification, and calling it one would name a document nobody could produce. When you compare vendors on this page or any other, the thing to interrogate is what a given test actually covered, not the tier or grade printed beside it.
- Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2
- Face recognition evaluated in NIST FRTE under Seventh Sense's own name since 2021
- The NIST report card is public.
- Levels 1 and 2 name tiers of the iBeta program, not grades awarded by ISO. The taxonomy lives in ISO/IEC 30107-1, and the testing and reporting requirements for presentation attack detection live in ISO/IEC 30107-3:2023
- ISO/IEC 24745:2022 defines the protection properties for a stored biometric reference, among them irreversibility, unlinkability, renewability and revocability, with ISO/IEC 30136:2018 as the framework for evaluating a template protection scheme
- The capture is a 2D RGB frame from whatever front camera the phone already has, with no depth sensor and no added hardware anywhere in the path
05
What changes when passwords are removed
Credential theft is the steady background of enterprise incidents rather than an exotic event. The 2026 Verizon Data Breach Investigations Report puts credentials in 28% of breaches, and its median time from a phishing email to a click is under 60 seconds. Microsoft's Digital Defense Report recorded 146% year-over-year growth in adversary-in-the-middle phishing in 2024, the technique that defeats one-time codes by relaying them live.
Removing the credential removes the payload. There is nothing to read out over the phone, paste into a lookalike page, or hand to a convincing caller. Help desk impersonation, the technique reported in the 2023 MGM Resorts incident with an about $100M reported impact, becomes a much harder conversation when the reset path does not end in a secret.
Two costs come with that, and both are better priced before a rollout than during one. Everybody on the two phone methods needs an enrolled phone whose camera works, with Simple Webcam as the deviceless alternative for enterprise deployments on secure terminals, and the familiar escape hatch, a password another person can reset over a call, is gone.
Remove password-reset workflows
The reset queue is the largest quiet cost of passwords. Removing the credential removes the cause of it, which is a different outcome from making the cure faster.
Recovery goes through the enrolled device
Nobody recovers an account by showing a face to a support agent. A person on a replacement handset binds it again using a one-time PIN, delivered by email and, where a mobile number is held, by SMS as well, or by proving control of the email address through the CIBA flow. The replacement must also prove a new device key; the account remains bound to the enrolled person through biometric-free, disposable face tokens, and the live face check is still required at sign-in.
How lifecycle changes affect access
Suspending a user, deleting them, or removing them from an application's groups revokes their device keys and refresh token families at once, and the next token mint or refresh fails. Applications must still enforce token expiry and end their own sessions.
Step-up requires a fresh face check
Session persistence is configurable per tenant in the IdP portal: set how long a session lasts, or don't persist sessions at all; with session persistence turned off, a second sign-in is a second face check rather than a cookie being read back. An application that needs a guaranteed recent ceremony sends max_age, and the age of the completed check is tested at the token exchange.
06
Rolling it out
Most deployments never run a capture campaign. An operator can enroll a person from a badge or HR photo already on file, and the person completes the binding the first time they open the app. Users provisioned from a directory arrive as pending shells, a profile and its group memberships with no face binding yet, which they supply themselves on first use.
The trial period is 30 days with no card required, long enough to enroll real people from real photos and follow a joiner and a leaver all the way through.
The number a rollout is usually sized on is the seat rate, and the number that decides the invoice is the seat rate plus key custody, extra tenants and extra custom domains. All four are published, so a business case can be built without a call.
Published seat pricing
$1/user/month, 20-seat minimum, which puts the smallest invoice at twenty dollars a month. Consumer deployments count monthly active users instead of every account that has ever existed.
Additional charges
A signing key held in a managed key service is $20/key/month. Three tenants and three custom domains are included; each additional tenant or custom domain is $10/month.
Create the account, then enroll the phone
Provisioning creates the account and its memberships. The person still binds a device before they can sign in, so put that step in the onboarding plan rather than in the first support ticket.
07
Compare the details
| Method | Where the face is captured and matched | Phishing-resistant | Who it is for |
|---|---|---|---|
| Simple QR | In the SenseCrypt Authenticator companion app on the enrolled phone, which also runs liveness and the match | Not the method to choose where that is the requirement | Any customer, self-serve |
| Passkeys | In a FIDO2 roaming authenticator app on the enrolled phone, with a real FIDO2/WebAuthn passkey (ES256) as the possession factor | Yes, through FIDO2/WebAuthn origin binding | Any customer, self-serve |
| Simple Webcam | Inside the customer deployment, for the licensed on-premises webcam method (deviceless: no phone is used) | No | Available to enterprise customers on secure terminals; contact sales@seventhsense.ai |
Simple QR
- Where the face is captured and matched
- In the SenseCrypt Authenticator companion app on the enrolled phone, which also runs liveness and the match
- Phishing-resistant
- Not the method to choose where that is the requirement
- Who it is for
- Any customer, self-serve
Passkeys
- Where the face is captured and matched
- In a FIDO2 roaming authenticator app on the enrolled phone, with a real FIDO2/WebAuthn passkey (ES256) as the possession factor
- Phishing-resistant
- Yes, through FIDO2/WebAuthn origin binding
- Who it is for
- Any customer, self-serve
Simple Webcam
- Where the face is captured and matched
- Inside the customer deployment, for the licensed on-premises webcam method (deviceless: no phone is used)
- Phishing-resistant
- No
- Who it is for
- Available to enterprise customers on secure terminals; contact sales@seventhsense.ai
08
Frequently asked questions
Is a face image or a biometric template stored anywhere?
No. What persists is sealed, biometric-free, disposable face tokens and their verifier challenges, plus standard account, device and log records, sessions where the tenant enables session persistence, and encrypted tenant signing keys; no face images or templates are retained in the documented phone flow. On the two phone methods the match runs on the phone, so no face crosses the network; the licensed webcam method processes captures inside the customer deployment and runs on secure terminals, because unsecured terminals expose webcam capture to injection attacks.
Which login method is phishing-resistant?
On the passkey path, yes. The possession factor there is a real FIDO2/WebAuthn passkey, and WebAuthn binds each assertion to the origin that asked for it, so an assertion harvested by a lookalike domain cannot be replayed against yours. Treat that as a property of the passkey method rather than of every method.
Does the user need their phone every time?
For the two phone methods, yes, whenever a fresh face ceremony is required; session reuse depends on the tenant's persistence setting in the IdP portal. The enrolled key and the on-device match live on the phone. The device in front of the user needs nothing, so a browser, a kiosk or a shared workstation can run a sign-in with no enrollment and no stored credential. Simple Webcam is the deviceless alternative: a webcam captures the biometric and no phone is used. It is available to enterprise customers through sales@seventhsense.ai and runs on secure terminals, because unsecured terminals expose webcam capture to injection attacks; it does not add an enrolled-phone possession factor.
Is this identity verification or KYC?
No. Face login proves that the person signing in is the person who enrolled. Whether that person was who they claimed to be is decided by whatever proofing your organization runs before it accepts an enrollment photo.
What happens when someone loses their phone?
They bind a replacement handset; a face alone recovers nothing. Replacement-device enrollment requires email verification and a new device key; the enrolled face is still required at sign-in. Email verification is a one-time PIN sent to the recorded mailbox, with an SMS copy where a mobile number is held, or the CIBA email-possession proof.
Has the liveness detection been independently tested?
Yes: liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2. Levels 1 and 2 are tiers of the iBeta program rather than grades issued by ISO, and the scope is presentation attacks such as printed photos, masks and screens. Injection through a virtual camera is a different threat and is not part of that test.