TL;DR: Resetting MFA in Entra ID, Okta, or Duo only restores access safely when the requester has already been verified, because the reset deletes the old factor and opens a fresh registration window that attackers can hijack, according to Trusona. The real control is not the reset itself but the identity proofing and session revocation that must happen before the reset is allowed.
NHIMG editorial — based on content published by Trusona: How to reset MFA safely: Entra ID, Microsoft 365, Okta, and Duo
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
Questions worth separating out
Q: What goes wrong when a help desk resets MFA without verifying the requester first?
A: The reset can hand the account to an impersonator.
Q: When should organisations revoke sessions after an MFA reset?
A: They should revoke sessions whenever the reset is prompted by suspected compromise, not just when a user lost a device.
Q: How do security teams know a reset workflow is failing?
A: Warning signs include repeated reset requests, urgent calls after MFA fatigue prompts, recent SIM swap or port-out activity, and requests that expand from password recovery to device re-enrollment or mailbox changes.
Practitioner guidance
- Require proofing before any MFA reset Make the verification step mandatory before an administrator clears an enrollment, and ensure the proofing method uses a record the caller cannot control.
- Pair every suspicious reset with session revocation If compromise is suspected, revoke active sessions and refresh tokens in the same workflow so the attacker cannot continue using an established session.
- Restrict bypass codes and emergency recovery paths Keep bypass codes short-lived, single-use, and tightly monitored so a temporary recovery path does not become a standing second factor.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step reset guidance for Microsoft Entra ID, Microsoft 365, Okta, and Duo.
- Vendor-specific verification options, including how each platform handles proofing before a reset.
- Help desk workflow examples that show where reset requests are most likely to be abused.
- Product detail on ATO Protect as the verification layer used in front of the reset workflow.
👉 Read Trusona's guidance on safe MFA resets across Entra ID, Okta, and Duo →
MFA reset abuse: is your help desk verifying the right user?
Explore further
Identity reset is not the control. Verified identity is the control. The reset action only deletes the old factor and opens the door for a new one. That means the security boundary is the verification decision that happens before the reset, not the administrative click that follows. In IAM terms, organisations that treat the reset as the control are protecting the wrong stage of the workflow.
Reset abuse is a governance failure, not just a help desk problem. The organisation that can prove who asked for recovery, who approved it, and what happened to the existing session is the organisation that has an auditable control, not just a documented process. That is why support workflows should be evaluated like security controls and measured accordingly.
A question worth separating out:
Q: What should teams do when an MFA reset is requested through the support desk?
A: Use an out-of-band verification step before clearing the factor, then apply session revocation if compromise is suspected. The support desk should have a documented escalation path for failed verification so agents are not forced to choose between delaying a reset and approving an untrusted request.
👉 Read our full editorial: MFA reset abuse shows why identity verification is the control