WebAuthn L3 Support in Credential Managers

Passkey feature support is documented per browser and per operating system. That is how the specs are written and how our own PRF support tables are built, and for a long time it was enough, because the passkey was stored by whatever shipped with the device.

That assumption no longer holds. Since Android 14 and recent Windows 11 builds, third-party credential managers act as full passkey providers, which adds a third axis that the browser and OS tables do not cover. A user on Android with a third-party manager set as the default provider is in a different situation than the same user on the same phone with Google Password Manager. As a relying party you usually notice the difference only when a feature returns nothing and raises no error.

This article covers that third axis: which WebAuthn Level 3 features depend on the credential manager, what we can verify today and where the answer is still open.

Experiment with passkey flows in the Passkeys Debugger.

Try for Free

One note on wording. Password manager, credential manager, passkey manager and passkey provider all mean the same thing here: the software that stores the passkey and answers the WebAuthn call. We use the four labels interchangeably and spell out a distinction only where it changes the answer.

The three layers have to be separated before the matrix makes sense, because most of the confusion in this topic comes from mixing them.

• Browser and platform layer. getClientCapabilities and related origin requests live here. They depend on the browser version and, in the case of related origins, on your own .well-known file. A credential manager cannot add or remove them.
• Credential manager layer. The PRF extension, conditional create, conditional UI, largeBlob and the Signal API all need the provider to implement them. This is the layer the matrix covers.
• Authenticator layer. credProtect, credBlob, minPinLength and enterprise attestation are CTAP features of hardware authenticators. A software credential manager does not implement them at all. They are covered in our security key article and not in the matrix below.

The distinction decides where you look first. "PRF does not work" can mean that the browser does not surface it, that the provider does not implement it or that the credential was created before the feature existed. The three have different fixes.

The matrix has two parts. The first is the status per provider and feature, built from our own tests, community data and vendor documentation. The second lists what we measured ourselves, per operating system and browser, because the same manager answers differently depending on where it runs.

Legend: ✅ works in every combination we measured, 🟡 partial, meaning it works on some platforms or browsers but not others or only in a share of attempts, ❌ no output in the combinations we measured. There is no symbol for "we do not know": a provider we cannot measure is named below the table instead of taking up a row.

Status: August 2026. The two PRF columns are taken from our PRF support article, which owns the detail, the per-platform numbers and the sources for that feature.

Two providers sit below the table rather than in it. KeePassXC and KeePassDX are covered by community data that puts both in the group returning a PRF value on the assertion, KeePassXC only sometimes at creation, and we have run neither ourselves.

Every row in the table above is a measurement. A cell we cannot stand behind keeps the provider out of the table rather than filling it with symbols that look like knowledge.

Sources and caveats per row:

