SenseCrypt vs Keyless

Keyless publishes an approach built on secure multi-party computation, and describes privacy properties that follow from it. SenseCrypt takes a different route to a related goal: a sealed token derived from the face, with the comparison itself performed on the user's enrolled phone.

Both are worth reading in the vendor's own words rather than in a competitor's summary, which is why this page describes ours precisely and points you at theirs. Marketing adjectives converge in this category; the architecture does not.

The other difference is scope. Keyless is a biometric authentication technology. SenseCrypt is the identity provider around it, issuing the tokens your applications already know how to consume.

When two vendors both describe themselves as privacy-preserving, the way to separate them is to ask each for the list of what persists and to read the two lists side by side. Ours: 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. ISO/IEC 24745:2022 describes those properties for a protected biometric reference, and ISO/IEC 30136:2018 describes how they are measured.

Because the token is sealed and tenant-bound, an exfiltration of the SenseCrypt datastore must be assessed for exposed references and account records. That is the whole content of the term biometric-blind, and it is a narrower statement than it first appears.

Keyless is now part of a large enterprise identity platform, which changes what you are buying and who supports it. For an organization that already holds a Ping relationship, adding a biometric line inside an existing contract is a materially easier purchase than onboarding a new vendor, and that advantage is real regardless of the technology underneath.

What we sell is smaller and deliberately less: a single ceremony, carried from capture to issued token by one service, with the identity protocols already inside it.

Neither of those is a technical argument. They are procurement facts, and procurement facts decide more evaluations than architecture does.

If your evaluation of Keyless started before it joined Ping, part of it needs redoing. We will not guess at another company's roadmap or packaging, and you should be wary of any vendor page that does.

What is worth doing is sending one identical set of four questions to each company and reading the written replies together. Ours are set out underneath, which puts them on the record alongside anyone else's.

Seats cost a dollar a month, with twenty as the smallest order, which opens an estimate rather than settling it. Non-exportable signing keys in a managed key service are twenty dollars per key per month, and the key cannot be copied out by anyone, including us. Past the three tenants or custom domains an account already carries, each additional one is ten dollars a month, and customer identity deployments meter monthly active users.

The trial runs thirty days and takes no card. Two limits, named in advance: end-user authentication keeps no operator-side single sign-on session, so each application sign-in is its own ceremony and the only browser session in the product belongs to the admin console; and the hash-chained tamper-evident log covers administrative actions, while end-user sign-ins go to a separate read-only activity stream that is not part of that chain.

• OpenID Connect and OAuth 2.0 (RFC 6749), with PKCE (RFC 7636) and pushed authorization requests (RFC 9126)
• SAML 2.0 identity provider, and SCIM 2.0 (RFC 7644) provisioning for users and groups
• FAPI-CIBA / CIBA: a backchannel push starts a face check on the enrolled phone.
• Real FIDO2/WebAuthn passkeys (ES256) via the companion app acting as a roaming authenticator
• Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2
• Multi-tenant isolation, roles and permissions in the token, a default-closed group gate at sign-in