For years, the password was treated as the basic proof that an online account belonged to a particular person. That model is now being replaced by something fundamentally different: cryptographic credentials stored on devices, security keys, or credential managers, unlocked through a local gesture such as a fingerprint, face scan, or PIN.
The shift is no longer confined to experimental security systems. In May 2026, the FIDO Alliance said an estimated 5 billion passkeys were in active use worldwide, based on research covering consumers and enterprise organizations across ten countries. Its April 2026 consumer survey found that 75% of respondents had enabled a passkey on at least one account, while 49% said they regularly use passkeys when available. The same research found that 68% of surveyed organizations with 500 or more employees were deploying, piloting, or rolling out passkeys. Those figures come from the FIDO Alliance’s own research, so they should be treated as an industry survey rather than an independent census, but they illustrate how far the technology has moved beyond early adoption.
The more important development, however, is not simply that people are typing fewer passwords. Passwordless authentication is changing the technical meaning of an online identity. Instead of asking a service to recognize a secret that the user knows, modern authentication can ask a device or authenticator to demonstrate possession of a private cryptographic key that is associated with that account. That distinction affects everything from phishing to account recovery, device management, and the relationship between an identity provider and the person using it.
The Password Was Never the Identity
A password looks like an identity credential because people type it into a login form, but technically it is a shared secret. The user knows the password, and the service normally stores a verifier derived from it rather than the original plaintext. When authentication succeeds, the service concludes that whoever supplied the correct secret is authorized to act as the account holder.
The weakness is built into that arrangement. The same secret exists, in some form, on both sides of the authentication relationship. If a password is reused, stolen, guessed, phished, exposed in a breach, or entered into a fake login page, the attacker may be able to use it elsewhere. Multi-factor authentication can reduce this risk, but conventional methods such as SMS codes and manually entered one-time passwords still require the user to transfer a value that can potentially be intercepted or relayed.
NIST’s current digital identity guidance draws an important technical distinction here. Its 2025 SP 800-63-4 framework separates identity proofing, authentication, and federation rather than treating them as one operation. Identity proofing establishes evidence about who an applicant is; authentication determines whether a claimant controls an authenticator associated with an account. That distinction becomes much more visible with passkeys.
A passkey does not, by itself, prove that someone is a particular human being. It proves control of a cryptographic credential. The account provider may separately have information establishing the person’s identity, but the passkey is primarily an authenticator. That sounds like a subtle terminology change. It is actually one of the most important parts of the transition.
What a Passkey Changes Technically
Passkeys are based on the FIDO authentication model and use public-key cryptography rather than a shared password. During registration, an authenticator generates a public/private key pair for the service. The private key remains under the control of the authenticator or credential-management system, while the corresponding public key is registered with the service. The website does not receive the private key. During a later login, the service sends a cryptographic challenge. The authenticator signs the appropriate authentication data with the private key after the user authorizes the operation. The service verifies that signature using the public key it previously registered.
The result is fundamentally different from submitting a password. There is no password for the website to receive, and the private key is not supposed to be transmitted to the website. WebAuthn provides the browser-facing standard that allows websites to interact with these credentials. In August 2026, the W3C published Web Authentication Level 3 as a formal recommendation. The specification defines strong, scoped, public-key credentials and describes how browsers mediate access to authenticators while preserving user privacy.
The next stage is already being developed. W3C published the first public working draft of WebAuthn Level 4 on September 15, 2026. That does not mean the new features are established production requirements; it is a working draft and therefore part of an ongoing standards process. This standards progression matters because passwordless authentication is not a single company’s login feature. It depends on interoperability between websites, browsers, operating systems, authenticators, and credential managers.
Why Phishing Looks Different With Passkeys
The strongest security argument for passkeys is not simply that they eliminate password reuse. It is that properly implemented cryptographic authentication can bind the credential operation to the legitimate relying party. NIST’s current authentication guidance explicitly says that manual entry of an authenticator output, such as an OTP, does not qualify as phishing-resistant authentication because an impostor verifier can potentially relay the value to the legitimate verifier. NIST recognizes cryptographic approaches involving channel binding or verifier-name binding as methods of achieving phishing resistance.
A passkey can therefore change the attacker’s problem. A convincing fake website may persuade someone to interact with it, but the authenticator is designed to use a credential scoped to the legitimate relying party rather than simply handing the site a reusable secret. That does not make every passwordless system invulnerable. Account recovery, malicious applications, compromised endpoints, stolen sessions, social engineering, and poorly designed enrollment processes can still create attack paths. The cryptographic credential protects a particular part of the authentication process; it does not automatically secure every component surrounding an account. This is increasingly important because authentication is moving from a single login event toward a larger identity system involving sessions, tokens, and federated access.
The Device Is Becoming Part of the Credential
The user experience often hides the complexity. On a phone, a person may approve a passkey with Face ID, a fingerprint, or a device PIN. On Windows, a passkey can be protected by Windows Hello. Microsoft currently supports both synced passkeys and device-bound passkeys, depending on the scenario. Its Microsoft Entra documentation describes Windows passkeys stored locally in the Windows Hello container, with authentication performed using Windows Hello biometrics or a PIN. Those credentials do not synchronize between devices, meaning each device needs its own registration.
Google’s implementation illustrates the other side of the model. Google Password Manager can synchronize passkeys between supported environments, with the passkeys protected using end-to-end encryption. Android also allows users on supported versions to select passkey providers rather than being restricted to one storage system. Chrome supports cross-device authentication, including using a phone to authenticate on another device.
Apple likewise supports passkeys through its platform credential infrastructure and has added mechanisms for external providers, management, and passkey import and export. This creates an important distinction that is easy to miss:
| Authentication model | What the service relies on | Main credential location |
|---|---|---|
| Password | Shared secret/verifier | User memory + service-side verifier |
| OTP-based MFA | Secret-generated code | Authenticator + service |
| Device-bound passkey | Public/private key pair | Specific device/authenticator |
| Synced passkey | Public/private key pair | Credential manager ecosystem |
| Security-key passkey | Public/private key pair | Hardware authenticator |
The last three are all part of the broader passkey/FIDO ecosystem, but their operational characteristics are not identical. A synced passkey can make device replacement easier, while a device-bound credential can impose more administrative work when hardware is replaced or lost. That trade-off is increasingly becoming an identity-management question rather than merely a password-security question.
The Meaning of “You Are You” Is Moving Up the Stack
Consider what happens when a person signs into a cloud service. The service may already know an account identifier. An identity provider may have established an account relationship. A passkey then proves control of a registered authenticator. After that, the service issues a session or access token that represents the authenticated session.
The password used to sit near the center of that chain. Passkeys move the proof of possession toward the device or authenticator while leaving other parts of the identity architecture intact. This helps explain why eliminating passwords does not eliminate identity infrastructure.
In September 2026, NIST and CISA finalized guidance specifically addressing the protection of tokens and assertions from forgery, theft, and misuse. The document covers identity providers, authorization servers, single sign-on, federation, and API access. NIST notes that tokens can become dangerous in an attacker’s hands even when the initial authentication process is secure. In other words, a strong login credential solves one problem. It does not mean that everything issued after login is automatically trustworthy.
Microsoft Is Also Removing Some Older Assumptions
The enterprise transition is becoming more concrete in 2026. Microsoft announced that passkeys would become the default authentication experience in Microsoft Entra ID beginning September 1, 2026, with users who had SMS or voice authentication enabled being automatically enabled for passkey registration and prompted to register when performing multifactor authentication. Microsoft also announced plans to retire Microsoft-provided SMS and voice authentication in Entra ID beginning February 1, 2027, with limited exceptions and later deadlines for certain accounts.
That is an important change in authentication policy, but it should not be interpreted as meaning passwords or SMS authentication disappeared everywhere on September 1. It applies to Microsoft’s Entra environment and its stated migration schedule. The broader significance is that passkeys are increasingly being treated as a standard authentication mechanism that organizations can deploy at scale rather than an optional convenience feature.
What Happens When a Device Is Lost?
This is where passwordless authentication becomes less straightforward. A password can be memorized and entered into a replacement device. A device-bound passkey cannot simply be remembered. If the only credential is stored on a lost device, the account needs another registered authenticator or a recovery mechanism.
Synced passkeys address some of this problem by allowing credentials to become available through a credential-management ecosystem. Google documents synchronization across supported platforms, while Microsoft distinguishes synced credentials from local Windows passkeys. But synchronization introduces a different dependency: the security and recovery model of the credential provider becomes important. The question therefore changes from “Can I remember my password?” to “How do I recover access to my authenticators without creating an easier path for an attacker?”
That is a harder systems-design problem than simply removing the password field.
Passwordless Does Not Mean Identity-Free
Another common misunderstanding is that a biometric passkey means a website receives the user’s fingerprint or face data. In the normal platform-authenticator model, the biometric or PIN is used locally to authorize use of the credential. The website receives the cryptographic result, not a copy of the user’s biometric template. WebAuthn’s architecture deliberately places the user agent between the web application and authenticator and requires user consent for authenticator operations.
The practical result is that authentication can become more private in one respect: the service does not need to collect a reusable password, and the biometric check can remain local to the device. But privacy still depends on the surrounding account and platform ecosystem. Credential managers, account recovery systems, device-management policies, and identity providers all remain part of the trust chain.
A New Problem: Credential Portability
As passkeys become widespread, portability becomes one of the industry’s unresolved technical and operational questions. Users increasingly have credentials spread across phones, computers, browsers, password managers, and security keys. A person may want to move between platforms without losing access to accounts. Organizations may want to change identity providers without forcing every employee through an entirely new enrollment process.
Apple now documents passkey import and export capabilities, while the wider FIDO ecosystem continues to work on interoperability between credential providers. The existence of portability mechanisms does not mean that every passkey can be moved freely between every system. Credential type, provider, platform policy, and organizational controls can affect what is possible. That makes interoperability one of the areas worth watching as adoption expands.
What Is Confirmed—and What Is Still Unsettled?
Several parts of the transition are now established.
- Public-key authentication through WebAuthn is a formal web standard, with Level 3 becoming a W3C Recommendation in August 2026.
- Major operating systems and browsers support passkeys, including Android, Chrome, and Windows.
- FIDO’s 2026 research reports billions of passkeys in use and substantial consumer and enterprise adoption, although the figures are estimates and survey-based.
- Microsoft is actively moving Entra customers toward passkeys and away from its native SMS and voice authentication services according to a published 2026 schedule.
- WebAuthn Level 4 remains a working draft rather than a finalized standard.
Several questions remain less settled. The industry still has to determine how smoothly credentials can move between competing ecosystems, how organizations should handle recovery at a large scale, how device-bound and synchronized credentials should coexist, and how identity systems should respond when the authentication credential is strong but the surrounding session or account-recovery process is weak.
There is also a broader conceptual question: if a passkey proves control of a cryptographic credential rather than a person’s real-world identity, organizations will need to be precise about what they actually mean when they say a user has been “identified.”
A Practical Way to Understand the Difference
For readers who still manage conventional passwords, the easiest way to understand the transition is to separate the pieces that passwords used to blur together. A password is something the user knows. A passkey is a cryptographic credential the user controls. A biometric or PIN can unlock that credential locally. The website verifies a cryptographic signature. An identity provider may then issue a session or access token. None of those steps, individually, necessarily proves a person’s legal or real-world identity.
For password users who want to understand why password entropy matters—and why passkeys approach the problem differently—TechTalksX’s Password Entropy Checker provides a useful reference point for the older shared-secret model.
The comparison is important because passkeys are not simply “stronger passwords.” They change where the secret lives, how it is used, and what the service has to verify.
What Comes Next
The passwordless transition is therefore less about deleting a login field than about relocating trust. With passwords, the critical secret is something the user can reproduce. With passkeys, authentication depends on a private key controlled by an authenticator, while the service retains a public key and verifies cryptographic proof. Web standards are becoming more mature, operating systems increasingly provide native support, and major identity platforms are changing their default authentication policies.
What is changing is clear: authentication is becoming less dependent on memorized secrets and more dependent on cryptographic credentials controlled through devices and credential-management systems. What remains uncertain is how the industry will handle recovery, portability, provider dependencies, and the distinction between proving control of an account and proving a person’s real-world identity.
That distinction may ultimately be more important than the disappearance of the password itself. A passwordless account still has an identity behind it. The difference is that the system is increasingly proving that identity’s authorized control through cryptography rather than asking a person to reveal a secret.