01
The modern kit does not need your password to be weak
Adversary-in-the-middle kits stopped guessing years ago. They proxy your real sign-in page, pass each prompt straight through to the user, collect whatever the user supplies, and forward it to the genuine service inside its validity window. The Microsoft Digital Defense Report recorded 146 percent year-over-year growth in that attack pattern in 2024.
Speed is what makes it work. Verizon's 2026 Data Breach Investigations Report puts the median time between opening a phishing message and clicking the link at under sixty seconds. A control that depends on the user noticing something wrong inside that window is not a control.
So the question is not which secret is strongest. It is whether the sign-in produces anything a proxy can usefully forward.
One-time codes can still be relayed
Thirty seconds of validity is an eternity to a relay. Whatever the user gives the counterfeit page is handed straight to the genuine one, and both sides see exactly what they expected to see.
A timely prompt can appear legitimate
Approval requests turn up in the middle of a sign-in the user started, which is precisely when the answer is yes without much thought. Number matching narrows the window without dissolving the reflex.
Delivery depends on the carrier
A number can be ported away, a SIM can be reassigned to somebody else, and a message can be intercepted in transit. All three happen inside a network your application can neither observe nor influence.
The password underneath is still the target
Where a second factor sits on top of a password, the password is what leaks, what gets reused, and what is tried against every other service the same person uses.
02
Origin binding protects the passkey flow
There are two honest ways to beat an adversary in the middle. Either the user hands over nothing a proxy can forward, or the proof is cryptographically tied to the site that requested it. The SenseCrypt passkey path does both.
The enrolled phone acts as a roaming FIDO2/WebAuthn authenticator. Once the live face check passes on the phone, the app produces an ES256 signature over the challenge, and WebAuthn scopes that signature to the requesting origin. A proxy operating from a look-alike domain receives a signature that names the look-alike domain, and the real service rejects it.
This is also the category that public guidance points at. CISA's phishing-resistant MFA guidance and US National Security Memorandum 10 both single out FIDO and WebAuthn authenticators, for exactly this reason.
The signature names the origin
A WebAuthn assertion is bound to the origin that asked for it. Relaying it elsewhere does not produce a valid sign-in, whatever the user believed at the time.
The face check gates the signature
The passkey is exercised only after a live one-to-one match on the enrolled phone. A phone in somebody else's hand does not sign.
Nothing is typed at any point
A relay page has no input to capture, because the ceremony asks for none. Nor is there a code that a caller on the phone can persuade somebody to read out.
One token, one sign-in, then gone
Each ceremony consumes one sealed face token and leaves a fresh one in its place, so a copy lifted from the wire refers to something that no longer works.
03
Which methods are phishing-resistant?
Vendors like to advertise phishing resistance as a property of a platform. It is a property of a protocol path, so it is worth stating exactly where ours sits and where it does not.
The QR flow removes the shared secret, which defeats credential theft, credential stuffing and the classic harvest-and-replay page. It does not carry WebAuthn origin binding. Where your threat model includes a proxy relaying a live session, enable the passkey path for those applications and write the requirement against that path. Phone sign-in also combines a live face check with a key bound to the enrolled device.
Passkeys: phishing-resistant
FIDO2/WebAuthn with ES256, bound to the origin. This is the path to select when a requirement or a questionnaire uses the words phishing-resistant.
Simple QR: no secret exists to steal
The user scans a code and completes the face check on their own phone. There is nothing to phish out of the user, which is a real property and is not the same guarantee as origin binding.
Simple Webcam: enterprise, on a trusted network This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Capture happens at the workstation camera rather than on a phone. It is offered to enterprise customers on a trusted customer network rather than self-served, through sales@seventhsense.ai.
A PIN exists at one moment in the lifecycle
Binding a new phone is the only event that produces one. It goes to the mailbox recorded on the account, and by SMS as well where a mobile number is held. Sign-in never asks for it, so no user has any reason to read one out to anybody.
04
The face check has to hold up on its own
Deleting the secret is only an improvement if the thing put in its place resists a convincing artifact at the lens and leaves no gallery of faces behind it. Those are two distinct engineering problems, and each one should be settled with evidence rather than with adjectives.
The first has been exercised by an accredited lab: SenseCrypt has liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2. The second is a question about storage, answered in full in the note below, and on the two mobile methods the comparison producing the result is performed on the user's phone and nowhere else.
Presentation attacks are tested by a lab
iBeta ran the testing under ISO/IEC 30107-3, the standard that governs how a presentation attack detection claim has to be exercised and written up. Levels 1 and 2 are tiers within the iBeta program, describing how much effort and money the attacker is assumed to spend on the artifact.
What NIST evaluation means
Face recognition is evaluated in the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021. The wording is deliberate, because NIST evaluates algorithms and certifies nothing at all.
What the service retains, stated exactly
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.
05
Where application responsibilities begin
What origin binding defends is a single instant: the one in which the user proves who they are. Everything downstream of that instant is untouched, and a vendor content to let a buyer assume otherwise is selling a gap rather than a control.
Malware already resident on a handset can act as the person holding it. A session cookie lifted from a browser after your application issued it remains a working session. Token lifetimes, refresh handling and device posture are all exactly as necessary as they were the week before.
Session handling remains yours
SenseCrypt keeps no single sign-on session for end users, so there is no provider-side session to steal. The session your application mints after the token exchange is yours to scope, bind and expire.
Revocation is fast, not automatic
Removing a user takes out their device keys and their refresh-token families together, and a suspension lands at the next token refresh.
Sign-ins are recorded, at person level
Every authentication appends to a person-level record that administrators can read and export. What a user then does inside your application stays your application's log to keep.
06
Frequently asked questions
Is SenseCrypt phishing-resistant?
On the passkey path, yes: it uses FIDO2/WebAuthn with ES256, and the signature is bound to the origin, which is what stops a relayed proof. Every method removes the password and the shared code, so there is no shared password to harvest in the sign-in flow, but origin binding belongs to the passkey path and we scope the claim to it. Phone sign-in also combines a live face check with a key bound to the enrolled device.
Is a one-time password phishing-resistant?
No. An OTP is a shared secret with a short expiry, and a proxy page can collect it and spend it comfortably inside its validity window. A SenseCrypt sign-in never asks for one.
Does the QR method stop adversary-in-the-middle attacks?
It removes the secret an attacker would harvest, which defeats credential theft and the replay of a captured credential. It does not carry WebAuthn origin binding, so where a relayed live session is in scope, use the passkey path for that application. Phone sign-in also combines a live face check with a key bound to the enrolled device.
Does this satisfy a phishing-resistant MFA requirement?
CISA's guidance and US National Security Memorandum 10 both identify FIDO and WebAuthn authenticators as the phishing-resistant category, and the SenseCrypt passkey path is a real FIDO2/WebAuthn implementation. Check the exact wording of your own requirement against the method you plan to enable.
What happens if a user's phone is stolen?
The device key signs only while the device is unlocked, and the passkey is exercised only after a live face match against the enrolled account. An administrator can deprovision the device, which severs its keys and refresh-token families together.
Do you still need a phishing awareness program?
Yes, for everything that is not authentication: invoice fraud, malicious attachments, and requests that ask a person to act rather than to sign in. What changes is that the credential itself stops being a phishable object.