Passkeys vs MFA is the authentication decision most businesses will make in the next two years, and it is being made badly almost everywhere. The usual version of the conversation treats it as a straight upgrade — passkeys are newer, therefore passkeys win, therefore book the project. That framing skips the only questions that matter: which attacks each option actually stops, which parts of your application estate can accept a passkey at all, and what happens on the morning somebody drops their phone down a drain.
Multi-factor authentication was the right answer for a decade and it is still far better than a password alone. What changed is that the criminal economy caught up. Adversary-in-the-middle phishing kits now defeat one-time codes and push prompts routinely, at scale, sold as a service to people with no technical skill. That does not make traditional MFA worthless. It does mean the control you deployed in 2020 is no longer doing the job you think it is doing, and the honest passkeys vs MFA comparison has to start from that fact rather than from a vendor slide.
This guide is written for the person who has to make the passkeys vs MFA call and then defend it — to a board, an insurer, or an auditor. It covers how passkeys work at the protocol level, exactly where conventional MFA breaks, what the migration genuinely costs in service desk time and hardware, the parts of your estate that will not be ready, and a staged rollout that does not strand anybody outside their own account. It assumes you already have MFA switched on; if you do not, that is the emergency, not this.
The short answer on passkeys vs MFA, stated up front: passkeys should replace passwords as the primary sign-in method for your identity provider and your highest-risk roles this year, while MFA remains the fallback for the long tail of systems that cannot yet accept anything else. Passwordless is a direction of travel, not a launch date. If you want the wider context around identity, phishing and incident readiness, our IT security and cybersecurity pages cover the surrounding controls this decision sits inside.
Table of contents
- What the passkeys vs MFA debate is really about
- How passkeys actually work under the bonnet
- Where traditional MFA still leaves you exposed
- Passkeys vs MFA: the security comparison that decides it
- Passkeys vs MFA on cost, helpdesk load and productivity
- Where passkeys are not ready for your business yet
- Should businesses replace passwords completely?
- A staged passkeys vs MFA rollout that does not break anything
- Passkeys vs MFA mistakes that quietly undo the benefit
- Frequently asked questions about passkeys vs MFA
- References
What the passkeys vs MFA debate is really about
It is a question about phishing, not about convenience
Almost every passkeys vs MFA discussion gets sold on convenience — no codes to type, no app to open, a fingerprint and you are in. Convenience is real and it matters for adoption, but it is not the reason to spend the money. The reason is that a passkey is structurally unphishable in a way that no code-based factor can be, and phishing remains the most commonly identified attack type against UK businesses year after year.
If you strip the marketing away, the passkeys vs MFA question reduces to one sentence: do you want an authentication factor that a human being can be tricked into handing over, or one that they cannot?
Both are multi-factor — that is the confusing part
A passkey is not an alternative to multi-factor authentication. It is a form of it. Unlocking a passkey requires possession of the device holding the private key plus a user verification step — a biometric or a device PIN — so two factors are satisfied in a single gesture.
This is why the passkeys vs MFA framing trips people up. You are not choosing between security and no security. You are choosing between two multi-factor designs with very different failure modes, and the interesting differences are in how each one fails rather than in how each one works.
The decision has three separate parts
Most businesses conflate three questions that deserve separate answers. First, what is the primary sign-in method for your identity provider. Second, what happens for the systems that cannot use that method. Third, what the recovery path looks like when the primary method is unavailable.
Treating the passkeys vs MFA choice as one binary decision is what produces stalled projects. Split it into those three and the sequencing becomes obvious.
How passkeys actually work under the bonnet
A key pair, not a shared secret
When you register a passkey, the device generates a public and private key pair. The private key stays in the device’s secure hardware and never leaves it. The public key goes to the server. At sign-in the server sends a random challenge, the device signs it with the private key, and the server verifies the signature against the stored public key.
Nothing reusable ever crosses the network. There is no secret sitting in a database waiting to be stolen, which changes what a server-side breach means for you.
Origin binding is the part that kills phishing
This is the mechanism that makes the passkeys vs MFA comparison lopsided on phishing. Every passkey is cryptographically bound to the exact domain it was registered against. The browser and operating system will only offer that credential back to that origin.
A user who lands on a convincing replica of your login page cannot use their passkey there, because the fake domain is not the registered origin and the credential is simply never offered. The user does not have to notice the deception. The protocol notices for them, which is the entire point — you have moved the defence from human vigilance to mathematics.
Device-bound and synced passkeys are not the same thing
A device-bound passkey lives on one authenticator — a hardware security key or a single laptop’s secure enclave — and cannot be copied off it. A synced passkey is backed up to a credential manager such as an Apple, Google or third-party password manager account and appears across the user’s devices.
Synced passkeys drive adoption because they survive a lost handset. Device-bound passkeys give you a stronger assurance story and cleaner attestation. Most businesses end up using both, and that split is usually the first real design decision in a passkeys vs MFA programme: synced for the general population, device-bound hardware keys for administrators and anyone with access to money.
FIDO2, WebAuthn and CTAP in one paragraph
FIDO2 is the umbrella. WebAuthn is the browser API that websites call to create and use credentials. CTAP is the protocol between the browser and an external authenticator such as a USB security key or a phone acting as one. You do not need to know more than that to make the passkeys vs MFA decision, but you will see all three terms in vendor documentation and they are not competing standards.
Where traditional MFA still leaves you exposed
One-time codes are phishable by design
A TOTP code from an authenticator app is a shared secret rendered as six digits. The user reads it and types it somewhere. If the somewhere is an attacker’s proxy, the attacker types it into the real site within the same thirty-second window and is admitted. The code did its job perfectly and the account still fell. That gap is the whole passkeys vs MFA argument in one sentence.
This is not a theoretical weakness. It is the default behaviour of every commodity phishing kit currently on sale.
SMS is the weakest common factor
SMS one-time codes carry every weakness of TOTP plus SIM swap fraud, number porting attacks, and delivery over infrastructure you do not control. NIST’s digital identity guidance has treated SMS as a restricted authenticator for years, and the passkeys vs MFA argument is at its most one-sided here — there is no scenario in 2026 where SMS is the right primary second factor for a business account.
Push fatigue and the 3 a.m. approval
Push approvals removed the typing, which removed the phishing-by-typing problem and introduced a behavioural one. Bombard someone with prompts at two in the morning and eventually a thumb finds the green button. Number matching helps considerably and every serious platform now enforces it, but it is a mitigation layered on a design that still asks a tired human to make a security judgement.
Adversary-in-the-middle steals the session, not the code
This is the attack that ended the debate. A reverse-proxy phishing kit sits between the user and the real service. The user authenticates genuinely — password, second factor, number match, all of it correct — and the proxy quietly copies the resulting session cookie. The attacker replays that cookie and is inside the account without ever needing to authenticate again.
Every code-based and push-based factor is defeated by this, because the factor was completed successfully. Only origin binding breaks it, which is the strongest single argument in the whole passkeys vs MFA comparison. Our business email compromise playbook walks through what that intrusion looks like once it succeeds.
The service desk is a factor you forgot to count
Attackers who cannot beat the technology phone your service desk and ask for a reset. If a friendly agent can re-enrol an authenticator on the strength of a name and a date of birth, your MFA strength is exactly the strength of that phone call. This is true whichever side of the passkeys vs MFA choice you land on, and it is the control most often left untouched.
Passkeys vs MFA: the security comparison that decides it
The table below is the core of the passkeys vs MFA assessment. Read it by attack rather than by column — the question is never “which is better” in the abstract, it is “which of these attacks is realistically aimed at us”.
| Attack | Password only | Password + SMS or TOTP | Password + push | Passkey |
|---|---|---|---|---|
| Credential stuffing and reuse | Fails | Stops | Stops | Stops |
| Fake login page phishing | Fails | Fails | Partly stops | Stops |
| Adversary-in-the-middle proxy | Fails | Fails | Fails | Stops |
| SIM swap or number porting | Not applicable | Fails on SMS | Stops | Stops |
| Prompt bombing and approval fatigue | Not applicable | Not applicable | Fails without number matching | Stops |
| Server-side credential database breach | Fails | Partly stops | Partly stops | Stops |
| Stolen session token replay | Fails | Fails | Fails | Needs session controls |
| Service desk social engineering | Fails | Fails | Fails | Fails |
| Malware on an already-compromised device | Fails | Fails | Fails | Partly stops |
Read the last two rows before you celebrate
The bottom rows are the ones that stop a passkeys vs MFA rollout being a victory lap. Session token theft is not solved by the sign-in method, because it happens after sign-in — it is solved by short session lifetimes, token binding and conditional access policies that re-evaluate risk mid-session.
Service desk social engineering is not solved by it either. If your recovery process is weak, an attacker will simply target the recovery process. A passkey deployment that leaves both of these untouched has moved the risk rather than removed it.
What the comparison means in practice
For the vast majority of UK businesses the realistic threat is commodity phishing aimed at email and finance, not a targeted attack on a specific engineer’s laptop. Against that threat the passkeys vs MFA verdict is not close. The two rows where passkeys do not simply win are both fixable with controls you should have anyway, and neither is an argument for staying on codes.
Passkeys vs MFA on cost, helpdesk load and productivity
The sign-in time nobody measures
Passkeys vs MFA cost is usually presented as licences and hardware, which is the smallest part of it. The bigger number is the aggregate seconds your staff spend proving who they are, several times a day, every working day.
The figures below are a planning model built from typical deployment experience rather than survey data — use them to size the business case and then measure your own, because the ratio matters far more than the absolute values.
Where the service desk savings actually come from
Password resets and locked-out authenticators are a standing item on every service desk queue, and they are where the passkeys vs MFA business case is usually won. Remove the password from the daily path and a large share of that queue disappears, but only if you also remove the password’s expiry policy and stop treating it as the recovery route.
The saving is real and it is also the number most commonly overstated in business cases. Reset tickets do not go to zero. They change shape — fewer forgotten passwords, more lost-device re-enrolments, which take longer per ticket and need better identity checks. Our service desk work sees that shift on every passwordless project.
The hardware question
Synced passkeys on phones and laptops staff already own cost nothing in hardware. Hardware security keys, which you will want for administrators, break-glass accounts and anyone in finance, run roughly £25 to £60 each and should be bought in pairs so a lost key is an inconvenience rather than an incident.
Budget two keys per privileged user and a small spare pool held by IT. That is the whole hardware conversation for most organisations, and in passkeys vs MFA terms it is a rounding error next to the cost of one successful invoice fraud.
Licensing and platform readiness
Passkey support is now standard rather than premium across the major identity platforms, but the policy engine you need to enforce it — conditional access, authentication strength requirements, session controls — usually sits in a paid tier. Check that before you build the passkeys vs MFA business case, because enforcing a passkey requirement is what turns a pilot into a control.
Where passkeys are not ready for your business yet
The legacy estate is the real blocker
WebAuthn needs a modern browser or a native client that supports it. Anything speaking an older protocol simply cannot participate — and most businesses discover the size of that problem three weeks into a passkeys vs MFA project rather than before it.
| System type | Passkey capable | Interim control |
|---|---|---|
| Cloud identity provider and SSO apps | Yes, today | Enforce passkey as primary |
| Modern SaaS with federated sign-in | Yes, via the identity provider | Move it behind SSO first |
| SaaS with local accounts only | Varies by vendor | Authenticator app, never SMS |
| On-premises Windows sign-in | Partly, with platform support | Hardware key plus PIN policy |
| Legacy VPN, RDP and thick clients | Rarely | Certificate or hardware token |
| Line-of-business apps with basic auth | No | Disable basic auth, then front with SSO |
| Shared floor, warehouse or kiosk devices | Awkward | Shared hardware keys or badge plus PIN |
| Machine and service accounts | No | Managed identities and secret rotation |
Shared devices and staff without a smartphone
A passkey assumes a device that belongs to a person. Warehouse floors, clinical settings, hot desks and shift patterns break that assumption immediately. Hardware security keys solve it cleanly — a key on a lanyard is a credential that travels with the human rather than the terminal — but somebody has to buy, issue and replace them.
Do not skip this population and quietly leave them on passwords while the passkeys vs MFA project declares success elsewhere. That is precisely where an attacker will go.
Account recovery becomes your weakest link
This is the single most underestimated part of the passkeys vs MFA migration. Once the password is demoted, recovery is the only remaining path into an account, so its strength becomes the account’s strength.
Recovery designed as “email a link” is not recovery, it is a bypass. Serious options are a second registered passkey, a hardware key held in a safe, in-person verification for high-risk roles, or a manager-attested reset with an out-of-band callback. Pick one and write it down before you enrol a single user.
Personal accounts holding company credentials
Synced passkeys live in the user’s Apple or Google account by default. That is convenient and it also means a work credential is backed up inside a consumer account your business does not administer. Some organisations accept that; regulated ones frequently cannot, and will require device-bound credentials with attestation instead.
The leaver problem
Deprovisioning is straightforward in principle — delete the public key from the directory and the passkey is inert. In practice you need to be certain you have removed every registered credential, including any registered on a personal device, and that your joiners and leavers process actually checks. Our device management guidance covers the enrolment side of this.
Should businesses replace passwords completely?
Not completely, and not this year
The honest answer is that you should replace the password as the primary sign-in method wherever you can, this year, and accept that the password persists as a recovery artefact and a legacy fallback for some time after that. Anyone promising complete elimination in one passkeys vs MFA project is selling something.
What you can realistically achieve in twelve months is that no member of staff types a password to reach email, files, finance systems or anything else behind your identity provider — which is where the risk overwhelmingly lives.
Passwordless does not mean no password in the directory
A subtle point that trips up auditors and IT teams alike: making sign-in passwordless does not delete the password hash from the directory. Unless you explicitly remove it, the password still exists and can still be used somewhere you have not blocked.
Removing the password entirely is a separate, later step, and it needs every fallback path closed first. Until then, treat the password as an unused-but-live credential and monitor it accordingly.
The compliance angle
Cyber Essentials and most insurers ask for multi-factor authentication on cloud services, which makes passkeys vs MFA a documentation question as well as a technical one. Passkeys satisfy that requirement comfortably — they are stronger than what is being asked for, not weaker — but your documentation needs to say so clearly, because an assessor reading “passwordless” may read it as “no second factor”. Our Cyber Essentials Plus vs ISO 27001 comparison covers how these assessments treat authentication evidence.
Who should move first
Administrators, finance, executives and anyone who can move money or change payroll details. These are the accounts that get targeted, and they are small enough populations to support properly with hardware keys and hands-on enrolment, so they are where a passkeys vs MFA rollout should start.
A staged passkeys vs MFA rollout that does not break anything
The order that works
Every failed passkeys vs MFA project I have seen started with a company-wide announcement. Every successful one started with an inventory. The sequence below is deliberately slow at the front and fast at the back.
| Phase | Who | What happens | Exit criteria |
|---|---|---|---|
| 0. Inventory | IT only | Every app classified by sign-in protocol | No unknowns left on the list |
| 1. Recovery design | IT and HR | Written recovery and verification process | Signed off and rehearsed twice |
| 2. Pilot | IT plus one friendly team | Passkey enrolled alongside existing MFA | Two weeks, zero lockouts |
| 3. High-risk roles | Admins, finance, executives | Hardware keys issued in pairs, in person | All privileged accounts covered |
| 4. General rollout | Everyone else | Self-service enrolment with a deadline | Above 90% registered |
| 5. Enforcement | Everyone | Passkey required, SMS disabled | Weak methods off in policy |
| 6. Cleanup | IT | Legacy auth blocked, passwords demoted | No basic auth in sign-in logs |
Where the effort actually goes
Teams budget a passkeys vs MFA migration for enrolment and then lose the schedule to the two phases nobody costed. The breakdown below is again a planning model, and its purpose is to stop you from booking a two-week project.
Register the passkey over a trusted session
A credential is only as trustworthy as the session that created it. Enrolling a passkey from an unverified browser on an unknown network means an attacker who already holds a stolen password can register their own credential and become a legitimate user.
Bootstrap enrolment from a managed device, an existing strong factor, or in person. This is the step most guides omit and it is where a passkeys vs MFA migration quietly goes wrong.
Keep MFA running alongside, then retire it deliberately
Do not switch anything off during the passkeys vs MFA rollout. Run the passkey as an additional method until registration is high, then disable weak methods in policy order — SMS first, then voice, then codes — with a communicated date for each. Retiring by policy is reversible; retiring by deletion is not.
Monitor the right things afterwards
Track passkey registration coverage, sign-ins still using a legacy method, failed recovery attempts, and any account where a credential was registered outside the expected process. That last one is your early warning for the enrolment attack described above, and it belongs in whatever incident response runbook you already maintain.
Passkeys vs MFA mistakes that quietly undo the benefit
Leaving SMS enabled as a safety net
The most common and most damaging error. If a weaker method remains available, an attacker simply asks for it — the account falls back to the weakest enabled factor, not the strongest registered one. A passkeys vs MFA project that leaves SMS switched on has bought a stronger front door and left the side gate open.
Not hardening the service desk at the same time
Cover this in the same passkeys vs MFA project or it will be the route taken. Multi-step verification, callback to a number held in HR records, manager attestation for privileged accounts, and a rule that no agent may re-enrol a credential on the basis of information an attacker could find on LinkedIn.
No break-glass account
You need at least one emergency account with a hardware key held physically in a safe, excluded from conditional access policies that could lock it out, and monitored for any use at all. Passwordless environments have locked entire IT teams out of their own tenant. Do not be the anecdote in somebody else’s passkeys vs MFA post-mortem.
Ignoring session and token controls
Passkeys stop the sign-in being stolen. They do not stop the session being stolen afterwards. Short lifetimes, continuous access evaluation, device compliance requirements and re-authentication for sensitive actions are what close that gap, and none of them is optional in a modern data protection posture. It is the one row in the passkeys vs MFA comparison that no sign-in method closes on its own.
Treating it as a project rather than a lifecycle
New starters, replacement handsets, lost keys and leavers all touch credentials. If enrolment and revocation are not built into your joiners, movers and leavers process on day one, coverage decays quietly from the moment the project team disbands.
Measuring registration instead of enforcement
Ninety per cent of staff having registered a passkey means very little if the policy still accepts a password and a code. Registration is an input, not a passkeys vs MFA outcome. The number that matters is the proportion of successful sign-ins that used a phishing-resistant method, and it is the only figure worth putting in front of a board.
Frequently asked questions about passkeys vs MFA
Is a passkey the same as multi-factor authentication?
Effectively yes. Using a passkey requires the device holding the private key and a user verification step such as a fingerprint or PIN, which satisfies two factors in one action. In passkeys vs MFA terms, a passkey is a stronger implementation of multi-factor rather than a replacement for the concept.
What happens if somebody loses their phone?
With a synced passkey, they sign in on another device signed into the same credential manager and nothing is lost. With a device-bound passkey they use their second registered credential, which is why you issue hardware keys in pairs. If neither exists, they go through the recovery process you designed in phase one — the part of passkeys vs MFA planning that repays the most effort.
Can passkeys be phished at all?
Not by a fake login page — origin binding prevents it outright. They can still be undermined by malware on an already-compromised device, by a weak recovery process, or by tricking a service desk into registering a new credential. The attack moves rather than disappearing, which is why the surrounding controls matter.
Do passkeys work without an internet connection?
The cryptography is local, but the service you are signing into generally is not, so you still need connectivity to reach it. Local device unlock with Windows Hello or equivalent works offline.
Do we still need a password manager?
Yes, for a long while. Legacy systems, shared service accounts and vendors without passkey support all still need strong unique passwords, and a manager is where synced passkeys often live anyway.
Does Cyber Essentials accept passkeys?
Yes. The requirement is multi-factor authentication on cloud services, and a passkey exceeds it. Say so explicitly in your submission and describe the user verification step, so the assessor is not left inferring it.
How long does a realistic rollout take?
For a business of 50 to 250 staff, plan three to six months of passkeys vs MFA work from inventory to enforcement, with the inventory and recovery design taking longer than anyone expects. Larger estates with significant legacy applications should plan in quarters rather than weeks, and our managed IT services team usually runs it alongside a wider cybersecurity programme rather than as a standalone piece.
Should we wait for the standard to settle?
No. WebAuthn is a mature, widely implemented specification and the major platforms already ship it. Waiting means another year of phishable factors while adversary-in-the-middle kits keep improving, and the passkeys vs MFA gap widens in the attacker’s favour every quarter you delay.
References
NCSC: Multi-factor authentication for your corporate online services
NCSC: Password administration for system owners
NCSC: Cyber Essentials overview
NCSC: Device Security Guidance
Microsoft: Passkeys and FIDO2 in Microsoft Entra ID
Microsoft: Enable passkeys for your organisation
NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management
