Phishing-Resistant MFA: Planning a Phased Migration

Cybersecurity · 3 min

SMS codes and push notifications remain vulnerable to social engineering. Learn how to prioritise systems, handle exceptions and protect credential recovery.

Phishing-Resistant MFA: Planning a Phased Migration

TL;DR

Not all multi-factor authentication methods offer the same protection against phishing.
FIDO2/WebAuthn and PKI-based authentication bind the credential to the legitimate service and resist fake pages.
Migration should start with the most targeted systems and profiles: email, remote access and administrators.
Credential enrolment and recovery become the weak link if they accept less robust methods.
Documented exceptions and adoption metrics help manage what cannot yet be migrated.

Not all multi-factor authentication protects equally

Multi-factor authentication (MFA) is now widespread across enterprises, but the most common methods, such as SMS codes, time-based codes in apps or push notifications, still depend on the user recognising a fraudulent attempt. CISA, the US cybersecurity agency, considers phishing-resistant MFA the most secure form of MFA and recommends treating the migration as a priority. For a CISO or IT lead, the practical question is how to make this transition without disrupting operations or creating new weak points.

Traditional methods have well-known weaknesses

These weaknesses are well documented. An attacker can convince a mobile carrier to transfer the victim's number and receive the SMS codes, or send repeated push requests until one is approved by mistake or out of fatigue. Fake authentication pages can also capture the code and reuse it in real time. Methods based on FIDO2/WebAuthn bind the credential to the legitimate domain, so authentication fails when the user is led to a fraudulent site. Authentication based on digital certificates, supported by a public key infrastructure (PKI), can also offer phishing resistance when properly implemented and bound to the legitimate service. However, it requires greater maturity in identity and certificate management and is not always supported by the applications in use. The difference therefore lies less in the existence of a second factor and more in how that factor is bound to the legitimate service.

The inventory sets the priorities

Before distributing security keys or enabling passkeys, it is worth knowing which systems support these methods, which depend on a central identity provider and which still use legacy authentication protocols. CISA's guidance recommends prioritising administrative and privileged accounts. Selecting the systems to migrate should take into account risk exposure, service criticality and the information accessible, including, depending on the context, email, remote access and applications with sensitive data. For remote access, the migration can be aligned with a Zero Trust / ZTNA architecture, in which each request is evaluated based on identity and context. Legacy applications without support for modern authentication can be placed behind a federated identity provider or isolated with compensating controls, as appropriate.

Enrolment and recovery are the new point of attack

The effectiveness of a phishing-resistant authentication method can be undermined if the processes for initial enrolment, authenticator replacement or access recovery allow the implemented controls to be bypassed. If replacing a lost key depends on a call to the helpdesk with superficial verification, or on an automatic fallback to SMS, the attacker will target that process instead. Good practice includes verifying identity during enrolment, providing backup authenticators and limiting alternative methods that could allow authentication controls to be bypassed. Emergency accounts require their own treatment, described in emergency access. Choosing between hardware keys tied to a device and passkeys synced across devices involves a trade-off between control and convenience, which should be assessed case by case.

Metrics and exceptions make the transition manageable

Migration is rarely completed in a single cycle. Tracking the proportion of accounts using phishing-resistant methods, by system and by profile, helps show progress and identify pockets of resistance. Each exception should have an owner, a justification and a review date. When it is not yet possible to implement phishing-resistant methods, CISA recommends number matching in push notifications as an interim measure to reduce the risk associated with improper approval of authentication requests. This measure does not, on its own, make the method phishing-resistant. Monitoring the use of alternative methods and anomalous sign-ins complements this work, along the lines of identity risk detection.

A gradual transition, adjusted to risk

Phishing-resistant MFA can significantly reduce the risk of account compromise through phishing attacks, although it does not replace privilege management, endpoint protection or monitoring. The right pace depends on the application estate, the maturity of identity management and the organisation's tolerance for changes in user habits. A phased approach, starting with the most exposed systems and people and treating enrolment and recovery with equal care, tends to deliver more solid results than replacing everything at once.