Beyond MFA: Why FIDO2 Changes the Security Model of Authentication

Introduction: MFA Is Not the Finish Line

For years, one of the most common pieces of cybersecurity advice has been simple:

Enable multifactor authentication.

It remains good advice.

A password protected by a second authentication factor is substantially harder to compromise than a password alone. Multifactor authentication can prevent many attacks involving stolen passwords, credential stuffing, password reuse, brute-force attacks, and database breaches.

But an important distinction is often lost in the message.

Not all MFA is equally resistant to attack.

SMS codes, emailed codes, authenticator-generated one-time passwords, push notifications, hardware OTP tokens, smart cards, passkeys, and FIDO2 security keys may all participate in multifactor authentication, but they do not provide the same security properties.

An attacker does not necessarily need to defeat MFA cryptographically.

The attacker may simply convince the victim to authenticate for them.

Modern phishing frameworks can capture passwords and one-time codes in real time. Adversary-in-the-Middle techniques can relay authentication between a victim and a legitimate identity provider. Push-notification attacks can bombard users until one request is approved. Social engineers can impersonate support personnel and ask users to read authentication codes over the phone.

In all of these cases, MFA may be functioning exactly as designed.

The problem is that the authentication method allows the user to give an attacker something the attacker can use.

FIDO2 changes this relationship.

Rather than relying primarily on the user to determine whether an authentication request is legitimate, FIDO2 uses public-key cryptography and relying-party binding so that the authentication protocol itself participates in determining where a credential may be used.

That distinction is the foundation of phishing-resistant authentication.

NIST defines phishing resistance in terms of an authentication protocol preventing useful authentication secrets or outputs from being disclosed to an impostor verifier without depending upon the vigilance of the user. NIST specifically states that manually entered OTP and out-of-band authentication methods are not phishing-resistant because their outputs can be relayed by an impostor verifier. WebAuthn, which forms part of FIDO2, is identified by NIST as an example of phishing resistance through verifier-name binding.

The important lesson is therefore not:

FIDO2 adds stronger MFA.

It is:

FIDO2 changes what an attacker must defeat.

Understanding why requires first understanding the weakness in conventional authentication.

1. The Fundamental Problem With Passwords

Traditional authentication is built around a shared secret.

A user knows a password:

CorrectHorseBatteryStaple

The service maintains information that allows it to determine whether the user supplied the correct password.

Conceptually:

USER                    SERVICE

Password
   |
   +---------------------->

                         Verify
                         password
                            |
                            v
                         ACCESS

Modern services should not store plaintext passwords. Proper password storage uses salted, computationally expensive password hashing.

That improves protection of stored credentials.

It does not change an important characteristic of password authentication:

The user still transmits something that can authenticate the user.

If an attacker obtains the password, the attacker can generally attempt to authenticate as that user.

The service cannot inherently distinguish between:

Alice entering Alice's password

and:

An attacker entering Alice's password

Both possess the same secret.

This produces several familiar attacks:

• phishing;
• credential stuffing;
• password spraying;
• malware-based credential theft;
• keylogging;
• database attacks;
• social engineering;
• password reuse attacks.

MFA was introduced in large part to make possession of the password insufficient.

That was a major improvement.

But it did not completely eliminate the underlying problem.

FIDO2 in Plain English

The Difference Between “Proving Who You Are” and “Giving Someone a Code”

Imagine you are standing outside your house.

Your front door has a lock.

Your password is like the key.

If someone steals your key, they can open the door.

That is the basic problem with passwords.

So we added MFA.

Now imagine the door has two locks.

The first lock uses your key.

The second lock asks for a six-digit number from your phone.

That is better.

If someone steals your key but does not have the six-digit number, they still cannot get in.

This is why MFA has been such an important improvement in computer security.

But there is still a problem.

The six-digit number can be copied.

It can be read over the phone.

It can be typed into the wrong website.

It can be sent in a text message.

It can be handed to someone pretending to be the help desk.

The computer does not know why you gave someone the number.

It only knows the number is correct.

That is the weakness attackers take advantage of.

A Simple Example

Imagine someone calls you and says:

“Hi, this is the bank. We detected fraud on your account. I am going to send you a six-digit security code. Please read it back to me so I can verify your identity.”

You receive:

472913

You read it to the caller.

The caller is not really the bank.

They are an attacker who already knows your password.

They are sitting on the real bank website, typing your information into the login screen.

The bank asks them for the MFA code.

They ask you for it.

You give it to them.

They type it in.

They are now logged in as you.

The password worked.

The MFA worked.

The security system did exactly what it was designed to do.

The problem was that the six-digit number could be transferred from you to the attacker.

That is what FIDO2 changes.

Think of FIDO2 Like a House Key That Only Works at Your House

A normal password is like a key that someone can copy.

An MFA code is like a second key that only works for a minute.

FIDO2 is more like a special electronic key that is programmed to work only at one specific building.

If someone tricks you into walking up to the wrong building, the key refuses to work.

That is the important part.

You do not have to notice that you are at the wrong building.

The key notices.

That is the security improvement.

The Construction-Site Example

Imagine you work on a large construction project.

Every employee has a badge.

A normal badge might have an identification number printed on it.

If someone copies the number, they might be able to use it somewhere else.

Now imagine instead that the badge contains a secure electronic chip.

Every morning, the gate sends the badge a different secret question.

The badge proves that it is genuine without giving away the secret inside it.

More importantly, the badge is programmed only to respond to gates belonging to your construction company.

Someone sets up a fake gate down the street.

It looks real.

It has the same company logo.

The person standing there wears the right uniform.

The sign looks exactly like the one at your jobsite.

You scan your badge.

Nothing happens.

The badge knows:

This is not one of my company’s real gates.

That is very close to what FIDO2 does.

2. What Conventional MFA Actually Adds

Consider an account protected by a password and a six-digit TOTP code.

The user enters:

Username
Password
123456

An attacker who steals only the password cannot authenticate.

That is valuable.

The attacker now needs another factor.

But notice something about 123456.

The code itself does not know where it is being entered.

It does not contain an inherent cryptographic statement saying:

I authorize authentication only to:

https://login.example.com

The victim can enter it into the legitimate site.

The victim can also be tricked into entering it into:

https://login-example-security.com

An attacker can then relay the value to the legitimate service while it remains valid.

