MFA, passwordless and passkeys explained
Multifactor authentication (MFA) means proving identity with two or more different kinds of evidence (something you know, have or are). Passwordless means the password is removed from the sign-in altogether. A passkey is a passwordless credential built on FIDO standards that cannot be phished, because it only answers to the website it was created for. The decision rule for exams: when a question asks for the strongest option or says “phishing-resistant”, pick a passkey (FIDO2 security key, Windows Hello for Business, or a passkey in Microsoft Authenticator); when it asks only for “MFA”, almost any second factor qualifies.
A ladder of sign-in strength
Exam answers become easier when the methods are placed on one ladder. Higher rungs are stronger against attackers who trick the user.
| Rung | Methods | What it defends against | What still breaks it |
|---|---|---|---|
| 1. Password only | Password | Nothing beyond a guess limit | Phishing, spraying, leaked credentials |
| 2. Password plus a second factor | SMS or voice code, OATH code, Authenticator push | Stolen password alone | Phishing proxies that relay the code, prompt bombing |
| 3. Passwordless MFA | Microsoft Authenticator phone sign-in | Password theft, because none exists | The user can still be tricked into approving |
| 4. Phishing-resistant | FIDO2 security key, Windows Hello for Business or platform credential, certificate-based authentication (multifactor), passkeys | Phishing, replay, fake sign-in pages | Theft of the device plus its unlock gesture |
Rungs 2 to 4 all count as “MFA”. Rungs 3 and 4 are also “passwordless”. Only rung 4 is “phishing-resistant”. Temporary Access Pass sits outside the ladder: it is a time-limited passcode for onboarding and recovery that satisfies MFA, but not the Passwordless or Phishing-resistant strengths. Authenticator push is a good example of why the distinction matters: Microsoft enabled number matching for all Authenticator push notifications, so the user must type a number shown on the sign-in screen rather than tap Approve, which blunts approval fatigue. It still depends on the user paying attention, so it is not phishing-resistant.
Why a passkey cannot be phished
A passkey is a key pair. The private key stays in the authenticator; the public key is registered with Microsoft Entra ID. At sign-in, Entra sends a challenge, the user unlocks the authenticator with a biometric or PIN, and the authenticator signs the challenge. The signature is only produced for the site the key was registered with, so a look-alike page gets nothing it can replay. The protocols behind this are WebAuthn (browser side) and CTAP (talking to the authenticator).
Microsoft describes two kinds:
- Device-bound passkeys: the private key never leaves one device. FIDO2 security keys and Microsoft Authenticator are the examples given.
- Synced passkeys: the key is encrypted and synchronised by a cloud provider such as Apple iCloud Keychain or Google Password Manager. They are convenient and low cost, but they do not support attestation.
Attestation verifies the make and model of the authenticator at registration. In Entra, if a passkey profile enforces attestation, only device-bound passkeys are accepted and synced ones are excluded. Microsoft recommends security keys, or passkeys in the Authenticator app, for highly regulated sectors and privileged users, and notes the cost of equipment and lost-key recovery.
Using strength as a requirement
Conditional Access can require not just “MFA” but a particular strength. Authentication strengths come as three built-in sets: Multifactor authentication, Passwordless MFA and Phishing-resistant MFA. You can also build custom ones. Points that appear in questions:
- Requiring a strength needs Conditional Access, so Microsoft Entra ID P1 at minimum.
- The “Require multifactor authentication” grant control and “Require authentication strength” cannot be used in the same policy; the built-in MFA strength is equivalent to the first.
- Conditional Access is evaluated after first-factor sign-in. A strength does not stop the user typing a password first; they then have to complete a method from the allowed set.
- Temporary Access Pass appears only in the built-in Multifactor authentication strength, not in the Passwordless MFA or Phishing-resistant MFA strengths.
The policy mechanics are in Conditional Access explained; how stolen sessions and risky sign-ins are handled is in Entra ID Protection explained.
Worked example
Contoso has three groups and wants to raise the bar without breaking people.
- All staff currently use password plus SMS. The security team enables Microsoft Authenticator and a registration campaign, and later turns on synced passkeys. Policy: require the built-in Passwordless MFA strength for Microsoft 365 apps once registration is high enough.
- Global administrators and the finance payment approvers get FIDO2 security keys. Policy: require the Phishing-resistant MFA strength for the Azure portal and the admin portals.
- New hires have no method yet. They receive a Temporary Access Pass to register their first passkey; a TAP is time-limited and is meant for onboarding and recovery, not daily use.
What each choice answers: the staff policy removes passwords from daily sign-in; the admin policy defends against phishing proxies and prompt bombing; the TAP solves the bootstrap problem of how a passwordless user signs in the first time. Break-glass accounts are excluded from the strength policy and protected another way, as covered in the PIM guide.
Which exams test this
| Exam | How it appears | Covered on this site |
|---|---|---|
| SC-300 | Implement authentication and access management: manage authentication methods (certificate-based authentication, Temporary Access Pass, Microsoft Authenticator, passkeys/FIDO2), tenant-wide MFA settings and Windows Hello for Business; MFA registration through registration campaigns; authentication context in Conditional Access | Authentication and access |
| SC-500 | Manage identity, access, and governance: implement and configure authentication methods, including MFA and passwordless | Identity, access and governance |
| SC-900 | Capabilities of Microsoft Entra: describe the authentication methods and MFA; concept level | Microsoft Entra explained |
| AZ-900 | Azure architecture and services: describe authentication methods in Azure, including SSO, MFA and passwordless | Architecture and services |
| SY0-801 | Security Operations, identity and access management objective (4.5): MFA factors (hard and soft tokens, biometrics, OTP), passkeys, passwordless and password managers; V8 launches November 17, 2026 | Security operations |
| AB-900 | Core features of Microsoft 365: understand authentication methods, and pick tools to troubleshoot sign-in issues involving MFA; passkeys are not named | Microsoft 365 core features |
| N10-009 | Minor: Network Security (4.1) lists MFA among IAM authentication options | Network security |
| 200-301 | Minor, CCNA v1.1 only (until February 2, 2027): Security Fundamentals 5.4 names MFA, certificates and biometrics as password alternatives; v2.0 drops this objective | CCNA 200-301 services and security explained |
How questions are built around it
Questions usually give a threat and ask for the weakest change that stops it. Match the threat to the rung:
- “Users approve prompts they did not start” (MFA fatigue): number matching, or move to passkeys.
- “Users enter credentials on a fake page” or “adversary-in-the-middle”: phishing-resistant methods only. Adding SMS or an OATH code does not help, since a proxy can relay both.
- “Eliminate passwords”: passwordless. “Stop phishing”: phishing-resistant. They overlap, but an Authenticator phone sign-in is passwordless without being phishing-resistant, and the exam likes this gap.
- “Without hardware purchases”: synced passkeys or Authenticator, not security keys.
- “Prove the authenticator model” / “only approved key models”: attestation, which excludes synced passkeys.
- “Enforce a specific method for one app”: authentication strength in Conditional Access, not the per-user MFA setting.
Wrong answers often include SMS as “more secure than the app”, per-user MFA states where a policy is required, or Windows Hello for Business on a device that is not signed in with it. Also note that the authentication methods policy decides which methods may be registered and used; the strength decides which are accepted for a given resource.
Practice questions
Question 1. Attackers use a reverse proxy that shows users a copy of the Microsoft sign-in page and relays one-time codes in real time. You must protect the finance team with a method that this attack cannot defeat. What should you require?
- A. SMS codes for all finance users
- B. A software OATH token
- C. Microsoft Authenticator push with number matching
- D. A FIDO2 security key through the Phishing-resistant MFA authentication strength
Show answer
Answer: D
Passkeys such as FIDO2 security keys are bound to the real site and sign a challenge, so a proxy page receives nothing it can replay. SMS codes and OATH codes can be relayed by the proxy, and Authenticator push with number matching still relies on the user approving a request that the attacker initiated. Only the Phishing-resistant MFA strength, which allows FIDO2 security keys and passkeys, Windows Hello for Business or platform credential, and multifactor certificate-based authentication, defeats the attack.
Question 2. You want a Conditional Access policy to accept only passkeys from approved security key models and reject synced passkeys. Which setting makes this possible?
- A. Number matching for Microsoft Authenticator
- B. Attestation enforcement in the passkey profile
- C. Both Require multifactor authentication and an authentication strength in one policy
- D. A Temporary Access Pass for each user
Show answer
Answer: B
Enforcing attestation in the passkey profile validates the authenticator model at registration, and Microsoft Entra then allows only device-bound passkeys, because synced passkeys do not support attestation. Number matching only changes how Authenticator push is approved. Combining Require multifactor authentication with an authentication strength is not supported in one policy and does not check models. A Temporary Access Pass is a bootstrap credential and says nothing about passkey models.
Go deeper
- Authentication methods in Microsoft Entra ID: passkeys (FIDO2) (Microsoft Learn)
- Conditional Access authentication strengths (Microsoft Learn)
- Number matching in Microsoft Authenticator notifications (Microsoft Learn)
- Related guides: Zero Trust explained for why verification is explicit, cryptography basics for the public-key mechanics, and the SC-300 cheat sheet.