Passkey

At registration the authenticator, which may be a security key, a phone or a platform module in a laptop, generates a key pair for the site’s origin and returns the public key. At sign-in the site sends a challenge, the authenticator signs it after the user gestures or presents a biometric, and the site verifies the signature against the stored public key. It is the strong form of passwordless authentication.

Two properties do the work. The server never holds a secret capable of authenticating, so a breach of the credential database yields public keys. And the signature includes the origin the browser was actually talking to, which the authenticator obtains from the browser rather than from the page. A proxy on a lookalike domain therefore receives a signature bound to the lookalike domain, which the real site rejects. That is why passkeys defeat adversary-in-the-middle phishing where a code-based second factor does not.

The fallback survives. A deployment that adds passkeys and keeps a one-time code or an approval prompt from ordinary multi-factor authentication as an alternative has not become phishing-resistant, because an attacker simply drives the user to the alternative. The security of the account equals the weakest enabled method, and on a test that is the method we use.

Account recovery is the second gap and it is harder. A user who loses their device has to be re-enrolled, and the recovery process becomes the real authentication mechanism. A help desk that re-enrols on the basis of information an attacker can research is the whole control, and social engineering the desk is cheaper than attacking the credential.

Third is the distinction between synchronised and device-bound credentials. Synchronised passkeys are copied between a user’s devices through a platform account, which is what makes them practical for consumers and means the credential inherits the security of that account. Device-bound credentials in hardware cannot be exported. For a high assurance requirement the difference is material; verify the wording of the applicable scheme before asserting compliance.

In a phishing exercise the measurable outcome is whether our proxy obtained a usable session. Against a tenant where passkeys are enforced and no weaker method remains, it does not, and the report says so with the evidence, which is a far stronger argument for the rollout than a vendor claim. Where a fallback exists we use it and report the path. This is part of how we deploy and test phishing-resistant sign-in.