SenseCrypt vs Okta

An Okta sign-in policy is assembled. A password here, a push there, a code, a security key, and conditions deciding which combination applies to whom. The expressiveness is the value on offer, and it exists only because every method remains on the shelf, available to be selected.

SenseCrypt does not assemble. There is one ceremony, and the methods behind it are transports for the same proof rather than alternatives of differing strength. Taking the password out is the point, and keeping one as a fallback would quietly put the weakest path back into the policy.

The 2023 attack on MGM Resorts shows why the fallback decides the outcome. Attackers phoned the IT helpdesk, impersonated an employee, and entered through the recovery path rather than the front door, with a reported impact of around 100 million dollars. A front door is worth what its softest reset path allows.

Ask any biometric vendor for the list rather than the reassurance. 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 is the standard that frames those properties for a protected biometric reference; ISO/IEC 30136:2018 is the one that frames how the protection is measured.

The consequence is what an incident can cost. There is no face gallery to exfiltrate, biometric-free face tokens and account records to assess in a data request, and sealed, biometric-free, disposable face tokens and account records to assess if you later change vendors. That is the work the term biometric-blind is doing in our material.

Okta brings a directory, lifecycle management, policy, device signals, and an integration catalog assembled over more than a decade. It also brings a hiring pool: administrators who have run the console somewhere else and need no training on it here. When an estate is heterogeneous and the requirements are broad, that whole surface is the product being bought, and giving it up is not a small decision.

SenseCrypt brings one method with a hard floor under it. Narrowing the surface is what raised that floor; the two are a single fact seen from opposite sides.

Protocol coverage will not separate them. Both issue standard tokens and assertions, so the switching cost sits in rollout, support and enrollment rather than in application code.

Replacing Okta is rarely proportionate to a change in sign-in method, and it is not the recommendation here. External identity providers are a standing Okta concept, registered over OIDC or SAML 2.0, and SenseCrypt registers as one of them.

Everything your team administers stays administered in Okta: the directory, the group assignments, the policy, the audit history. Applications keep pointing at the same place. Only the proof step relocates. A redirect sends the user to SenseCrypt, the face ceremony completes on the enrolled phone, a token or assertion comes back, and Okta mints the session on exactly the terms it always did.

Both sides are configured rather than installed: endpoints and metadata, a client registration, a claim mapping, and a routing rule that decides who takes the new path.

SenseCrypt is a standards-based provider first and a biometric second. An application integrates with it the way it integrates with any OIDC or SAML provider, and the face ceremony is how presence is proven inside that flow rather than a second system to keep in step.

Two limits, stated rather than implied. End-user authentication has no operator-side single sign-on session; each application sign-in is its own ceremony, and the browser session that does exist belongs to the admin console. The hash-chained tamper-evident log covers administrative actions in that console, while end-user sign-ins go to a separate read-only activity stream that is not part of the chain and has no customer-facing verification interface.

A seat costs a dollar a month and twenty is the smallest order we take. 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. Tenants and custom domains beyond the three included in every account are ten dollars per month each. Customer identity deployments meter monthly active users rather than registered accounts, and a thirty-day trial runs without a card.

• OpenID Connect and OAuth 2.0 (RFC 6749), with PKCE (RFC 7636) and pushed authorization requests (RFC 9126)
• SAML 2.0 identity provider for the applications that federate that way
• SCIM 2.0 (RFC 7644) provisioning for users and groups
• FAPI-CIBA / CIBA for backchannel initiation, where the push opens a face ceremony on the enrolled phone
• Roles and permissions in the token, a default-closed group gate at sign-in, capability checks on console routes
• Tenant isolation, with three tenants or custom domains per account included.