• Proton Pass returns a PRF value at creation and the identical value on the next authentication, tested by us on macOS 26.3 with Chrome 151. That is the CTAP 2.2 shape and the property an encryption feature depends on, and 1Password is the only other third-party manager where we have measured it.
• Enpass creates a passkey silently while the browser says it cannot. Chrome 151 reported conditionalCreate: false for the active Enpass provider and the ceremony went through anyway, in two separate runs. Enpass also returns a PRF value at creation and the identical value on the next authentication, which puts it in the same CTAP 2.2 bracket as iCloud Keychain and Google Password Manager. It declined largeBlob at registration and acted on none of the three signal calls.
• The PRF columns are a summary of another page. The PRF article carries the per-platform numbers, the screenshots and the sources behind them. Where a PRF cell here disagrees with that article, the article is the authority.
• Twelve rows carry our own measurements for everything outside PRF, eight of them on macOS 26.3 with Chrome 151 and each with the manager set as the active provider. Section 4.2 lists every run. Google Password Manager stored a largeBlob and returned the identical value in a second ceremony, and answered conditional UI from the autofill dropdown. 1Password and Enpass declined largeBlob at registration. iCloud Keychain stored and returned the blob.
• All twelve accepted every Signal API call and only one acted on it. Google Password Manager renamed the entry after signalCurrentUserDetails; the other eleven left theirs untouched. No call threw an error, and the reported capability contradicted the observed behaviour in both directions. Section 6 has the numbers.
• Conditional create splits the field. Chrome 151 on macOS reported conditionalCreate: false for Google Password Manager and iCloud Keychain and rejected the ceremony for both, which matches the version table in our conditional create article: the Chrome path covers Windows, Linux and Android, and macOS runs the feature in Safari. 1Password, Bitwarden and Proton Pass created a passkey silently on the same machine. The versions in the column come from that article, except the Dashlane entry on iOS 18 and macOS 15, which Dashlane documents itself.
• Create and get are separate capabilities, so a single "supports PRF" answer per vendor can be wrong in either direction. Keeper was listed as creating the passkey and then returning nothing on the assertion until we ran it ourselves in August 2026: it returned a value at creation and the identical value on the next authentication. Either Keeper closed the gap or the community numbers came from a different platform. Our own run takes precedence and the row now says so.
• Keeper declares almost everything and delivers less. Chrome 151 returned twenty-four capability keys for the active Keeper provider with all but two set to true, including extension:largeBlob. Keeper then declined largeBlob at registration and acted on none of the three signal calls it had just reported as supported. Conditional create is the one place where the flag and the behaviour agree.
• Bitwarden differs by platform. It returns PRF on Linux with Firefox and nothing on iOS with Safari, and our own test on macOS with Chrome came back empty. The provider path has been open since 2025.
• Dashlane uses PRF as a relying party to unlock its own vault and still returns nothing to third-party sites. A vendor announcement about PRF therefore says little about what your own integration will receive.
• Microsoft Password Manager and Windows Hello are two different providers. The former is the manager built into Edge and reports its own AAGUID, d3452668-01fd-4c12-926c-83a4204853aa against Windows Hello's 08987058-cadc-4b81-b6e1-30de50dcbe96. Its behaviour differs as well, and more sharply than we previously recorded: the assertion does not return nothing, it fails.
• Microsoft Password Manager aborts the whole ceremony over an extension it cannot serve. At registration it confirmed largeBlob through the extension output itself, not merely through a capability flag, and returned a PRF value. Every later get() that asked for largeBlob or PRF failed with a NotAllowedError after the user had already picked the passkey and confirmed. A modal get() for the same credential without any extension succeeded on the same machine in the same session, which rules out the modal ceremony as the cause. WebAuthn expects a client to ignore an extension it does not support. Here the request takes the login down with it.
• Samsung Pass returns PRF on the assertion and nothing at registration. The registration came back with no extension result at all for PRF, and the next authentication returned a value. That is the CTAP behaviour where hmac-secret is available unconditionally, and it means a relying party that gates its encryption feature on the registration result will write Samsung Pass off for a capability it actually has. Read both ends before you decide.
• Windows Hello declares more than it delivers. On Windows 11 with Chrome 151 the client reported twenty-four capability keys with all but two set to true. extension:largeBlob came back true and the registration returned no blob support at all. All three signal calls were reported as supported, all three were accepted and the entry under Settings > Accounts > Passkeys was unchanged afterwards. This is the same pattern as Keeper, on a platform authenticator rather than a browser extension.
• Windows Hello needed the February 2026 update on 25H2 to expose hmac-secret, which is the CTAP feature the PRF extension is built on. hmac-secret is not itself a Level 3 feature, it is the authenticator side that L3's PRF extension talks to, which is why a browser can support PRF while the platform still hands back nothing.
• largeBlob is the thinnest column. Apple documents it for iCloud Keychain since iOS 17, Google documents it as unsupported for Google Password Manager, and our own run on macOS 26.3 with Chrome 151 wrote a blob to a Google Password Manager passkey and read it back unchanged. We record what we measured and leave the contradiction visible.
• A feature has to pass two gates before it reaches a third-party manager. The browser or the platform has to forward it, and the provider has to implement it. The Signal API needs Chrome or Edge 132 and above, and on Android additionally Android 15 with androidx.credentials 1.6.0; Chrome's own documentation states that desktop extension providers then decide whether to act on the signal. Conditional create has been up to the provider since iOS 18 and Android 14. For every provider in the table the first gate is open, so each ❌ in those two columns is a decision by the provider and not a missing browser feature.

