An enabled option is not a replaced password
Passkeys are intended to replace password-based sign-in with a credential linked to an account and protected by the person’s device or credential manager. In everyday use, authentication can be confirmed with the local method available, such as biometrics or a PIN. The important difference is not that every interaction disappears: it is that users do not have to remember or type a password for that sign-in. Apple and Google’s developer documentation describes passkeys as an authentication alternative for services and applications, but a service offering passkeys demonstrates technical availability only. It does not show how many people have created them or how many use them regularly. Apple and Google explain implementation and the user experience.
Passkeys should also be distinguished from one-time codes. A code is usually an additional proof or temporary mechanism sent or generated for a session; a passkey is a credential used in an authentication process based on cryptographic keys. Although both methods can reduce reliance on a password, they are not interchangeable and do not necessarily follow the same recovery flow. Calling an experience “passwordless” is not, by itself, enough to describe its security or ease of use: the outcome depends on how the service implements access, credential creation, and account recovery.
Precise terminology matters when making comparisons. “Compatible” may mean that an operating system, browser, or service supports the standard; “enabled” may mean that a person registered a credential; “use” may refer to a particular sign-in or to a proportion of sessions. These are distinct stages. Without a definition for each indicator, figures that appear similar may describe different things. A useful comparison therefore needs to identify what is being counted, rather than relying on the label attached to a number.
Availability, registration, and use: three different indicators
When trying to establish whether the technology is spreading, it is tempting to count services that announce compatibility or devices capable of storing credentials. That is a useful signal about infrastructure, but it does not measure individual adoption. A person may have a compatible device without registering any passkeys; they may also have created one once and still sign in with a password. The unit of analysis must always accompany the figure: accounts, people, credentials, access attempts, and sessions do not mean the same thing.
A company report can provide data about its own product: for example, the percentage of users choosing a method in a particular flow, or the conversion observed in a sign-in experience. But that figure is not automatically equivalent to general passkey use. The Dashlane case published by Google concerns a comparison of sign-in conversion in the context of that service; it is an outcome measure for a specific flow, not a census of users or a universal estimate. The case study should be read as contextual evidence, not as proof that the same difference occurs in every country, service, or type of account.
When assessing a published figure, it is worth checking at least four details before comparing it with another: which population was included, what period was measured, what behavior was counted, and who collected the data. A creation rate is not a recurring-use rate; an improvement in conversion at one sign-in step does not by itself demonstrate fewer security incidents. And if a platform reports that its users can use passkeys, that describes capability, not frequency. Keeping those distinctions visible helps prevent a measurement of product performance from being presented as a measure of market-wide behavior.
What surveys and studies can contribute
Survey reports can measure stated awareness, intention to use, or reported experiences. These are relevant dimensions, but they differ from authentication records observed by a service. Responses depend on the wording of the questions, the composition of the sample, and the recruitment method; moreover, knowing the term “passkey” does not mean someone has created a credential. If a result comes from a survey by an organization interested in promoting the technology, that does not invalidate it, but it does make it sensible to check who commissioned the study and how the data were collected.
The FIDO Alliance publishes a Passkey Index and a report on the state of passkeys in 2026. These materials may bring together indicators or findings related to their expansion, but any percentage needs to retain its context: source, date, market, definition, and method. It is not rigorous to turn a company indicator or a survey into a global adoption rate if it does not share the population and denominator of that supposed rate. The information available for this article does not detail the methodology or numerical findings of the 2026 report here; accordingly, no figure is attributed to it, and it is not used to support a quantified trend.
Field-based academic research can also be valuable when it observes real behavior, but its conclusions depend on the sample, the services included, and the study period. A finding from a specific setting can help formulate hypotheses and identify barriers; it does not necessarily represent users of other services or regions. When comparing studies, the question is not only “what percentage did they find?” but also “what event did they count, and who was counted?” If a publication does not make that clear, its number can serve as an indication, but not as a directly comparable measure.
The practical journey: devices, synchronization, and recovery
The experience depends on where a passkey is stored or synchronized and on which options the service offers for getting back into an account. Changing phones, losing a device, or using someone else’s computer raises different questions: Is the credential available on another device? Can it be authorized from a nearby phone? Can the credential manager’s provider restore credentials? Apple and Google’s documentation describes their respective platform approaches, but specific capabilities should not be generalized without checking which operating system, browser, and service are involved.
Recovery deserves particular attention because it may be the least visible part of access when evaluating a sign-in method. If someone loses access both to the device and to the synchronization mechanism, the alternative process depends on the service. That process may include other authentication factors or help from the company; a passkey does not, by itself, remove the need to design a recovery path. In organizations, access policies, device management, and the ability to revoke credentials associated with an account also matter. Implementation and administration are part of adoption, not afterthoughts.
Before enabling passkeys on an important account, it is reasonable to check which devices can use them, how the account can be recovered if the main device is unavailable, and which alternative access options the service retains. It is also worth finding out whether the credential is synchronized through a manager and how access to that manager is administered. These checks do not imply that a passkey is insecure; they help explain the complete system on which sign-in depends.
What conclusion does the available evidence support?
Official documentation confirms that Apple and Google provide guides to implementing and using passkeys; FIDO materials and cases published by platforms add signals about interest and outcomes observed in particular contexts. Together, this supports the conclusion that technical support exists and that some companies measure sign-in experiences with passkeys. It is not enough, however, to conclude that their use is already common among the general population: that would require comparable data on active users, frequency, markets, and periods, supported by an explicit methodology.
The most useful conclusion for readers and system managers is narrower: availability is a necessary condition for adoption, but it is not a measure of adoption. Compatibility, registration, selection at sign-in, and recurring use need to be separated; the effects of recovery and practical interoperability also need to be considered; and company case results should be treated as situated evidence. If future reports publish consistent definitions and comparable time series, it will be possible to assess change more accurately without confusing deployment with habit.
For now, anyone considering enabling this method can make a concrete decision without waiting for a universal statistic: check service compatibility, understand where the credential will be available, and review account recovery. Judging a market trend, by contrast, requires more than support announcements or isolated percentages. The central question remains simple and verifiable: how many people use passkeys effectively, in which contexts, and how consistently?