01
Adding MFA leaves the password in place
The architecture of ordinary MFA is a password with a check bolted on behind it. The password is still the object that leaks, is reused and gets phished. The second factor only decides whether an attacker needs one extra move, and phishing kits added that move years ago: the Microsoft Digital Defense Report measured 146 percent year-over-year growth in adversary-in-the-middle attacks in 2024.
Meanwhile the cost of the control is paid on every sign-in by every user, forever. That is why exception lists exist, why they keep growing, and why people learn to approve prompts without reading them.
The cost lands on every sign-in
A second factor charges time to all users in exchange for slowing one class of attack. The people who feel that cost most are the ones who sign in most often, which is rarely the population you wanted to inconvenience.
Code delivery depends on external services
SMS depends on carriers, portability and roaming. Push depends on notification services and battery settings. Neither is a dependency your team can debug when it fails at nine on a Monday morning.
Repeated prompts create approval fatigue
A prompt offering approve or deny, arriving while the user is already signing in somewhere, gets approved. Number matching narrows the window rather than removing the reflex.
You are still running password infrastructure
As long as the first factor exists, so do resets, rotation policy, hash storage, stuffing defenses and a leaked-credential program. The second factor did not remove any of that work.
02
One ceremony instead of two steps
Nothing here is added beside the password. The password goes, the code goes, and one device-bound face check occupies the space that both of them used to need.
If fewer prompts sounds like fewer controls, count what an attacker now has to assemble: that particular handset, unlocked, presenting a living face that matches the enrolled record, and on the passkey path a challenge that came from your genuine origin.
The face check gates the cryptography
The device key, and on the passkey path the FIDO2/WebAuthn passkey, is exercised only after a live match on the enrolled phone. Possession of the phone by itself produces nothing.
A single-use token replaces the reusable secret
Each sign-in consumes the sealed token it presented and leaves a successor in its place, so interception buys an attacker an object that has already been spent.
Step-up runs the camera, not a button
A FAPI-CIBA / CIBA request pushed to the phone opens the same face check as a sign-in. What is being approved is carried inside the signature itself, where nothing along the path can rewrite it, so the approver answers for a named operation rather than an anonymous prompt.
One sign-in, not a first and a second
A glance at the camera ends it. There is no first factor to clear and no message to wait on, which is why the replacement is quicker than the thing being replaced.
03
Planning the cutover
Replacement projects fail on coverage, not on cryptography. Where enrollment asks every user to complete a task, coverage stalls somewhere short of complete, the legacy sign-in stays open to serve whoever is left, and an attacker keeps using the door you meant to close.
SenseCrypt inverts the order. Where a photo already exists, in HR records, a badge system or a KYC file, tokens are created for the whole list in one operation and those people can authenticate as soon as the import finishes. Where no photo exists, self-signup is enabled for a named application, admitted only from email domains you approve, and pointed at a group that is closed until you open it.
Provisioning follows SCIM 2.0 from whatever directory you already treat as the source of truth, so the cutover does not create a second place where a joiner or a leaver has to be remembered.
Provisioning does not wait for an image
An account created before a usable photo exists waits in a pending state and comes alive at the first ceremony, so a start date is never held hostage to a missing file.
Swapping the photo does not swap the person
A replacement image produces a replacement token only if the biometrics agree that it belongs to the same individual, which closes the route that runs from a profile edit to a second way in.
Revoke access when users leave
Removing a person takes their device keys and their refresh-token families out in a single action. A suspension lands at the next token refresh, and since the provider holds no standing session for end users, nothing keeps running behind it.
04
What moves to the provider, and what does not
What makes this a replacement instead of one more MFA product is that SenseCrypt occupies the identity provider position itself. Roles, tenancy, provisioning and the ceremony all come out of a single system, which removes the second console and the quiet divergence between two records of who exists.
The authorization boundary is worth stating exactly, because it is the part buyers most often assume wrongly. Roles and permissions resolve centrally and travel inside the token or the assertion; whether an operation proceeds is decided by your application at the moment it reads them. Enforcement inside SenseCrypt is deliberately narrower than that. It amounts to two things: membership of a group, denied unless granted, tested when somebody signs in, and capability checks guarding the routes of the admin console. Nothing else is enforced there.
- OpenID Connect and OAuth 2.0 (RFC 6749), with PKCE (RFC 7636) and pushed authorization requests (RFC 9126)
- SAML 2.0 with signed assertions and a per-tenant issuer
- SCIM 2.0 (RFC 7644) for joiners, movers and leavers
- CIBA for backchannel sign-in and step-up approval
- Role-based access control, with the decision carried in the token your application validates
05
What the audit records contain
Audit questions deserve exact answers, so this is the shape of the evidence rather than a claim about it.
Changes made by administrators in the console append to a hash-chained, tamper-evident log. Authentications are kept apart from that, as a per-person record that is read only and exports as CSV, and no hash chain runs through it. Nor is there a customer-facing endpoint or screen that verifies the console chain, so nobody should sit in an audit meeting and claim you can check it yourselves.
Two records, two purposes
The console chain covers administrative change: who altered configuration, and when. The activity stream covers authentication: who signed in, when, and from which device.
Access decisions stay in your logs
Because your application enforces the permissions it receives, the record of what a user then did with them belongs to your application and not to the identity provider.
Export is CSV, at person level
Activity exports as CSV for investigators and reviewers. It is a read-only stream by design: nothing in the console edits it.
06
Frequently asked questions
Can SenseCrypt replace our existing MFA rather than sit beside it?
Yes, and replacement is the intended shape. The password and the second factor both come out, and one face ceremony on the enrolled phone takes their place. Running it alongside a password login preserves the weakness you were trying to remove, so plan the cutover application by application.
Is it phishing-resistant?
On the passkey path, yes, through FIDO2/WebAuthn origin binding. Every method removes the password and the shared code, so there is no shared password for a phishing page to collect, but origin binding belongs to the passkey path and the claim is scoped there. Phone sign-in also combines a live face check with a key bound to the enrolled device.
What replaces push approvals for high-value actions?
A FAPI-CIBA / CIBA request. It reaches the enrolled phone and starts the same face check as a sign-in, and the operation being approved sits inside the signed payload, so there is no blank prompt for a user to tap through by reflex.
What about users without a suitable phone?
They have no fallback, because there is no password kept alive underneath. Enterprise customers on a trusted customer network can discuss the webcam method with sales@seventhsense.ai. Otherwise the device question has to be settled before the cutover rather than during it. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Do we still pay for SMS?
Sign-in never sends a code. The only event that produces a one-time PIN is binding a new device, and it is delivered to the mailbox recorded on the account, plus SMS where a mobile number is held. The replacement must also prove a new device key; the account remains bound to the enrolled person through biometric-free, disposable face tokens, and the live face check is still required at sign-in.
Does authorization move to SenseCrypt as well?
Partly. The roles and permissions are worked out centrally and emitted inside the token or the assertion, but the decision to permit an operation is taken by your application when it reads them. What SenseCrypt enforces on its own account is limited to two checks: group membership at sign-in, denied unless granted, and capability guards on the routes of the admin console.