Should organisations replace SMS and push MFA before fixing help desk resets?

Why help desk resets usually come before an MFA replacement project

When the main failure path is account recovery, replacing SMS or push MFA first can miss the faster route an attacker will take. help desk resets, identity proofing gaps, and weak escalation steps let an intruder re-enrol a stronger factor or take over the recovery channel, which makes the authentication stack look better on paper while the takeover path stays intact.

A better sequence is to treat recovery as the control plane: verify who can reset what, under which evidence standard, with what logging, and with what delay. If recovery can still be abused to change the factor, the organisation has not actually reduced takeover risk yet.

For workforce sign-in, the practical upgrade path is usually to harden recovery and then move users toward phishing-resistant methods such as passkeys or security keys. NHIMG’s Workforce Identity Security Guide covers both the factor choice and the recovery workflow, which is the right pairing for this question.

Why SMS and push MFA are weaker than they look

SMS MFA is exposed to SIM swap, phone-number takeover, forwarding abuse, and phishing. Push MFA is exposed to fatigue attacks, adversary-in-the-middle relays, and malicious re-enrolment when an attacker gets a foothold in account recovery. Those weaknesses matter, but they are not all equally urgent in every environment.

The key distinction is that a weak factor and a weak reset process fail differently. SMS and push are often bypassed during interactive sign-in, but a compromised reset path can let an attacker replace the factor entirely, after which even a strong future MFA control may authenticate the wrong person. That is why the factor and the recovery workflow need to be assessed together, not as separate hygiene items.

NHIMG’s MFA Guide is useful here because it contrasts SMS, push, and phishing-resistant methods and shows where fatigue, relay, and token theft enter the picture.

For external guidance, NIST SP 800-63 Digital Identity Guidelines gives the clearest policy backdrop for authenticator strength, assurance levels, and recovery expectations in digital identity systems. See NIST SP 800-63 Digital Identity Guidelines.

What to fix first in the recovery chain

The fastest risk reduction usually comes from tightening the steps that allow a factor reset, re-enrolment, or help desk override. That means stronger identity verification, narrower help desk authority, explicit approval paths for high-risk changes, and reliable audit trails for every recovery action.

In practice, the reset workflow should answer four questions clearly: who may request a reset, what evidence is required, who may approve it, and what happens when the request looks suspicious. If any of those answers depends on informal judgement alone, the organisation should assume the reset path is exploitable.

Practical prioritisation often starts with the highest-impact accounts: privileged users, finance, HR, admin consoles, and remote access users. A reset on one of those accounts is rarely just a sign-in event, it is a privilege-change event.

NHIMG’s IAM and Identity Provider Buyer's Guide is relevant because it treats recovery, lifecycle, admin security, and phishing-resistant MFA as part of the same workforce identity decision.

Recent breach reporting shows why this order matters. In Uber breach 2022, MFA fatigue and social engineering helped an attacker reach internal tooling, while in Cisco Yanluowang breach 2022 the chain involved vishing, MFA fatigue, and abuse of machine accounts after access was obtained.

Risk and Threat Considerations

Replacing SMS or push MFA without fixing recovery can create a false sense of safety. Attackers often do not need to defeat the factor itself if they can persuade or bypass the help desk, re-enrol a new authenticator, or capture a recovery channel that still trusts weak proofing.

Failure mechanism: The attacker exploits the reset path, not the live authentication challenge, by using social engineering, stolen personal data, or procedural gaps to change the enrolled factor or approve a takeover.

Impact: The account is lost even if the original MFA method is later retired, because the attacker has already installed a new trusted path. That can turn a local sign-in weakness into full account compromise, privilege escalation, or lateral movement.

Practitioner Guidance

What to prioritise: Fix the reset and recovery controls first for accounts that can change other access, approve payments, administer systems, or access sensitive data. Those are the accounts where a weak reset path has the highest blast radius.

What to verify: The help desk should be able to show consistent identity proofing, approval evidence, step-up checks for high-risk resets, and logs that let you reconstruct who changed the factor, when, and why.

Decision rule: If an attacker could obtain a new MFA enrollment by answering a call, using basic personal data, or exploiting a single weak approval step, treat the reset process as the urgent defect, even if the current MFA method is still SMS or push.

Practitioner takeaway: The real control objective is not simply to replace one MFA method with another, it is to make sure no one can rebind trust through the recovery workflow without strong, auditable verification.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat MFA resets as routine help desk tasks?
• How should organisations govern help desk MFA resets?
• Should organisations replace VPNs before fixing privileged access governance?
• Why do organisations replace SMS OTP in high-risk journeys before full account-wide migration?