MFA isn't always enough: Which authentication methods better withstand phishing

A username and password are no longer a strong enough foundation for protecting important corporate systems. A password can be exposed in a data breach, reused across multiple services, or obtained through phishing.

Multi-factor authentication adds another step. Knowing the password alone may therefore not be enough for an attacker. However, this does not mean that all forms of MFA provide the same protection. A one-time code can be obtained through a fraudulent website. Push notifications may be approved by a user under pressure. And with more sophisticated phishing, an attacker may also work with the authentication session.

The question is therefore no longer simply: Is MFA enabled? The more important question is: What type of attack can a particular authentication method prevent?

What MFA actually means

MFA, multi-factor authentication, combines more than one type of authentication factor when verifying identity.

Typically, these are:

Faktor	Example
Something the user knows	Password or PIN
Something the user has	Phone, token, security key
Something the user is	Fingerprint or facial biometrics

 

The point is not to perform the same check twice. Security comes from combining independent factors. If a password is compromised, the attacker still needs to overcome another authentication mechanism.

This is precisely why MFA is an important part of protecting corporate infrastructure. ANASOFT also addresses it in the broader context of identity protection, access management, and the Zero Trust model in the article How to Keep Your Corporate Infrastructure from Being Hacked. The problem arises when all MFA methods begin to be regarded as equivalent.

SMS: better than a password alone, but not without weaknesses

One of the best-known forms of MFA is a one-time code delivered by SMS. The process is simple:

1. the user enters a password,
2. a one-time code is sent to the phone,
3. the code is entered into the login form.

The advantage is accessibility. No separate authentication app or special hardware is required. However, phishing leaves a fundamental weakness: a code is a piece of information that can be re-entered. A fraudulent website can obtain the user's password and then ask for the SMS code as well. If the attacker uses the information against the legitimate service in real time, the user may actually authorize the attacker's login.

SMS also depends on the mobile network and phone number, so there are additional risks associated with the telecommunications channel. This does not mean that SMS MFA has no value. Compared with a password alone, it adds another security barrier. However, it should not be confused with a method designed to technically prevent phishing itself.

OTP app: a stronger channel, a similar phishing problem

Another common method is one-time codes generated by an authentication app. OTP, one-time password, is valid only for a short time and is not transmitted by SMS. This removes some of the weaknesses associated with the mobile network.

From a phishing perspective, however, the problem is similar to SMS: a user can also enter a code displayed in the app on a fraudulent website. The attacker therefore does not need to break the mathematics that generates the code. They only need to persuade the person to give a valid code to the wrong website. This clearly illustrates the difference between a strong second factor and phishing-resistant authentication.

OTP can significantly improve security against attacks based solely on a stolen password. However, the authentication protocol itself does not prevent the user from giving the one-time information to a phishing website.

Push notification: convenience created a new type of problem

Instead of requiring a code to be entered, mobile authentication apps can display a push notification: Allow sign-in? The user presses a button and authentication continues. This is convenient, but it creates a new form of social engineering, MFA fatigue, also known as push bombing.

The attacker already knows the password and repeatedly attempts to log in. Authentication requests begin arriving on the user's device. One. Another. And another. The goal is to make the user:

• approve one by mistake,
• approve one out of habit,
• or approve one simply to make the notifications stop.

Once again, this type of attack does not break the technology itself. It exploits how people interact with the authentication process. That is why additional mechanisms are used for push authentication, such as displaying login context or matching a number between the login screen and the authentication app. However, this does not change the basic principle: the outcome of authentication still depends on whether the user correctly recognizes a legitimate request.

Not all MFA methods protect against the same threats

The differences can be summarized as follows:

Method	Main advantage	Phishing risk
SMS code	Easy deployment	The code can be obtained through deception
OTP app	The code does not depend on SMS	The code can be obtained through deception
Push approval	Convenient to use	Fraudulent or repeated requests
Passkey	Cryptographic verification of the service	Designed to resist phishing
FIDO2 security key	Strong cryptographic verification	Designed to resist phishing

 

The table does not mean that the first three options are useless. All of them can represent a significant improvement over a password alone. The difference is whether the protection still assumes that the person correctly recognizes who they are giving the authentication information to or which login they are approving.

