Verify identity before resetting administrator MFA

An administrator who loses a phone still needs a way back into the business application. Recovery should verify the account owner before a new factor is enrolled or privileged access is restored. OWASP warns that a recovery mechanism can become a way to bypass multi-factor authentication (MFA).[1][5]

Separate replacement from recovery

If an enrolled alternate factor remains available, use it with the application's required checks to verify the change. OWASP recommends reauthentication with an existing factor before replacement. An active session alone is not enough.[1]

A registered spare security key can be one planned alternate route. A new, unregistered key does not establish account ownership. If no suitable factor remains, follow the agreed recovery process rather than treating the request as an ordinary settings change.[2][5]

Define the evidence before someone is locked out

Write down the supported recovery methods, who may review a request and what evidence they must check. NIST's digital identity guidance describes recovery codes, prearranged contacts and repeated identity proofing. Its requirements depend on the account's assurance level and whether its owner was previously identity-proofed.[2]

A method listed in guidance is not automatically sufficient for every administrator account. For assisted recovery, establish the verification procedure in advance. A familiar name or urgent message should not replace it.[1][2]

Saved recovery codes need secure offline storage and a plan for handling them after use. NIST requires a used saved code to become invalid and a replacement to be issued. Keep recovery secrets out of ordinary support tickets and application logs.[2]

Keep access locked while verification is pending

In an illustrative recovery screen, show "Verification required" and keep that recovery session outside administrator actions. Offer an enrolled alternate-factor route and a request for identity review. Neither button should silently remove MFA or grant the protected role.[5]

Do not use an unverified recovery request alone to lock out the legitimate owner.[3]

Record the decision and authorized factor change without retaining the secret itself. Notify the account owner through established channels, with a way to report unauthorized recovery. NIST requires recovery notifications; OWASP also recommends notifications when MFA factors change.[1][2]

A suspected takeover needs a separate response. Review recovery contacts and enrolled methods for unauthorized changes. After successful recovery, invalidate existing sessions and outstanding reset or recovery links or codes, as OWASP recommends for potentially compromised accounts.[3]

Check what an incomplete request can do

With approved test accounts, try an invalid recovery code and a request from an existing session. Check that the protected administrator action still refuses access, not just that the screen displays a warning. Verify the successful recovery decision, notification and subsequent access separately.[4][5]

Rootscratch's Cyber Security Services can examine authentication, sessions and administrator role boundaries within a written scope. Bring the application address, account roles and recovery concern to the scoping discussion. Share credentials only through the secure process agreed afterward.[4]

Sources

[1] https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html — OWASP: Multifactor Authentication Cheat Sheet [2] https://pages.nist.gov/800-63-4/sp800-63b/events — NIST SP 800-63B-4: Authenticator Event Management [3] https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html — OWASP: Forgot Password Cheat Sheet [4] https://rootscratch.com/services/cyber-security — Rootscratch: Cyber Security Services [5] https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html — OWASP: Authentication Cheat Sheet