A password is only as safe as every place it has ever been
Every password works the same way. You know it, the service knows it (or a hashed version of it), and to prove who you are, you hand it over. That hand-over is the whole problem. A look-alike website can collect it. A proxy sitting between you and the real site can relay it. A breached database can leak it. And because people reuse passwords, a secret stolen from one service often opens several others.
Multi-factor authentication added a second secret, usually a code, but did not change the shape of the problem. A code typed into a fake page can be relayed to the real one within seconds. Microsoft documented one adversary-in-the-middle campaign in 2022 that attempted to target more than 10,000 organisations this way, stealing the session regardless of the sign-in method the victim used.
Passkeys change the shape of the problem rather than adding another layer to it. Nothing secret crosses the network, so there is nothing to intercept, relay or leak.
A private key that never moves, and a public key that is useless to a thief
When you create a passkey, your device generates two mathematically linked keys. The private key can create signatures. The public key can only check them. The private key is stored in protected hardware on your device and never leaves it. The public key goes to the service.
The relationship is deliberately one-way. Knowing the public key tells an attacker nothing useful about the private one, which is why the FIDO Alliance, Apple and Google all describe the public key as something that simply is not a secret. If a service that uses passkeys is breached, the attacker walks away with a list of public keys that cannot sign anyone in.
A password proves who you are by revealing a secret. A passkey proves who you are by using a secret it never reveals.
Each passkey is also unique to one service. There is no such thing as reusing a passkey across sites, so the familiar chain reaction of one breach unlocking many accounts has nothing to work with.
Registration: how a passkey is created
The standards call each exchange a ceremony, because it involves three parties acting in a strict order: the website (which the standards call the relying party), your browser or operating system, and an authenticator, the piece of hardware that holds the keys. Step through it below.
- The website starts. It sends a random challenge, its own identifier (the relying party ID, which is essentially its domain) and details of the account being set up.
- The browser passes it on, and adds what it can see. The request goes to the authenticator along with the origin the browser has actually loaded. The website cannot vouch for itself here; the browser does.
- The authenticator checks a person is present. A face, fingerprint or PIN. That check happens on the device and proves a human is there, not a script.
- A key pair is generated inside secure hardware. The private key is stored and permanently bound to that site's identifier. It is never shown to the browser, the operating system or the website.
- Only the public key goes back. With it comes a credential ID and, if the organisation asks for it, an attestation statement describing what kind of authenticator created the key.
- The website stores the public key. That is all it keeps. A public key can check a signature but can never produce one, so there is nothing worth stealing from this side.
Two details matter more than they first appear. The site identifier is recorded inside the authenticator at the moment the key is created, and the origin the authenticator hears about comes from the browser, not from the page. Those two facts are what the rest of passkey security is built on.
Signing in: a fresh challenge, answered with a signature
Every sign-in starts with the website generating a challenge: a block of random data that has never been used before and will never be accepted again. The WebAuthn standard asks for at least 16 random bytes. Your authenticator signs that challenge, and the website checks the signature with the public key it stored at registration.
- The website sends a challenge. A fresh block of random data, generated for this attempt only. The WebAuthn standard asks for at least 16 random bytes, which is what makes an old answer worthless next time.
- The browser adds the origin. It hands the authenticator the challenge plus the web address it has genuinely loaded. A page cannot change what the browser reports about it.
- The authenticator looks for a matching key. It only has keys bound to specific sites. If it holds one for this site, it asks for your face, fingerprint or PIN. If it does not, the ceremony simply ends.
- It signs. The authenticator signs a small structure: a hash of the site identifier, flags confirming a user was present and verified, a counter, and a hash of the browser's data containing the challenge and the origin.
- Only the signature travels back. No secret crosses the network. Anyone who copies this signature has a record of one sign-in that has already happened.
- The website checks the signature against the public key it stored. It also confirms the challenge is the one it issued and the origin is its own. Everything matches: you are in.
The signed structure is small but precise. Each field has a job:
Replay fails because the challenge is new every time. Relay fails because the origin is baked into what gets signed. Both are properties of the protocol, not of anyone's vigilance.
Why a perfect copy of a login page gets nothing
This is the property that makes passkeys phishing-resistant rather than merely harder to phish. The standards specify that a credential can only be used with the same relying party it was registered with. The browser reports the origin; the authenticator compares it with the site identifier it stored; if they do not match, there is no key to use.
Notice what is missing from that picture: any need for you to spot the fake. A traditional phishing defence asks a person to notice a subtly wrong domain under time pressure. Origin binding takes that decision away from the person entirely. It is one of the rare security controls that works just as well on your worst day as on your best.
That does not mean attackers give up, and it does not mean the person stops mattering. It means they stop trying to steal the credential and start working on everything around it. That is the subject of Parts 3 and 4.
Inside the chip: secure hardware, local biometrics
The private key is generated and used inside isolated hardware, not in ordinary memory where other software could reach it. On an iPhone or Mac that is the Secure Enclave. On Windows it is the Trusted Platform Module (TPM) that Windows Hello uses. On many Android phones it is a hardware-backed keystore. On a security key or smart card, it is the chip inside the key itself.
Your fingerprint or face is also checked on the device. The biometric never goes to the website, and in most designs never even leaves the secure hardware. What comes out is a yes or a no, followed by a signature. The website never learns which finger you used, or whether you used a PIN instead.
Secure Enclave
Face ID or Touch ID authorises use of the passkey. Apple describes the design as having no shared secrets at all.
TPM with Windows Hello
Face, fingerprint or PIN unlocks a key held by the TPM. The PIN is local to the device, not a network password.
Hardware-backed keystore
Keys protected by the device's secure hardware and unlocked with the screen lock.
The chip itself
Keys are created in the key's own secure element and, by design, cannot be exported from it.
Whether that key can ever be copied to another device is the fault line between synced and device-bound passkeys, and it is the most important choice an organisation makes when rolling them out.
Part 2 · Choosing the right kindSynced vs device-bound passkeys: how to choose for every employee→FIDO2, WebAuthn and CTAP, untangled
FIDO2 is not an encryption algorithm, and it is not a product. It is an umbrella name for two specifications that work as a pair.
- WebAuthn is a W3C web standard. It is the interface a website's code calls to ask the browser to create or use a credential. The website can only ask; it can never touch a key.
- CTAP, the Client to Authenticator Protocol, is published by the FIDO Alliance. It governs how the browser or operating system talks to an authenticator over USB, NFC or Bluetooth, including how a PIN is checked without ever being sent in the clear.
"Passkey" is the friendly name the FIDO Alliance and the major platforms adopted for a FIDO credential that can be discovered and used without typing a username. Windows Hello for Business, Face ID on an iPhone, a YubiKey on a keyring and a badge you tap on a reader are all the same idea underneath: a key pair, a challenge, a signature, bound to a site. What differs is where the key lives and how it gets to you.
There is no serious competing standard for phishing-resistant passwordless sign-in. Older approaches such as certificate-based smart cards (PIV) are also phishing-resistant and remain common in government, but the industry's direction of travel is FIDO2.
Regulators on both sides of the Atlantic, and here, point the same way
Guidance from the United States, the United Kingdom and Australia has converged on the same conclusion: phishing-resistant authentication is the target, and FIDO2 passkeys are the practical way to get there.
Describes phishing-resistant MFA as the gold standard and states that the only widely available phishing-resistant authentication is FIDO/WebAuthn. SMS and voice codes are for last resort only.
The 2025 revision of the federal digital identity guidelines defines phishing resistance and allows synced passkeys at AAL2, but not at AAL3, where keys must be non-exportable.
In April 2026 the NCSC said passkeys should be consumers' first choice of login and that they are at least as secure as the strongest password paired with two-step verification.
Requires phishing-resistant MFA from Maturity Level Two, including for users signing in to their workstations. Security keys, smart cards and Windows Hello for Business are the usual ways to meet it.
If your organisation sits under a different regime, look for the same phrase in your own framework: phishing-resistant, sometimes written as verifier impersonation resistant. It almost always means FIDO2 or certificate-based authentication.
What to take into your next security conversation
No shared secret, nothing to steal
The private key never leaves the device. The service holds only a public key, which cannot sign anyone in.
Every sign-in is unique
A fresh random challenge each time means a captured signature is a record of the past, not a way in.
Origin binding removes the judgement call
The browser reports the real address and the authenticator refuses to sign for any other. Nobody has to spot the fake.
FIDO2 is the standard, passkey is the name
WebAuthn plus CTAP. Windows Hello, Face ID, security keys and tap-on badges are all the same mechanism in different places.
Synced vs device-bound passkeys: how to choose for every employee
Passkeys close the door on stolen credentials. People still decide what happens next.
Rolling out phishing-resistant sign-in changes which behaviours matter. Click or Flick Corporate is built for that shift: phishing simulation is one part of the programme, not the whole of it.
- W3C, Web Authentication: An API for accessing Public Key Credentials, Level 3
- FIDO Alliance, Client to Authenticator Protocol (CTAP) 2.2, July 2025
- FIDO Alliance, Passkeys
- Apple, About the security of passkeys
- Google, Security of passkeys in the Google Password Manager, October 2022
- Microsoft, From cookie theft to BEC: attackers use AiTM phishing sites, July 2022
- CISA, Implementing Phishing-Resistant MFA, October 2022
- NIST, SP 800-63B-4, Authentication and Authenticator Management, 2025
- UK NCSC, Leave passwords in the past: passkeys are the future, April 2026
- ASD, Essential Eight maturity model changes, November 2023