What phishing-resistant authentication means

Phishing-resistant authentication is intended to prevent an authentication secret or usable authentication output from being obtained by a fake service posing as a legitimate one. The key difference is that security no longer depends solely on the user's attentiveness.

The current NIST SP 800-63B-4 guidance defines phishing resistance as a property of an authentication protocol that prevents the disclosure of usable authentication data to a fraudulent verifier without relying on user vigilance. At AAL2, at least one phishing-resistant authentication option must be available.

This is a significant shift. With OTP, the security mechanism may end with the statement: The code must not be entered on a fraudulent website. With phishing-resistant authentication, the technical mechanism itself is intended to make authentication against the wrong service impossible.

Passkeys: the user no longer re-enters a secret

A passkey uses cryptographic keys instead of a password or one-time code. In simplified terms:

• the service knows the public part of the key,
• the private part remains protected on the device or within a secure ecosystem,
• the user unlocks the login, for example, with biometrics or the device PIN,
• authentication is cryptographically bound to a specific service.

Unlike a password or OTP, there is no code here that can be copied from a legitimate app and entered into a phishing form. The FIDO Alliance states that passkeys are based on FIDO standards and use cryptographic key pairs. A passkey is cryptographically linked to a specific service. It therefore cannot be used on a fraudulent website that merely imitates a legitimate login in the same way as a password or one-time code. This binding is one of the foundations of phishing resistance.

Passkeys are no longer merely an experimental technology. According to FIDO Alliance research from May 2026, 68% of 1,400 surveyed managers at organizations with more than 500 employees across ten countries were deploying or introducing them in the workplace. These are survey data, not a universal adoption rate for all companies, but they show the technology moving toward broader use.

Where FIDO2 fits in

A passkey and FIDO2 are not two competing authentication methods. FIDO2 refers to a set of standards that combines WebAuthn and the Client to Authenticator Protocol (CTAP). Modern FIDO credentials, including passkeys, are built on these standards. In practice, an authenticator may exist, for example:

• directly on a computer or phone,
• on a managed device,
• as a separate hardware security key.

These options do not automatically have the same operating model. For a company, it may be important whether a passkey is synchronized across devices or remains bound to a specific device, how recovery is handled, and what requirements apply to administrator accounts. Therefore, simply saying ‘we use passkeys’ does not replace a security policy.

Biometrics are not a password sent to a server

With passkeys, a user can confirm a login with a fingerprint or facial recognition. This may create the impression that biometric data is sent to the web service. In FIDO authentication, however, biometrics typically serve to unlock the authenticator locally. The FIDO Alliance states that biometric information does not leave the user's device in this model.

The service receives cryptographic proof, not a facial image or fingerprint database. This distinction is also important when communicating with employees, because biometric device unlocking and centralized storage of biometric data are two different things.

Stronger MFA should start where compromise would have the greatest impact

Not all corporate accounts pose the same risk. Compromising a user with access to one internal tool has a different potential impact from compromising an account that can:

• create additional users,
• reset passwords,
• change security policies,
• access backups,
• manage cloud infrastructure,
• change identity configuration,
• or disable security controls.

That is why privileged and administrator accounts are a natural priority when introducing stronger authentication.

Account type	Potential impact of compromise
Standard user	Access to the user's data and applications
Finance role	Payments, invoicing, financial data
HR	Personal and personnel data
IT administrator	Broad system privileges
Identity administrator	Accounts, MFA, and access policies
Backup administrator	Recovery and backups
Cloud administrator	Infrastructure and services

 

The table does not define a universal hierarchy. The specific risk depends on the company's architecture and permissions. However, it shows why it may not be appropriate to deploy authentication methods solely according to convenience or uniformly for every user. A more sensitive role may require a higher level of assurance.

MFA must be combined with least privilege

Even phishing-resistant authentication does not solve every identity problem. If a legitimate account has unnecessarily broad permissions, strong authentication reduces the likelihood of account takeover but does not change the extent of the damage if a compromise still occurs. Identity protection therefore involves two separate questions: Is this really an authorized user? And what is this user allowed to do?