NIST identifies precisely this limitation. Authentication mechanisms involving manual entry of an authenticator output, including OTP mechanisms, are not considered phishing-resistant because the authenticator output is not bound to the specific authentication session and can be relayed by an impostor verifier.

That distinction is enormously important.

TOTP can be replay-resistant in the sense that an old OTP cannot normally be reused indefinitely.

It is not necessarily relay-resistant against an attacker using the current OTP immediately.

Those are different properties.

3. A Real-Time MFA Phishing Attack

Consider Alice, an employee of Example Corporation.

Her Microsoft 365 account uses:

Username
+
Password
+
TOTP

Alice receives an email:

Your Microsoft 365 session has expired.

Sign in to prevent interruption of email access.

The link leads to:

https://microsoft-login.example-attacker.com

The page looks convincing.

Alice enters her username and password.

The attacker’s infrastructure immediately attempts authentication against the legitimate identity provider.

ALICE             ATTACKER              IDENTITY PROVIDER

Username
Password
   |
   +-------------->

                  Username
                  Password
                     |
                     +------------------->

                                        MFA REQUIRED
                                             |
                  <--------------------------+

   <--------------
Enter verification
code

Alice opens her authenticator application.

It displays:

482193

Alice enters the code into the phishing page.

ALICE             ATTACKER              IDENTITY PROVIDER

482193
   |
   +-------------->

                     482193
                        |
                        +------------------>

                                          VALID
                                            |
                                      AUTHENTICATED

The MFA system worked.

The OTP was valid.

Alice possessed the second factor.

The identity provider correctly verified it.

Yet the attacker authenticated.

The security failure occurred because the authentication ceremony did not cryptographically establish:

Who is Alice authenticating to?

Humans were expected to answer that question.

Humans are not particularly reliable domain-name validation engines.

FIDO2 moves that decision into the authentication protocol.

4. FIDO2: A Different Authentication Architecture

FIDO2 combines technologies developed through the FIDO Alliance and the W3C Web Authentication standard.

At a high level, FIDO2 uses asymmetric cryptography.

Instead of establishing a reusable shared authentication secret between the user and service, the authenticator creates a cryptographic key pair.

PRIVATE KEY             PUBLIC KEY

User/authenticator      Service
keeps this              stores this

The private key is used to sign authentication challenges.

The public key is used by the service to verify those signatures.

The private key does not need to be transmitted to the service.

The FIDO Alliance describes FIDO authentication as public-key-based, phishing-resistant authentication in which passkeys are unique and bound to the online service’s domain.

This creates fundamentally different security properties from password authentication.

5. Registration

When a user initially registers a FIDO credential with a service, the authenticator creates or establishes a credential associated with that relying party.

Simplified:

SERVICE
   |
   | Registration request
   v
BROWSER
   |
   v
AUTHENTICATOR

Generate:

Private Key
Public Key

The public key is registered with the service.

The private key remains under control of the authenticator.

Conceptually:

AUTHENTICATOR                        SERVICE

Private Key
    |
    | stays here

Public Key
    |
    +--------------------------------->
                                      Store
                                      public key

For a device-bound authenticator, the private key can remain bound to that device. Syncable passkeys introduce a different storage model, which we will discuss later.

The critical point is that the service does not need a copy of the private authentication key.

6. Authentication: Challenge and Response

Later, when the user authenticates, the service generates a random challenge.

Conceptually:

SERVICE

Generate random challenge:

7F92A8...

The challenge is sent to the client.

The authenticator performs a cryptographic operation using the private key.

Challenge
+
Relying-party information
+
Authenticator data
+
Private key

        |
        v

Cryptographic signature

The service verifies the resulting assertion using the registered public key.

The W3C WebAuthn specification requires relying parties to generate cryptographically suitable challenges and verify that the returned challenge matches the one generated for the authentication ceremony. This freshness property is central to WebAuthn’s replay resistance.

An attacker who records yesterday’s successful authentication cannot simply replay it tomorrow.

The next challenge will be different.

7. The Feature That Changes Phishing: Relying-Party Binding

Public-key cryptography alone is not the most important part of this story.

The transformative feature is credential scope.

A WebAuthn credential is associated with a Relying Party ID.

The W3C specification requires the authenticator to ensure that a credential created for one relying party is used only for the appropriate RP ID. The requesting origin is also incorporated into the WebAuthn ceremony and validated by the relying party.

Suppose Alice registered her credential with:

example.com

An attacker creates:

example-security.com

The attacker can copy:

• the logo;
• CSS;
• fonts;
• wording;
• login graphics;
• JavaScript behavior;
• corporate branding.

The attacker can make the phishing site visually indistinguishable from the legitimate one.

But the attacker cannot make:

example-security.com

become:

example.com

to WebAuthn simply by making the page look convincing.

That difference is cryptographic rather than visual.

This is the core security improvement.

8. Humans Versus Protocols

Conventional phishing defense frequently asks the user to perform security analysis.

The user must notice:

login.microsoftonline.com

versus:

login-microsoftonline.com

or:

microsoftonline.example.net

Attackers exploit:

• typos;
• similar characters;
• Unicode;
• misleading subdomains;
• URL shorteners;
• QR codes;
• mobile browsers;
• hidden address bars;
• compromised advertising;
• search-engine results;
• urgency;
• fear;
• authority.

Security awareness training remains valuable.

But humans will eventually make mistakes.

NIST’s definition of phishing resistance is important precisely because it focuses on protecting authentication without depending on the vigilance of the claimant.

That is one of the most important conceptual differences between FIDO2 and conventional MFA.

Traditional MFA often says:

USER:
Determine whether this authentication
request is legitimate.

FIDO2 adds:

PROTOCOL:
Determine whether this credential
belongs to this relying party.

We have moved an important security decision from human perception into cryptographic protocol enforcement.

9. Attack Scenario: Credential Phishing

Consider the classic credential-phishing site.

An attacker copies a Microsoft sign-in page and hosts it elsewhere.

With passwords:

Victim -> phishing site -> attacker obtains password

With password + OTP:

Victim -> phishing site -> attacker obtains password

Victim -> phishing site -> attacker obtains OTP

Attacker -> legitimate IdP

The attacker must operate quickly, but the attack is feasible.

