Every smartphone on sale can hold a passkey

The question from the field

The question came from a sales leader at a financial services company, not from its IT function. The organization’s identity provider was configured to require a password change every three months, a value set by an administrator in the provider’s configuration, and each cycle produced the same result. Some members of the field team missed the deadline; others attempted the change and failed. Those locked out could not read their email or open the applications on which their work depends, and they turned to their leader, who then spent a considerable part of each cycle coordinating with the IT department to restore access. The work fell outside the leader’s role, consumed time meant for the team, and recurred every three months. The leader was not seeking a security programme. The objective was a team that could sign in and sell.

The proposal brought to us was modest and specific: procure passwordless sign-in for the leader’s own unit, with the identity platform fronting Google Workspace so that email and the associated Google tools sat behind a passkey rather than an expiring password. One question had to be answered before the proposal could go to IT. The team works in the field, on phones its members own, and some of those phones are not new. Could those people sign in with a passkey at all?

Two things about the question are worth saying before answering it. First, the setting that caused the lockouts is out of step with current guidance, and the fault is shared. NIST’s digital identity guidelines now state that verifiers shall not require periodic password changes, and shall force one only on evidence of compromise.¹ That requirement is addressed to the verifier, which is the identity provider, not to the administrator who configures it. The vendor shipped the setting; the organization chose ninety days. In a financial services company that value is rarely arbitrary: until 2022 the payment card standard required every user password to change at least once every ninety days, and the current version still accepts that rotation, as one of two options, for accounts that authenticate with a password alone.² Compliance obligations keep such settings in place long after the guidance has changed. But the clause now applies only where a password is the sole factor, and the standards council’s own guidance says an assessor may mark it not applicable once every in-scope system uses multi-factor authentication. A passkey removes the password altogether, so there is nothing left for the clause to govern and nothing to rotate. How a passkey is counted against the standard’s other authentication requirements is a question for the assessor; the rotation cycle is not. The cycle does not become easier; it ends, and the setting that produced it has no counterpart. Second, the readiness question is the most common one raised in any passwordless deployment, and it is usually answered from a desk, by consulting a device-support matrix and extrapolating. We answered it that way first, and then went to the market to check. This note sets out what a passkey actually needs from a phone, what we found when we asked the people who sell them, what it would take to turn that into a measurement, and why the answer generalises well beyond the market where we asked.

What a passkey needs from a phone

A passkey is a public-key credential created and stored by the phone’s platform, so what matters is the platform, not the sensor. Two cut-offs define readiness.

On Android, passkeys are supported on devices running Android 9 or later with Google Play services present; the platform’s Credential Manager stores them in Google Password Manager by default, and since Android 14 a user can choose another provider.³ Android 9 shipped in August 2018.⁴ The Go editions that the lowest-priced phones ship with carry Play services, so they qualify. On iPhone, passkeys arrived with iOS 16 in September 2022, with iCloud Keychain and two-factor authentication turned on, and iOS 16 runs on the iPhone 8 and every model since.⁵ Both cut-offs sit at the same place in a phone’s life: a handset that misses them launched on Android 8 or earlier, or is an iPhone 7 or older, and was never updated. In practice that is a phone bought before 2019 and never updated since.

Two further conditions are about the person, not the device: a screen lock must be set, and an account must be signed in for the passkey to sync to. Both are easy to miss when the question is asked about hardware, and both matter more than the sensor.

What a sensor decides, and what it does not

Every smartphone unlocks by some means, and Android’s compatibility definition grades the strength of each.⁶

A fingerprint sensor is almost always Class 3, and it is what a phone offers when a passkey must be confirmed. The 2D face unlock on a low-priced phone is Class 1: it opens the phone, and the passkey prompt falls back to the PIN or pattern instead. That fallback is not a degraded mode. WebAuthn’s user verification is satisfied by a PIN exactly as it is by a fingerprint; the relying party sees the same verified flag either way.⁷ A fingerprint makes a passkey convenient. A screen lock makes it work.

The chain that produces that verified flag is where readiness is decided. The website asks the browser, the browser hands the ceremony to the platform, the platform hands it to a passkey provider, and the provider asks the person to confirm with whatever the phone provides: a strong biometric if one is enrolled, a PIN or pattern if not. The sensor matters only at the last step. Everything before it is software.

What we found in the market

In December 2025, two months before our first application integration went live, we visited a phone market in which each brand sells from its own kiosk: iPhone, Samsung, Infinix, Tecno, itel, Huawei, and others. At every kiosk we put the same question to the representative: was any phone available, at any price, without a fingerprint sensor or face unlock? Every representative gave the same answer: none, and the cheapest model on the shelf had both. We put the same question in writing to several dealers and received the same answer.

That is informant evidence, and it is about sensors. It establishes that the lowest-priced smartphone each brand sells today unlocks with a fingerprint or a face, as reported by the people who sell them. It does not establish an OS version, whether Google services are present, or whether a passkey can in fact be created on that phone. Those are the questions that decide readiness, and they require a device-level test.

A protocol anyone can run

We did not test the phones on the kiosks, and we state that plainly. What we have from the market is what the sellers told us about sensors. What we have from the standards and the vendors is where the cut-offs sit. The step that would join them is a device-level test. The kiosk layout makes it straightforward to specify, and we set it out here so that it can be run in any market, by us or by others.

At each brand kiosk, take the lowest-priced model currently on sale and record: model, launch year, price, shipped OS version and whether it is a Go edition, whether Google services are present, the sensor type and its class from the manufacturer’s specification, the screen-lock options offered, whether a passkey can be created, which verification the phone offers for it, and whether that passkey then signs in. A test account is signed in on the display unit with the seller’s permission, and the manufacturer’s specification page is recorded for every model so the sellers’ claims about sensors can be checked against the catalogue.

