The headline numbers on passkey adoption look about how you would expect them to look at this point. 87% of enterprises are deploying or have already deployed them. Around half of the world's top 100 websites support them. Google reports 2.5 billion passkey sign-ins across 800 million accounts. NIST has formally classified syncable passkeys as AAL2-compliant. The UAE's SMS OTP phase out plan took effect in March, India's followed in April, and the Philippines has a June deadline. (We covered the full picture in the year passkeys went mainstream.)
Getting passkeys into production without breaking the rest of your auth stack is the part most teams underestimate. And it's the messy middle that conference talks tend to skip. "We rolled out passkeys and adoption hit 80%" is a great quote. It's also a small fraction of what actually happens between board approval and a stable production rollout. The teams hitting those numbers have done a lot of unglamorous work on enrollment timing, recovery, fallback hierarchies, channel coverage, and risk-based step-up. Most of it is invisible from the outside.
This piece is about what that work looks like, and what we have learned from helping enterprises ship passkeys to real users at Authsignal.
What "at scale" means
A passkey deployment is a system, adding a button to your sign-in page isn’t the only thing. You're committing to operating a credential lifecycle for every user you have, across every device they own, and every channel they might call you on, including the recovery scenarios they will eventually find themselves in.
The teams that do this well treat passkeys as one node in a larger authentication graph. The ones that struggle tend to treat passkeys as a swap-in for whatever they had before, then meet the edge cases one production incident at a time.
There are five places where a deployment usually lives or dies under load.
1. Enrollment that meets users where they are
The most-cited finding in the FIDO Alliance's 2025 deployment data came from eBay. When they moved their passkey enrollment prompt out of the settings menu and into the moment immediately after a successful login, adoption jumped 102%. About three-quarters of all new passkey enrollments came from that single auto-triggered prompt.
Timing explains most of that, not UI. Users who have just authenticated are in a small window where they're willing to do one more thing. Users sitting in a settings page are usually there to do something else and resent the detour. Same prompt, same product, very different result depending on when it appears.
Scaling this across a real user base is harder than it looks because the right moment varies. A first-time user needs to see a passkey at registration before any password gets created. A returning user with a password needs an uplift moment that doesn't feel like an interruption. Someone who has already declined needs a defined cool-down period before they see the prompt again. A user on a shared workstation should probably be skipped entirely.
In practice, what works is treating the prompt as a policy rather than a static piece of UI. You define when, you define for whom, and you define what cool-down applies after a decline. At Authsignal we expose this as a passkey uplift prompt that gets driven by rules, so the trigger logic lives next to the rest of your authentication policy instead of getting bolted onto the front-end.
2. Recovery that doesn't fall back into a password
Recovery is where a lot of passkey deployments fail in ways the team doesn't notice for months.
A passkey is bound to a device or to a sync ecosystem. When the user loses both, you need a path back into the account that's at least as resistant to social engineering as the passkey itself. If your recovery flow is "click a magic link sent to the email address on file," and your user's email account is protected by a password they have reused on three breached sites, you've built a phishing-resistant front door with a password-shaped hole in the back wall.
The NCSC's 2025 paper on traditional credentials and FIDO2 called account recovery the next target attackers will move toward as passkeys become standard. They specifically flagged post-compromise passkey registration, where someone who gets in through a weak recovery flow registers their own passkey on the account to maintain persistent access. We wrote up the full set of takeaways from that paper in our breakdown of the NCSC's FIDO2 analysis.
Recovery that holds up at scale needs a few things. More than one factor, so a single channel compromise isn't enough. A higher-trust signal than the original sign-in factor, otherwise you've created a downgrade attack. And it needs to be operable from a customer support context, because some percentage of users will not be able to self-serve no matter how good the flow is.
That last point is where omnichannel matters. If your recovery only works on the web, you've moved the problem to your contact center, which now has to verify identity using the same knowledge-based questions that scammers have been defeating for a decade. Authsignal's call center authentication path lets a support agent trigger the same factors the user has already enrolled, including passkeys, push, biometrics, and WhatsApp OTP, all without leaving the helpdesk interface. Recovery stays on the same security floor whether the user comes in through the app, the website, or the phone.
3. Step-up that runs on signals
Once a user is signed in, the next question is what they're allowed to do without re-authenticating. Most teams default to one of two answers and neither is great.
The first option is to trust the session for everything until it expires. It's fast, but a stolen session token, a shared workstation, or a compromised browser extension all give an attacker the same powers as the user.
The second is to challenge on every sensitive action. Safer, and also punishing for users doing high-frequency tasks like payments or moderation. They tend to find a way around it, often by leaving the session permanently authenticated on their primary device.
The middle path is step-up authentication driven by risk. Low-risk actions stay frictionless. High-risk actions require a fresh, phishing-resistant factor. What counts as "high risk" depends on the action, the device, the location, the time of day, the velocity of recent activity, and the user's history.
Building this in code is a project. Teams that try usually end up with a tangle of conditionals that nobody wants to touch six months later. What scales is a rules engine where product, fraud, and security teams can compose policies without a deploy. At Authsignal that lives as a no-code rules engine with backtesting, so a team can see what a new rule would have done against last month's traffic before it goes live. The thing that makes it work in practice is that the people who understand the risk are the same people who can change the rules. (For a worked example with code, see our walkthrough on adaptive MFA with passkeys.)
4. Fraud signals that survive the move to passkeys
A common misconception is that passkeys make fraud detection easier. They don't. They eliminate one specific class of attack, credential phishing, which is a large class but far from the only one. Account takeover via session hijacking, malicious insider activity, mule accounts, and AI-driven credential stuffing all still happen on passkey-protected accounts.
What changes is the signal teams used to rely on. "This login is suspicious because the password came from a strange place" stops working because the credential is bound to the device, so device origin no longer carries the same information. You need different signals.
What works at scale tends to be behavioural and contextual: device fingerprint and posture, network reputation, velocity of attempts across the user base (not just per user), cross-channel coherence where a session on web that suddenly behaves like a session on mobile is a flag, and behavioural biometrics like typing cadence and pointer movement, which bot operators have so far failed to spoof at scale.
Verizon's 2025 DBIR put credential stuffing at 19% of all authentication attempts when measured against SSO logs. That number doesn't go away when passkeys arrive. What goes away is the easy detection. Building or buying the replacement signal stack is part of the cost of moving to passkeys, and it's one of the things teams routinely under-budget. This is where Authsignal's risk-based authentication and user observability tooling earn their keep.
5. An orchestration layer that doesn't become the bottleneck
The piece that ties the previous four together is orchestration. Enrollment, recovery, step-up, and fraud signals are four views of the same authentication system, and they need to share state.
This is the part where teams either move fast or get stuck. The ones who get stuck try to bolt passkeys onto an IDP that wasn't designed for them, then build the orchestration logic in glue code spread across three services and two front-ends. Six months in, nobody understands how the system actually decides anything. Adoption stalls because every change requires an engineering sprint.
Faster deployments tend to separate the orchestration layer from the IDP. The IDP keeps doing what it does well, which is identity storage, federation, and session issuance. The orchestration layer sits on top and handles what the IDP was never built for: contextual authentication decisions, factor management, and lifecycle events across channels.
This is the architectural choice Authsignal was built around. We don't replace your IDP. We sit between your application and whatever you're already using, whether that's Auth0, Cognito, Azure AD B2C, Keycloak, or something custom. Passkeys, MFA, recovery, step-up, and rules all live in one orchestration layer behind a single API. The reason it ships fast is straightforward: organisations with an existing identity stack don't want to migrate it, and organisations starting fresh don't want to rebuild authentication every time their requirements change.
What we keep seeing in production
A few patterns show up across enough deployments that we treat them as defaults now.
Prompt timing produces the largest single lift in activation rates. Teams that move the prompt from settings to a post-login moment see a step change, often somewhere between 50 and 100 percent. Teams that A/B test prompt copy or button placement see incremental gains on top of that. When matters more than how.
Recovery is the most common reason a rollout stalls in QA. A team gets passkeys working end-to-end on the happy path, then someone asks "what happens when the user loses their phone" and the answer takes another six weeks to design. Building the recovery flow alongside the enrollment flow saves months.
SMS volume drops faster than passkey activation rises. Users who enroll a passkey tend to use it heavily because it's faster than typing an OTP, so even moderate activation rates produce outsized SMS savings. This is usually one of the easier wins to put on a finance slide.
Call center load shifts before web load does. Once a deployment is live, the support side of the business starts seeing changes first. The kinds of tickets coming in change (more recovery, fewer password resets) and so does how agents resolve them, with authenticated factors replacing knowledge-based questions.
We've written up more of what processing millions of passkey transactions has taught us elsewhere. The clearest public example is Air New Zealand, where over 30% of customers opted into passkeys on prompt and call center volume dropped 5 to 10%. Both numbers track what we see across the wider deployment base.
Where 2026 actually lands
The standards argument is over. The platforms are aligned. Regulators are setting deadlines a quarter at a time. What still varies is whether a given organisation treats passkeys as a checkbox to tick or as a system to operate.
The checkbox version produces visible passkey support with hidden problems underneath. Recovery flows that fall back to weaker factors. Step-up logic that's too coarse to be useful. Fraud detection that loses ground when the password signal goes away. Adoption that plateaus around the engaged minority and never moves.
A working system gets you the numbers the FIDO Alliance has been publishing: higher success rates, lower support costs, fewer takeovers, real reductions in SMS spend. Most of that comes from the work behind the credential rather than the credential itself, and that work is where we spend our time at Authsignal.
If you're mid-deployment and any of this sounds familiar, we should talk.
.svg)
