Seventh Sense
Features

SenseCrypt
Technical library

Authentication

Face login: proof of person, proof of device

Phone sign-in combines a live face check with a key bound to the enrolled device. The passkey method adds FIDO2/WebAuthn origin binding, which is what makes it phishing-resistant, alongside a separate live face proof.

8 sectionsSeventh Sense / SenseCrypt
On this page

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

The three login methods
MethodWhere the face is captured and matchedPhishing-resistantWho it is for
Simple QRIn the SenseCrypt Authenticator companion app on the enrolled phone, which also runs liveness and the matchNot the method to choose where that is the requirementAny customer, self-serve
PasskeysIn a FIDO2 roaming authenticator app on the enrolled phone, with a real FIDO2/WebAuthn passkey (ES256) as the possession factorYes, through FIDO2/WebAuthn origin bindingAny customer, self-serve
Simple WebcamInside the customer deployment, for the licensed on-premises webcam method (deviceless: no phone is used)NoAvailable 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.

Next step

The next level of detail depends on your stack, so the fastest route is a conversation.