On this page
The problem with OTP and push
Legacy MFA was designed to prop up the password, not to retire it. The password still goes first, so it is still the thing an attacker phishes. The second factor only decides whether the attack needs one extra step, and phishing kits added that step years ago.
The result is a control that costs your users time on every sign-in and buys less than the deployment slide promised.
The password is still underneath
Whatever you bolt on top, the credential below is reusable, leakable, and the first thing an attacker tries against every other service your user touches.
A code can be relayed in real time
A proxy page collects the OTP and replays it inside its validity window. The user sees a normal login and the attacker walks away with a session.
SMS delivery is outside your control
SIM swaps, number porting and interception are carrier-side failures. Your application cannot detect them and cannot prevent them.
Prompt fatigue is a real failure mode
Users approve pushes that arrive when they expect one, so attackers time theirs to arrive then. Number matching helps and does not solve it.
What replaces the code and the tap
SenseCrypt does not add a factor beside the password. It removes the password and the code together, and puts a device-bound face ceremony where both used to be.
There is one screen and nothing on it to type. If that sounds like fewer controls, look at what an attacker now has to obtain: a specific enrolled device, plus a live face in front of its camera.
One step, not two
The user looks at the camera and is signed in. There is no first factor to get through and no second factor to wait for.
Matching runs on the device
The comparison happens on the user's own phone or laptop. The server keeps no face image and no face template, so retiring OTP does not create a biometric database to defend.
The token is single-use and patent-pending
Each face becomes one token, spent on the sign-in that produced it. There is no reusable credential in flight and nothing worth intercepting.
CIBA push starts a face ceremony, not a tap
When a backchannel request reaches the phone, the user does not approve a prompt. The device runs the same face check, so the answer cannot be given by reflex or by a thumb in a pocket.
What you get instead
The reason this is a replacement and not another MFA product is that SenseCrypt is the identity provider. Roles, tenancy, provisioning and audit come from the same system that runs the face ceremony, so there is no second console to keep in step and no drift between them.
Your applications keep the integration shape they already have.
Nothing left to phish
No password, no code, no approval tap. The attack that produced last year's incident report has no input to work with.
Authorization travels in the token
SenseCrypt computes roles and permissions and emits them in the token, and your application enforces them. SenseCrypt itself runs a default-closed group gate at sign-in and capability checks on admin console routes.
The protocol surface is standard
OIDC and OAuth 2.0 with PKCE and PAR, SAML 2.0, SCIM 2.0 and CIBA. Most of the integration code you wrote for your current provider carries over.
Sign-ins are recorded
Each authentication is written to the audit log with the user and the device. Access decisions inside your application stay yours to log.
Who it fits
This fits any team that has decided OTP and push have run out of road, and wants the sign-in itself replaced rather than reinforced. One dollar per user per month with a 20-seat minimum, and a 30-day trial that takes no card.
- Customer identity (CIAM) teams.
- Workforce single sign-on (SSO) teams.
- B2B SaaS teams with many tenants.
Frequently asked questions
Is SenseCrypt phishing-resistant?
Yes. A sign-in asks for no password and no shared code. Each sign-in binds to the device.
Does SenseCrypt store my face?
No. Face matching runs on-device. SenseCrypt stores no face image and no face template on the server.
Can SenseCrypt replace my current MFA?
Yes. It gives passwordless MFA through OIDC, OAuth 2.0, SAML 2.0, and SCIM 2.0. A user signs in by face.
What does liveness detection add?
It checks for a live face. Its liveness detection holds iBeta ISO 30107-3 certification, at Level 1 and Level 2.
Related