With properly configured FIDO2/WebAuthn, the attacker’s site cannot simply request a useful authentication assertion for the legitimate relying party.

A credential registered for the legitimate RP is scoped accordingly.

NIST describes this property as verifier-name binding and explicitly cites WebAuthn/FIDO2 as an example.

The attacker can reproduce the appearance of the login page.

The attacker cannot reproduce the legitimate relying-party identity merely by doing so.

Result

Password-only: vulnerable.

Password + OTP: substantially stronger, but phishable.

Properly configured FIDO2: resistant to this form of credential phishing.

10. Attack Scenario: Adversary-in-the-Middle Phishing

Modern phishing can be more sophisticated than collecting values in a form.

An attacker can position infrastructure between the victim and legitimate identity provider.

Conceptually:

VICTIM
   |
   v
ATTACKER PROXY
   |
   v
REAL IDENTITY PROVIDER

The victim may actually interact indirectly with the real authentication process.

The attacker relays requests and responses.

This can defeat several conventional MFA mechanisms because the attacker does not need to understand or predict the authentication code.

The attacker simply relays it.

Microsoft specifically identifies adversary-in-the-middle attacks as a token-theft vector capable of capturing credentials and session information and potentially bypassing conventional MFA protections.

FIDO2 makes authentication relay substantially harder because the WebAuthn assertion incorporates information tied to the authentication context and relying party.

A phishing proxy operating under the attacker’s domain cannot simply turn its origin into the legitimate RP.

This removes one of the most powerful capabilities of modern credential-phishing frameworks.

However, an important qualification is necessary.

FIDO2 protects the authentication ceremony. It does not make authenticated sessions invulnerable.

If malware compromises the legitimate endpoint after authentication and steals usable session material, FIDO2 does not transform that session token into something that cannot be stolen.

This distinction matters.

11. Authentication Theft Versus Session Theft

Consider two different attacks.

Attack A

Steal authentication credential
        |
        v
Authenticate as victim

FIDO2 is specifically designed to make this substantially harder.

Now consider:

Attack B

Victim authenticates legitimately
        |
        v
Session established
        |
        v
Attacker steals session

Those are not the same attack.

Microsoft documents malware and adversary-in-the-middle techniques as mechanisms through which tokens can be stolen. Once a usable token has been stolen, an attacker may be able to impersonate the user without repeating the original authentication process.

FIDO2 cannot retroactively protect every artifact created after authentication.

Organizations therefore still need:

• endpoint security;
• token protection where available;
• Conditional Access;
• device compliance;
• EDR;
• browser security;
• application security;
• session monitoring;
• identity threat detection.

FIDO2 dramatically improves authentication.

It does not eliminate the rest of cybersecurity.

12. Attack Scenario: MFA Fatigue

Push-based authentication introduced an exceptionally convenient MFA experience.

The user enters a password.

A notification appears:

Approve sign-in?

[Approve] [Deny]

Unfortunately, convenience creates an attack surface.

Suppose an attacker already knows the victim’s password.

The attacker repeatedly attempts authentication.

The victim receives:

Approve sign-in?

again.

And again.

And again.

Perhaps at 2:00 AM.

Eventually the user may press Approve simply to make the notifications stop.

Attackers can also combine push bombing with social engineering:

“This is IT. We’re troubleshooting your account. You’ll receive an authentication request. Please approve it.”

The authentication technology is now depending on a human to correctly interpret the request.

FIDO2 changes the workflow.

There is no generic remote push approval that can simply authorize the attacker’s independent browser session.

The authenticator participates in a cryptographic authentication ceremony associated with the appropriate relying party.

This substantially reduces the value of classic push-fatigue attacks.

13. Number Matching Helps, But It Is Not the Same Thing

Push MFA has improved.

Number matching may display a number at the login session that must be entered into the authenticator application.

This makes blind push approval considerably harder.

It is a useful improvement.

But the user is still participating in verification.

An attacker using real-time social engineering may tell the victim:

“To verify your account, enter 42 in Authenticator.”

The user can still cooperate with the attacker.

Phishing-resistant authentication tries to reduce reliance on the user’s ability to distinguish legitimate authentication from fraudulent authentication.

That is a different security objective.

14. Attack Scenario: Help-Desk Social Engineering

Imagine an attacker calling an employee.

“Hi, this is David from the security team. We’re migrating your account. You should receive a six-digit verification code. Read it to me so I can confirm your enrollment.”

The employee receives:

739201

and reads it aloud.

From the authentication system’s perspective, the code is valid.

The computer cannot determine whether the employee typed it into a legitimate browser, pasted it into a phishing site, sent it through chat, or read it over the telephone.

The OTP is transferable.

A FIDO private key is different.

There is no six-digit representation of the private key that the user can read to “David.”

There is no useful authentication secret for the user to copy into a support ticket.

This dramatically changes the social-engineering opportunity.

The attacker now needs another path.

And that observation leads to one of the most important lessons of FIDO2 deployment:

Attackers move.

15. Attack Scenario: SIM Swapping

SMS MFA is better than password-only authentication, but telephone numbers were never designed as high-assurance cryptographic identities.

An attacker may attempt to persuade or compromise a mobile carrier into transferring a victim’s number to another SIM.

If successful, SMS authentication messages can potentially be redirected to the attacker.

FIDO2 does not rely on possession of a telephone number.

Transferring:

+1 555 555 1234

does not transfer the victim’s FIDO private key.

This eliminates the direct relationship between telephone-number control and authentication.

16. Attack Scenario: SMS Interception

SIM swapping is not the only problem with SMS authentication.

The telecommunications ecosystem introduces additional attack surfaces.

SMS messages are transferable pieces of information:

Your security code is 583912

Anyone who obtains that code during its useful lifetime may potentially use it.

FIDO2 avoids sending an equivalent reusable authentication secret through the telecommunications network.

Again, the difference is architectural.

17. Attack Scenario: Credential Stuffing

Credential stuffing exploits password reuse.

Suppose attackers compromise an unrelated website and obtain credentials:

alice@example.com
Winter2026!

They test those credentials against:

Microsoft 365
Google
Salesforce
VPN
Payroll
Banking

If Alice reused the password, the attacker may succeed.

MFA can limit the damage because the password alone is insufficient.

FIDO2 goes further when deployed passwordlessly.

