Passwords have survived in software for far longer than they deserve.
Everyone knows they are awkward. Users forget them, reuse them, store them badly, mistype them, reset them and hand them over to convincing fake login pages. Product teams then spend years adding extra layers around the problem: password rules, reset emails, SMS codes, authenticator apps, backup codes, suspicious-login alerts and support processes for people who still get locked out.
Some of that work has been necessary. None of it has been especially elegant.
Passkeys are now changing the direction of travel. In April 2026, the National Cyber Security Centre said it would begin recommending passkeys wherever a service supports them, with two-step verification still recommended where passkeys are not available. That matters for UK SaaS companies because passkeys are no longer a niche security upgrade for early adopters. They are becoming the authentication pattern users, customers and security teams will increasingly expect to see.
For product-led SaaS teams, the useful question is not simply “should we add passkeys?” It is how to introduce them without making account access confusing, brittle or hostile to the people who rely on the product every day.
That makes passkeys product work.
Why the mood has shifted
The NCSC’s public position is clear: passkeys should now be the preferred login method where they are available. Its reasoning is practical rather than fashionable. Passkeys are resistant to phishing because they cannot be intercepted, reused or stolen in the same way as passwords. They are also faster and more convenient for users once the flow is working well.
That combination matters.
Security changes often fail when they ask users to accept more friction for a benefit they cannot see. A stronger password rule may reduce risk, but to the person signing in it mostly feels like another small punishment. SMS verification may be familiar, but it is not especially strong and it introduces its own reliability problems. App-based MFA can be effective, but it still creates interruptions, device-change headaches and recovery paths that support teams have to manage.
Passkeys offer a better trade-off. The user normally signs in with the same unlock pattern they already use on their device, such as Face ID, fingerprint or PIN. Behind that simple interaction is a cryptographic login that does not reveal a reusable secret to the service or a phishing site.
That does not make implementation trivial. It does mean the old compromise between security and usability is beginning to look less fixed than it used to.
This is not just an engineering ticket
It is tempting to treat passkeys as an authentication-library upgrade.
That would miss most of the product work.
Authentication sits at the entrance to the product, but it also touches onboarding, account recovery, support, enterprise administration, compliance evidence, device changes, customer communication and perceived trust. If a user cannot get into the product, every other feature is irrelevant. If an admin cannot recover access safely, the business has a serious operational problem.
Adding passkeys well means answering product questions before the implementation is half-built:
- Which users should see passkeys first: all users, admins, new accounts, enterprise customers, or high-risk roles?
- Should passkeys be optional at first, encouraged after signup, or required for certain account types?
- How will the product explain what a passkey is without turning the login screen into a help article?
- What happens when a user loses a device, changes phone, moves credential manager or leaves a company?
- How will customer administrators see adoption across their organisation?
- What recovery routes are acceptable without recreating the same account-takeover risks passkeys were meant to reduce?
Those are product, operations and trust decisions. Engineering has to make them real, but product leadership has to decide the shape of the experience.
The admin problem is different from the consumer problem
Many passkey explanations are written for individual consumers. That is useful, but SaaS teams also have to think about organisations.
A B2B SaaS account may include owners, billing users, support agents, analysts, contractors and integrations. Some users may authenticate through single sign-on. Others may still use product-native login. Some roles can export data, change billing details, invite users or disable security controls. The authentication bar should reflect that difference.
This is where passkeys need to sit inside a wider access model.
For low-risk roles, an optional passkey prompt after a successful login may be enough to start adoption. For account owners, billing administrators and users with sensitive permissions, the product may need stronger defaults. That could mean requiring phishing-resistant authentication before changing payment details, exporting data, rotating API keys or altering organisation-level settings.
The key is to avoid treating all sign-ins as equal. A user reading a dashboard does not create the same risk as a user inviting a new administrator or changing SSO settings. Passkeys are most valuable when they are connected to the moments where trust matters most.
Recovery is where teams need to be careful
Passkeys can reduce phishing risk, but weak recovery flows can quietly undermine the whole thing.
If an attacker can bypass a passkey with a poorly protected email reset, a rushed support process or a single static backup code, the product has not really solved the problem. It has moved the weakest point somewhere less visible.
Good recovery design needs a calm balance. Locking legitimate users out of business-critical software is not acceptable. Letting attackers talk their way into an account is not acceptable either.
For SaaS teams, this usually means designing recovery as a policy-backed workflow rather than a one-size-fits-all button. Personal accounts, sole-owner workspaces and enterprise-managed organisations may need different routes. High-risk actions may need a cooling-off period, administrator approval, verified device checks or manual review. Support teams need clear playbooks, not judgement calls made in a hurry.
This is also a good moment to audit older authentication assumptions. If password reset is still the de facto master key for everything, passkeys will only get you so far.
Passkeys should change the onboarding conversation
The best time to introduce a passkey is often not when a user is already annoyed.
If someone has just failed a login, is trying to finish a task, or is under pressure, a new authentication concept feels like an obstacle. If they have just created an account, accepted an invitation or completed a successful sign-in, the same prompt can feel like a sensible setup step.
That makes onboarding design important.
SaaS teams should think about passkey adoption as a journey:
- introduce the option in account security settings
- prompt after successful sign-in rather than during a failed one
- make the benefit concrete: faster sign-in and better protection against phishing
- show whether the account has a passkey configured
- give administrators visibility of adoption for their organisation
- nudge high-risk users more firmly than low-risk users
The language matters as much as the feature. “Create a passkey” will mean something to some users and very little to others. “Sign in faster and protect this account from phishing” is closer to the outcome people actually care about.
What UK SaaS teams should do next
This does not need to become a dramatic rebuild.
For most SaaS products, the first step is an authentication review. Map the current login methods, MFA options, SSO paths, reset flows, support processes and high-risk actions. Identify where passwords still carry too much responsibility. Then decide where passkeys would reduce risk without creating a support burden the team cannot handle.
The next step is to design the rollout deliberately. A sensible early version might make passkeys available to internal users, then admins, then selected customer accounts. That gives the team time to test device coverage, credential manager behaviour, recovery flows, analytics, support scripts and customer communications before passkeys become a headline feature.
Product teams should also decide what success looks like. Adoption percentage is useful, but it is not the whole story. Watch failed sign-ins, account recovery requests, support tickets, security incidents, setup completion rates and whether high-risk roles are actually using stronger authentication. A passkey rollout that looks good on a launch note but creates confusion in support is not finished.
Finally, treat authentication as part of the product’s trust surface. Customers increasingly want to know how software protects accounts, handles administrators and reduces avoidable operational risk. Passkeys can become part of that trust story, but only if the product experience backs it up.
The direction is obvious now
Passwords will not disappear overnight. SaaS teams will still need fallback routes, compatibility decisions and a careful migration path for customers with different devices, policies and levels of technical confidence.
But the direction is no longer especially mysterious.
The UK cyber guidance has moved. Major platforms already support passkeys. Users are becoming more familiar with device-based sign-in. Attackers are still very good at abusing passwords and weaker MFA. Waiting until customers demand passkeys in procurement questionnaires is the slow way to learn the lesson.
For UK SaaS teams, the practical move is to start now: review the authentication journey, decide where passkeys fit, design recovery properly, and make stronger sign-in feel like a product improvement rather than a compliance chore.
That is the difference between adding passkeys as a feature and making authentication meaningfully better.