Cyber Security, Insights, Strategy

Your MFA is enabled. But is it phishing-resistant?

12th October 2026
A person using MFA to log onto computer

Multi-factor authentication has become a standard measure of security maturity. Organisations track deployment percentages, encourage users to register an authenticator app and require a second factor before granting access to important systems.

That progress matters. MFA can stop many account takeover attempts that would succeed against passwords alone.

But the percentage of users enrolled in MFA no longer tells security leaders enough about the protection their organisation has achieved. Traditional MFA methods can still be vulnerable to phishing attacks, particularly when an attacker can intercept a one-time code, manipulate an end user into approving a login request or relay an authentication process through a convincing phishing site.

The more important question is therefore not simply whether MFA is enabled. It is whether the authentication methods being used are phishing-resistant.

The US Cyber security and Infrastructure Security Agency (CISA) has urged organisations to implement phishing-resistant MFA. Where organisations cannot immediately replace push-based authentication, it recommends number matching as an interim mitigation, while making clear that this is not as strong as phishing-resistant authentication.

For organisations that have already invested in MFA, the next step is not to dismiss that work. It is to assess whether the authentication process remains effective against the phishing techniques attackers now use.

If you are reading this because your organisation has experienced a cyber incident and is unsure how to respond, contact Zensec immediately.

Why enabled does not necessarily mean protected

MFA strengthens authentication by asking a user to provide more than one form of evidence.

These authentication factors usually include something the user knows, such as a password or PIN; something the user has, such as a security key or registered device; or something the user is, represented by biometrics such as a fingerprint or facial recognition.

Combining factors is considerably stronger than single-factor authentication. An attacker who steals a password should not be able to gain access without satisfying the additional requirement.

However, not every second factor provides the same level of security.

Many traditional MFA methods still require users to receive, enter or approve something during the login process. If that information or action can be captured, relayed or fraudulently prompted, the attacker may be able to authenticate despite MFA being enabled.

For example, a user may enter a credential into a phishing site designed to resemble a legitimate online service. The attacker can attempt to use that information against the genuine service and prompt the victim for the next stage of authentication. If the user supplies a one-time token or approves the login request, the attacker may be able to complete the session.

The organisation has MFA. The attacker has still found a way through it.

This is why MFA should not be treated as a single, uniform security control. The protection depends on the authentication method, how it has been implemented and whether enrolment and recovery processes are equally secure.

How attackers target traditional MFA methods

Attackers do not always need to break cryptography or compromise an identity provider. Often, it is easier to manipulate the user or exploit how the authentication flow has been designed.

Phishing kits can recreate legitimate login pages and relay information to the genuine service in real time. This allows an attacker to collect a password and then ask for an SMS or authenticator app code while the victim still believes they are completing a normal login.

Push-based authentication creates a different opportunity. After obtaining a user’s password through phishing, credential stuffing or another technique, an attacker may generate repeated MFA requests on the user’s device.

Some users will reject those requests. Others may eventually approve one because they are distracted, assume it relates to a legitimate login or want the notifications to stop. This technique is commonly described as MFA fatigue or push bombing.

CISA recommends number matching as a way to reduce that risk when an organisation cannot immediately implement phishing-resistant MFA. Rather than presenting a simple approve or deny request, number matching requires the user to interact with information associated with the login attempt. It is a stronger form of validation, but CISA describes it as an interim measure rather than a substitute for phishing-resistant MFA.

The distinction is important. Improving a vulnerable authentication method does not necessarily make it phishing-resistant.

What makes authentication phishing-resistant?

Phishing-resistant authentication is designed to prevent credentials from being used with the wrong service or relayed by an attacker.

With weaker MFA methods, people remain responsible for deciding whether a login page or authentication request is genuine. That places considerable weight on user awareness at precisely the moment an attacker is trying to create confusion or urgency.

Phishing-resistant methods introduce technical controls into that decision.

FIDO authentication, including suitable security keys and passkeys, uses public key cryptography. A private key remains protected by the user’s authenticator or device, while the service uses the corresponding public key to verify the authentication.

The private key is not handed to the website during login. The credential is also associated with the legitimate service, which helps prevent an attacker-controlled phishing site from capturing and replaying it elsewhere.

A user may still need to complete a user gesture, such as touching a security key or unlocking a device with a PIN, fingerprint or facial recognition. That gesture proves the person is present and authorised to use the credential, but it does not reveal a reusable secret to the website.

CISA describes FIDO as using cryptographic keys on users’ devices to provide a secure, phishing-resistant way to authenticate identities without passwords. Its case study of the US Department of Agriculture also presents FIDO as an option where PIV smart cards or other forms of certificate-based authentication are unsuitable.

The result is stronger authentication that does not depend entirely on the user’s ability to identify a sophisticated attack.

Which MFA methods are phishing-resistant?

The methods available to an organisation will depend on its identity platform, devices, applications and existing infrastructure.

  • FIDO security keys are physical authenticators that use public key cryptography. They can provide strong protection for privileged users, administrators and others who need access to sensitive data or critical systems.
  • FIDO passkeys use the same broad cryptographic model but may be held on, or available through, a user’s device. Passkeys can support a seamless user experience because users may authenticate using familiar device controls rather than repeatedly entering passwords and one-time codes.
  • Certificate-based authentication uses digital certificates and public key infrastructure. Depending on the implementation, certificates may be held on a smart card, another physical device or a managed endpoint. This can provide phishing-resistant authentication, but it also requires effective certificate issuance, provisioning, management and revocation.

These approaches are not identical. FIDO authentication and certificate-based authentication have different infrastructure, device and operational requirements.

