How a help desk can reset MFA without handing over an account

Treat the reset as a change of control

A colleague calls from an unfamiliar number. Their phone is gone, they say, and payroll closes in twenty minutes. The problem may be genuine. The call supplies a reason to open a ticket, while a separate step establishes who is asking. If the help desk adds an authenticator before taking that step, the next sign-in may belong to whoever called.

A joint advisory updated in July 2025 described Scattered Spider actors impersonating employees to persuade IT help desks to reset passwords or transfer multifactor authentication. That is evidence that this route has been used, with no estimate of how often it succeeds across organizations. It explains why a small team should rehearse recovery alongside its ordinary sign-in controls.

Write the task in plain language. Are you adding a replacement method while the user can still authenticate, restoring access after all suitable methods are lost, or responding to suspected theft? Each path should end with a different record. A routine replacement can use an existing approved authenticator. A full recovery needs independently established grounds to proceed. A compromise case also needs an owner for containment.

The working rule is to treat a reset as a transfer of access. The operator needs enough evidence to identify the requester, permission to act on the target account, and a safe means of delivering the result. A sincere voice or a familiar name gives context. It cannot perform those three jobs.

Source notes: 1, 2. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Verify through a route the caller cannot choose

Start from records your organization already trusts. Open the employee entry and the account details from your usual administrative tools. If policy allows a callback, use a number that was enrolled and verified before this incident. A number supplied in the same call, email or chat remains a claim from the requester, even when it is entered neatly into a ticket.

Treat a callback as a step in a policy. A recorded number may be shared, forwarded, recently reassigned or tied to the phone reported missing. If the employee still controls another approved authenticator, the existing sign-in path may give stronger grounds for adding a replacement. If both the primary method and independent contact route are gone, move to your documented proofing or escalation process. In-person checks may be an option for some organizations.

Avoid substituting facts people can learn about a colleague for the required evidence. A manager’s name, an internal project title and a plausible description of a deadline can all turn up in messages. A manager can confirm that an employee needs access and which business work is affected. Ask how the manager established who requested the change before treating their involvement as additional evidence.

New Zealand’s National Cyber Security Centre separately advises teams to define how support staff verify identity and what to do if they cannot complete that verification. Its guidance reinforces a practical distinction between training an operator to spot a suspicious call and giving that operator a procedure they can follow on any call.

A small team can describe its procedure on a single page. List approved verification routes, their limitations, who can authorize each type of reset and what happens when the required route is unavailable. Give the help desk an escalation contact and a way to tell the user when to expect a response. This makes waiting for a proper decision possible even when the user is under pressure.

Source notes: 2, 7. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Give privileged resets a separate path

The same phone-loss story means something different for a basic employee account and for an administrator who can change access for others. Consider what the target can reach, including identity policy, mail routing, backups, production and financial approval. Apply the stricter path based on the account’s authority and downstream access, even if its display name looks ordinary.

Microsoft’s Entra role documentation distinguishes operators who can manage authentication methods for some accounts from privileged operators who can act across administrative accounts. Those product roles govern who can perform an action. Your workflow also needs a decision about when they should perform it. A person can have permission in the console and still lack adequate evidence for this particular request.

A reasonable design for a small team is to have one person verify the request and a second authorized person review the evidence before a privileged reset. Both work from records the requester cannot edit. If there is no second authorized reviewer on duty, follow an established escalation or emergency-access procedure. A deadline should not silently turn into a new authorization rule.

Exercise the staffing problem explicitly. Suppose the only operator who can issue the recovery credential has lost their own authenticator. Decide in advance which separate emergency account or alternate administrator can take over and how they will reach the records they need. A policy stored only in the locked tenant is hard to use during a tenant-wide outage.

Source notes: 1, 5. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Issue only the credential the verified case needs

Compare the mechanisms at the level of the decision they support. Microsoft Entra can issue a Temporary Access Pass for users allowed by its authentication methods policy. An administrator can configure it for limited duration and, where appropriate, single use. The pass can enable enrollment of a replacement method. Its creation says the administrator acted, while the ticket must show why the requester was entitled to receive it.

Google Workspace documents a different option for accounts protected by two-step verification. An administrator with the relevant privileges can generate backup verification codes for a locked-out user. Only a super administrator can generate codes for another administrator. For a security-key-only policy, check the documented grace-period requirements before relying on this option. This is a second-step recovery option with its own prerequisites. A team using both services should document which credential and approvals apply to each.