We put twelve providers through the same test page, eight of them on one Mac, three on a Windows 11 machine and one on a Galaxy phone. The table grows with every provider we can reach.

Three results stand out:

• Conditional create differs by provider on the same browser. Chrome 151 on macOS reports conditionalCreate: false for Google Password Manager and iCloud Keychain and rejects the ceremony for both. With 1Password, Bitwarden, Proton Pass, Enpass and Keeper the same call created a passkey without a prompt, none of which had a saved password for the origin either. NordPass sits between the two: the ceremony returns a credential, but only after its own window asks the user to confirm, which is the opposite of the silent upgrade the feature exists for. Microsoft Password Manager advertises the capability, holds a password for the origin and still rejects the ceremony. Windows Hello advertises it too and has no password store to upgrade from in the first place. For Enpass the browser reported conditionalCreate: false and the ceremony still went through, so the flag and the behaviour disagree within a single run.
• Conditional UI works almost everywhere, and the exception matters. Eleven of twelve providers answered the autofill request with a usable credential. Extension-based managers serve it from their own overlay rather than the browser dropdown, so check both when you debug it; Enpass is the clearest case, its list replaces the Chrome dropdown entirely. NordPass is the one that did not answer: the listener runs, the field is focused and no credential is ever offered, in either surface. Without conditional UI the passkey never appears while the user types, and they have to open the manager by hand at every login.
• largeBlob separates the providers most sharply. Only iCloud Keychain and Google Password Manager stored a blob. All six third-party managers declined it at registration, and so did Windows Hello, which rules out the simple reading that shipping with the operating system is what decides it. Microsoft Password Manager is the one case that is worse than a decline: it accepted largeBlob at registration and then failed the write ceremony outright.

The first step of every run. The AAGUID decides which row a result belongs to, because a dialog that falls back to the provider shipped with the OS is the easiest way to mislabel a whole row.

Conditional UI, Google Password Manager on macOS 26.3 with Chrome 151. The dropdown names the provider, so the result cannot be confused with one produced by another manager. The credential list is fixed when the conditional request starts, so a passkey created afterwards only appears once you restart the request.

Conditional UI stays 🟡 for the managers we have not run ourselves. A ❌ there needs a failed run rather than a missing one. Enpass moved from 🟡 to ✅ for exactly that reason, and NordPass is the first provider that earned the ❌ the hard way, by advertising the capability and then offering nothing. Without conditional UI the passkey never appears in the dropdown and the user has to open the manager at every login, which degrades the flow without blocking it.

Passkeys Cheatsheet. Practical guidance, rollout patterns and KPIs for passkey programs.

Get Cheat Sheet

• Detect capabilities, not products. Ask getClientCapabilities and the extension outputs, then branch on the answer. Sniffing the provider by AAGUID does not work as a control flow anyway, because you only get the AAGUID from the attestation object at registration and not on a login, so it is unavailable at the moment you would need it. Treat the capability answer as an indication and not as proof, for the reason given in section 6.
• Design the missing case first. Decide what happens when PRF comes back empty before you design the path where it works. A flow that only survives with two providers is a flow for Apple and Google users.
• Never let a login depend on an extension request. An unsupported extension is supposed to come back empty. With Microsoft Password Manager it took the whole ceremony down instead: the same credential that failed a get() asking for PRF authenticated without complaint once the extension was dropped from the request. Ask for the extension in a separate ceremony, or retry without it when a get() fails and never put the extension on the request that has to authenticate the user.
• Do not push the problem onto the user. Asking people to switch credential manager is not an option. Keep the feature-dependent part optional, or offer a second path that works without it. Falling back to the provider shipped with the operating system is technically sound, and it still reads as a downgrade to anyone who installed their manager deliberately, which is the commercial side of the same problem.
• Measure it in your own traffic. The provider distribution of your users is a property of your user base and not of the market, and it determines whether a feature-dependent flow is worth building at all.