Their shared advantage is that authentication does not depend on a transferable shared secret that a user can enter into a phishing site.

Are authenticator apps phishing-resistant?

An authenticator app is not automatically phishing-resistant. The protection depends on what the app is being used to do.

A time-based one-time password generated by an authenticator app may be stronger than relying on a password alone, but the code can still be entered into a fraudulent site and relayed by an attacker.

A push notification may make authentication more convenient, but a simple approve or deny request can be targeted through MFA fatigue. Number matching makes this harder by requiring greater interaction with the login attempt, but it does not provide the same protection as a phishing-resistant credential.

Some authenticator apps can also support FIDO passkeys. In that situation, it is the underlying passkey authentication process that provides phishing resistance, not merely the fact that an app is involved.

Security teams should therefore avoid classifying methods only by product name or delivery channel. They need to establish exactly how users authenticate and what an attacker could capture, relay or fraudulently prompt.

Where does SMS fit?

SMS MFA remains better than protecting an account with a password alone, but it is not the gold standard for authentication security.

The code sent to a user’s device is still transferable. If the user is persuaded to type it into a phishing site, an attacker may be able to use it against the legitimate service. SMS authentication may also be exposed to risks affecting the user’s mobile account or communications channel.

That does not mean organisations should remove SMS immediately if the result would be a return to password-only authentication. It means SMS should be treated as part of a managed transition rather than the desired end state.

Organisations should identify where SMS remains necessary, understand which users and systems depend on it, and create a realistic plan for stronger authentication. High-impact accounts should be prioritised rather than waiting for every technical and operational obstacle to disappear.

What does phishing-resistant MFA mean in Microsoft Entra?

For organisations using Microsoft Entra ID, Authentication Strength can be used within Conditional Access to specify which authentication methods or combinations users may use to access a resource.

Microsoft provides three built-in authentication strengths: multifactor authentication, passwordless MFA and phishing-resistant MFA. Organisations can use these controls to require stronger methods for specific situations, such as access to sensitive applications, higher-risk users or privileged activity.

This is more precise than applying a policy that merely requires “MFA”. A general MFA requirement may accept methods that provide different levels of resistance to phishing. A phishing-resistant authentication strength restricts access to the methods that meet the stronger requirement.

Microsoft recommends phishing-resistant MFA for a range of administrator roles because privileged accounts are frequent targets for attackers. It also cautions organisations to ensure administrators have registered an appropriate method before enforcement, as an incorrect rollout could result in tenant lockout.

The practical lesson extends beyond Microsoft Entra. Security policy should reflect the strength of the authentication method, not simply the presence of a second factor.

Where should organisations start?

A successful transition begins with understanding the current environment.

Security teams should establish which MFA methods are enabled, which methods users actually use and where applications or legacy infrastructure restrict the available options. The assessment should also cover external users, service access, privileged identities and any exceptions that have accumulated over time.

The next step is to prioritise according to potential impact.

Administrators and other privileged users are an obvious starting point because a compromised account could give an attacker extensive access. The same principle applies to people who handle sensitive data, manage security controls, approve financial activity or operate critical business systems.

Microsoft’s deployment guidance recommends a user persona-based approach, distinguishing between groups such as administrators, highly regulated users and non-administrative users. It also highlights device readiness, credential registration and enforcement as distinct parts of the rollout.

A practical implementation plan should therefore address:

  • the users and services with the greatest exposure;
  • device and browser support for FIDO passkeys or security keys;
  • requirements for certificate-based authentication and public key infrastructure;
  • secure provisioning of each new credential;
  • support for users who lose or replace a device;
  • emergency access and account recovery;
  • legacy applications that cannot support the preferred methods; and
  • monitoring for unexpected registrations and suspicious login attempts.

This is not simply a technology deployment. Authentication affects how users access systems every day, so support, communication and recovery procedures need to be designed alongside the security policy.

Why enrolment and recovery are part of the security boundary

Stronger login controls can be undermined by weaker processes elsewhere in the credential lifecycle.

If an attacker can register a new authentication method after passing a less secure identity check, the strength of normal authentication becomes less relevant. The same applies if a helpdesk recovery process can be manipulated into resetting MFA without adequately verifying identity.

Organisations implementing phishing-resistant MFA should examine how credentials are issued, linked to an account, replaced and revoked.

They should also define what happens when a device is lost, a security key fails or a user cannot complete the expected biometric or device-based authentication. Recovery needs to be usable, but it must not become an easier path for fraud.

Known and trusted parties should be involved in sensitive recovery decisions, with clear authorisation, auditable actions and proportionate identity validation. Emergency access accounts also need specific controls so they remain available when required without becoming a permanent way around stronger authentication.

The objective is not only to secure the most visible login screen. It is to protect every process that can create or restore access.

Move beyond the MFA completion rate

Enabling multi-factor authentication remains one of the most valuable steps an organisation can take to reduce identity risk. But an MFA completion rate is a measure of deployment, not a complete measure of resilience.

The stronger questions are more specific.

Which authentication methods are users actually relying on? Can credentials be captured by a phishing site or relayed during a sophisticated attack? Are privileged and high-impact accounts subject to stronger requirements? Could insecure provisioning or recovery allow an attacker to bypass those controls?

Organisations do not need to replace every existing method at once. They do need a clear view of the remaining risk and a defensible plan for reducing it.

Start with the identities whose compromise would have the greatest impact. Enforce phishing-resistant authentication where the technology already supports it. Use improvements such as number matching as interim protection where necessary, but do not mistake them for the destination.

MFA being enabled is an important milestone. Whether it is phishing-resistant is what determines how much confidence the organisation should place in it.

References