Because they do not carry the same risk. A password reset may restore access, but an MFA reset can remove the last remaining control protecting the account. Separate approval paths prevent one convincing call from disabling both layers in a single interaction.
Why the approval path has to differ
Password reset and MFA reset sit in different parts of the account recovery chain. A password reset usually restores one factor of access, while an MFA reset can remove the control that blocks the next sign-in attempt. That difference means the second action changes the security posture more materially than the first, so it deserves stricter approval, stronger verification, and clearer escalation criteria.
A good rule is to treat password recovery as a controlled restoration event and MFA recovery as a control-removal event. The first is about regaining access; the second is about deciding whether the person requesting help should still be trusted to control the account at all. That distinction is why one scripted approval path is often too weak for both.
In practice, the approval model should reflect blast radius. If a reset only changes a password, the main question is whether the requester is the legitimate account holder. If the reset changes MFA, the question becomes whether the existing second factor has been lost, stolen, replaced, or socially engineered away, because that can open a path for takeover even when the password remains protected.
What changes in the risk picture
Password resets and MFA resets fail differently. A password reset can be abused for simple account takeover, but an MFA reset can defeat the last remaining barrier protecting a high-value account. That makes the latter more attractive to attackers who already have partial access, stolen personal data, or a help desk script they know how to exploit. See the Workforce Identity Security Guide for the operational patterns behind password reset, MFA reset, and account recovery abuse.
The practical failure mode is not just weak verification. It is a single approval path that assumes both requests have the same sensitivity. Once that assumption is embedded in process, an attacker only needs one convincing interaction, one compromised mailbox, or one social-engineering success to downgrade protection and then complete the login flow under the new trust state.
That is why help desk procedures, approver authority, and evidence requirements should diverge. A password reset may be recoverable with moderate proof of control. An MFA reset usually needs a higher threshold because it is effectively a decision to re-establish trust after a factor has been lost or may have been compromised.
How to design the approval split
Separate the decision by what the reset changes, not by who asks. Password resets can often follow a standard recovery workflow with identity verification, logging, and an audit trail. MFA resets should require a stronger control path, such as supervisory approval, out-of-band confirmation, or a more formal exception process when the reset would remove the only remaining step-up protection.
This is especially important for privileged staff, remote workers, and accounts with broad access. An MFA reset for those users should be treated as a high-risk event even when the request looks routine, because it can silently convert a protected account into one that is easy to replay, phish, or hijack. The right benchmark is whether the request would still look acceptable if the requestor turned out to be an attacker with partial account knowledge.
When organisations use the same approver for both actions, they often underweight the second factor because the workflow feels operationally familiar. In reality, the safer model is to make the password reset path fast enough for recovery, but make the MFA reset path deliberately harder to complete and easier to review after the fact.
Risk and Threat Considerations
The main risk is control bypass through account recovery. If password and MFA resets share the same approval logic, attackers can target the weaker path and use it to neutralise the stronger one. That increases the chance of account takeover, persistence, and downstream access to mail, SSO, VPN, or admin tools.
Failure mechanism: A requestor or help desk operator treats MFA removal as a routine support action, so a socially engineered reset can replace a protected sign-in state with a weaker one before defenders notice.
Impact: The account may remain accessible to the attacker even after the password is changed again, because the attacker has already removed the factor that would have blocked the next sign-in.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers password and MFA credential lifecycle decisions. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because resets change how users are authenticated to accounts. | |
| AC-2 — Account Management | Account recovery and reset approvals are part of account lifecycle governance. | |
| Recommendation — Separate reset approvals by authenticator type and require stricter verification before revoking a second factor. Verify user identity before restoring or replacing authentication factors. Define distinct approval paths for password recovery and MFA re-enrollment events. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Reset workflows can expose accounts when trust is withdrawn or control is lost. |
| NHI-04 — Insecure Authentication | Weak reset handling can let attackers bypass authentication controls. | |
| NHI-07 — Long-Lived Secrets | Password and MFA recovery frequently interact with durable secrets and recovery channels. | |
| Recommendation — Require stronger approval when a reset effectively re-establishes account control after factor loss. Harden reset verification so an attacker cannot trade a password reset for MFA removal. Shorten recovery windows and rotate affected secrets after any high-risk reset. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Provides identity assurance and authenticator recovery guidance directly relevant to reset flows. |
| Recommendation — Apply higher assurance requirements when a recovery action changes the authenticator set. | ||
Practitioner Guidance
What to prioritise: Put MFA resets behind a stricter exception path than password resets, especially for privileged, executive, and remote-access accounts. The approval rule should be driven by the security state being changed, not by the convenience of the support queue.
What to verify: Require evidence that the requester still controls a trustworthy recovery channel, and verify whether the existing MFA factor was lost, replaced, or simply unavailable. If the answer is unclear, treat the reset as higher risk and escalate rather than defaulting to speed.
Common mistake: Teams often optimise for ticket closure and assume any reset is harmless once logging exists. Logging helps after the fact, but it does not compensate for a recovery process that can remove the last meaningful barrier in real time.
Practitioner takeaway: Use different approval rules because the security meaning of the action is different: a password reset restores access, while an MFA reset can redefine who is trusted to hold the account.