The authentication credential for one relying party is not a human-selected password that can simply be reused at another.

FIDO credentials are scoped to relying parties, and the FIDO Alliance describes passkeys as unique and bound to the online service domain.

There is therefore no equivalent of:

Use my Microsoft FIDO credential
on Salesforce.

The credential architecture prevents that kind of cross-service reuse.

18. Attack Scenario: Password Database Compromise

Suppose an attacker compromises an application’s authentication database.

Traditional password systems contain password verifiers, typically salted hashes.

Proper password hashing significantly increases the cost of recovering passwords, but weak passwords may still be cracked offline depending on the hashing scheme, configuration, and password strength.

FIDO changes what the service stores.

The relying party stores a public key.

A public key is not supposed to be secret.

Obtaining it does not provide the corresponding private key.

Conceptually:

STOLEN PASSWORD DATABASE

Hash(password)
        |
        v
Potential offline guessing

versus:

STOLEN FIDO CREDENTIAL DATABASE

Public key
        |
        v
Cannot derive private key
with practical public-key cryptography

This changes the consequences of a verifier database breach.

NIST’s AAL3 requirements specifically use public-key cryptography to protect authentication secrets against verifier compromise.

Application databases still contain sensitive information and must still be protected.

But the authentication architecture no longer requires the verifier to possess a reusable private authentication secret corresponding to the user’s credential.

19. Attack Scenario: Replay

Suppose an attacker records an authentication exchange.

Can it simply be sent again?

WebAuthn relies upon randomly generated challenges.

A relying party issues a challenge for an authentication ceremony.

The response is tied to that challenge.

The next authentication ceremony receives another challenge.

W3C explicitly requires sufficiently unpredictable challenges and describes them as necessary to prevent replay attacks.

NIST likewise describes cryptographic authenticators using nonce/challenge mechanisms as replay-resistant.

So:

Recorded successful response
          |
          v
Replay later
          |
          v
Challenge mismatch
          |
          v
FAIL

This is another important difference from passwords.

A password is fundamentally reusable:

Password today = Password tomorrow

until somebody changes it.

20. Attack Scenario: QR-Code Phishing

QR phishing, sometimes called “quishing,” has become attractive because it moves users from a managed workstation to a mobile device.

A malicious QR code might direct the victim to:

https://example-login-security.com

A user scanning the code may see a convincing authentication page.

Traditional authentication still depends heavily on the user noticing the wrong destination.

FIDO2 does not make QR codes trustworthy.

Instead, it reduces the usefulness of directing the victim to the wrong relying party.

The attacker’s domain does not become the legitimate RP merely because the user reached it through a QR code rather than an email link.

This illustrates a broader point.

Phishing resistance is not primarily about identifying how the victim arrived at the attacker.

NIST explicitly notes that the method used to direct the claimant to the impostor verifier does not change whether the event constitutes phishing.

The security property is in the authentication protocol.

21. Attack Scenario: Lookalike Domains

Consider:

contoso.com

versus:

cont0so.com

A human might miss the substitution.

The authentication system does not reason visually.

WebAuthn works with origins and relying-party identifiers.

The W3C specification defines constraints on RP IDs and requires clients and authenticators to enforce the credential’s RP scope.

The attacker can create something that looks similar to the user.

Similarity does not make it cryptographically equivalent.

This is an excellent example of moving security away from subjective human recognition.

22. Attack Scenario: The Attacker Knows the Password

One particularly useful way to understand FIDO2 is to assume the password is already lost.

Imagine an attacker has:

Username: alice@example.com
Password: Winter2026!

Under password-only authentication, the account is compromised.

Under conventional MFA, the attacker must obtain or induce the second factor.

That may involve:

OTP phishing
Push fatigue
SIM swap
Help-desk social engineering
AiTM proxy

Under properly enforced FIDO2 authentication, knowledge of the password alone is insufficient.

Even if the password becomes completely public, the attacker still lacks the private key required for the cryptographic authentication ceremony.

This changes the economics of credential theft.

23. User Verification: PINs and Biometrics

FIDO authenticators frequently require local user verification.

That might be:

PIN
Fingerprint
Face recognition

It is important to understand what this means.

The biometric normally does not become a biometric password sent to the website.

The FIDO Alliance notes that biometric information used with FIDO authentication remains on the user’s device.

Conceptually:

Fingerprint
    |
    v
LOCAL AUTHENTICATOR

"Is this the authorized user?"

    |
    v
Unlock use of private key

The website receives the cryptographic authentication result.

It does not need the user’s fingerprint image.

This separation has both security and privacy benefits.

24. Is FIDO2 Really Multifactor Authentication?

This causes understandable confusion.

Imagine a security key protected by a PIN.

The physical authenticator represents:

Something you have

The PIN used to activate it represents:

Something you know

Similarly, a biometric can serve as an activation factor associated with the authenticator.

NIST describes multi-factor cryptographic authenticators in these terms: possession of the authenticator combined with an activation factor representing knowledge or a biometric characteristic.

The factors can therefore be combined within a single authentication ceremony.

This is very different from thinking:

MFA must mean password + phone.

MFA describes independent authentication factors.

It does not require two separate Internet transactions.

25. Passkeys, FIDO2, WebAuthn, and Security Keys

These terms are often used interchangeably, but they are not identical.

WebAuthn is the W3C web authentication API and protocol framework.

CTAP defines communication between clients/platforms and external authenticators.

Together, WebAuthn and CTAP form the core of what is generally called FIDO2.

A security key is a physical authenticator that may implement FIDO protocols.

A passkey is a FIDO credential designed around public-key authentication and can be either device-bound or syncable depending on the implementation.

This distinction becomes important in enterprise security.

26. Device-Bound Versus Syncable Passkeys

Not every FIDO credential has the same threat model.

Microsoft Entra currently distinguishes between device-bound and synced passkeys.

For device-bound passkeys, Microsoft describes the private key as being created and stored on one physical device and not leaving it. Security keys and supported device-bound Authenticator implementations are examples.

Synced passkeys use a passkey provider that allows protected credential material to become available across a user’s devices.

This provides enormous usability benefits.

A user who replaces a phone does not necessarily lose access to every account.

But synchronization introduces another trust relationship:

FIDO credential
       |
       v
Passkey provider
       |
       v
