MFA Changed the Attack — It Did Not End It
An employee receives what appears to be a legitimate Microsoft 365 sign-in request.
— > They enter their username and password.
— > A one-time passcode arrives on their phone.
— > They enter that too.
The attacker captures the credentials, relays the OTP in real time, and successfully signs in to the legitimate service.
** The employee had MFA.
** The account was still compromised.
That is the distinction security leaders need to understand:
MFA does not automatically mean phishing-resistant MFA.
Traditional multifactor authentication significantly improves security compared with passwords alone, but attackers have adapted. Modern adversary-in-the-middle phishing frameworks can proxy legitimate authentication sessions, capture passwords and one-time codes, and in some cases obtain authenticated session access.
NIST’s current Digital Identity Guidelines explicitly state that manually entered OTP and out-of-band authenticators are not phishing-resistant because the authentication output is not bound to the specific session. An impostor verifier can relay that output to the legitimate verifier and successfully authenticate. NIST Publications
The security question is therefore evolving from:
“Do we have MFA?”
to:
“Can our MFA resist phishing?”
1. MFA Raised the Bar — Attackers Changed Tactics
Passwords have long been a weak point in enterprise security.
Users reuse them.
Attackers steal them through phishing.
Credentials appear in breach datasets.
Malware can capture them.
Organizations responded by deploying MFA.
That was the right move.
Adding a second factor makes many traditional password attacks far less effective.
But MFA is a category, not a single technology.
Different MFA methods provide different levels of protection.
Examples include:
- SMS codes
- email OTP
- authenticator-app OTP
- push notifications
- number matching
- hardware security keys
- passkeys
- platform authenticators
- FIDO2/WebAuthn
Some protect effectively against password theft but remain susceptible to sophisticated phishing.
Others are designed specifically to resist phishing.
That distinction matters increasingly as attackers focus on stealing valid authentication sessions rather than simply stealing passwords.
2. Why OTP Can Still Be Phished
A one-time password sounds inherently secure.
After all, the code expires quickly and normally cannot be reused.
The problem is that an attacker does not necessarily need to reuse it later.
They can relay it immediately.
A simplified attack might work like this:
- A user receives a convincing phishing email.
- The link opens a malicious page resembling the organization’s real login portal.
- The attacker simultaneously connects to the legitimate service.
- The user enters their username and password.
- The malicious site forwards those credentials to the legitimate service.
- The legitimate service requests an OTP.
- The user enters the OTP into the phishing page.
- The attacker immediately relays it to the real service.
- Authentication succeeds.
The OTP performed exactly as designed.
It was valid once.
The problem was where the user entered it.
NIST explains that manually entered authentication outputs such as OTPs are not phishing-resistant because they are not cryptographically bound to the particular authentication session or verifier. NIST Publications
This is why an expired OTP is not the only issue security teams should consider.
The more important question is:
Can the authentication factor distinguish the legitimate service from an impostor?
3. Push MFA Has Its Own Risks
Push-based authentication improved usability by replacing manually entered codes with an approve/deny notification.
But attackers adapted here as well.
Common attack patterns can include:
- repeated approval requests
- social-engineering calls
- help-desk impersonation
- attacker-generated number matching
- user confusion during legitimate login activity
If users become conditioned to approving prompts, security can degrade into a human decision under pressure.
Number matching and additional contextual information can improve push authentication, but organizations should still understand the difference between stronger MFA and phishing-resistant authentication.
The objective should not simply be to make phishing more difficult.
The strongest architecture should prevent the authenticator from working against the wrong service in the first place.
4. What Makes Authentication Phishing-Resistant?
Phishing-resistant authentication relies on cryptography rather than asking a user to recognize whether a login page is legitimate.
That distinction is important.
A traditional password or OTP can be entered into the wrong website.
A phishing-resistant credential is designed so that the impostor site cannot successfully use it to authenticate to the legitimate service.
NIST recognizes phishing resistance through cryptographic mechanisms such as channel binding and verifier-name binding. The core objective is to prevent valid authentication output from being disclosed or reused by a fraudulent verifier. NIST Publications
In practical terms, phishing-resistant authentication typically involves:
- a public/private key pair
- a credential registered to the legitimate service
- cryptographic proof during authentication
- binding to the intended verifier or domain
- no reusable secret transmitted to the website
The private key remains protected by the authenticator.
The legitimate service receives proof that the user possesses the correct credential.
A fake login page cannot simply capture a code and replay it.
5. FIDO2 and WebAuthn in Practical Terms
FIDO2 and WebAuthn are among the most widely adopted technologies for phishing-resistant authentication.
CISA specifically identifies FIDO/WebAuthn as the widely available phishing-resistant authentication approach organizations should strive toward. CISA
WebAuthn is supported across major browsers, operating systems, mobile devices, and identity platforms.
Authentication can use several types of authenticators.
Hardware security keys
A physical device connects through technologies such as:
- USB
- NFC
- Bluetooth
The device contains the cryptographic credential used during authentication.
Platform authenticators
The credential can also live on the user’s existing device.
Examples include authentication protected by:
- fingerprint
- facial recognition
- device PIN
- secure hardware
Passkeys
Passkeys extend this model into a more user-friendly credential experience.
Rather than typing a password, the user authenticates using a device-bound or synchronized cryptographic credential.
The underlying principle remains the same:
The user proves possession of a cryptographic key rather than presenting a reusable secret to the website.
6. Why Domain Binding Changes the Phishing Model
Consider the previous phishing example.
The attacker creates:
account-secure-login.com
and copies the appearance of:
login.microsoft.com
A password does not know the difference.
An OTP does not know the difference.
The user has to recognize the difference.
FIDO2/WebAuthn changes that relationship.
The credential is associated with the legitimate relying party.
Authentication will not simply succeed because a fake site looks convincing.
This removes a major burden from the user.
Instead of relying primarily on:
“Can the employee detect the phishing page?”
the authentication protocol itself helps enforce:
“This credential only works for the legitimate service.”
That is a fundamental security improvement.
7. Where Organizations Should Start
Most organizations will not migrate every application and every user to phishing-resistant authentication overnight.
That is not necessary.
Start with the identities where compromise would create the greatest business impact.
Privileged administrators
Administrators can modify infrastructure, security controls, identities, and data.
They should be among the first users migrated.
Executives
Executives are frequent phishing targets and may have access to sensitive corporate, financial, and strategic information.
Cloud administrators
Access to AWS, Azure, OCI, Google Cloud, or SaaS administration can create an enormous blast radius.
Remote access
VPN and other remote-access systems are attractive authentication targets because successful compromise may create a direct path into the environment.
Financially sensitive roles
Finance, payroll, treasury, accounts payable, and similar users are frequent targets for account takeover and fraud.
Developers with production access
Developers may have access to:
- source repositories
- CI/CD
- production infrastructure
- secrets
- cloud environments
Compromise can quickly become a software-supply-chain or infrastructure issue.
A phased rollout allows organizations to reduce the highest-risk exposure first while preparing broader deployment.
8. Inventory Applications Before Migration
A phishing-resistant MFA program depends partly on application compatibility.
Before defining the migration plan, organizations should identify:
- identity providers
- SaaS applications
- VPN platforms
- legacy applications
- privileged-access systems
- cloud consoles
- administrative interfaces
- federation relationships
- protocols in use
Some modern applications may support FIDO2 or WebAuthn directly.
Others may inherit the capability through a centralized identity provider.
Legacy applications may require:
- federation
- proxy integration
- modernization
- compensating controls
This is why phishing-resistant MFA is usually best approached as an identity architecture initiative, not simply a hardware-key deployment.
9. Do Not Forget Enrollment and Recovery
Strong authentication can still be undermined by weak recovery processes.
Consider this scenario:
A privileged administrator uses a hardware security key.
The key is lost.
They call the help desk.
If the help desk resets the account based on weak identity verification, an attacker may bypass the stronger authenticator entirely.
A mature deployment should address:
- initial enrollment
- credential registration
- lost-device procedures
- backup authenticators
- key replacement
- account recovery
- help-desk verification
- termination and revocation
- device lifecycle
For high-risk accounts, organizations may require multiple registered authenticators so loss of one does not trigger insecure emergency procedures.
Security should evaluate the entire authentication lifecycle, not only the sign-in event.
10. Passkeys Need Governance Too
Passkeys can substantially improve both user experience and security.
But organizations should still establish policy around:
- device ownership
- credential synchronization
- personal vs. corporate devices
- recovery
- credential revocation
- privileged users
- regulated workloads
The question should not simply be:
“Do we support passkeys?”
It should be:
“What passkey architecture is appropriate for this user, device, and resource?”
Different risk levels may justify different implementations.
For example, a normal SaaS user and a production cloud administrator may not require identical authentication policy.
11. Authentication Is Only One Layer of Zero Trust
Phishing-resistant MFA is powerful.
But authentication alone does not create Zero Trust.
Strong access decisions should consider more than whether the user successfully authenticated.
Additional context can include:
- device posture
- device ownership
- geographic signals
- user risk
- resource sensitivity
- privilege level
- session behavior
- network conditions
Velocis approaches Identity & Zero Trust around a broader question:
Who or what should be allowed to access a resource, under what conditions, and for how long?
That means connecting authentication with:
Identity
Who is requesting access?
Device
Is the device trusted and compliant?
Resource
What is the user trying to access?
Privilege
How much access is required?
Context
Does the request match expected behavior?
Velocis’ Identity & Zero Trust practice combines IAM, SSO, federation, MFA, adaptive access, cloud identity, lifecycle governance, and Zero Trust architecture across cloud and hybrid environments. Velocis Technologies
12. Strong Authentication Should Reduce Friction — Not Add It Everywhere
Zero Trust is sometimes misunderstood as requiring constant challenges for every user.
That is not the objective.
A well-designed identity architecture can actually make legitimate access easier.
For example:
A user authenticates strongly with a phishing-resistant credential.
Their corporate device is healthy.
Their access request matches policy.
Their behavior is expected.
The organization may then allow access without repeatedly challenging the user.
Meanwhile:
A privileged login from an unmanaged device requesting access to a sensitive resource may require stronger controls.
The goal is more precise trust decisions, not more friction.
13. Identity Events Should Feed the SOC
Authentication does not operate in isolation.
Identity activity can be an important security signal.
Security teams should monitor for:
- unusual authentications
- unexpected device registrations
- new authenticators
- privilege escalation
- abnormal geographic activity
- impossible travel
- repeated recovery attempts
- unusual session behavior
- changes to MFA configuration
Velocis explicitly connects identity signals to its broader security-operations model, where suspicious authentication, stale accounts, unusual access, or service-identity misuse can become detection and investigation signals. Velocis Technologies
This becomes especially important after deploying stronger authentication.
If an attacker cannot easily phish the primary authentication factor, they may target:
- recovery processes
- session tokens
- device enrollment
- help desks
- legacy authentication
- privileged exceptions
Continuous monitoring remains essential.
A Practical Phishing-Resistant MFA Roadmap
Organizations can approach migration through five steps.
1. Discover
Identify:
- MFA methods currently in use
- applications
- authentication protocols
- privileged identities
- high-risk users
- legacy dependencies
2. Assess
Determine:
- which MFA methods remain phishable
- which applications support FIDO2/WebAuthn
- where authentication risk is highest
- where recovery processes are weak
3. Prioritize
Start with:
- administrators
- executives
- high-risk remote access
- cloud administration
- sensitive business functions
4. Deploy
Implement:
- FIDO2/WebAuthn
- hardware security keys where appropriate
- platform authenticators
- passkeys
- strong enrollment and recovery
5. Monitor
Review:
- authentication anomalies
- registration events
- bypasses
- recovery usage
- policy exceptions
The goal is not to replace every authentication method immediately.
It is to systematically remove the highest-risk paths first.
The Question Security Leaders Should Ask
Many organizations can already answer:
“Do we use MFA?”
That question is no longer sufficient.
The more useful questions are:
Which MFA methods are we using?
Which ones can still be phished?
Which high-value identities remain exposed?
Which applications support FIDO2/WebAuthn today?
How strong is our credential-recovery process?
Can identity events be monitored by our SOC?
Those answers provide a much clearer picture of authentication risk.
Make Authentication Harder to Steal — Not Harder to Use
Phishing-resistant MFA changes an important part of the attacker equation.
Instead of relying primarily on users recognizing every fake website, organizations can use cryptographic authentication that helps prevent credentials from working at the wrong site.
But the strongest results come when phishing-resistant MFA becomes part of a broader identity architecture.
At Velocis Technologies, we connect modern authentication with:
- Identity and Access Management
- Zero Trust
- privileged-access controls
- cloud identity
- lifecycle governance
- conditional access
- security monitoring
The objective is straightforward:
Make access easier for legitimate users while making stolen credentials significantly less useful to attackers.
Is Your MFA Actually Phishing-Resistant?
Velocis can help organizations assess current authentication methods, identify high-risk accounts and applications, and develop a phased migration toward phishing-resistant authentication.
Request a Velocis Phishing-Resistant MFA Readiness Assessment
A readiness assessment can evaluate:
- current MFA methods
- privileged identities
- application compatibility
- FIDO2/WebAuthn readiness
- passkey strategy
- recovery processes
- conditional access
- identity monitoring