MFA resets are among the routine requests that fill Level 1 queues. A user gets a new phone, loses an authentication device, or gets locked out and needs access restored.
But an MFA reset goes further than a password reset. It restores access to the second factor, the very thing meant to stop a stolen password from working. And the help desk is exactly where attackers go to get it, because impersonating a user on the phone is often easier than hacking their way in.
The challenge for MSPs is that a legitimate reset and an account takeover attempt can look identical on the ticket. Telling them apart is the whole job, and that judgment often falls to a senior technician whose time is needed elsewhere.
You can automate these requests without opening an account-takeover path. The technical changes are relatively straightforward. What protects the account is the verification and policy checks before those changes, and the security controls afterward.
What makes an automated MFA reset safe?
A safe automated MFA reset follows six steps:
- Verify the requester. Establish that the person requesting the reset is the legitimate account owner.
- Apply security rules. Decide whether the request can be automated, needs approval, or requires human handling.
- Confirm the client and tenant. Ensure the reset targets the correct user in the correct identity environment.
- Execute the reset. Make the approved changes, with human oversight for exceptions.
- Secure the account. Remove compromised methods, establish new ones, manage sessions, and notify the user.
- Document the work. Log verification, approvals, changes, and outcomes in the PSA ticket.
The sequence matters. Most automation projects start with the reset because that’s the part the identity provider’s API exposes. But the danger sits in the checks before it and the cleanup after it.
For MSPs, those checks must work across clients with different policies. One wants sign-off from a named contact, another requires additional verification, and a third has executives who should never receive an unattended reset.
A procedure that works for one tenant but quietly skips a step for another is how you end up explaining yourself to a client’s insurer.
Why are MFA resets a target for attackers?
Attackers call help desks and ask for MFA resets because it works.
The joint FBI and CISA advisory on Scattered Spider describes attackers impersonating employees to convince help desks to reset passwords and transfer MFA to devices the attackers control. It also notes that the group targets large companies and their contracted IT help desks.
That describes an MSP’s risk almost perfectly.
- The calls are rehearsed. Attackers research reset procedures and gather information about their targets, sometimes making multiple calls to learn what the help desk requires.
- Security questions don’t stop them. Employee IDs, birthdays, managers’ names, and other personal information may already be available through public sources and data leaks.
- SMS isn’t a reliable fallback. SIM swapping and other attacks can compromise phone-based authentication.
A help desk that resets MFA for a convincing voice is a locksmith who opens the door for anyone who sounds sure it’s their house. Automation makes that locksmith faster unless the rules come first.
How to automate MFA resets safely, step by step
Each step should follow the client’s policies, operate within the correct identity tenant, and leave a record in the PSA.
Step 1: Verify the requester before anything runs
Identity verification must establish that the requester is the legitimate account owner. Knowing facts about the user isn’t enough.
Verification methods include:
- Existing registered authenticator: If the user still controls a trusted authentication method, require successful authentication through it.
- Callback to a number on file: Contact the user through a previously established number, never one supplied in the request. Because phones and SIMs can be compromised, additional verification may be necessary.
- Approved recovery process: When all registered factors are lost, follow the client’s documented procedure for additional identity proofing or live verification. For example, you could require the user to display a government ID on a live video call.
Many clients also require manager confirmation or approval from a named contact. That’s an authorization control, not a substitute for identity verification. A manager can approve a request without knowing whether the caller is really the employee.
If verification can’t be completed, stop the automation and route the request to a technician.
Step 2: Decide which requests can run automatically
Not every verified request should be automated. Evaluate the request against the client’s policies, the user’s privileges, and any security risk signals.
Escalation triggers should include:
- Privileged and emergency access accounts
- Executives and other client-designated high-value users
- Repeated requests or unexpected phone number changes
- Requests through unusual channels
- Active identity-provider risk detections
- Pressure to bypass verification
Microsoft Entra ID Protection signals, Conditional Access policies, and client-specific rules can help determine which requests need review.
Start narrow. Automate the safest, most routine requests first, then expand as each client’s playbook proves reliable.
Step 3: Keep each reset inside the right client
Multi-tenant security is one of the biggest differences between MFA reset automation for an MSP and automation for a single IT department.
The reset must run only in the tenant associated with the client identified in the PSA ticket. If the ticket’s client and the target tenant don’t match, the workflow stops.
Permissions should be scoped just as carefully.
In Microsoft 365, MSPs can use Microsoft Entra ID administrative roles, granular delegated administrative privileges (GDAP), and appropriately scoped application permissions to manage authorized operations.
Use the least privileges necessary, and keep the rules and credentials for each client appropriately isolated. A reset permitted for one client shouldn’t become permissible at another simply because both use Microsoft 365.
Microsoft’s Temporary Access Pass documentation shows the split clearly: the Authentication Administrator role can manage passes for users who aren’t administrators, while only the Privileged Authentication Administrator role can do so for admins. That split only holds when the automation is assigned the Entra role. Microsoft Graph application permissions such as UserAuthenticationMethod.ReadWrite.All or UserAuthMethod-TAP.ReadWrite.All apply to every user in the tenant, including Global Administrators, so automation built on them must enforce the admin exclusion in its own logic. Okta and Google Workspace offer comparable scoped admin roles, so the same principle carries to clients outside Microsoft.
Step 4: Run the reset with a human watching the exceptions
Once verification and policy checks pass, automation can execute the approved changes.
Build the workflow to read before it writes. Confirm the account exists, check current authentication methods and risk signals, and validate the requested action before making changes.
There are three possible outcomes:
- Fully automated: The request meets all requirements, so automation completes the workflow.
- Human-approved automation: An analyst or designated contact reviews and approves the request, then automation executes.
- Human-handled recovery: The request fails verification or falls outside the approved playbook, so a technician takes control.
The technician handling an exception should see who requested the reset, how identity was verified, which rule triggered escalation, and what automation has already done.
That’s particularly important after hours. A user locked out at 2 a.m. still needs help, but not at the cost of bypassing the client’s security rules.
Step 5: Lock the account back down
Restoring access isn’t the end of the reset. The workflow must secure the account afterward.
Issue controlled temporary access. Microsoft Entra ID supports a Temporary Access Pass (TAP), a time-limited passcode that can help verified users register new authentication methods. Configure a short lifetime and single-use behavior where appropriate. Microsoft’s TAP documentation notes that the default lifetime is one hour and single-use behavior isn’t enabled by default.
Review and revoke sessions. For suspected compromises, lost devices, or policies that require it, revoke existing sign-in sessions. Microsoft Graph supports this through revokeSignInSessions (permission: User.RevokeSessions.All), which invalidates the user’s refresh tokens and browser session cookies. Revocation can take a few minutes to apply, and access tokens already issued stay valid until they expire unless the application supports Continuous Access Evaluation. For a suspected compromise, also block sign-in until the account is secured.
Remove compromised methods. Delete authentication methods associated with lost or compromised devices, then have the user register approved replacements. Whenever possible, move users toward stronger authentication rather than restoring the same vulnerable setup.
Notify the user. Send confirmation through a previously established, trusted channel. Notify the designated client contact for unusual requests. If the user didn’t request the reset, that notification may reveal an attempted compromise.
Step 6: Log everything to the PSA ticket
The PSA ticket should contain the complete reset history:
- Requester: Who made the request and through which channel.
- Client and tenant: Which organization and account were targeted.
- Verification: The method used and result.
- Approval: Who authorized the reset and under which policy.
- Actions: Methods changed, temporary access issued, and sessions revoked.
- Results and timestamps: Whether each action succeeded, failed, or required escalation, and when it occurred.
Link relevant identity-provider audit events to the ticket, but never store temporary credentials or other authentication secrets in ticket notes.
The identity provider’s logs may identify the automation account as the actor. The PSA ticket connects those changes to the requester, approval, and reason for the reset.
How does an MSP automate MFA resets in Microsoft Entra ID?
For MSPs supporting Microsoft 365 clients, Microsoft Entra ID and Microsoft Graph API provide the underlying capabilities for automating authentication method management.
A typical workflow looks like this:
- Receive the PSA ticket and identify the client, user, requested action, and applicable policy.
- Verify identity and evaluate risk, including relevant sign-in and account risk signals.
- Connect to the correct tenant using approved, appropriately scoped credentials.
- Inspect authentication methods through Microsoft Graph.
- Execute approved changes, such as removing an obsolete method, issuing a Temporary Access Pass, or requiring re-registration.
- Validate and document the results, apply necessary session controls, and update the PSA ticket.
Microsoft Graph supports these operations through its authentication methods APIs. Organizations can invoke them directly or through Microsoft Graph PowerShell.
What permissions does Microsoft Graph need?
The permissions depend on the operation.
For example, UserAuthenticationMethod.ReadWrite.All supports reading and managing all authentication methods, and Microsoft also offers narrower per-method permissions, such as UserAuthMethod-TAP.ReadWrite.All for Temporary Access Passes. As application permissions, both apply to every user in the tenant, including Global Administrators. An app holding UserAuthenticationMethod.ReadWrite.All can issue a Temporary Access Pass to any account, so treat it as equivalent to Global Administrator. Revoking sessions requires a separate permission, User.RevokeSessions.All.
Delegated operations also depend on Microsoft Entra administrator roles. Authentication Administrator can manage methods for non-administrator users and a limited set of lower-privileged admin roles, while Privileged Authentication Administrator can manage methods for all users, including Global Administrators. These role limits apply only to delegated access or to roles assigned directly to the automation’s identity; they don’t restrict Graph application permissions.
For MSPs, the important distinction is that authorization must be validated separately for each client and operation. Routine resets shouldn’t require broad Global Administrator access.
Microsoft’s Graph permissions reference provides the specific requirements.
The key is that Microsoft Graph executes the action. It doesn’t decide whether the requester is trustworthy, whether the client’s policy permits the reset, or whether the work has been properly documented. Those controls belong in the workflow surrounding the API.
Which MFA methods should you move users to?
Every MFA reset is an opportunity to improve the user’s authentication security. Try to move users toward phishing-resistant methods, and treat every reset as the moment to do it.
The options rank, worst to best:
CISA recommends phishing-resistant methods such as FIDO/WebAuthn and PKI-based authentication.
The objective isn’t merely to restore the user’s previous method. It’s to return the user to an approved authentication state, preferably with stronger protection.
Which security standards cover MFA resets?
Two frameworks provide useful guidance and cover what clients and their auditors will ask about.
NIST SP 800-63B, Revision 4, finalized in July 2025 and replacing Revision 3, requires that account recovery always trigger a notification to the user. It also names the use of the phone network for out-of-band authentication, meaning SMS and voice codes, as its one restricted authenticator.
The CIS Critical Security Controls v8.1 cover this ground in Control 5 (Account Management) and Control 6 (Access Control Management), which includes the safeguards requiring MFA for externally exposed applications, remote access, and administrative access. See the CIS Controls.
How should you start automating MFA resets?
Start with your own queue. Pull the MFA, lockout, and password tickets for each client and sort them by who asked, how they were verified, and how often the same users come back.
The repeatable requests with reliable verification paths are your best automation candidates. The admin, executive, and odd-hour requests are your escalation list.
If you can’t tell from the ticket notes how a requester was verified, the logging step needs fixing before any automation does.
That sort also answers the cost-per-ticket question. Each routine reset your techs stop handling by hand becomes reclaimed technician capacity for L2 and L3 work, and the risky ones still land with a person who has the context to say no.
Fixify runs L1 resets and lockouts inside your existing PSA under your brand, with Fixify analysts on the exceptions 24/7, and it is paid for the resets it resolves, not for seats, endpoints, or customers.
The same 90 days of ticket data feeds the free IT Help Desk Ticket Snapshot, which returns a customized benchmarking report in 48 hours, no credit card or commitment. Start there.
If you’d rather walk through your own clients’ reset rules with someone, book a demo and bring your queue and stack.
.avif)