This principle is also reflected in the Zero Trust concept, which does not base trust solely on the fact that a user has successfully logged in once. ANASOFT addresses the broader principle of verifying identity, devices, and permissions in its article on Zero Trust security. MFA is therefore part of access management, not a replacement for it.

An attack can continue even after a successful login

Stronger authentication addresses a significant part of the problem, but the security model cannot end at the login screen. After an identity or session is compromised, events may include:

• an unusual login,
• access to a new system,
• an unusual volume of downloaded data,
• a change in permissions,
• the creation of a new authentication mechanism,
• or activity at a time and in a context that do not match the user.

Authentication is therefore supplemented by monitoring and the ability to evaluate context. The article 5 Most Common IT Security Mistakes Companies Make discusses this need for multi-layered protection in greater detail and highlights the problem of relying on isolated measures instead of systematic security.

Stronger authentication must not create weaker account recovery

When moving to passkeys or hardware security keys, it is easy to focus only on the primary login process. However, the account must also address situations where:

• the device is lost,
• the authenticator stops working,
• an employee changes phones,
• a new employee receives initial access,
• an administrator needs to recover an account,
• or a user leaves the company.

If the primary login is phishing-resistant but the account can be recovered through a significantly weaker mechanism, an attacker may try to bypass strong authentication through the recovery process.

In its guidance on the path to a phishing-resistant environment, the FIDO Alliance explicitly warns that introducing a new login method is not enough; the entire lifecycle, including recovery, must be handled securely. For a company, authentication is therefore a process, not just a login screen.

Which MFA strategy should you choose?

There is no single rule that is optimal for every organization and every system. Decisions should be based on risk. Important questions include:

• what data or systems the account protects,
• what permissions the user has,
• whether the system is accessible from the internet,
• what consequences an account takeover would have,
• whether the authentication method resists phishing,
• how account recovery is handled,
• and how authentication will be managed throughout the user's entire lifecycle.

For a standard account, even traditional MFA can be a significant improvement over a password. For an account with access to sensitive systems or administrative privileges, it makes sense to require stronger, more phishing-resistant authentication.

At AAL2, NIST now requires verifiers to offer at least one phishing-resistant option, and it already requires such an option for workforce access at U.S. federal organizations. Although this framework is not automatically mandatory for Slovak or Czech private companies, it clearly illustrates the direction in which modern authentication recommendations are moving.

‘We have MFA’ is the beginning, not the result of a security analysis

Deploying MFA is an important step. However, security should not be assessed solely by whether an account displays the information ‘MFA enabled’.

What matters is:

• the authentication method used,
• how it is implemented,
• the risk associated with the specific account,
• the recovery process,
• the scope of permissions,
• and the ability to detect unusual behavior.

The difference between an SMS code and FIDO2 authentication is therefore not merely a matter of user experience. It is a difference in the type of attack the mechanism is designed to withstand. The ANASOFT article Password as the First Line of Protection explains the basic principle of multi-factor authentication.

Today's developments in authentication take this idea further: the goal is no longer simply to add a second factor, but to use a mechanism for sensitive access that can better resist phishing itself.

From MFA to identity protection

Phishing shows why a password alone is no longer enough. Today's phishing techniques also show why not every form of MFA should automatically be considered equivalent. Stronger identity protection comes from combining:

1. an appropriate authentication method,
2. appropriate permissions,
3. a secure account lifecycle,
4. monitoring of unusual behavior.

For administrator and other critical accounts, the authentication method is particularly important because successful phishing can give an attacker disproportionately broad access to the corporate environment. The goal is therefore not to deploy as many authentication steps as possible. The goal is to use a level of verification that matches the risk of the specific access.

Strong authentication starts with assessing high-risk accounts

Moving to more resilient authentication does not have to mean immediately changing every account and every application. The first step may be to identify the accounts and systems where compromise would have the greatest impact - administrative roles, cloud services, critical applications, or external-user access.

It is then possible to assess where the current MFA is adequate and where it is appropriate to move to authentication mechanisms with greater phishing resistance. Stronger authentication should not create additional obstacles for users. It should reduce the likelihood that a compromised password or convincing phishing attack will lead to the compromise of a corporate account.

Frequently Asked Questions