getClientCapabilities() is the standardised way to ask what the current client and provider support, and it belongs at the start of any feature detection. It should not be the only check.

In a run on macOS 26.3 with Chrome 151, the browser reported all three Signal API capabilities as false for the active provider:

{
  "signalAllAcceptedCredentials": false,
  "signalCurrentUserDetails": false,
  "signalUnknownCredential": false
}

We called the three methods regardless, with three different providers active on the same machine and in the same browser. None of the calls threw an exception, and the outcomes were not the same:

The flag is wrong in both directions. Google Password Manager reports false and renames the entry anyway. Bitwarden reports true for all three signal methods and for PRF, and in two runs it applied no signal and returned no PRF output at all. Keeper reports true for all three signal methods as well and renamed nothing. Conditional create fails in both directions. Chrome reported false for Enpass and Enpass created the passkey regardless. Edge reported true for Microsoft Password Manager, and with a password for the origin sitting in that same manager the ceremony still came back with a NotAllowedError. The saved password matters here: conditional create has nothing to upgrade without one, so a rejection on an empty vault would prove nothing. We ran it twice, once without and once with the password, and got the same answer both times.

The shape of the answer varies too. With Google Password Manager, iCloud Keychain and 1Password active, Chrome returned eleven keys with several set to false. With Keeper active it returned twenty-four keys with all but two set to true, including extension:payment, extension:minPinLength and extension:largeBlob, and Keeper then declined largeBlob at registration. Windows Hello on Windows 11 answered with the same twenty-four keys and the same two exceptions, and declined largeBlob as well, so the pattern is not limited to browser extensions. In another combination Chrome left conditionalCreate and the three signal keys out of the response entirely. An absent key says something different from false, and neither is a promise about behaviour. Read the capability answer as a starting point and confirm the ones you depend on.

Bitwarden on macOS 26.3 with Chrome 151. Every capability in the upper block is green. The registration in the lower block returned no extension result at all for largeBlob and PRF, in two separate runs.

Microsoft Password Manager on Windows 11 with Edge 151. The provider confirms largeBlob through the extension output at registration, which is a stronger statement than a capability flag.

The same run, a few ceremonies later. Both requests that carry an extension come back with a NotAllowedError after the user has already picked the passkey and confirmed. A modal request for the same credential without any extension succeeded in the same session.

Gate the feature on the capability check and you skip the calls Google Password Manager would have executed. Trust the resolved promise instead and you record twelve successes where you got one. Nothing in the return value separates the provider that acted from the eleven that did not.

The display name in Google Password Manager carries the value we sent through signalCurrentUserDetails, on a client that had reported the capability as false a minute earlier.

The silent no-op is the more dangerous of the two, because nothing in the API distinguishes it from success. A signal call that resolves without an error shows only that the browser accepted it, and there is no return value to inspect. Where revocation is part of your security model, verify it in the credential manager during testing instead of trusting the resolved promise, and keep a server-side path that does not depend on the signal arriving.

The measurements were taken in August 2026. The method is documented here because it determines how much weight a single cell can carry.

