The passkeys vs MFA question is less “which one” than “which sign-in for this group of people and this system”. NIST’s test is that a passkey is itself multi-factor sign-in when the device checks the person before using the key. A password plus a second step is the other pattern in use today. Search results contradict each other on this (as of November 2026), so this article uses NIST’s test and labels each source.
Last reviewed 2026-11-02 by Manish Sharma.
This guide is for an IT manager or business owner at a firm of roughly 250 to 2,000 people in India or the GCC. It gives five questions, a group-by-group table and a short decision process. Moving a firm off passwords and why passwords fail are separate articles. It ranks no method, names no product and offers no compliance opinion.
Passkeys vs MFA in Short: Two Different Questions
Multi-factor authentication (MFA) is a sign-in that asks for more than one kind of evidence: something you know, have or are. You can find a plain definition of multi-factor authentication in the glossary. The FIDO Alliance’s passkey page describes a passkey as a secret stored on the person’s devices and unlocked the way they unlock the device, for example with a fingerprint, face scan or PIN. The FIDO Alliance promotes passkeys, so this is its own description, not a neutral one.
A test, set out in the next section, decides whether a passkey adds up to more than one kind of evidence. That is why the comparison starts with a question about the device and not with a list of methods.
Passkeys vs MFA: When a Passkey Counts as Multi-Factor
NIST decides the matter with a test, not a label. NIST SP 800-63B is US federal guidance for providers and verifiers of sign-in, and a firm adapts its wording to its own decision. It lists single-factor cryptographic authentication, which is proof that the person holds a key, and multi-factor cryptographic authentication, which is the same proof where the key needs a second factor to activate (Sec. 3.1.6 and Sec. 3.1.7 of the page, which states that it supersedes the earlier SP 800-63B).
In plain words, the test is whether the device checked the person. NIST’s Appendix B on syncable authenticators has verifiers inspect a user verification (UV) flag, which indicates whether the authenticator counts as a multi-factor cryptographic authenticator. If the device did not verify the user, agencies treat it as a single-factor cryptographic authenticator. A passkey that anyone holding an unlocked device could use therefore counts as single-factor under NIST, while the same passkey unlocked with a fingerprint or PIN counts as multi-factor.
The FIDO Alliance’s page goes further and says passkeys can replace older multi-factor flows, such as a password plus a text-message code. That is the FIDO Alliance’s own position. NIST’s test sits beside it, and neither is the reader’s rule.
The page timestamps differ: NIST’s page carries 26 August 2025, and the FIDO Alliance page lists 16 September 2026 as its last modification.
Key Takeaway Under NIST’s test, a passkey counts as multi-factor when the device checked the person before using the key.
Synced or Device-Bound: The Choice That Changes the Answer
The FIDO Alliance says passkeys can sync across a user’s devices or stay bound to a particular device (device-bound passkeys), and lists security keys among the devices that hold them. NIST describes the sync route as keys managed through a sync fabric, such as a cloud provider. In our reading, both describe how the key travels, not how well it is protected.
NIST adds a rule for US federal services. NIST says syncable authenticators must stay out of its highest assurance level, AAL3 (Sec. 2.3), because that level needs a key that cannot be exported. Appendix B also requires AAL2-equivalent multi-factor sign-in for user access to keys in the sync fabric.
AAL3 and Appendix B are requirements for US federal services. This passkeys vs MFA comparison does not turn them into a rule for the reader’s firm.
Synced or Device-Bound: Four Questions for the Firm
The decision for the firm is a set of questions for people:
- Which groups need a key that stays on one device?
- Which groups can use a key that follows the person across devices?
- Who owns the account the keys sync through, the person or the firm?
- What does the identity system document about allowing each kind?
For a synced key, who owns the account the keys sync through, and who can get back into it? The firm decides that per group, and it is a decision for a named person, not a setting to leave at its default.
Advantages
Limitations
Key Takeaway The firm decides synced or device-bound per group, and a named person owns the decision.
Passkeys vs MFA, Group by Group: Questions to Ask
Placing a group means asking the same passkeys vs MFA questions of each one. The table below is not a ranking, and every cell is a question for your team or your supplier.
| Group | Device question | System question | Lost-device question |
|---|---|---|---|
| Office staff on firm-managed devices | Does the device verify the person before it uses the key? | Does the identity system document passkeys for this group? | If the phone goes missing, who approves a reset? |
| Staff who share a device | If staff share the device, does the key belong to the person or to the device? | Does the identity system document a way to tell the people apart? | If someone loses the shared device, who is affected and who decides? |
| Administrators | Should the key stay on one device for this group? | If the system documents it, can the firm require passkeys for sensitive resources? | If someone loses the key, who may approve a reset for an admin account? |
| Outside users such as contractors | Does the firm own the device, or does the person? | If the person owns the device, does the system document it for outside users? | If the person leaves the firm, who removes the key? |
| Systems with no documented passkey option | If the system has no passkey option, is a password plus a second step the answer for it? | Does the supplier’s documentation list a passkey option, and who in the firm owns that answer? | If someone loses the second step, who approves a reset? |
Passkeys vs MFA in Five Steps: How to Place a Group
The five steps below turn the questions into a written decision for one group. Run them again for each group, and keep the answer next to the system it applies to.
List the group and the systems it signs in to.
Ask whether the device verifies the person before it uses the key (NIST’s test), and whether the identity system reports it.
Choose synced or device-bound for the group, and name who owns the account the keys sync through.
Ask the supplier of each system whether a passkey sign-in appears in its documentation. Where it is not, the answer for that system in this comparison is password plus a second step.
Ask who approves a reset after a lost device for this group.
The guide to setting up a second check during an identity rollout covers the wider identity work.
A Worked Example (Illustrative): An Accounts Team
This passkeys vs MFA example is illustrative, not a client case, and it uses no numbers. An accounts team works on firm-managed laptops that check the person with a fingerprint or PIN. The device answer is yes, and the identity system’s documentation lists passkeys for staff accounts, so the system answer is yes too. The firm decides on device-bound keys for the two people who approve payments, because it wants their keys to stay on one device. Everyone else on the team uses synced keys, and the firm records who owns the account those keys sync through. One person, named in writing, approves a reset if someone loses a laptop. A payroll tool whose supplier documents no passkey option stays on password plus a second step until the supplier answers. That result is the firm’s decision, not a finding.
Write each group’s decision beside the system it applies to, with the name of the person who owns it.
What This Comparison Leaves to Others
This passkeys vs MFA comparison does not rank methods, give a compliance opinion, compare products or quote a price. NIST’s assurance levels are US federal terms, and a framework’s own text decides what applies to a firm. It also says nothing about Indian or GCC rules, because it draws on NIST and the FIDO Alliance only.
Other questions belong in other articles. The order of work for moving off passwords, with a recovery test, a pilot and waves, is a separate article. Why passwords fail is another, and a scored password checklist is a third. For the wider picture, see the password-risk use case.
Get specialist help when the identity system’s documentation does not answer the device, key-kind and supplier questions, or when a regulator’s text applies. That is the point where a second pair of eyes is worth having. Signisys offers identity and access management services, and this is a Signisys offer, not neutral advice.
Signisys provides identity and access management, helping organisations control who can access what, with single sign-on, strong authentication, privileged access and automated provisioning. Signisys agrees the exact scope for each engagement. Our Solution: Identity and Access Management (IAM). Our Service: Cybersecurity Services.
Passkeys vs MFA: Frequently Asked Questions
Can a passkey count as multi-factor sign-in?
Do we still need a second step if staff use passkeys?
Does the kind of passkey change what happens when someone loses a device?
Does a shared device change the answer?
Should staff use a synced or a device-bound passkey?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.