A temporary credential is sensitive for as long as it can be used. For an ordinary case, select a lifetime that gives the verified user a realistic enrollment window and limits exposure. Choose the permitted delivery channel based on the earlier identity check. Avoid a ticket comment, shared queue or mailbox whose control is uncertain. Record that delivery took place and which approved channel you used. Keep the secret itself out of the record.

Plan the end of the handoff before issuing anything. Who can confirm the new method was registered? Can the user sign in independently after enrollment? What happens to an unused recovery credential if the person misses their appointment? A recoverable process has a way to expire or withdraw the exception, close the case and start a separately verified request if needed.

Source notes: 3, 4. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Move suspected compromise into incident handling

A forgotten authenticator and a report of an unauthorized sign-in call for different responses. If a user sees an unfamiliar method on their account, a notification reports a change they did not request, or an independent check suggests an attacker may already have access, involve the team responsible for containment. Opening a new sign-in path for the employee addresses one part of the problem.

List the objects the response needs to address. There may be a missing device, an authenticator registered by an attacker, a compromised password and established sessions. Record the relevant identifiers and timestamps without exposing secrets. Use the organization’s incident procedure to decide which methods to suspend or invalidate, which accounts or devices to restrict and which evidence to preserve.

Microsoft distinguishes revoking access through Entra from sessions an application controls itself. The expiry of a temporary pass also does not retroactively end every established session. Check the identity platform and the applications that matter to the user’s work. Document which controls were applied, what delay is possible and what still needs action from the owner of an application.

When the employee has safely re-enrolled, verify the state the incident owner intended. Check the list of registered methods and review alerts or sign-in activity available to your role. A successful login by the employee is a useful milestone. A closed incident needs a record of the broader access that was examined, the containment applied and any unresolved exposure.

Source notes: 2, 6. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Tell the real user and leave a usable record

NIST’s current authenticator guidance calls for an independent notification to the subscriber or their designee for account recovery in systems within its scope. The operating idea is useful for workplace teams. A notice delivered through a previously established channel gives a genuine user a chance to report a change they did not request. Decide how to handle cases where the only available notification route might be compromised.

Build a record that someone else can read a week later. Capture the account, the verification route used, the operator and approver where applicable, the method changed, the type and expiry of any temporary credential, and the notification outcome. Note the work that remains open. Keep passwords, backup codes, one-time links and unnecessary identity documents out of ordinary support logs.

A useful notice gives the user enough information to recognize the action and a way to report an unexpected change through an independently known channel. For example, tell them the approximate time and the kind of change, and direct them to the help-desk route they already know. Tell the responder where to find evidence if a user disputes the event.

Make the outcome explicit. A case can end as restored, escalated, waiting for better evidence or transferred to incident handling. Teams that track only ticket closure can miss the difference between an access restoration and an unresolved security report. Use the outcome to decide who owns the next step and what they need from the record.

Source notes: 2. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Rehearse the two cases that break the shortcut

Start with a simulated employee who has genuinely lost their only phone. Use a test account and a controlled environment approved for the exercise. Give the operator the information they would normally have and observe which independent route they choose. Can they locate the policy while working under time pressure? Can the second reviewer reconstruct why the request was accepted?

Then try a simulated impersonation request. The caller knows ordinary workplace details, claims urgency and supplies a new contact route. The expected action is to stop the ordinary reset and move to the agreed escalation path. Add a variation involving an administrator and another in which an application still has a live session. These are tests of the decision process as well as the console controls.

Measure a few things you can actually observe. Record time to reach a verified decision, whether the operator followed an approved route, whether the credential reached only the intended recipient, and whether someone could locate the audit record afterward. With a small team, one missed alert or one unavailable reviewer can be more actionable than a polished success percentage.

Use the results to revise the runbook. If the documented callback cannot be completed when the phone is lost, identify a different approved proofing path and test it. If the procedure relies on one employee’s memory or an always-online identity system, give the team another way to retrieve instructions and contact the on-call decision maker.

Lumacta analysis. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

What the evidence supports

The advisory establishes a documented threat. NIST describes requirements for systems in its scope. The vendor manuals describe available mechanisms and permissions that can change with platform policy and account type. They do not measure which runbook gives a particular organization the best tradeoff between restoring access quickly and stopping impersonation.

The scenarios, second-review proposal and exercise design are Lumacta’s analysis of those sources. Adapt them to the assurance needs, applicable rules and approved tools of your organization. The useful output is a process that distinguishes verifying a person, authorizing a change, and handing back access, with enough evidence for a later reviewer to see how each decision was made.

Source notes: 1, 2, 3, 4, 5, 6, 7. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.