Passkey Adoption
The Passkey Adoption page (Dashboard > Passkey Adoption) tracks which MFA methods your employees actually use when they sign in — and what fraction of those sign-ins are phishing-resistant (passkeys / WebAuthn) versus phishable methods like SMS codes or TOTP apps.
Most organizations know which MFA methods are available in their identity provider. This page shows what is really being used, across every login service your employees touch — including SaaS apps outside your IdP — which makes it the scoreboard for a passkey rollout program.
[SCREENSHOT PLACEHOLDER: Passkey Adoption page showing the three summary cards (Phishing-Resistant Rate, Users with Passkeys, Total Auth Events) and the MFA Method Distribution bars below them]
How it works
The signal comes from the browser extension. As employees sign in to websites, the extension observes the authentication flow and classifies the second factor that was used:
- WebAuthn (Passkeys) — detected when the browser's passkey/security-key API is invoked during the flow. This includes platform passkeys (Touch ID, Windows Hello) and roaming security keys. These are the phishing-resistant methods: a passkey is cryptographically bound to the real site, so it simply will not work on a lookalike phishing page.
- TOTP — one-time codes from an authenticator app.
- SMS — codes delivered by text message.
- Push — approve-a-prompt style verification.
- Email — codes delivered by email.
No credentials, codes, or page contents are captured — only the kind of method observed. Events from across the fleet are aggregated into a per-day summary that refreshes hourly, so the page reflects today's sign-in activity with at most about an hour of lag.
Because measurement is per sign-in event (not per configured account), the numbers reflect real behavior: a user who has a passkey registered but keeps typing SMS codes counts as SMS usage.
Method reference
| Method | Phishing-resistant | Why |
|---|---|---|
| WebAuthn (Passkeys) | Yes | Bound to the genuine site's origin; cannot be entered on, or relayed through, a fake page |
| TOTP | No | A user can be tricked into typing the current code into a phishing page, which relays it in real time |
| Push | No | Vulnerable to prompt-bombing and real-time relay ("approve this sign-in") |
| SMS | No | Relayable like TOTP, plus exposed to SIM-swapping |
| No | Relayable, and only as strong as the mailbox protecting it |
Only the WebAuthn share counts toward the Phishing-Resistant Rate; everything else is treated as phishable regardless of how it is delivered.
Using the page
The page has three parts:
Summary cards
- Phishing-Resistant Rate — the percentage of observed authentication events that used WebAuthn/passkeys. This is the headline number to drive upward.
- Users with Passkeys — how many distinct users authenticated with a passkey
at least once today, out of all users who authenticated today (shown as
x/y). - Total Auth Events — the day's total observed MFA events; useful context for judging whether the percentages rest on meaningful volume.
MFA Method Distribution — a horizontal bar per method (WebAuthn (Passkeys), TOTP, SMS, Push, Email) showing each method's share of the day's authentication events.
Recommendation — when the phishing-resistant rate is below 100%, a callout summarizes what fraction of users still rely on phishable MFA and suggests enabling passkey enforcement for those groups.
[SCREENSHOT PLACEHOLDER: MFA Method Distribution section with a visible SMS bar, plus the yellow Recommendation callout underneath]
Using it to drive a passkey rollout
A practical rollout loop looks like this:
- Baseline. Note today's Phishing-Resistant Rate and the distribution. A typical starting point is a large TOTP/SMS share and a small passkey share.
- Find the laggards. SMS is usually the first target — it is the most phishable and the easiest to migrate. Use the per-user view to identify who is behind: each user's profile lists their Authentication Endpoints with the MFA type observed per service.
- Enable passkeys where they are missing. Work with the owners of the services showing heavy SMS/TOTP usage to enable WebAuthn, starting with your IdP — moving the IdP to passkeys moves every SSO-fronted app at once.
- Campaign by group. Target a department at a time (your Groups mirror the directory), announce the change, and have users register passkeys.
- Verify on this page. The distribution shifts within a day of real behavior changing — registration alone does not move the needle; usage does.
- Enforce. Once a group's usage is consistently passkey-based, disable the phishable fallback methods in the service. The Recommendation callout disappears when the rate reaches 100%.
Worked example
Your baseline shows a Phishing-Resistant Rate of 22%, with SMS at 40% of events. You enable passkeys on your IdP, run a two-week registration campaign for the Engineering group, then check back: the rate is 41% and the SMS bar has halved. The Users with Passkeys card shows 180/450 — so you repeat the campaign for Sales and Operations, then disable SMS as an MFA option in the IdP once the SMS bar approaches zero. Each stage is verified with observed behavior, not survey data.
Troubleshooting and FAQ
Everything shows zero. The page needs authentication events observed by enrolled extensions. Check that extensions are deployed and devices are active on the Devices page. A brand-new deployment shows data after the first day of sign-in activity.
The rate seems lower than our IdP's passkey registration numbers. Registration is not usage. Users often keep choosing a familiar fallback method even after registering a passkey, and sign-ins to services outside your IdP are counted too. That gap is exactly what this page is designed to expose.
Do sign-ins without any MFA appear here? This page summarizes events where an MFA method was observed. To find services where users sign in with no MFA at all, use the MFA column on a user's Authentication Endpoints table or the attack-surface views.
How fresh is the data? Summaries are recomputed about once an hour for the current day.
What about privacy? The extension reports only the category of MFA method observed during a sign-in flow. It never captures passwords, one-time codes, passkey material, or page contents — consistent with the platform-wide principle that credentials never leave the endpoint.
Related pages
- Users and Groups — per-user MFA detail on the Authentication Endpoints table
- Devices — confirm extension coverage before trusting the numbers
- Identity Verification — phishing-resistant identity checks for the help desk