Account recovery / sync ecosystem

The security of that ecosystem now matters.

27. NIST AAL2 and AAL3

NIST’s Authentication Assurance Levels provide a useful way to understand this distinction.

At AAL2, NIST requires stronger authentication controls and requires federal verifiers to offer phishing-resistant authentication; federal agencies are required to use phishing-resistant authentication for workforce access to federal information systems.

Properly configured syncable WebAuthn authenticators can support AAL2 requirements under NIST’s current guidance.

AAL3 is different.

AAL3 requires a cryptographic authenticator with a non-exportable private key and phishing resistance.

Because synchronization inherently requires the authentication key to be exportable from its original authenticator environment in some protected form, NIST states that syncable authenticators cannot satisfy AAL3.

That does not mean synced passkeys are insecure.

It means:

phishing resistance and maximum key non-exportability are separate security properties.

Organizations should select authenticator types based on risk.

28. Hardware Security Keys

For high-value accounts, hardware FIDO2 security keys remain particularly compelling.

Examples include accounts belonging to:

• global administrators;
• identity administrators;
• security administrators;
• domain/cloud infrastructure engineers;
• executives;
• finance personnel;
• developers with production access;
• privileged third-party administrators.

The private credential can remain inside dedicated authenticator hardware.

An attacker may know:

Username
Password
Phone number
Employee ID
Manager's name

and still lack the physical cryptographic authenticator.

This dramatically raises the cost of remote account takeover.

29. FIDO2 Does Not Eliminate Physical Attacks

If an attacker physically steals a security key, possession of the device becomes relevant.

That is one reason user verification matters.

A stolen authenticator protected by a PIN or other activation mechanism presents a different security posture from an unprotected bearer token.

Organizations should therefore consider:

• authenticator PIN policy;
• device inventory;
• lost-device procedures;
• credential revocation;
• backup authenticators;
• replacement processes.

Authentication security includes the entire authenticator lifecycle.

30. The Recovery Problem

Every authentication system eventually encounters:

“I lost my authenticator.”

That creates one of the most important security questions in a FIDO2 deployment.

Suppose an organization requires hardware security keys.

An attacker cannot phish them.

So the attacker calls the help desk.

“I lost my key and my phone. I need access immediately because I’m traveling.”

If the help desk resets the account after asking:

Employee ID?
Manager?
Date of birth?
Last four digits of phone number?

the attacker may simply bypass the strongest authentication control in the environment.

This is not a FIDO2 cryptographic failure.

It is an identity lifecycle failure.

The strength of an authentication system is constrained by its weakest recovery mechanism.

31. Enrollment Is Part of Authentication Security

The same principle applies when credentials are initially registered.

Suppose an attacker compromises an account using conventional MFA and then registers the attacker’s own FIDO credential.

The organization may subsequently require FIDO2.

Unfortunately:

ATTACKER'S KEY

is now a legitimate registered authenticator.

The protocol cannot determine that the wrong human enrolled it.

Secure FIDO2 deployment therefore requires protection around:

• initial registration;
• credential addition;
• credential replacement;
• recovery;
• administrative reset;
• authenticator removal.

These workflows deserve the same security attention as login itself.

32. Microsoft Entra ID: Temporary Access Pass

Microsoft provides Temporary Access Pass as one mechanism for bootstrapping passwordless authentication.

A TAP is a time-limited passcode that can be configured for one-time or multiple use and can allow a user to register passwordless methods such as a FIDO2 passkey.

This solves an important bootstrap problem:

How does a new employee register
strong authentication before they
already possess strong authentication?

But the issuance of the TAP becomes security-sensitive.

An organization should therefore treat bootstrap credentials as privileged artifacts.

If an attacker fraudulently obtains a TAP and enrolls an authenticator, FIDO2 will subsequently protect the attacker’s credential perfectly.

Cryptography cannot repair incorrect identity proofing.

33. Microsoft Entra Authentication Strengths

One of the most important implementation features in Microsoft Entra is authentication strength.

It is not enough to register a FIDO2 credential.

An organization must determine when it is required.

Microsoft provides built-in authentication strengths including:

Multifactor authentication
Passwordless MFA
Phishing-resistant MFA

The phishing-resistant strength can be required through Conditional Access. Microsoft specifically recommends this approach for protecting administrator roles.

This distinction matters enormously.

Consider a user with:

FIDO2 security key
Microsoft Authenticator
SMS

If an attacker is allowed to select:

Use another authentication method

and fall back to SMS, the attacker does not need to defeat FIDO2.

The attacker attacks SMS.

Strong authentication must therefore be enforced, not merely available.

34. The Fallback Problem

This deserves emphasis.

Imagine a castle with a sophisticated biometric entrance.

Next to it is an unlocked side door.

The castle does not have biometric security.

It has an unlocked-door security model.

Authentication works the same way.

Suppose the allowed methods are:

FIDO2
TOTP
SMS
Voice

An attacker will normally choose the weakest viable path.

Therefore:

Security != strongest registered method

A more useful approximation is:

Security ≈ weakest permitted path
           capable of reaching
           the protected resource

This is why Conditional Access and authentication strengths matter.

35. A Practical Entra Architecture

A mature Microsoft environment might separate authentication requirements by risk.

For ordinary applications:

Standard MFA

For sensitive business applications:

Stronger authentication requirements
+
managed/compliant device controls

For privileged administration:

Phishing-resistant authentication
+
managed privileged workstation
+
Conditional Access
+
PIM
+
strong session controls

Microsoft’s phishing-resistant authentication strength includes methods such as FIDO2 security keys, Windows Hello for Business/platform credentials, and appropriate certificate-based authentication.

This creates defense in depth rather than treating FIDO2 as a magic checkbox.

36. Windows Hello for Business

Windows Hello for Business is sometimes dismissed as merely a convenient PIN or biometric login.

That misunderstands the architecture.

The PIN does not operate like a traditional reusable network password.

It activates cryptographic credentials associated with the device.

This means:

4-6 digit local PIN

can participate in an authentication system with fundamentally different properties from:

4-6 digit server password

The length of the visible secret alone does not determine the security model.

Where the secret is validated and what it unlocks matter.

37. Attack Scenario: Keylogger

Consider malware recording keyboard input.

With password authentication, the malware may capture:

Alice@example.com
Winter2026!

