Picture a finance manager who types her password into a login page that looks exactly like her bank's. The attacker behind the page now holds a working credential, and she notices nothing until the transfer alert arrives. A passkey would have refused to answer that page, because the browser ties each passkey to the real domain where it was created. That single design property is why passkeys are more secure than passwords against phishing and remote attacks, and it is the reason this article exists.
The short answer for cyber security experts and risk owners is yes, with conditions. A passkey keeps a private key on the user's device and gives the website only a public key, so a breached server or a fake page has nothing worth stealing. What changes is where the attacker goes next: the phone in a thief's hand, the recovery flow, the cloud account that syncs the keys, malware on the laptop, and the old password that most accounts still keep alive. A recent TechRadar explainer by Mark Gill reaches a similar verdict. It calls passkeys an upgrade, warns against treating them as a cure-all, and names device access and platform lock-in as the main residual risks. This piece adds recovery, rogue enrollment and malware to that list and turns each gap into a control.
You can apply the nine controls below this week. They are ranked from most efficient to least, where efficient means the amount of risk removed for each hour of effort and each user you inconvenience. The first six suit any individual or small team. The last three matter most to security teams, administrators and anyone who builds a login. Each control names an owner and the evidence an auditor would ask for, so the work survives a review.
Are Passkeys More Secure Than Passwords?
Yes. Against phishing, credential stuffing and server breaches, passkeys are stronger than passwords by design, and production data agrees. A passkey is a WebAuthn credential: the device creates a key pair for one website, the site stores the public half, and the private half stays in the device or its credential provider. When you sign in, the site sends a challenge, your device signs it after you approve with a fingerprint, face scan or PIN, and the site checks the signature. The private key never travels, so there is no shared secret to intercept, reuse or crack. NIST SP 800-63B-4 reflects that logic and states plainly that passwords are not phishing-resistant, whatever their length.
The phishing resistance comes from scoping. The W3C Web Authentication specification ties every credential to a relying party, which is normally the registrable domain of the site, and the browser writes the real origin into each response. A lookalike domain therefore receives nothing usable, even when the user is fully convinced by the page. That moves the defense from human judgment, which fails at a predictable rate, to protocol enforcement, which does not get tired. A password manager gives a weaker version of the same protection because it usually refuses to autofill on an unknown domain, though a user can still paste the password by hand.
People often worry that a passkey hands their fingerprint to a large technology company. It does not. The fingerprint or face scan opens the key on the device, the website receives only a signed response, and the platform providers manage an encrypted container of keys without ever seeing the biometric template. The TechRadar explainer makes the same point, and the FIDO white paper on digital credentials describes biometric checks as local to the device. In practice the biometric is a convenient lock on the key, and the key is what proves identity.
The numbers point the same way, with caveats. The latest FIDO Alliance Passkey Index, built from 15 large consumer services, reports a 93 percent sign-in success rate for passkeys against 78 percent for passwords and traditional multi-factor methods, and sign-ins about 2.8 times faster. All 8 participants that measure phishing reported fewer successful phishing attacks after deploying passkeys, and the 3 participants that shared account takeover observations all reported fewer. One large payments provider reported that account takeover rates on passkey-authenticated transactions were 70 percent lower than on password-based ones. Treat these figures as encouraging and self-reported: the Index uses unweighted averages from member organizations, and the takeover observations come from a handful of firms. They show direction well and magnitude poorly.
Credential abuse is the reason to care. The Verizon Data Breach Investigations Report found stolen credentials involved in 88 percent of breaches in the basic web application attack pattern, which is one attack pattern among several, and it found that credential abuse began 22 percent of all breaches. Passkeys remove the reusable secret that those attacks depend on. They do not remove every path into an account, and the rest of this article deals with the paths that remain.
For compliance owners, NIST SP 800-63B-4 sets the benchmark. At AAL2, verifiers must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication from their staff, contractors and partners. At AAL3, the authenticator needs a non-exportable private key that also resists phishing. Synced passkeys can support AAL2 under the syncable authenticator appendix, but syncing makes a key exportable, so it breaks the AAL3 non-exportability requirement, while a device-bound key in a hardware authenticator can meet it. CISA's multi-factor goal in its Cross-Sector Cybersecurity Performance Goals points to phishing-resistant MFA, and its published USDA case study names FIDO and PKI as the only non-proprietary methods that stop users from being tricked into revealing authentication secrets.
Passkeys vs Passwords: Pros and Cons Side by Side
Passkeys win on security against remote attack and on sign-in speed. Passwords win on reach and familiarity. The table sets the trade-offs on the dimensions that change decisions, with the practical consequence in the last column.
| Dimension | Passwords | Passkeys | Practical consequence |
|---|---|---|---|
| Phishing | The secret can be typed into any page that looks right | The credential answers only the domain where it was created | Phishing stops working against enrolled users |
| Reuse and credential stuffing | Reuse is common and one breach exposes many accounts | One key pair per site, no shared value | Stuffing fails against enrolled accounts |
| Breach of the website | Hashes can be attacked offline | A stolen public key cannot sign in | Smaller blast radius, though personal data and sessions stay exposed |
| Sign-in success and speed | 78 percent success for passwords and traditional MFA | 93 percent success, about 2.8 times faster | Fewer failed logins and fewer help desk resets |
| Device theft | Does not depend on one device | A thief who passes the screen lock may reach the keys | The strength of the screen lock now guards the accounts |
| Recovery | Email reset is familiar and weak | Needs backup authenticators or a designed recovery path | Recovery becomes the main attack surface |
| Portability | Works everywhere | Tied to a provider unless exported or hardware-based | Plan a platform switch before you need one |
| Support | Nearly universal | Growing, uneven on older apps and shared accounts | Expect a hybrid period while legacy systems catch up |
The benefits are real and they compound. A user who signs in with a passkey has no password to forget, no code to retype and no fake page to judge, so the secure path is also the fast path. That alignment is rare in security, where controls usually add friction, and it explains why the FIDO participants report lower support cost and lower spending on SMS codes. The consumer services in the Index reported SMS one-time passcode savings that ranged from about 1 million dollars a year to hundreds of millions, depending on size and usage.
The costs are equally real, and they land in different places than password costs did. Recovery needs design work, the screen lock becomes a security control, the sync account becomes a high-value target, and moving between platforms takes planning. Shared accounts, kiosks and service accounts fit passkeys poorly because the credential binds to an individual and a device. Many older applications and internal tools still lack WebAuthn support, so a hybrid period is the norm.
Passwords do not disappear in that period, so keep them properly managed where they remain. NIST SP 800-63B-4 asks for at least 15 characters when a password is the only factor, bans composition rules such as forced symbols, and bans periodic forced changes unless there is evidence of compromise. Store those passwords in a reputable manager, make each one unique, and add the strongest second factor the service supports. A password protected that way is a reasonable fallback for the accounts that cannot use a passkey yet, and a poor fallback for the accounts that can.
Where Do Passkeys Still Fail in Practice?
They fail at the edges the cryptography does not cover. The key pair is sound, so attackers go around it, and the routes they take are predictable enough to plan against. Six gaps matter in practice: the surviving password, recovery, device access, the sync account with its lock-in, malware with rogue enrollment, and the enrollment gap that keeps passkeys from reaching everyone.
The weakest part of most rollouts is the password that stays behind. In the FIDO Index, 42 percent of eligible accounts have a passkey enrolled and passkeys account for 36 percent of successful sign-ins. Eight of the ten participants that report both see a passkey sign-in share below their enrollment rate, and two say their flow shows a password or one-time code before it offers the passkey, even to users who have one. One of those two estimates that offering the passkey first would roughly double its passkey share. As long as the password path works, an attacker can choose it, and a phishing kit does not need to defeat the passkey at all.
Recovery is the second gap. A user who loses every device without a backup authenticator faces a reset flow, and attackers know that flow is where an account is easiest to take. NIST lists cloud-based account recovery as a potential weakness of synced keys and recommends binding multiple authenticators at AAL2 and above, requiring AAL2 authentication to add new ones, and notifying the user of any recovery activity. A recovery path that falls back to an emailed link or an SMS code reintroduces the phishable factors the passkey removed. The FIDO white paper on passkeys and verifiable digital credentials goes a step further and proposes using a verified digital credential to recover a passkey where one exists.
Physical access moves the risk to the device. The TechRadar explainer points out that a thief who holds your phone and knows your screen lock PIN could potentially reach the accounts protected by passkeys on it. Most services still ask for a fresh approval at each sign-in, which helps, but a PIN the thief has watched you type may be enough on many phones. NIST treats the user verified flag in the WebAuthn response as the signal that separates a multi-factor authenticator from a single-factor one, and a verifier that sees no user verification must treat the passkey as single-factor. So the strength of the device lock and the way a service checks it both carry weight.
Synced passkeys move trust to the cloud account that syncs them. NIST requires access to the sync fabric to be protected by AAL2-equivalent multi-factor authentication, which means a weak password on the Apple, Google or Microsoft account becomes the weak link for every passkey behind it. Lock-in is the other cost. Passkeys sit in iCloud Keychain, Google Password Manager or a third-party manager, and moving between them is still awkward. FIDO's Credential Exchange Protocol for transfers between providers is published as a working draft, so check its current status before you depend on it. A person who switches from iPhone to Android without a plan can find that the keys do not follow.
Malware and session theft go around the key. A phishing toolkit called iAuthFlow v2, reported in August, relays a victim's login to a real Google page, captures the authenticated session, and then enrolls a passkey that the attacker controls. That passkey survives a password reset and session revocation because it is a separate credential that stays until someone removes it. The toolkit abused a phishable login and left the passkey cryptography intact, which is why the first fix is to remove phishable fallbacks. A separate Unit 42 research paper showed three attack chains in which malware already running on a Windows machine abused the way Google Password Manager syncs passkeys. The researchers did not break WebAuthn cryptography and tested only that implementation, so the finding says little about other providers. Both cases agree on one point: once an attacker is inside the session or the endpoint, the passkey cannot help.
My reading of this evidence is that passkeys remove the most common attack and leave attacks that need more effort, more luck or a foothold on the device. That is a good trade. It also means the next dollar of risk reduction comes from controls around the passkey, which is where the ranked list begins.
How Should You Rank Passkey Controls?
Rank them by risk removed per hour of effort, then break ties by how many users the control touches. This is a judgment call, and I have not tested the order against incident data, so treat it as a defensible default that your own threat model can overrule. The reasoning is explicit so you can change a rank when your facts differ from the ones assumed here.
Four questions sort the list: how common is the attack the control stops, how cheap is the control to deploy, how many accounts does it cover, and how painful is a lockout if the control is misapplied. The first control scores high on all four. Enrolling the accounts that can reset every other account removes the most valuable targets from the phishing path in an afternoon, and a mistake there is easy to undo. In my judgment, removing the password fallback removes more risk than any other step, yet it sits third because it causes the worst lockouts when it comes before a working backup.
The later controls cost more and protect fewer people. Device-bound security keys, endpoint hardening and server-side verification all deliver real protection, and each needs money, administrator time or developer time. They rank lower because the earlier controls capture most of the risk reduction for less. A team with a small budget should finish the first five and then choose among the rest by the size of its privileged population and the age of its devices.
The table gives the full order, with the owner who should be able to defend each control and the evidence that proves it exists. An auditor will ask for the evidence column, so build it as you go and do not reconstruct it later.
| Rank | Control | Owner | Evidence to keep |
|---|---|---|---|
| 1 | Passkey the recovery email and identity provider first | Security lead for staff, account holder for personal use | Enrollment report listing each top-tier account and the enrollment date |
| 2 | Register a second authenticator and test it | Account holder, checked by IT for staff | Count of accounts with two or more authenticators, and a dated recovery test |
| 3 | Remove the password and SMS fallback | Identity owner | Policy export showing fallback disabled, plus the exception list |
| 4 | Harden account recovery | Identity owner with the help desk lead | Recovery runbook, test record and a sample of recoveries matched to approvals |
| 5 | Alert on every new passkey and review the list | Security operations | Alert rule and quarterly review sign-off |
| 6 | Secure the sync account and the screen lock | Account holder, endpoint owner for staff | MFA status of sync accounts and a device compliance report |
| 7 | Use device-bound security keys for privileged accounts | Privileged access owner | Key inventory and admin enrollment report |
| 8 | Keep malware and stolen sessions off the endpoint | Endpoint owner | Patch status, detection coverage and session settings |
| 9 | Verify the ceremony on the server | Application owner | Test cases for origin, relying party identifier and user verification checks |
Nine Passkey Controls, Ranked From Most Efficient
Each control below states what to do, the decision rule, the owner, the failure mode you should expect in the first weeks, and the evidence to keep. Individuals can apply controls 1 to 6 to their own accounts today. Organizations should run the full list and assign every owner by name before starting, since a control without a named owner tends to stall at the first awkward exception.
1. Passkey the Recovery Email and Identity Provider First
Start with the accounts that can reset all the others. For a person, that means the primary email account, the password manager or the Apple, Google or Microsoft account, and any bank or carrier account that holds recovery codes. For a company, it means the identity provider that issues sign-in for every application, the mail system and the administrator consoles. Enrolling these first takes the most valuable credentials off the phishing path in an afternoon, and every account behind them gets harder to reach by reset. Do it before any broad rollout, because a passkey on a shopping site protects a shopping site, while a passkey on the mailbox protects the reset link for everything.
The decision rule is simple: enroll an account when losing it would let an attacker reset other accounts. The owner is the security lead for staff and the account holder for personal use, and the evidence is an enrollment report that lists each top-tier account with the date a passkey was added. Two failure modes show up in the first weeks. Users enroll on a shared or borrowed computer, which stores the key where other people can reach it, and users enroll once and assume they are done while the password still works. Controls 2 and 3 close those gaps, which is why the order matters.
2. Register a Second Authenticator and Test It
Register at least two authenticators on every account that matters before you rely on the first. A second passkey on another device, a hardware security key kept in a drawer, or a passkey held in a credential manager that is independent of your phone platform all count. The cost is about ten minutes per account, and the benefit is that a lost phone becomes an inconvenience instead of a lockout. This control also answers lock-in: a hardware key or a third-party manager that you control keeps working when you move from one phone platform to another. NIST recommends binding multiple authenticators at AAL2 and above to support recovery for the same reason.
Test the backup, because an untested backup is only a belief. Sign out, sign in with the second authenticator, and write down the date. For staff, a sensible rule is to flag any top-tier account that still has a single authenticator after thirty days and to report that count monthly. The failure mode to expect is the second key that lives in the same bag as the first, so ask where each one is stored. If the second authenticator depends on the same phone as the first, it is not a second authenticator.
3. Remove the Password and SMS Fallback
Once the passkey and its backup work, disable the password and the SMS or email code as sign-in routes wherever the service allows it. This control turns phishing resistance from a possibility into a fact, because an attacker who cannot use the fallback has to attack the passkey itself. The FIDO Alliance names the removal of weaker fallbacks such as passwords and SMS as the next phase of deployment, and the two participants that show a password before the passkey illustrate how a fallback quietly keeps the old risk alive. Some services keep the password active after you add a passkey, so look in the security settings for an option that makes the account passwordless. Where the service has no such option, set a long unique password in a manager and never type it by hand.
Do this third, since removing the fallback before the backup exists is how people lock themselves out. For staff, the identity owner should phase the change by group, starting with the people who already sign in with a passkey most of the time, and keep a documented exception list for shared and service accounts that cannot use passkeys. NIST sets the rules for the passwords that remain: at least 15 characters when the password is the only factor, no composition rules, and no forced periodic change without evidence of compromise. The evidence for an auditor is a policy export that shows the fallback disabled, plus the exception list with an owner and a review date for each entry.
4. Harden Account Recovery
Treat recovery as a second login and give it the same strength. The recovery path decides whether a strong passkey is worth anything, since an attacker who cannot beat the key will go through the reset. Replace email-only and SMS-only recovery with a path that needs a second registered authenticator, a recovery code stored offline, or an identity check performed by a trained person following a script. Add a waiting period for high-risk resets, and send a notice to every channel on file when recovery starts, which matches the NIST recommendation to notify users of recovery activity. Where you can verify a digital identity credential, such as a mobile driver license or a national digital ID, the FIDO white paper recommends using it to recover a passkey.
Help desk staff are the target, so give them a runbook. The runbook should say which proofs each account tier requires, who may override and how an override is logged, and when a call-back to a number already on file is mandatory. Test it twice a year with a staged request and record the result. The failure mode is the helpful agent who resets an executive account after a convincing phone call. The evidence an auditor will ask for is the runbook, the test record and a sample of recent recoveries matched to approvals.
5. Alert on Every New Passkey and Review the List
Every new passkey, security key or recovery method on an account should trigger a notice to the owner and, for staff, an alert to security operations. The rogue enrollment that iAuthFlow v2 performs happens within seconds of a phished login, and the attacker's passkey survives a password reset. So after any suspected compromise, the response has to include a review of passkeys, security keys, recovery options, OAuth grants and mail rules, and a password reset alone does not close the case. Require fresh strong authentication before any new authenticator can be added, even inside an active session, which matches the NIST recommendation to require AAL2 authentication to add authenticators to the sync fabric. Many identity providers log authenticator registration events, so the alert can often be a rule on data you already collect.
Review the list on a schedule. For personal accounts, spend five minutes each quarter in the security page of your email and sync accounts and delete passkeys for devices you no longer own. For staff, run a quarterly report of authenticators per user, flag any registered from unusual locations or devices, and remove stale ones. The WebAuthn Level 3 Signals API gives sites a way to tell the client that a credential is stale, which helps builders keep these lists tidy. Keep the alert rule and the sign-off from each review as evidence.
6. Secure the Sync Account and the Screen Lock
A synced passkey is only as safe as the account that syncs it. Put phishing-resistant authentication on the Apple, Google or Microsoft account, or on the third-party manager, and keep a long unique recovery secret offline. NIST requires access to the sync fabric to be protected by AAL2-equivalent multi-factor authentication, and it recommends encrypting the keys with a secret the user controls. In practice that means turning on the strongest sign-in option your provider offers, reviewing the list of signed-in devices, and removing any you do not recognize. If you manage staff devices, enforce device management that stops synced keys from moving to unapproved devices or accounts, as the NIST syncable authenticator appendix describes for federal enterprise use.
The screen lock is the second half of this control. The TechRadar explainer warns that a thief who has the device and knows the PIN could reach passkey-protected accounts, so use a long alphanumeric passcode rather than a four-digit one, and turn on the stolen-device protections your phone offers. Keep devices updated and set a short auto-lock time. For staff, the endpoint owner should report device compliance for passcode length, disk encryption and operating system version. The evidence is the MFA status of each sync account and the device compliance report.
7. Use Device-Bound Security Keys for Privileged Accounts
Use hardware-backed, device-bound keys for administrators, finance approvers and anyone who can change who has access. Syncing makes a key exportable by definition, and NIST says that this violates the non-exportable key requirement of AAL3, so a synced passkey cannot meet AAL3 while a device-bound key in a hardware authenticator can. A key that cannot be copied also takes the sync account and the cloud recovery path out of the attack surface for those accounts. The cost is administrative work: each user needs two keys, one primary and one spare, and the identity team has to track them. For a privileged population of tens or hundreds of people, that cost is small next to the exposure.
Set the decision rule by account tier. Accounts that can change authentication settings or move money require a device-bound key and refuse synced passkeys, while ordinary staff accounts accept synced passkeys under controls 5 and 6. Where your identity provider exposes the backup eligible flag from the WebAuthn response, you can use it to tell device-bound credentials from syncable ones and require the first kind for chosen groups. The NIST appendix describes that flag and the related backup state flag for this purpose, and it advises public-facing services against conditioning access on backup state because of the user experience cost. Keep an inventory that ties each key serial number to a person, and test the spare once a year.
8. Keep Malware and Stolen Sessions Off the Endpoint
Passkeys protect the login and nothing after it. If infostealer malware or a malicious browser extension takes a session token, the attacker rides the session without touching the passkey, and the Unit 42 research shows that malware with a foothold on a Windows machine can also go after the sync trust path. So the endpoint controls come back into the picture: patch the operating system and browser quickly, run endpoint detection, restrict extensions, and keep administrator rights off daily-use accounts. The Verizon DBIR reported that 46 percent of unmanaged devices in its infostealer log sample held corporate logins, which is a good reason to limit personal devices on work accounts. A passkey on a compromised laptop is a passkey on a laptop that the attacker already shares.
Shorten what a stolen session can do. Set session lifetimes to match the risk, require a fresh passkey approval for sensitive actions such as changing recovery options, adding an authenticator or approving a payment, and revoke sessions and tokens when a device is lost. Provider tools exist to end every session on an account, and you should use them during incident response together with the passkey review in control 5. For personal accounts the advice reduces to updates, a clean browser profile and few extensions. The evidence is patch status, detection coverage and the session settings exported from the identity provider.
9. Verify the Ceremony on the Server
If you build a login, verify every step of the WebAuthn ceremony on the server with a maintained library, and do not write the parsing yourself. The OWASP Passkey Security Cheat Sheet lists the checks: the origin is an exact member of your allowlist, the relying party identifier hash matches, the user present flag is set, and the user verified flag is set whenever you required verification. NIST adds that verifiers must inspect the user verified flag and treat a passkey without user verification as a single-factor authenticator. Keep the relying party identifier as narrow as your domains allow. Treat any related-origin or app association file with the same change control as your origin allowlist, because an over-broad file lets an unrelated app collect assertions for your identifier.
Build the lifecycle in from the start. Let users see and remove their passkeys, notify them on enrollment and recovery, and support more than one authenticator per account. Test the negative cases: a response from the wrong origin, a replayed challenge and a missing user verification flag. W3C published WebAuthn Level 3 as a full Recommendation, so it is now a stable reference you can cite in requirements and audits. The evidence for an auditor is the test cases with their results and the version of the library in use.
How Do You Measure Whether the Passkey Rollout Works?
Measure four things: enrollment, passkey share of sign-ins, fallback exposure and recovery volume. Fallback exposure is the one most teams skip, and it tells you how much of the old risk is still live. The other three tell you whether people are using the new path and whether the safety net holds.
Define each metric in one line so that two people compute the same number. Enrollment is the number of active accounts with at least one passkey divided by all active accounts. Passkey share is the number of successful sign-ins made with a passkey divided by all successful sign-ins in the same period. Fallback exposure is the number of active accounts that can still sign in with a password or SMS code divided by all active accounts, and recovery volume is the number of recoveries per 1,000 accounts each month, with the share that completed the full proof. The identity owner holds these numbers, the data comes from identity provider sign-in logs, the authenticator registration report and help desk tickets, and the monthly export is the evidence.
Here is an illustrative scenario with assumed numbers, not a real engagement. A company has 1,200 active staff accounts. After a three-month rollout, 780 accounts have a passkey, which is 65 percent enrollment. The sign-in logs show 5,400 passkey sign-ins out of 9,000 successful weekday sign-ins, a 60 percent share. The password still works on all 1,200 accounts, so fallback exposure is 100 percent and the phishable path is as open as before the project began. Disabling the password for the 780 enrolled staff, after confirming that each has two authenticators, would cut exposure to 420 accounts out of 1,200, or 35 percent.
For orientation, the FIDO Index reports 42 percent enrollment among eligible accounts and a 36 percent passkey share across 15 large consumer services. Those are consumer figures, and an employer can set policy in ways a retailer cannot, so use them as a floor and not as a target. Report what did not improve as well. If recovery volume rises after the rollout, fix the recovery runbook in control 4 before you disable more fallbacks, because a rising recovery rate means people are being pushed into the weakest path.
Final Perspective
The decision in front of most teams is how fast to close the fallback, since adoption is already happening. More than a third of successful sign-ins at the services in the FIDO Index now use a passkey, and nine of the 13 participants that answered plan to offer passwordless accounts within a year. W3C has published WebAuthn Level 3 as a Recommendation, which gives requirement writers and auditors a stable standard to cite. The attacks are following the same path: the August reports on a phishing toolkit and on malware abusing a synced passkey workflow both aim at what surrounds the key. Expect more research of that kind, and expect your controls on recovery, enrollment alerts and endpoints to matter more each quarter.
Take one account this week and run controls 1 to 3 on it from start to finish, including the backup test, so you learn where your own flow breaks before you scale. Then ask the question that decides your exposure: which account in your organization can reset the most other accounts today, and does it still accept a password?
References
- TechRadar, Mark Gill, Are passkeys more secure than passwords?, published October 26, 2026, link to verify (URL not supplied or fetched in this session)
- FIDO Alliance, Passkey Index October 2026, https://fidoalliance.org/wp-content/uploads/2026/10/Passkey-Index-October-2026.pdf
- NIST, SP 800-63B-4, Authentication Assurance Levels, https://pages.nist.gov/800-63-4/sp800-63b/aal
- NIST, SP 800-63B-4, Authenticators, https://pages.nist.gov/800-63-4/sp800-63b/authenticators
- NIST, SP 800-63B-4, Appendix B, Syncable Authenticators, https://pages.nist.gov/800-63-4/sp800-63b/syncable/
- W3C, Web Authentication, An API for accessing Public Key Credentials, Level 3, https://w3c.github.io/webauthn/
- FIDO Alliance, WebAuthn Level 3 Is Now a W3C Recommendation, https://fidoalliance.org/webauthn-level-3-is-now-a-w3c-recommendation/
- OWASP, Passkey Security Cheat Sheet, https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html
- CISA, Take the First Steps Towards Better Cybersecurity With These Four Goals, https://www.cisa.gov/news-events/news/take-first-steps-towards-better-cybersecurity-these-four-goals
- CISA, Phishing-Resistant Multi-Factor Authentication Success Story, USDA's FIDO Implementation, https://cisa.gov/resources-tools/resources/phishing-resistant-multi-factor-authentication-mfa-success-story-usdas-fast-identity-online-fido
- Verizon, 2025 Data Breach Investigations Report, Executive Summary, https://www.verizongov.com/resources/reports/2025-dbir-executive-summary.pdf
- PayPal Newsroom, Solving the Convenience and Security Equation, https://newsroom.paypal-corp.com/2025-01-23-Solving-the-Convenience-and-Security-Equation
- Security Affairs, iAuthFlow v2, The $10,000 Phishing Toolkit That Survives Your Password Reset, https://securityaffairs.com/197748/cyber-crime/iauthflow-v2-the-10000-phishing-toolkit-that-survives-your-password-reset.html
- TechRadar Pro, This new malware can use Google passkeys even after a victim resets their password, https://techradar.com/pro/security/this-new-malware-can-use-google-passkeys-even-after-a-victim-resets-their-password
- Palo Alto Networks Unit 42, Pass the Passkey, A Novel Attack Surface in Passwordless Authentication, https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/
- FIDO Alliance, White Paper, Passkeys and Verifiable Digital Credentials, A Harmonized Path to Secure Digital Identity, https://fidoalliance.org/wp-content/uploads/2025/09/FIDO-White-Paper-passkeys-and-verifiable-digital-credentials.pdf
- FIDO Alliance, Credential Exchange Protocol, Working Draft, https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html
