01
What a passkey is
A passkey is a credential made of a public and private key pair rather than a memorized string. At registration the authenticator generates the pair, retains the private half, and hands the website the public half to store against the account. No secret is transmitted, and the server ends up holding nothing that would be worth stealing.
FIDO2 is the specification family underneath the friendly name. WebAuthn is the browser API a website calls; CTAP is the protocol a browser uses to reach an authenticator sitting outside it, a security key or a phone standing in for one. Passkey is the consumer-facing word for the credential those specifications produce.
The vocabulary is worth keeping straight during an evaluation, because vendors use passkey for several different things. The question that separates them is where the private key lives and what is allowed to move it.
02
How the ceremony works
At sign-in the website issues a fresh random challenge. The authenticator produces a signature over it with the private key, and the website checks that signature using the public key recorded when the credential was created. What this demonstrates is that the registered authenticator took part in this particular exchange, and the freshness of the challenge is what prevents an older exchange from being replayed into it.
A local check gates the signature: a device PIN, a fingerprint, or an operating-system face unlock. The platform performs that check and reports the outcome, so the relying party receives an assertion about it rather than evidence of it.
One key pair per relying party
The credential is scoped to a single site, so a passkey created for one service is meaningless at another. There is no reusable credential to spray across an account list.
A resident credential removes the username field
A resident passkey lets the authenticator offer the right account itself, which is why a passkey sign-in can begin with no typing at all and no account enumeration on the server.
Synced and device-bound passkeys are different products
Platform passkeys are commonly synchronized by the operating system's credential manager, which is what saves a user whose phone ends up in a river. A hardware security key does not synchronize at all. Recoverability and assurance move in opposite directions here, and that movement should be a decision rather than a discovery.
03
Why origin binding defeats phishing
Before an authenticator is permitted to sign, the browser compares the origin it is talking to against the one recorded with the credential, and that origin forms part of what ends up signed. A near-identical domain resolves to a different origin, and the authenticator simply does not answer it. Nobody is asked to spot a substituted character in a hostname, which is the task human attention has always failed.
Nothing in the exchange is transferable either. No code is displayed and no secret crosses the wire, so an adversary-in-the-middle proxy holding a pixel-perfect copy of the login page still has nothing to forward. The label depends on both properties together: origin binding and the absence of a shared secret, rather than either one alone.
04
What a passkey proves, and what it does not
What a passkey demonstrates is that a registered authenticator produced the assertion. That is a strong claim about hardware and a thin one about people. The link between the hardware and a human runs entirely through the local unlock, a platform control the relying party cannot observe, measure or audit.
For ordinary consumer sign-ins that trade is the right one, and passkeys improve on everything they replace. In front of a payout approval, a shared workstation, a regulated action or an account several family members use, the question becomes whether device possession was the fact that needed establishing.
Possession is the whole of the claim
A valid assertion establishes that the enrolled authenticator was involved. It says nothing whatsoever about whose hands were on it.
The unlock is outside your control
A device PIN can be shared, observed or extracted under pressure, and an unlocked phone can simply change hands. Each of those situations produces an assertion indistinguishable from a legitimate one.
Recovery is where the design gives way
When a device is lost, recovery usually falls back to an emailed link or a support call. That fallback is frequently the weakest element of an otherwise phishing-resistant design, and it is where determined attackers concentrate.
05
How SenseCrypt uses passkeys
SenseCrypt is built on real FIDO2/WebAuthn passkeys (ES256), used through a roaming authenticator mobile app. This is the phishing-resistant sign-in path, and the resistance comes from WebAuthn origin binding rather than from anything proprietary. The useful comparison is not passkey versus face. It is possession of hardware against presence of a person, and one ceremony settles both. Phone sign-in also combines a live face check with a key bound to the enrolled device.
The passkey establishes the device. The live face check, with liveness and matching running in the app on the enrolled phone, establishes the person. A user is enrolled from a photograph already on file, so there is no separate biometric registration step before the first sign-in.
The credential lives in the mobile app's hardware-backed key storage. Platform behavior varies by operating system version, and synchronization is a property of the platform's credential manager rather than of the identity provider, so treat any absolute claim about a passkey never leaving a phone with care, including from us.
Both approaches remove the password
Neither a passkey nor a face ceremony hands the user a secret that could be coaxed out of them, which removes the material a credential-phishing kit exists to relay.
The claims are different, and they compose
A passkey says this device signed. The face check says the enrolled person was present at that device. Requiring both is what you want in front of a high-value action.
Enrollment happens once, at the identity provider
A passkey is registered against each relying party separately. Here the person is enrolled once at the provider, which then issues standard OIDC tokens or SAML assertions to every connected application, so no per-site registration ceremony is required.
The capture is tested, not asserted
Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2 covers the capture, and it works from an ordinary 2D RGB camera, so enrollment is not restricted to phones with a depth sensor.
06
Frequently asked questions
What is a passkey in plain terms?
It is a key pair that your device creates for one website. The device keeps the private key, the website keeps the public key, and signing in means proving you hold the private key rather than typing a shared secret.
Are passkeys phishing-resistant?
Yes. The browser binds each assertion to the site origin, and a fake site has a different origin, so the authenticator does not respond. Nothing readable is displayed to the user either, so there is no shared password for a proxy to relay.
How is SenseCrypt different from a plain passkey deployment?
SenseCrypt uses real FIDO2/WebAuthn passkeys and adds a live face check on the enrolled phone. The passkey proves the device took part; the face check proves the enrolled person was there. A passkey on its own cannot distinguish the owner from anyone holding an unlocked device.
Do passkeys work on shared or public machines?
A platform passkey stored on a shared machine is a poor fit, which is why SenseCrypt uses a roaming authenticator on the user's own phone. The shared terminal holds no credential and needs no enrollment, so nothing is left behind for the next person at that keyboard.
Does a passkey deployment still need account recovery?
Yes, and it deserves as much design attention as the sign-in itself. In SenseCrypt a replacement handset is bound with a one-time PIN sent by email, copied to SMS where the account carries a mobile number. Recovery is the route attackers probe once the front door has been closed. 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.