With TOTP, it may also capture:

593821

Timing determines whether that OTP remains useful.

With FIDO2, the user does not type the private authentication key.

A keylogger therefore cannot simply record the private key as keystrokes.

However, this does not mean malware is defeated.

Malware controlling the endpoint may:

• manipulate the browser;
• steal sessions;
• perform actions as the authenticated user;
• capture application data;
• exploit the OS;
• abuse authorized processes.

Again:

FIDO2 is authentication security, not endpoint security.

38. Attack Scenario: Infostealer Malware

Modern infostealers often target:

• browser cookies;
• tokens;
• saved passwords;
• browser databases;
• cryptocurrency wallets;
• application credentials.

Moving from passwords to FIDO2 removes one valuable reusable credential from the attacker’s inventory.

But authenticated browser sessions may remain attractive targets.

Microsoft explicitly recognizes malware-based token theft as a threat even in modern identity environments.

Organizations adopting FIDO2 should therefore avoid making the incorrect conclusion:

FIDO deployed
=
endpoint compromise no longer matters

The correct conclusion is:

One major account-takeover path
has been substantially hardened.

39. Attack Scenario: Malicious OAuth Consent

Another attack can avoid stealing authentication credentials entirely.

An attacker persuades a user to authorize a malicious application.

The user may authenticate legitimately with FIDO2.

Then the user grants the malicious application permissions.

FIDO2 has performed its job correctly.

The user really did authenticate.

The security failure occurred at the authorization layer.

This illustrates the distinction between:

Authentication:
Who are you?

and:

Authorization:
What may this application/user do?

Phishing-resistant authentication does not eliminate malicious application consent.

Organizations still need governance around:

• OAuth applications;
• delegated permissions;
• application permissions;
• consent;
• service principals;
• third-party applications.

40. Attack Scenario: Compromised Administrator

Suppose an attacker compromises an administrator through some independent mechanism.

The administrator has authority to:

Reset authentication methods
Add credentials
Change Conditional Access
Modify authentication policy

FIDO2 cannot protect an identity system from every action performed by an already-authorized administrator.

This is why privileged identity architecture still requires:

• least privilege;
• separation of duties;
• PIM;
• administrative workstations;
• change monitoring;
• audit logs;
• emergency-access controls;
• multiple-person approval where appropriate.

FIDO2 is one layer.

It should be a strong layer, but it remains a layer.

41. Attack Scenario: Stolen Unlocked Device

Suppose a user leaves an unlocked laptop unattended.

The browser contains an active session.

An attacker may not need to authenticate at all.

The security key could be sitting safely in the user’s pocket.

It does not matter if the application accepts the existing session.

This is why screen-lock policy and session management remain important.

Security architecture must distinguish between:

Establishing identity

and:

Maintaining an authenticated session

FIDO2 primarily strengthens the first.

42. Attack Scenario: Cookie Theft

A session cookie may effectively represent:

This browser has already authenticated.

If an attacker can steal and successfully reuse that session artifact, forcing the original user to authenticate with FIDO2 does not necessarily require the attacker to perform FIDO2 again.

Modern identity platforms increasingly add mechanisms intended to constrain token use and evaluate device state, but these are complementary technologies.

The lesson is straightforward:

Protect authentication and protect the resulting session.

43. Why Passwordless Matters

FIDO2 can be used as a second factor.

But its larger architectural potential comes from reducing or eliminating passwords.

Passwords have undesirable properties:

• users choose them;
• users reuse them;
• users disclose them;
• attackers guess them;
• attackers phish them;
• servers maintain password verifiers;
• users forget them;
• help desks reset them;
• password managers must manage them.

Passwordless FIDO authentication removes many of those problems from the normal authentication path.

That does not eliminate identity management.

It changes what must be managed.

44. The Economics of Attack

Security rarely makes attacks mathematically impossible.

More often, it changes their economics.

Imagine an attacker targeting 10,000 employees.

With password phishing, the attacker can automate:

Send email
Collect password
Attempt login

With OTP MFA:

Send email
Proxy login
Capture password
Capture OTP
Relay authentication

More complicated, but still scalable.

With phishing-resistant FIDO2, the attacker may have to move toward:

Endpoint compromise
Help-desk compromise
Credential enrollment fraud
Session theft
Identity infrastructure compromise
Physical theft

These attacks generally require more capability, access, or targeting.

The objective is not necessarily to make compromise impossible.

The objective is to make inexpensive, scalable account takeover substantially less effective.

45. Why This Matters at Enterprise Scale

Suppose an organization has 20,000 users.

Even if security-awareness training produces exceptional results and only 0.5 percent of users fall for a sufficiently convincing campaign, that represents:

100 users

An attacker does not need everyone to fail.

The attacker needs one sufficiently valuable account.

A protocol that reduces dependence on individual human vigilance therefore has enormous value at scale.

This is one reason phishing-resistant authentication is becoming increasingly important in identity security.

46. The Most Important FIDO2 Security Property

It is tempting to say:

FIDO2 is secure because it uses public-key cryptography.

That is true but incomplete.

Public-key cryptography is essential.

But the security improvement against phishing comes from combining several properties:

Public-key credentials
+
Relying-party scoping
+
Origin validation
+
Fresh challenges
+
Local authenticator control
+
User presence/verification

Together these properties produce something conventional OTP authentication does not:

A useful authentication assertion cannot simply be requested by an arbitrary phishing origin and replayed against the legitimate relying party.

47. Traditional MFA Versus FIDO2

A useful comparison looks like this:

Attack	Password Only	Password + SMS	Password + TOTP	Push MFA	Properly Configured FIDO2
Password phishing	Vulnerable	Partially mitigated	Partially mitigated	Partially mitigated	Strongly mitigated
Credential stuffing	Vulnerable	Mitigated	Mitigated	Mitigated	Strongly mitigated
Real-time OTP phishing	N/A	Vulnerable	Vulnerable	N/A	Strongly mitigated
SIM swap	N/A	Vulnerable	Resistant	Resistant	Resistant
Push fatigue	N/A	N/A	N/A	Potentially vulnerable	Resistant to classic push bombing
Lookalike-domain phishing	Vulnerable	Vulnerable to relay	Vulnerable to relay	Depends on workflow	Strongly mitigated through RP binding
Replay of captured password	Vulnerable	Second factor required	Second factor required	Second factor required	Challenge-response prevents assertion replay
Stolen verifier database	Password hashes at risk	Password hashes at risk	Password hashes at risk	Password hashes at risk	Public-key model changes credential-theft value
Session-cookie theft	Potentially vulnerable	Potentially vulnerable	Potentially vulnerable	Potentially vulnerable	Still potentially vulnerable
Endpoint malware	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Still a threat
Weak account recovery	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Still a threat
Malicious OAuth consent	Not solved	Not solved	Not solved	Not solved	Not solved

