On this page
- What is biometric-blind face login?
- How does SenseCrypt verify the live person without storing their face?
- Why does "the match runs on the device" matter?
- What exactly is stored — and what is never stored?
- How is biometric-blind face login different from device unlock or cloud face recognition?
- Is the face recognition and liveness independently proven?
- Does biometric-blind face login resist phishing?
- Where does biometric-blind face login fit in the SenseCrypt platform?
- Frequently asked questions
What is biometric-blind face login?
Biometric-blind face login is a sign-in model where the service verifies the live person by face but is architecturally unable to see, store, or reconstruct that face — it holds only a sealed, non-reversible token. SenseCrypt calls this template-free face authentication.
The word "blind" is literal. The identity provider is blind to your biometrics: there is no face photo in a database, no embedding, no feature vector, and no template that could be stolen, matched against another database, or reversed into an image. Most legacy "face login" systems make you trade privacy for convenience — to recognize you later, they keep a copy of your face or a template derived from it. Biometric-blind face login breaks that trade-off.
You enroll from a photo on file
Enrollment starts from a photo already on file — there is no new biometric handover to a central service.
You sign in by face
At each login the face match runs on your device, not on a server that holds your biometrics.
The provider stores only a sealed token
SenseCrypt keeps only a sealed, unlinkable, non-reversible face token that contains no PII and that even Seventh Sense cannot reverse.
How does SenseCrypt verify the live person without storing their face?
SenseCrypt verifies the live person by running the face match on the device and keeping only a sealed, non-reversible token server-side — so the person is proven without the provider ever holding a face image or template. The flow separates two proofs that legacy systems tangle together, which is why the server's only job is to validate a cryptographic token and a passkey assertion. The biometric stays with the human it belongs to.
The device is proven by a passkey
A FIDO2/WebAuthn passkey (ES256) proves the device. Because the passkey is bound to the origin, the passkey path is phishing-resistant.
The person is proven by a live-face check
A live-face check performed on the device, with liveness detection, proves the person and defeats photos, videos, and masks.
Why does "the match runs on the device" matter?
Running the match on the device matters because it removes the single largest target in biometric systems — the central template database — and keeps the raw face under the user's physical control, never in transit to or at rest on the provider.
This design intent aligns with long-standing guidance in NIST SP 800-63B, which treats stored biometrics as sensitive and cautions against using a biometric as a standalone secret — exactly the risk a device-side, template-free model is built to avoid.
No honeypot to breach
There is no server-side gallery of faces or templates to exfiltrate, so a server compromise cannot leak biometrics that were never stored.
No cross-linking
A sealed, unlinkable token cannot be matched against other databases to track a person across services.
No irreversible loss
You can rotate a passkey; you cannot rotate your face. Keeping the biometric off the server means a breach cannot permanently expose the one credential you can never change.
What exactly is stored — and what is never stored?
SenseCrypt stores only a sealed, unlinkable, non-reversible face token that contains no PII and cannot be reversed, even by Seventh Sense. It stores no face image and no biometric template anywhere. The token is the whole point: it is enough to confirm "this is the same enrolled person, live, right now," and nothing more.
Never stored: face image or photo
No face image is retained server-side at any point.
Never stored: biometric template or embedding
There is no template, embedding, or feature vector to reverse, match, or leak.
Stored: sealed, non-reversible face token
Contains no PII, is not linkable across services, and cannot be reversed into an image — not even by Seventh Sense.
Stored: FIDO2/WebAuthn passkey (public key, ES256)
Proves the device and is bound to the origin. This is a standard passkey, not a biometric record.
Stored: audit logs and RBAC metadata
Standard identity-provider records for accountability and access control — not biometrics.
How is biometric-blind face login different from device unlock or cloud face recognition?
Biometric-blind face login differs by storing no template anywhere: cloud face recognition keeps templates on a server, device unlock keeps a template in the phone's secure enclave, while SenseCrypt keeps only a sealed, non-reversible token and no template at all.
One clarification matters here: SenseCrypt's passkeys are standard FIDO2/WebAuthn, so it uses device authenticators like any passkey provider. "Biometric-blind" refers to the identity provider storing no face image and no template — not to avoiding device biometrics. The differentiator axis is "does the service store a biometric template or image?", where SenseCrypt's answer is a clean no for a server-side face IdP.
Is the face recognition and liveness independently proven?
Yes — SenseCrypt's face recognition is evaluated in the NIST FRTE (Face Recognition Technology Evaluation) under Seventh Sense's own developer name (seventhsense-000) since 2021, and its liveness holds iBeta ISO 30107-3 Presentation Attack Detection certification (Levels 1 and 2). These are the two claims worth citing first, because they are independently verified rather than self-asserted — together they answer the two hard questions about any face login: does it recognize the right person accurately, and can it tell a live person from a spoof?
NIST FRTE — recognition accuracy
An ongoing, government-run evaluation of the face recognition itself, listed under Seventh Sense's own developer ID since 2021.
iBeta ISO 30107-3 (PAD) — liveness
Third-party certification (L1 and L2) that the liveness check resists presentation attacks such as printed photos, screen replays, and masks.
Does biometric-blind face login resist phishing?
The passkey path is phishing-resistant because SenseCrypt is a full FIDO2/WebAuthn identity provider and WebAuthn binds each passkey to its origin, so credentials cannot be replayed on a look-alike site. The FIDO Alliance describes origin-bound passkeys as phishing-resistant by design, and industry breach research such as the annual Verizon DBIR continues to trace a large share of breaches to stolen credentials and phishing.
Pairing a phishing-resistant passkey (proving the device) with a live-face check (proving the person) closes both the "stolen password" and "borrowed device" gaps in one step.
Where does biometric-blind face login fit in the SenseCrypt platform?
SenseCrypt is a complete, standards-based identity provider — not a bolt-on face SDK — so biometric-blind face login plugs into existing SSO, provisioning, and federation with no biometric database to run.
Standards-native
OIDC, OAuth 2.0 (with PKCE + PAR), SAML 2.0, SCIM 2.0, and CIBA, with RBAC, audit logs, and multi-tenant isolation.
Passwordless by design
Real FIDO2/WebAuthn passkeys (ES256) prove the device while the on-device live-face check proves the person — no passwords to phish or reset.
Transparent pricing
A flat $1 per user per month, with a 30-day free trial and no card required.
Biometric-blind face login vs device unlock and cloud face recognition
| Approach | Where the biometric lives | Stores a biometric template or face image? | Verifies a live person? |
|---|---|---|---|
| Cloud face recognition (legacy) | Central server database | Yes — template, and often the image | Varies |
| Device biometric unlock (platform authenticators) | On-device secure enclave | Yes — a template, held on the device | Yes, on device |
| Password + OTP | No biometric | No | No |
| SenseCrypt — template-free face authentication | On the device at match time; nothing biometric at rest server-side | No — only a sealed, non-reversible token | Yes, with certified liveness |
Frequently asked questions
Does SenseCrypt store my face or a template of it?
No. SenseCrypt stores no face image and no biometric template — only a sealed, unlinkable, non-reversible token that contains no PII and that even Seventh Sense cannot reverse.
If my face isn't stored, how does it recognize me on the next login?
The face match runs on your device against the enrolled reference, and the server only validates a sealed, non-reversible token plus your FIDO2 passkey. The provider confirms it's you without ever holding your face.
Can the stored token be reversed back into my face?
No. The token is non-reversible by design and contains no PII, so it cannot be turned into an image or matched across other databases — and Seventh Sense cannot reverse it either.
How do you know the login is a live person and not a photo or video?
SenseCrypt's liveness detection is certified to iBeta ISO 30107-3 (Presentation Attack Detection, Levels 1 and 2), and its face recognition is evaluated in NIST FRTE — independent proof of both liveness and accuracy.
Is biometric-blind face login phishing-resistant?
The passkey path is phishing-resistant: it uses standard FIDO2/WebAuthn passkeys (ES256) that are bound to the origin, so credentials cannot be replayed on a fake site. A live-face check is layered on top to prove the person.
How do we deploy it with our existing SSO?
SenseCrypt speaks OIDC, OAuth 2.0 (PKCE + PAR), SAML 2.0, SCIM 2.0, and CIBA, and integrates via standard metadata files and discovery URLs — with no biometric database for you to build or secure.
Related