Face login: proof of person, proof of device

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.

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 captures from the webcam in front of the user instead, and it is offered to enterprise customers running on a trusted network rather than as a self-serve flow. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.

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.

SenseCrypt is biometric-blind. Enrollment creates a quantum-safe, sealed, biometric-free, disposable face token and its verifier challenge. The enrolled phone performs the live face verification. The service retains tokens and challenges alongside standard account, device, session, log and encrypted tenant signing-key records; it retains no face images or templates in this flow.

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 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.

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 the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021
• The report card is public: https://pages.nist.gov/frvt/reportcards/11/seventhsense_000.html
• 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
• Irreversibility and unlinkability, the two properties that matter for a stored biometric reference, are the ones defined in ISO/IEC 24745:2022, 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

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 needs an enrolled phone whose camera works, and the familiar escape hatch, a password another person can reset over a call, is gone.

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.