01
The operational cost of passwords
Thirty years of hardening have gone into a design that was weak at the start. Complexity rules, rotation schedules, breach monitoring, stuffing defenses and a second factor bolted on behind are all rent paid on one decision: that the proof of identity is a string a person has to remember and retype whenever something asks.
The measurements have barely moved. Verizon's 2026 Data Breach Investigations Report still finds credentials in 28 percent of breaches. That is not a training statistic. It describes a credential that works precisely as well for the person who stole it as for the person who chose it.
Removing the string closes the whole category at once, and it is the rare security change that also shortens the sign-in.
Reused passwords spread a single breach
People reuse passwords because remembering distinct ones is not realistic. A list dumped from an unrelated service gets replayed against your login, and the hit rate stays high enough to keep the practice profitable.
Users can disclose a password to the wrong site
Telling one origin from another is a machine's job. A password hands that decision to a person in a hurry, and the counterfeit page has to be convincing exactly once.
Recovery can become the weakest access path
A forgotten password sends the user into a flow that trusts a mailbox or a support agent rather than a credential. That is where attention moves as soon as the login itself gets harder.
02
Three methods, one kind of proof
SenseCrypt is a full identity provider with one kind of proof behind it: a live face check tied to a device that belongs to one person. What differs between methods is how that check reaches the screen the user is looking at.
Two of the three run inside the companion app on the user's own enrolled phone, which is where the liveness test and the one-to-one comparison happen. The third is a webcam flow for enterprise deployments. What none of them require is enrollment on the device in front of the user: a laptop browser, a kiosk or a shared desktop holds no credential and is provisioned with nothing.
Simple QR
Your sign-in page displays a code. The user scans it with the companion app, the liveness check and the face match run on their phone, and the waiting browser is released into a session when the phone answers.
Passkeys
The enrolled phone acts as a roaming FIDO2/WebAuthn authenticator and produces an ES256 signature once the face check passes. WebAuthn binds that signature to the requesting origin, which is what makes this the phishing-resistant path.
Simple Webcam
Capture runs at the workstation camera rather than on the user's phone. It is offered to enterprise customers on a trusted customer network rather than as a self-serve flow: write to sales@seventhsense.ai to discuss it.
The target device needs no enrollment
Adding a workstation means pointing a browser at a sign-in page. There is no agent to install, no key to provision, and nothing on the machine worth stealing afterwards.
03
What the server keeps
The storage question arrives early in every evaluation, so here is the precise answer rather than a comfortable one. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment.
The retained face token is quantum-safe, sealed, biometric-free and disposable. No face images or templates are retained in the documented phone flow. Tokens are tenant-bound and stored alongside the required account records.
The construction is patent-pending face tokenization, and it uses NIST 140-3 approved symmetric and hash primitives exclusively: AES-256-GCM, HKDF-SHA256 and SHA-256. No proprietary or non-approved cryptographic primitives are used in this construction. None of those rest on the hardness of factoring or discrete logarithms, which is why we call the result a quantum-safe face token. Traffic to the service runs over hybrid post-quantum TLS (X25519MLKEM768).
Irreversibility and unlinkability are the design target
ISO/IEC 24745:2022 sets out what a protected biometric reference has to achieve: irreversibility, unlinkability and renewability. The sealed token is built against that standard rather than against a marketing definition of privacy.
The enrollment photo is processed in memory
Minting runs inside a firewalled service that holds the image in memory for as long as the operation takes and releases it immediately afterwards. Nothing about that photo reaches a disk, a database or a log line.
Where capture and face verification run
On the two mobile methods, capture, liveness and comparison all run on the user's phone. The service receives the outcome of a ceremony, never the frames that produced it.
04
What your integration requires
Nothing about the face changes the shape of the integration. Your application redirects to an authorization endpoint, receives a code, exchanges it, validates a token and issues its own session, exactly as it would against any other provider.
SAML applications receive assertions signed with separate per-tenant RSA keys. OIDC federation uses classical ES256. IdP retains encrypted tenant signing keys, supports SCIM provisioning, and supports FAPI 2.0, FAPI 2.0 Message Signing and FAPI-CIBA for financial-grade flows.
- OpenID Connect and OAuth 2.0 (RFC 6749), with PKCE (RFC 7636) and pushed authorization requests (RFC 9126)
- SAML 2.0 with signed assertions, issued per tenant
- SCIM 2.0 (RFC 7644) for provisioning and deprovisioning
- CIBA for backchannel sign-in and step-up approval
- Per-tenant signing keys, optionally held as non-exportable keys in a managed key service, where the key cannot be copied out by anyone, including us
05
What changes once the password is gone
Two things normally trade against each other in authentication: how much work the sign-in costs the user, and how much work it costs an attacker. Deleting the shared secret moves both in the same direction, because one object was carrying the burden and the risk at the same time.
It also changes what a stolen database is worth. There is no hash file to crack, no reset-token table to abuse, and no dump anywhere in which your users' addresses can turn up next year.
There is nothing on the form to hand over
No secret is requested at any point in the ceremony, so a counterfeit of your login page can be rendered to the pixel and its operator has no password to collect; QR requests are not origin-bound.
How passwordless changes account support
Nobody forgets a credential that was never issued. What is left is genuine device replacement, which is both a smaller number and a far steadier one to staff against.
No idle session sits at the identity provider
SenseCrypt keeps no single sign-on session for end users, so there is no provider-side cookie to steal or ride. The session your application issues after the token exchange stays yours to scope and expire. The admin console is the exception: administrators do get an ordinary browser session there.
06
Frequently asked questions
What is passwordless login in SenseCrypt?
A sign-in that never asks for a password or a shared code. The user proves themselves with a live face check on their enrolled phone, and your application receives a standard OIDC token or SAML assertion. There is no password held behind the flow as a fallback.
Do users have to install an app?
Yes. The companion app on the user's own phone is where the face check runs and where the device key lives. The device they are signing in on, a laptop, a kiosk or a shared desktop, needs no app and holds no enrollment.
Which sign-in method is phishing-resistant?
The passkey path. It uses real FIDO2/WebAuthn passkeys with ES256, and WebAuthn ties each signature to the origin that asked for it, so a signature made for your domain is rejected everywhere else, including at a proxy that looks identical to it. That property belongs to the passkey path specifically and not to every method on the platform.
What is stored on the server?
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment. It is sealed for the intended verification flow, and it will not match the same person in a different tenant.
Can a user sign in from a laptop using its webcam?
There is a webcam method, and it is available to enterprise customers on a trusted customer network rather than as a self-serve flow. Contact sales@seventhsense.ai to discuss it. The default web experience is the QR flow, where the laptop displays a code and the face check happens on the phone. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
What does it cost?
Pricing starts at a dollar for each user in a month, against a floor of 20 seats. People outside your organization are counted only in the months they actually sign in. Evaluation runs for 30 days and asks for no card.