The final four rows are essential.

Without them, any discussion of FIDO2 risks becoming marketing rather than security analysis.

48. Migration Should Not Begin With Everyone

An enterprise does not necessarily need to migrate every employee simultaneously.

A risk-based rollout can begin with accounts whose compromise would have the greatest impact.

For example:

Phase 1
Identity/security administrators

Phase 2
Other privileged administrators

Phase 3
Executives and finance

Phase 4
Developers and infrastructure engineers

Phase 5
High-risk business units

Phase 6
General workforce

This allows organizations to solve enrollment, recovery, support, and compatibility problems before mass deployment.

49. Give Privileged Users More Than One Authenticator

A high-value account should not depend on one tiny physical object remaining available forever.

A practical model can include:

Primary authenticator
+
Backup authenticator

with both enrolled securely.

The backup can be stored appropriately rather than carried alongside the primary authenticator.

Otherwise a lost key becomes an emergency help-desk event.

Emergency processes are exactly where security controls are most likely to be bypassed.

50. Protect Registration as Strongly as Authentication

A strong deployment should monitor events such as:

New authenticator registered
Authenticator removed
Authentication method changed
TAP issued
Recovery initiated
Conditional Access changed
Authentication strength changed

For privileged users, these events may deserve immediate investigation.

If the authentication credential itself is difficult to steal, attackers will increasingly target the processes used to manage it.

51. Eliminate Weak Fallback Where Appropriate

This may be the hardest organizational step.

Deploying FIDO2 while retaining unrestricted:

SMS
Voice
OTP
Push

fallback can preserve the attacker’s preferred path.

Migration therefore involves more than adding authentication methods.

It requires examining every path capable of satisfying access requirements.

Microsoft’s Authentication Strength capability is particularly useful here because Conditional Access can require a phishing-resistant method for specific resources rather than merely requiring generic MFA.

52. Protect the Help Desk

Help-desk procedures become part of the cryptographic system’s effective perimeter.

Organizations should ask:

• How is a caller’s identity established?
• Can a help-desk technician issue a bootstrap credential?
• Who can reset authentication methods?
• Are privileged resets separately controlled?
• Are resets logged?
• Are users notified?
• Are suspicious changes alerted?
• Are high-risk resets subject to approval?

If an attacker cannot phish the authenticator, the attacker may phish the administrator who can replace it.

53. Train Users Differently

FIDO2 does not eliminate security awareness.

It changes what should be taught.

Traditional training says:

Don't give anyone your password.
Don't give anyone your MFA code.
Check links carefully.

A FIDO2-aware program can add:

No legitimate administrator needs
your security key PIN.

Do not register an authenticator
because somebody calls you.

Report unexpected authentication
registration requests.

Report unexpected recovery activity.

Do not approve unfamiliar OAuth
application permissions.

The human attack surface moves.

Training should move with it.

54. Inventory Applications That Cannot Support Modern Authentication

Legacy systems remain a challenge.

Organizations may discover applications dependent on:

• basic authentication;
• LDAP password binds;
• RADIUS;
• legacy VPN authentication;
• application-specific passwords;
• unsupported browsers;
• old thick clients.

These systems can prevent an organization from achieving a truly phishing-resistant identity architecture.

The correct response is not to pretend the problem does not exist.

Inventory it.

Segment it.

Apply compensating controls.

Then modernize or retire it.

55. Measure the Deployment

A FIDO2 project should produce measurable security outcomes.

Useful metrics can include:

% users with FIDO credentials

% privileged accounts with
phishing-resistant authentication

% applications enforcing
phishing-resistant authentication

% sign-ins using weak methods

SMS authentication events

TOTP authentication events

Authentication-method registrations

Authentication-method resets

Help-desk recovery events

Risky sign-ins

Legacy authentication events

The goal is not merely:

"We deployed security keys."

The goal is:

"An attacker cannot reach our critical
resources through a phishable
authentication path."

Those statements are very different.

56. A Better Definition of Success

A mature deployment should be tested adversarially.

Ask a penetration tester or red team:

Assume you know an administrator’s password. Obtain access without stealing the administrator’s physical authenticator.

That exercise tests the architecture rather than the feature.

The tester may discover:

SMS fallback
Weak recovery
Legacy VPN
Application password
OAuth abuse
Session theft
Help-desk reset
Unprotected enrollment
Break-glass misuse

Those findings tell the organization where phishing resistance actually ends.

57. The Authentication Ladder

Authentication security can be viewed as an evolutionary ladder.

Password

Something the user knows.

Password + SMS

Something the user knows
+
control of a phone number.

Password + OTP

Something the user knows
+
possession of an OTP secret/device.

Password + Push

Something the user knows
+
approval through another device.

FIDO2

Possession of a cryptographic credential
+
optional/required local user verification
+
credential scoped to the relying party
+
fresh challenge-response authentication.

The final step is not merely another factor.

It changes the structure of the authentication transaction.

58. The Central Security Insight

For decades, authentication systems have placed enormous responsibility on users.

Users must:

Choose a good password.
Don't reuse it.
Don't disclose it.
Recognize phishing.
Inspect the URL.
Don't enter the OTP into the wrong site.
Don't approve the wrong notification.
Don't trust the wrong caller.

Security professionals then become frustrated when, among tens of thousands of employees, somebody eventually makes a mistake.

FIDO2 represents a different philosophy.

Where possible:

Do not ask humans to perform work that cryptographic protocols can perform more reliably.

The user still has responsibilities.

But determining whether:

login-example.com

is cryptographically the same relying party as:

example.com

does not need to be one of them.

59. What FIDO2 Does Not Solve

A realistic security strategy should explicitly document FIDO2’s boundaries.

FIDO2 does not inherently prevent:

Endpoint compromise.
Malware controlling an authenticated endpoint may operate within the user’s session.

Session theft.
An attacker obtaining a reusable authenticated session may not need to repeat FIDO authentication.

Malicious authorization.
A legitimately authenticated user can still grant dangerous permissions.

Weak recovery.
An attacker who convinces support personnel to replace an authenticator may bypass the authentication control.

Fraudulent enrollment.
Strong cryptography protects whichever credential was registered, including one registered by an attacker through a compromised process.

Identity-provider compromise.
Authentication protocols cannot compensate for complete compromise of the systems enforcing authentication.

Authorized malicious insiders.
FIDO2 proves possession/control of credentials. It does not determine whether the authorized human has malicious intent.

Application vulnerabilities.
SQL injection, remote code execution, broken authorization, insecure APIs, and similar vulnerabilities remain vulnerabilities.

Physical compromise of an active session.
An unlocked authenticated workstation remains dangerous.

Recognizing these limitations does not weaken the case for FIDO2.

It strengthens it by identifying precisely which problem FIDO2 solves.

60. The Real Goal: Remove Transferable Authentication

The common thread among many traditional attacks is transferability.

A password can be transferred:

Winter2026!

An OTP can be transferred:

581942

An SMS code can be transferred.

A push approval can sometimes be induced remotely.

A recovery code can be transferred.

Phishing-resistant FIDO authentication attempts to replace those transferable authentication artifacts with a cryptographic ceremony whose useful output is constrained to the appropriate context.

This changes the attacker’s question.

Before:

“How do I convince Alice to give me what I need?”

After:

“How do I compromise Alice’s device, recovery process, authenticator lifecycle, session, or identity infrastructure?”

The second problem is considerably more expensive.

That is progress.

61. Conclusion: From Human Vigilance to Cryptographic Assurance

Multifactor authentication remains one of the most important security improvements an organization can deploy.

But MFA should no longer be treated as a binary property.

The question:

“Do we have MFA?”

is becoming less useful.

Better questions are:

“Which authentication methods do we permit?”

“Are they phishing-resistant?”

“Can users fall back to weaker methods?”

“How are authenticators enrolled and recovered?”

“How are authenticated sessions protected?”

“Which resources actually require phishing-resistant authentication?”

Password plus SMS is MFA.

Password plus TOTP is MFA.

Push approval is MFA.

FIDO2 can also provide multifactor authentication.

But these technologies do not offer equivalent resistance to modern attacks.

The fundamental improvement introduced by FIDO2 is not simply another factor.

It is the combination of public-key cryptography, relying-party scoping, origin validation, fresh cryptographic challenges, and authenticator-controlled private keys.

A traditional authentication system frequently asks:

“Can the user provide the right secret?”

FIDO2 allows the system to ask something stronger:

“Can the legitimate authenticator prove possession of the correct private credential, for this relying party, in this authentication ceremony?”

That distinction blocks or substantially mitigates entire classes of attacks that conventional MFA leaves exposed.

Credential phishing becomes far less useful.

OTP relay loses its transferable authentication artifact.

SIM swapping no longer transfers the relevant credential.

Push bombing loses the generic approval mechanism it exploits.

Credential stuffing loses reusable passwords when passwordless authentication is enforced.

Captured authentication assertions cannot simply be replayed against fresh challenges.

Lookalike domains cannot become legitimate relying parties merely by looking convincing.

But the security work does not end there.

Attackers adapt.

When authentication becomes difficult to phish, recovery becomes more attractive.

When credentials become difficult to steal, sessions become more attractive.

When users cannot hand attackers an OTP, attackers may attempt to convince administrators to enroll a new authenticator.

When identity becomes stronger, authorization and endpoint compromise become comparatively more valuable targets.

The correct conclusion is therefore not:

FIDO2 solves identity security.

It is:

FIDO2 removes one of the most important weaknesses from modern authentication: the assumption that humans must reliably distinguish the legitimate verifier from a convincing impostor.

That is why phishing-resistant authentication represents more than an incremental improvement over traditional MFA.

It changes where trust is placed.

Traditional MFA often depends upon the user recognizing the attacker.

FIDO2 allows cryptography to recognize that the authentication request belongs somewhere else.

And whenever a security decision can be moved from human judgment to a correctly implemented cryptographic protocol, defenders gain something extraordinarily valuable:

The user can make a mistake without automatically giving the attacker the credential needed to become them.

Author Note

This paper is intended as an educational and practical overview for business leaders, security practitioners, infrastructure teams, identity administrators, and technical decision-makers evaluating phishing-resistant authentication.

Its focus is not on treating FIDO2 as a product feature or a universal cure. The goal is to explain the security model clearly enough that organizations can understand what changes, what remains exposed, and which surrounding processes become more important once authentication itself becomes harder to phish.

About the Author

Jeff Campbell is an IT and cloud infrastructure consultant currently working with a high-quality Managed Service Provider supporting healthcare, enterprise, and regulated business environments. His background includes cloud architecture, database platforms, disaster recovery, security operations, infrastructure modernization, firewall governance, Microsoft 365, AWS, and enterprise systems integration.

Jeff previously spent seven years at AWS, including work with Amazon RDS, Aurora PostgreSQL, AWS Database Migration Service, and large-scale database modernization efforts. His current work focuses on helping organizations understand operational risk, modernize infrastructure, and prepare for technology shifts before they become emergencies.

For questions or follow-up discussion regarding this paper, Jeff can be reached at research@solvefor42.com.

References

• National Institute of Standards and Technology (NIST), Digital Identity Guidelines and guidance on phishing-resistant authentication, verifier-name binding, replay resistance, and Authentication Assurance Levels.
• World Wide Web Consortium (W3C), Web Authentication: An API for accessing Public Key Credentials (WebAuthn).
• FIDO Alliance, FIDO2, passkey, phishing-resistance, authenticator, and public-key credential guidance.
• Microsoft Learn, Microsoft Entra documentation covering phishing-resistant authentication strength, Conditional Access, passkeys/FIDO2 security keys, Temporary Access Pass, token theft, and authentication-method policy.

Suggested Citation

Campbell, Jeff. "Beyond MFA: Why FIDO2 Changes the Security Model of Authentication." SolveFor42 Research Publication No. 2, September 19, 2026.