We state the expectations before anyone collects the data. Every phone with Android 9 or later and Google services will create a passkey. Most will confirm it with a fingerprint. Phones without Google services will fail. A single Android 9 phone with Play services that cannot create a passkey falsifies the first claim; a majority falling back to PIN falsifies the second.

The third expectation is the exception to the rule in the title, and we have confirmed it once, on a phone we own rather than a kiosk unit. On 4 September 2026 we attempted to create a passkey for Trustaige ID on a Huawei Mate XT Ultimate Design, model GRL-LX9, running EMUI 14.2.0: a tri-fold flagship with a fingerprint sensor and no Google services. The ceremony did not complete in Huawei’s own browser, and it did not complete in Chrome either. That second failure is the informative one. Chrome on Android does not hold passkeys itself; it hands the ceremony to the platform’s credential manager, which on a Google-certified phone is backed by Play services. With no provider to call, both browsers fail identically, at the hand-off from platform to provider, so the limit is the platform’s, not the browser’s. The most expensive phone in this note is the one that failed, and the exception illustrates the rule: the sensor is present and irrelevant, and the software decides.

The result should be read narrowly. It shows that this phone could not create a synced platform passkey for a website, which is the ceremony our platform asks for. It does not show that WebAuthn never works on Huawei hardware. Huawei ships its own FIDO2 client for its browser and apps, built on the same standard, with platform and roaming authenticators,⁸ and we did not test a USB or NFC security key, which would bypass the missing provider entirely. Nor does it say anything about passwordless sign-in in China, where FIDO adoption runs through domestic platforms rather than Google’s, and where banks and government services have used the standard for years.⁹ What it says is precise: a phone sold without Google services falls outside the cut-offs this note describes, whatever its price and whatever its sensor.

Why the answer generalises

The phones on those kiosks are not a local peculiarity; they are the global entry tier. Transsion’s three brands, Tecno, Infinix, and itel, took close to half of the 84.4 million smartphones shipped in Africa in 2025 by Omdia’s count, and the same Go-edition models are sold across South Asia and beyond.¹⁰ If the cheapest phones this tier puts on sale can hold a passkey, every smartphone priced above them can too.

The desk data points the same way. In StatCounter’s measurement of Android web use for August 2026, versions at or above the cut-off, Android 9 and later, accounted for 96.5 percent of Android mobile page views worldwide and 95.3 percent in Africa. Android 8 and everything older together made up 3.3 percent worldwide and 4.7 percent in Africa, and Android 9 itself, the oldest capable version, 2.0 and 3.3 percent.¹¹ Roughly one Android phone in thirty worldwide, and one in twenty in Africa, still browses from software below the cut-off. That is the population the customer was asking about, and it is small, shrinking, and defined by software age rather than by price.

Capability, confirmation, admission

Most writing about passkey readiness collapses three questions into one, and the collapse is the source of most wrong conclusions.

Capability is whether the phone can hold a passkey. The cut-offs above decide it, and the cheapest phones on sale clear them, while a flagship without Google services does not. Confirmation is how the phone verifies the person when the passkey is used: a fingerprint on most, a PIN on the rest, and both satisfy the standard. Admission is whether an organization’s policy accepts the credential at the point of entry, and that is decided by the organization, not the phone.

The third question is where the field team is actually exposed. A passkey created on a low-priced Android is a synced credential, protected by the person’s Google account, not bound to the hardware. An organization whose posture policy requires hardware-bound credentials for a role will refuse every one of those phones, however new. That is a legitimate choice for administrators and a poor one for a field sales team, and it is the organization’s choice to make, per organization and per role. The sales leader who asked us faces no such policy: for a unit whose principal risk is a locked-out seller, a synced passkey on a phone the person already carries is the appropriate bar, and the device was never the obstacle.

One practical point for teams that share laptops: a passkey on a phone can sign a person in on another device by scanning a code, which requires Bluetooth and a data connection on the phone. Both belong in the protocol’s checklist.

What this does not settle

• One market, one visit, and informant evidence. We asked the people who sell the phones; we did not test the phones on the kiosks. Capability at the entry tier is inferred from the software those phones ship with, not demonstrated on them. The protocol above is how to close that gap, and we would welcome the table from any market.
• Owned phones are not display units. A team member’s own phone may have neither a screen lock nor a signed-in account, and this note does not measure how common that is.
• Phones without Google services. Huawei’s current models and any other handset shipping without Play services fall outside the cut-offs and are the exception to the title. The Mate XT test above is one confirmed case; roaming security keys and Huawei’s own FIDO client were not tested.
• The second-hand market. Used iPhones from before the iPhone 8, and used Androids that shipped on Android 8 and were never updated, are sold in the same markets and are not in this sample.
• Sensor class is read from specifications, not measured. A manufacturer’s grading is the best available evidence and is not a test.
• We have an interest in the answer. Trustaige sells a passkey-based identity platform. The method is set out so that anyone can check the claims.

The phone was never the obstacle

The phones are ready. They have been ready since roughly 2019, and the people who sell them cannot find one that is not. The exception is a phone sold without Google services, and it has nothing to do with age or price. What decides whether a field team can sign in with a passkey is a screen lock, a signed-in account, and a policy set by the organization. Two of those belong to the person. The third belongs to the organization, and it is the one that merits a decision.

The sales leader’s problem was never the phones the team carried. It was a password that expired every three months under a setting made for compliance and never revisited. Remove the password and the lockouts, the calls, and the time spent restoring access go with it. That is the assurance the leader was asking for, and the least expensive phone on the kiosk already has what it needs to provide it.

References