Security & Compliance
For end-user sign-in there are no passwords, no shared secrets, and no stored biometrics: the things attackers go after aren't there. What the platform does store, it stores hashed or encrypted, so a leaked database yields nothing an attacker can present as a credential.
First principles
The breach playbook assumes a vault of secrets. Here the dump holds no passwords and no faces, only sealed face tokens and hashes.
Face matching and liveness run on the user's device. The biometric never leaves it; only a single-use token ever crosses the network.
Each sign-in is a fresh proof signed by the enrolled device and bound to a single session, so a captured proof can't be replayed or relayed.
Liveness is tested by iBeta to ISO 30107-3 Levels 1 and 2 against photo, video, and 3D-mask attacks. Every action lands on the audit trail.
What goes away
The attacks still run. They just arrive to find nothing to act on.
A fake login page only works when there is something to type into it. A factor that can't be told to anyone can't be talked out of anyone.
Users sign in without passwords, so every breached-password list is a dead end.
Prompts can't be fatigued into a tap. Approval takes a live face check, and sign-in requests are rate-limited.
No one-time codes over SMS or email, so SIM swaps and inbox takeovers find nothing in transit.
Nothing secret is ever typed; recorded keystrokes authorize nothing.
Users re-establish access by presenting their face, so there is no password-reset script for a persuasive caller to run.
Additive, not a replacement
Authentication is built from three factors, and they compound rather than compete. Passkeys are the strongest possession factor ever shipped; we're not here to argue with that. SenseCrypt adds the one factor a passkey can't carry: proof of the person.
Something you know
A password, a PIN, a recovery answer. Anything a mind can hold, an attacker can extract: phished, guessed, keylogged, or talked out of someone. The factor the industry is rightly retiring.
Something you have
A device holding a private key. Passkeys made this factor unguessable and phishing-resistant; possession has never been stronger. But it proves which device showed up, not who was holding it: any finger or face the phone has enrolled will do.
Something you are
The only factor that proves a person rather than a proxy. It used to demand a stored template, a secret nobody can rotate. SenseCrypt delivers it biometric-blind: the live face, verified on the phone the user enrolled, with nothing biometric stored anywhere.
When TLS needed quantum resistance, nobody ripped out the classical algorithm and trusted the new one alone. Browsers shipped X25519MLKEM768, a hybrid: both key exchanges run and the session keys are derived from both, so an attacker has to break both. If ML-KEM ever falls, the connection is still exactly as strong as X25519. That floor is what let the whole ecosystem move.
Running SenseCrypt alongside passkeys is the same construction, applied to authentication factors instead of key exchanges. SenseCrypt is itself passkey-like (a hardware-bound device key signs every ceremony), with the one addition a passkey can't make: the live, verified person. The floor is the passkey security you already trust; everything above it is upside. An easy decision.
Regulatory scope
Storing no biometric data materially reduces the scope of GDPR, CCPA, and BIPA obligations: there is no biometric database to govern, breach, or delete.
Due diligence
These are the questions a security review asks first, answered with mechanisms rather than assurances.
Sealed face tokens it cannot decrypt, device public keys, and hashed credentials for console passwords, client secrets, and SCIM tokens. Signing keys are encrypted at rest with a key held outside the database.
Face images and biometric templates never persist here, and end-user sign-in has no password to keep. Its one photo touchpoint is disclosed: an upload at enrollment is handled in memory, only the sealed token is persisted, and nothing reaches disk, database, or logs.
Every tenant signs with keys of its own; there is no shared, deployment-wide signing key, and a token presented across tenant lines fails signature verification. Rotation carries a grace overlap, and a tenant can keep its key non-exportable inside AWS KMS.
Each request from the phone is signed with a key generated in its secure hardware, and the server keeps only the public half. The signature covers the method, path, body hash, and a timestamp, and no signature is accepted twice.
Unknown app, unknown email, and suspended user all fail the same way, matched in shape and latency, so sign-in reveals nothing about who exists. Per-action rate limits hold across every node, and the sign-in ceremony runs stricter, abuse-tuned ceilings.
Suspend or delete a user and their device keys and refresh-token families are severed immediately; access is not left to wait out a token's lifetime. A lost phone is one revoked key, and its user re-establishes access by presenting their face.
The full security model is in the documentation, down to the request signatures and the rate-limit tables. Read the security model
Our face recognition is evaluated in the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, not "powered by" an unnamed engine. We entered in 2021 and have maintained participation through our latest submissions. iBeta tested our liveness detection to ISO 30107-3 Levels 1 and 2. None of it is self-asserted. For the quickest check, run the live demo: a real sign-in takes about a minute. See the NIST report card (seventhsense-000)


Bring your review checklist. We'll walk your team through the architecture and the evidence behind it.