A passkey is not a password you cannot see. It is a pair of keys. The private key stays on your phone, laptop or security key and never leaves it. The public key goes to the service you are signing in to, and a public key is not a secret. When you sign in, the service sends a fresh random challenge, your device signs it with the private key, and the service checks the signature against the public key it already holds. Nothing reusable crosses the network, and nothing reusable sits in the service's database.
The word "passkey" is a product term, not a technical one. The standard underneath it is the W3C Web Authentication specification, usually shortened to WebAuthn, which defines the interface between a website and your browser. The FIDO Alliance publishes the companion protocol that lets your browser talk to an external authenticator such as a USB security key. The two together are marketed as FIDO2. WebAuthn Level 3 became a formal W3C Recommendation on 25 August 2026. Worth noting for anyone who reads the specification: it lists "passkey" as a deprecated term. In specification language a passkey is a discoverable credential, which simply means the credential can be found by your device without you typing a username first.
What the service stores is the interesting part. The specification lists the recommended fields in a server's credential record: the credential type, the credential identifier, the public key, a signature counter, the transports the authenticator supports, and three flags recording whether user verification was set up, whether the credential is eligible for backup, and whether it is currently backed up. There is no password, no password hash and no shared secret anywhere in that list. If the service is breached, the attacker gets a list of public keys. Compare that to plaintext, hashed and salted passwords, where the whole question is how long the stolen hashes hold out against cracking. With passkeys the question does not arise.
Why a fake login page cannot use your passkey
Every passkey is tied to one domain. WebAuthn calls that domain the Relying Party identifier, or RP ID. The rule in the specification is that "The RP ID must be equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain". The specification gives its own worked example. For a page served from https: //login.example.com:1337, the valid RP IDs are login.example.com and example.com. Not m.login.example.com, and not com.
Two separate barriers stop a lookalike domain, and most explanations only mention the second. The first is that the browser checks the requested RP ID against the page's actual origin before any signature exists. A page on a typosquatted domain that asks for a credential scoped to example.com is rejected by the browser itself, which throws a security error. A passkey registered for example.com is also simply invisible to that page, so the authenticator produces nothing at all. The user's judgement is never consulted. The second barrier applies after the fact: the full origin is signed over in the data the authenticator returns, so anything an attacker did relay would name the attacker's origin and fail the server's check. The specification puts it in six words. Credentials "cannot be replayed against a different origin".
This is what makes passkeys different in kind from a one-time code. A code typed into a fake page works perfectly on the real page. NIST's authentication guidance, SP 800-63B Revision 4, states the position bluntly in its per-method sections: "Passwords are not phishing-resistant", "Look-up secrets are not phishing-resistant", "Out-of-band authentication is not phishing-resistant", and "OTP authentication is not phishing-resistant". Only cryptographic authentication qualifies, and only when it meets the additional conditions in section 3.2.5. NIST's own definition of phishing resistance is the single most useful sentence in that document for a non-technical audience. It is "the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier", and the guidance adds that this must happen without relying on the claimant's vigilance. No amount of staff training produces that property. The protocol either has it or it does not.
Credential stuffing is defeated structurally rather than by policy. Stuffing works because one secret is valid in more than one place. A passkey private key never leaves the authenticator and each credential is scoped to one domain, so there is nothing reusable to try anywhere else. A combolist containing a million email and password pairs is worth nothing against an account that has no password.
What passkeys do not protect
Session theft. This is the big one, and it follows directly from NIST's own definition. Phishing resistance is a property of the authentication protocol. A session cookie issued after the authentication succeeds is a different object with none of the passkey's properties. It is a bearer token: whoever holds it is treated as the signed-in user, it is not bound to an origin by cryptography, and it is not challenge-fresh. Session cookie theft therefore works exactly as well against an account protected by a passkey as against one protected by a password, because it does not touch the sign-in at all. Passkeys change the attacker's preferred method rather than removing the risk. The mitigations are at the session layer, not the authentication layer: shorter reauthentication intervals, device-bound session tokens where your identity provider offers them, and risk signals that look at where a session is being used from. For context on how often this route is taken, see MFA bypass techniques.
Account recovery. The real assurance level of an account is the assurance level of its weakest route in, and for most deployments that is the lost-device flow. If losing your phone means an emailed link or an SMS code, you have a passkey on the front door and an SMS code on the back door. Both NIST and FIDO respond to this problem in the same way, which is telling: neither recommends making recovery stronger. NIST's guidance says that "CSPs and verifiers SHOULD encourage subscribers to maintain at least two separate means of authentication", and FIDO's enterprise paper advises organisations to "Minimize credential loss scenarios by registering multiple device-bound passkeys". Both are, in effect, conceding that recovery is the hard part and the answer is to avoid needing it.
The platform account that holds synced passkeys. A synced passkey is backed up to your Apple, Google or Microsoft account, which is what makes it available on your other devices. That convenience means the passkey inherits the blast radius of that platform account. Apple documents its own protections in detail and they are substantial: the escrow records are guarded by clusters of hardware security modules, the iCloud security code is verified using the Secure Remote Password protocol so that "the code itself isn't sent to Apple", and the escrow service "allows only 10 attempts to authenticate and retrieve an escrow record", after which the cluster destroys the record. Those controls stop brute force. They do nothing if the attacker has legitimately obtained the account password, the registered phone number and the security code. Equivalent documentation for Google Password Manager and Windows Hello was not available when this article was written, so Apple is used here as a single worked example rather than as a description of all three.
Malware on the device. A private key held in hardware cannot be exported. Malware does not need to export it. On an unlocked, signed-in machine, infostealer malware takes the session cookies that already exist, which is the same outcome by a shorter route. Passkeys are an authentication control, not an endpoint control.
Malicious application consent. In a consent attack the victim authenticates genuinely, with a real passkey, to the real provider, and then grants a malicious third-party application a long-lived token. Nothing was spoofed, so origin binding has nothing to catch. This is a question of who may grant access to what, and it is governed by application consent policy and by periodic admin review of third-party grants, not by the choice of authenticator.
The help desk. An attacker telephones, says they have lost their phone, and has a new passkey enrolled for them. The cryptography was perfect and completely irrelevant. For a small organisation without a dedicated identity team this is the most important gap on the list, because it is the cheapest attack to run and the one least likely to be covered by a written procedure. Identity proofing on re-enrolment matters more here than the authenticator you chose.
Synced or device bound
The difference is whether the private key can leave the device, and that one property decides everything else. A synced passkey's key is, in NIST's terms, an exportable key. It travels to a cloud sync service, which buys you recoverability and use across devices, and costs you the security of the platform account. A device-bound key never leaves its authenticator, which is usually a hardware security key or a platform authenticator deliberately configured not to sync.
NIST draws a hard line at the top assurance level. Its storage requirements split on exactly this axis: "Non-exportable authentication keys (usable at AAL3 or below) SHALL be stored in an isolated execution environment", while "Exportable authentication keys (usable at AAL2 or below) SHOULD be stored in appropriate storage". Because an authenticator that syncs has an exportable key by definition, the guidance states that syncable authenticators "SHALL NOT be used at AAL3". Note that NIST never uses the word "passkey", so reading "syncable authenticator" as "synced passkey" is interpretation, albeit interpretation nobody seriously disputes. FIDO's own assurance table reaches the same place from the other direction: it rates device-bound passkeys as potentially sufficient for high assurance depending on the authenticator and on compliance requirements, and rates synced passkeys as insufficient for it.
For most businesses that distinction does not bite, and it is worth saying so plainly. A synced passkey is a legitimate phishing-resistant authenticator at the assurance level that ordinary business systems operate at. The place to spend money on device-bound keys is the small set of accounts where a platform account compromise would be unrecoverable: the identity provider's own administrators, the domain registrar, the finance approval chain. Everyone else can have a synced passkey and be dramatically better off than they were with a password and a code.
One detail your developers can use. The server's credential record includes flags recording whether a credential is eligible for backup and whether it is currently backed up. That means an application can see whether a given passkey is syncable and apply its own policy, for example requiring a device-bound credential for administrative sessions. The signature counter in the same record is a cloned-authenticator signal rather than a defence, and should not be presented as one.
What you will actually run into
Service-side support is real but patchy, and the only figure with a reproducible method is lower than the marketing suggests. An academic census of the Tranco top 100,000 sites, published by Bhardwaj and Sastry at the University of Surrey and revised on 19 March 2026, found that 11.3 per cent of reachable sites support passkeys, roughly 9,400 sites. The gradient by popularity is steep: about 20 per cent of the top 100 sites, against 6.9 per cent of sites ranked between 50,000 and 100,000. By sector, 36.8 per cent of banking and financial sites in the sample supported passkeys, against 0.9 per cent of healthcare sites and 1.1 per cent of government sites. Two caveats matter when you quote these numbers. The census measures whether a site offers passkeys, not whether anyone uses them. And 82.3 per cent of the passkey-supporting sites were detectable only by instrumenting the browser interface, which is why hand-maintained directories undercount so badly.
Expect passkeys to sit beside your passwords rather than replace them, for years. The same census found passkeys are mostly an additional option alongside passwords and existing MFA, and its authors describe the passwordless future as still aspirational. That matters operationally, because if the password is still there, so is every attack against it. Enrolling a passkey and leaving a password-plus-SMS path enabled gives an attacker a choice, and they will take the easier one.
The domain rule is a deployment constraint, not a detail. Because a passkey's RP ID must be the page's domain or a registrable suffix of it, one passkey covers login.example.com and shop.example.com, but not example.co.uk. If your business runs separate country domains or acquired a second brand, you will register separate credentials or implement the related origins procedure that WebAuthn Level 3 introduced, which is new enough that support varies.
Shared devices are the limit nobody documents. A platform passkey belongs to a platform account, which is awkward on a shop-floor terminal or a till used by six people across three shifts. The workable patterns are a roaming hardware key per person, or keeping the passkey on each staff member's phone and authenticating the terminal from it. No standards body gives guidance on this, so treat the above as our reasoning rather than as a citation.
If you cannot get there yet, there is published interim advice, with a date caveat. CISA's fact sheet on implementing phishing-resistant MFA recommends app-based one-time codes and mobile push with number matching as the best interim options for small and medium businesses that cannot yet adopt phishing-resistant MFA, and it is explicit that SMS or voice "should only be used as a last resort MFA option" because it is "vulnerable to phishing, SS7 exploitation, and SIM swap attacks". The fact sheet is from October 2022 and predates mainstream passkey availability, so read it as a ranking of fallbacks rather than as current deployment guidance.
The honest state of the evidence
There is no credible published measurement of how much passkeys reduce account takeover. We looked for one. What exists is survey perception, vendor aggregate figures with no stated method, and restatements of both. We are not going to put a percentage in front of you that we cannot defend, and you should be suspicious of any provider who does.
The case for passkeys is mechanical, and it is strong enough without a statistic. There is no shared secret for a server breach to leak. There is no reusable secret for a stealer log or a combolist to contain. The browser, not the user, decides whether a credential may be used on a given domain. Those are properties of the design, attested by the specification text and by NIST's classification, and they do not depend on anybody's survey.
The honest summary is this. Passkeys close the credential-phishing path and the password-reuse path and they close them properly. What remains is everything after sign-in, everything around sign-in, and everyone who can be talked into enrolling a new one. Plan for those, and passkeys are the best single authentication decision available to a small business in 2026.
What to do about it this quarter
Start where a compromise is unrecoverable. Identity provider administrators, the domain registrar, the finance approval chain, and whoever can change payroll bank details. Device-bound hardware keys for those, two each, both registered.
Turn off the weak fallback once the passkey works. If SMS or an emailed link still opens the account, the account's real strength is SMS. This is the step most deployments skip.
Write down the re-enrolment procedure before you need it. Who may authorise a new passkey for a staff member who has lost a phone, what identity proofing is required, and who is not permitted to approve it alone. One page is enough. A help desk with no written rule will be helpful to the wrong person eventually.
Keep looking at your exposure after you deploy. Passkeys do not remove the passwords your staff have already reused on sites you do not control, and those credentials keep circulating. A password that no longer opens your systems still opens the employee's personal accounts and still tells an attacker who works for you and what your email format is. See what survives a password reset for the artefacts that outlive a credential change, and reading a credential exposure report for what to do with the findings when they arrive.