Keep your passkeys. Add the person

A passkey is an asymmetric key pair. The relying party is handed the public half and never sees the private half, so there is no shared secret to phish and nothing in the relying party's store a thief could reuse. Signatures are scoped to the origin that requested them, which is why a look-alike domain collects nothing usable. Credential stuffing and bulk phishing both need a reusable secret to exist somewhere, and neither survives that, which is the reasoning behind CISA's guidance on phishing-resistant MFA.

So the argument here begins where most vendor material will not. A passkey is a finished answer to the question it was built for, and the discussion worth having concerns how narrow that question turns out to be once the ceremony is stripped away and only the assertion remains.

None of the situations below is a flaw in the design. Each is the design working exactly as specified, because what the specification undertakes to verify is possession of an unlocked device and nothing past it. A gap opens only when an organization needs an answer to a different question, which is whether the account owner is present at this moment.

The core of it is composition rather than replacement. The TLS ecosystem faced a comparable decision and declined to choose between a proven key exchange and a newer one, shipping hybrid post-quantum TLS (X25519MLKEM768) so that a session inherits the strength of whichever half survives scrutiny. The paper applies the same reasoning inside a single sign-in, where hardware-backed possession is the floor and verification of the live person rides on top of it.

The person factor is a live face check on the enrolled phone, combined with a key bound to that device. The passkey method adds FIDO2/WebAuthn origin binding and live face proof for phishing resistance. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges, plus account, device, session, log and encrypted tenant signing-key records. No face images or templates are retained in the documented phone flow.

There is also a test that most multi-factor claims fail, which is whether the two factors can fail together. A code sent to the device already holding the session does not add a second factor; it adds a second step to the first one. The paper is exact about what independence has to mean before the word earns its place in a design document.

1. Three situations in which possession quietly stops standing in for the person, and the attack that lives inside each
2. How the ceremony establishes a live person without any face image or template ever being persisted
3. What independence between two factors has to mean, and the single question most multi-factor designs fail
4. The hybrid argument set out in full, taking its lead from how the TLS ecosystem approached post-quantum key exchange
5. A mechanism-by-mechanism comparison: what each one actually proves, and what is still exposed once it has
6. What becomes of a deployed passkey estate during adoption, and the point at which running both paths stops paying

Written for identity architects with passkeys already in production, or approved and about to be, who now want the assumption made at the moment of sign-in stated out loud. Of the seven, this is the one to open first if only one is going to be read.

Three sign-in methods sit behind the argument and they are not interchangeable, so the paper is careful about which property belongs to which. On the QR method the user scans a code shown by the sign-in page and completes the face scan in the companion app, with liveness and matching running on their own phone. The passkey method issues real FIDO2 and WebAuthn passkeys (ES256) through a roaming authenticator app, and that is the phishing-resistant path, by way of WebAuthn origin binding. A webcam method is available to enterprise customers on a trusted network, arranged through sales@seventhsense.ai rather than offered self-serve, and it matches from a webcam rather than from the user's phone. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor. Phone sign-in also combines a live face check with a key bound to the enrolled device.

Seven pages. Two diagrams, and a table setting the factors side by side. The security argument is self-contained, and the deployment material sits at the end for readers who have already accepted the premise and want to know what adoption looks like.

The PDF is hosted on sensecrypt.com behind a request form, and a copy is available on request if a form is not convenient. The quickest way to test the argument is not to read it twice: complete one ceremony and look at what the server is left holding afterward.