Topic starter
02/09/2026 1:29 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Trusona: “How to reset MFA safely: Entra ID, Microsoft 365, Okta, and Duo”.
Key questions
Q: What breaks when an MFA reset is approved without pre-reset identity proofing?
A: The reset deletes the old second factor and opens a fresh registration window, so the next person to complete enrollment becomes trusted.
Q: Why does session revocation matter after a suspicious MFA reset?
A: Because factor replacement and session validity are separate.
Q: What are the signs that a help desk reset request may be fraudulent?
A: Watch for a reset that follows repeated MFA prompts, a sudden request for device re-enrollment, urgency that escalates mid-call, or recent SIM swap indicators.
Practitioner guidance
- Require proof before re-registering MFA Gate every reset request on a pre-reset identity proofing step that occurs before any factor deletion or enrollment cancellation.
- Revoke active sessions when compromise is suspected When a reset is driven by suspected takeover rather than simple device loss, invalidate refresh tokens and force reauthentication across applications before the new factor is trusted.
- Separate lost-device recovery from suspicious-reset handling Use a different workflow for a misplaced phone than for a call that follows MFA fatigue, help desk impersonation, or recent SIM swap signals.
Bottom line: MFA reset abuse is a governance problem around identity proofing, not a problem with the administrative reset feature itself.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/09/2026 1:30 pm
Identity verification, not factor removal, is the real control point: MFA reset flows are often described as administrative recovery, but the security decision happens before the enrollment is deleted. If the requester has not been proven, the platform simply reassigns trust to the next person who completes registration. Practitioners should stop treating reset procedures as self-sufficient controls and start treating pre-reset proofing as the governing step.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: How should organisations govern help desk MFA resets?
A: Treat help desk resets as privileged identity actions. Restrict who can approve them, require strong verification before re-enrolment, keep a detailed audit trail, and review exceptions regularly. If the support path is easier to abuse than the factor it replaces, it becomes the main attack surface.
👉 Read our full editorial: MFA reset abuse shows why identity verification is the control
This post was modified 2 days ago by NHI Mgmt Group