Account recovery is necessary. People forget passwords, lose phones, replace devices, or otherwise lose every authenticator they have. But every legitimate way back into an account is another path an attacker can try to use. In May 2026, Microsoft said it assessed with high confidence that the Storm-2949 threat actor used social engineering consistent with known abuse of Microsoft’s Self-Service Password Reset (SSPR). Microsoft’s assessment illustrates how strong authentication at the login screen can still be undermined by a weaker process for resetting credentials or replacing authentication methods.

Two Ways Back In

Self-service recovery uses an automated process instead of relying on the help desk. An attacker may start that process and then convince the real user to approve prompts that appear legitimate. In the Storm-2949 investigation, Microsoft reported that attacker-controlled authentication methods were registered after users were compromised. While Microsoft didn’t state exactly how each user was socially engineered, it gave an example: an attacker could impersonate internal IT support, claim the account needed urgent verification, and present the MFA prompt as part of a routine password reset.

Help desk recovery depends on a support employee approving the change. An attacker may impersonate an employee and persuade support to change credentials or authentication methods, or bypass part of the normal process. A joint FBI and CISA advisory last updated in 2025 directly documents attackers convincing help desks to reset passwords or transfer MFA tokens.

Both paths can end with the legitimate user’s authenticator removed or an attacker-controlled method registered. Once that method is bound, later sign-ins can look like ordinary authentication.

What Strong Recovery Should Do

Under NIST SP 800-63B-4, a user who still has another registered authenticator must authenticate with it before a replacement is added (Section 4.1.2.1). If all the authenticators needed for normal sign-in are gone, the user must recover the account before a replacement can be added (Section 4.2). Lost or compromised authenticators must be suspended, invalidated, or destroyed, and requests to invalidate them must be checked for authenticity (Sections 4.3 and 4.5). A support agent can be part of the recovery process, but that process must be documented and based on a risk analysis (Section 4.2.1).

Those requirements can be translated into separate recovery playbooks. For example, a lost-phone playbook might use another registered authenticator to verify the request before the lost method is removed or a replacement is added. When no registered method remains, another playbook might route the request through the documented recovery process rather than an improvised reset. Other examples include notifying the user through contact details already stored on the account; recording the requester, approver, methods removed or added, and time; sending privileged or after-hours recovery events to a SIEM; and inspecting active sessions after a suspicious recovery.

Walk Through It Before It Happens

A tabletop exercise can give staff a chance to work through a difficult recovery request before it happens for real. A contractor with an administrative account calls after hours. The account is locked, the phone is lost, no authenticator remains, and an urgent maintenance window is closing. Then add two complications: the contractor’s manager cannot be reached, and monitoring shows a recent session from an unusual network.

Have everyone involved in receiving, verifying, approving, and monitoring recovery requests walk through the scenario. Who verifies the caller? Who can confirm the contractor is still authorized when the manager cannot be reached? Can the request wait, or is there an escalation path? Who can remove the lost method or register a new one, and who approves that change? Which sessions, if any, should be inspected or terminated? Who should be notified, and through which channel? How are we logging these events?

Our Consulting Services can help design and facilitate the tabletop, then turn its findings into clearer recovery policies, procedures, and training.

Know Every Way Back In

Strong authentication is only as dependable as the recovery paths connected to it. Walking through a recovery request from start to finish can reveal weaknesses in technology, procedures, and staff training.