• Our own tests ran on macOS 26.3 with Safari 26.3 and Chrome 150 and 151, and on Windows 11 with Chrome 151 for Windows Hello, with each credential manager set as the active provider one at a time. PRF was measured against our public PRF demo, the other features against a test page that registers a passkey, reads the AAGUID to prove which provider answered and then runs conditional create, conditional UI, a largeBlob write and read, then the three signal methods in that order.
• PRF is compared against one credential and not one provider. The value from registration only means something next to the value from an authentication with the same credential. In an early Enpass run the vault held a second passkey created by the conditional-create step, the two values came back different and the obvious reading was that Enpass derives PRF non-deterministically. Repeating the run with a single credential in the vault returned the identical value. We report the second run, and the first one is the reason this bullet exists.
• Every run is tied to one provider by its AAGUID. A dialog that falls back to the provider shipped with the OS is the easiest way to mislabel a whole row, so the page compares the AAGUID against the manager under test and voids the run when the two differ.
• Community results and vendor documentation cover the combinations we cannot reach ourselves. The community numbers are per-attempt success rates from small samples and indicate a tendency and no more. Vendor documentation about the vault says nothing about what the provider returns to your site. Where we can run the combination ourselves, our own result takes precedence over both.
• Each feature is documented on exactly one page. The matrix carries one symbol per provider and feature; the feature article carries the browser and OS detail behind it. When a status changes, the feature article is updated first and the matrix follows, so the two cannot drift apart.
• A resolved conditional create is not proof that it was silent. The API returns a credential either way, and nothing in the response says whether the provider put a window in front of the user. NordPass exposed this: the ceremony succeeded and the page reported a silent creation, while NordPass had opened its own dialog and waited for a click. We caught it because someone was watching the screen. For the providers in the ✅ column we recorded the result and not the presence of a dialog, so read that cell as "the ceremony went through" and verify the silence yourself if your flow depends on it.
• Conditional create needs a saved password to be measurable. The ceremony upgrades an existing password entry, so a manager that holds none for the origin answers with a NotAllowedError whether or not it supports the feature. A silent creation is proof of support; a rejection only counts once the manager demonstrably holds a password for the origin. Every ❌ in that column comes from a run that met the second condition.
• Open cells stay open. A cell without a test result or a clear vendor statement keeps its ❓. An incorrect ✅ in a table like this can cost a team weeks of implementation work.

One complete run, Google Password Manager on macOS 26.3 with Chrome 151. The blob written in one ceremony returns byte for byte in the next, and the three signal rows show the contradiction between the reported capability and the observed behaviour.

Update rhythm. We review this page quarterly, and additionally when a browser ships a Level 3 feature, a credential manager announces one, a vendor sends us a correction or our own field data contradicts a cell. Each review updates the status date even when nothing changed, so you can see how old the answer is.

Last checked: August 2026. Next scheduled review: November 2026.

If you maintain a credential manager and a row here is wrong or outdated, tell us and we will retest it. We would rather publish your result than our guess.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

This matrix is hard to build from the outside because the relevant behaviour occurs in production, on devices you do not own, with providers you did not choose.

Corbado Observe turns that into data from your own login:

• Authenticator inventory: see which providers your users bring, identified by AAGUID, instead of estimating from market share.
• Capability outcomes: conditional create, conditional UI, hybrid transport and signal support show up as real outcomes in the login flow, per platform and per provider.
• Error root cause: when a feature returns nothing without an error, the failing step is the starting point for debugging.
• Per-user reconstruction: replay a single session when a customer reports that passkeys "do not work" with their credential manager.

That is also how the open cells in the matrix will be filled: with outcomes from real traffic rather than with vendor claims.

The browser and OS view of passkey support is well documented, and it is no longer sufficient on its own. The credential manager decides whether PRF returns a value, whether a silent upgrade runs and whether a revocation ever reaches the user's credential list.

Version 1 has more open cells than closed ones, which is an accurate picture of the ecosystem. We close them by testing what we can reach and asking the vendors for the rest.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

The PRF extension, conditional create, conditional UI, largeBlob and the Signal API all need the credential manager to implement them. Related origin requests and getClientCapabilities are browser and relying party features, while credProtect, credBlob, minPinLength and enterprise attestation are properties of security keys rather than of a software credential manager.

Because the credential manager decides, and the same manager can behave differently per platform. Bitwarden returns PRF values on Linux with Firefox and nothing on iOS with Safari, so a single answer per vendor would be wrong. Detect the capability at runtime instead of inferring it from the product name.

Detect the capability instead of the provider, keep a working path for the case where the feature is missing and do not ask the user to switch credential managers. Falling back to the provider shipped with the operating system is technically sound, and vendors report that users who installed their own manager read it as a downgrade, most often in Japan and Germany.

Own tests on macOS 26.3 with Safari 26.3 and Chrome 150 and 151, the anonymous community results from our public PRF demo and vendor documentation where it is public and specific. Every cell carries a date and its source, and a cell with neither a test result nor a clear statement stays open.