Helpdesk security
Verify Identity Before Resetting MFA
A practical identity check for MFA reset requests, with the evidence to collect, the questions that expose a bad request, and the limits of a virtual assistant's authority.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
An MFA reset is one of the few helpdesk actions that can hand an attacker a working account. The person asking is locked out, often frustrated, and usually in a hurry. That combination is exactly why the reset needs a fixed procedure rather than a judgment call made at the keyboard.
The workflow below separates three things that are easy to blur: confirming who is asking, confirming that the account belongs to them, and confirming that the reset is still safe to perform after the check. An IT virtual assistant can run most of this sequence. The account owner or security lead keeps the authority to override it.
Why a reset request needs its own control
Most account recovery paths assume the helpdesk can recognize the requester. In a distributed company that assumption fails quietly. The assistant may never have met the employee, the request may arrive by chat from a new device, and the display name on the account may match someone else in the directory.
NIST SP 800-63B treats authenticator lifecycle events, including replacement and recovery, as part of digital identity assurance rather than an administrative afterthought. The practical translation is simple: a reset is an identity decision, so it needs evidence, a named approver, and a record.
The control does not need to be elaborate. It needs to be the same every time, including for the manager who asks informally because they are standing next to the locked-out employee.
Collect the request in writing first
Ask the requester to submit the request through the helpdesk, not a direct message. The ticket should name the account, the sign-in address, the device or app that is failing, the error text, and the last time the account worked. A screenshot of the error is more useful than a description of it.
Written intake does two jobs. It creates a timestamp and an audit trail, and it slows the request enough for the requester to notice a wrong account. A surprising number of resets are for a personal account, an old alias, or a second tenant the company does not manage.
If the request arrives by phone, the assistant opens the ticket and reads the details back. The ticket becomes the source of truth, not the call.
Verification that does not rely on the phone alone
Calling the number on file is the standard check, but it fails when the number is the compromised factor or when the employee has a new phone and cannot receive the call. Treat the phone call as one signal, not the whole test.
A stronger packet combines several independent signals: a video call with the company directory photo visible, a check that the requester can name their manager and team, a confirmation sent to the manager through a separate channel, and a review of recent sign-in activity for anything unusual.
For privileged accounts, add a second approver. The assistant prepares the packet and routes it. The approver decides. If the signals conflict, the assistant stops and records why, rather than choosing the most convenient answer.
A short script with stop conditions
Open with the purpose: "I am going to verify your identity before we reset the authenticator. This takes a few minutes and protects your account." Then ask for the employee identifier, the work email, the manager's name, and the last successful sign-in.
Ask one question that only the account holder would answer comfortably, such as the name of the team channel where they last posted or the building they normally work from. Do not ask for a password, a one-time code, or a recovery code. Those are never part of verification.
Stop the reset if the requester cannot name the manager, if the manager cannot be reached, if the sign-in history shows a new country or device that the requester cannot explain, if the account has recent privilege changes, or if the requester pressures the assistant to skip the check. A polite hold is cheaper than an account takeover.
Perform the reset and prove recovery
After approval, the assistant performs only the approved step: remove the old authenticator registration or issue a temporary enrollment. Do not disable MFA outright and leave it off. The account should move from one protected state to another.
Record the exact action, the time, the approver, and the method used. Then confirm recovery with the user on a channel that is independent of the account being recovered. Ask them to complete enrollment and sign in while the ticket is open.
If enrollment fails twice, stop and route to the identity owner. Repeated failures can indicate a device problem, a conditional access policy, or an attacker holding a session. None of those are solved by another reset.
Close the record and review the pattern
A closed ticket should show the request, the verification signals, the decision, the action, and the confirmation of recovery. Store it where the security lead can retrieve it without asking the assistant, and keep it for the period the retention policy requires.
Review resets monthly. Count them by team, by cause, and by time of day. A cluster after a device rollout is expected. A cluster on one account, or a run of requests that arrive just after a phishing campaign, deserves a closer look.
The review is also where the script improves. Every exception the assistant had to escalate is a missing rule, and every override is a candidate for a clearer approval path.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what verify identity before resetting mfa means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review