Choosing the Right Identity-Verification Method

Hello again. In the last lesson, you learned that a request which looks routine can actually be a security incident when it contains signs of compromise. This lesson adds the control that comes before most account changes: establish that the requester is really entitled to act as the account holder.

For IAM support, identity verification is not a formality. Resetting a password, unlocking an account, registering a new MFA device, or changing a recovery phone number can each hand control of an account to an impersonator if performed for the wrong person. By the end of this lesson, you should be able to select a verification method that matches the risk of the action, the user’s available authenticators, and any signs of compromise.

Suggested study time: about 40 minutes.

---

Verification is a decision, not a script

A caller may know a user’s name, department, manager, employee number, and even their date of birth. Much of that information can be found through social media, breach data, internal directories, or a convincing pretext. It may help support staff hold a sensible conversation, but it is not necessarily strong proof that the caller controls the account.

Before an account action, separate four related ideas:

Concept	Support question	Example
Identification	Which account does the person claim to be?	“I am Elena Garcia; my username is egarcia.”
Authentication	Can they demonstrate control of an authenticator already bound to that account?	They approve a prompt in their registered authenticator app.
Identity proofing / verification	Can the organization establish that this is the real person when normal authenticators are unavailable?	A recovery service validates an identity document and liveness check.
Authorization	Is the requested action approved and within your role to perform?	A manager-approved request permits a group assignment.

In day-to-day help-desk language, “verify the user” can describe any of these. Be precise in ticket notes: write which method was used and whether it was an existing authenticator, an approved callback, or formal identity proofing.

Most importantly, verification does not replace authorization. A verified employee may still not be authorized to receive a privileged role, access another employee’s mailbox, or alter a shared service account.

The action determines the required confidence

Think of account actions as changing the attacker’s ability to control an identity. The greater the control gained, the stronger and more independent the verification should be.

Account action	Consequence if performed for an impostor	Appropriate verification posture
Explain a public support process	Little or no account control	No account-specific disclosure; provide general guidance.
Confirm limited account status to an authenticated portal user	Limited disclosure	Existing authenticated session, if policy permits.
Unlock a standard account	May restore access to someone with stolen credentials	Use the organization’s approved verification method; consider compromise indicators first.
Reset a password	May enable account takeover	Require strong verification through an existing, registered method or an approved recovery flow.
Add or replace an MFA method	Can defeat MFA and establish persistent attacker access	Treat as high risk: require strong existing authentication or formal recovery, never just knowledge-based questions.
Change recovery email, phone, or contact details	Lets an attacker intercept future recovery	Treat as high risk and notify through an existing independent channel.
Reset a privileged administrator account or grant privileged access	Could compromise many systems	Follow privileged-account procedure, usually with stronger verification, documented approval, and escalation or dual control.

A simple rule is:

Never let the requester choose the evidence that proves their identity.

For example, a person calling from an unknown number cannot establish identity by asking you to send a code to a new number they provide. That number has not yet been bound to the account and may belong to the attacker.

---

Why common help-desk questions are not enough

The following excerpt from IT: Helpdesk Level 1 Dealing With Account Lock Out/Password Reset by Kevtech IT Support usefully illustrates the moment when a technician pauses before changing credentials for an off-site caller.

Directory attributes can support a verification conversation, but they should not be the sole factor for a high-impact action. A manager name, job title, and department are often discoverable. Even a caller ID is not reliable by itself, because phone numbers can be spoofed.

Stronger approaches are based on something the organization already trusts:

• an existing registered authenticator, such as an authenticator app approval, security key, or other permitted sign-in method;
• an out-of-band callback to a phone number already recorded in the authoritative identity system;
• a pre-issued recovery code stored by the user before the incident;
• a formal identity-proofing recovery process when no usable authenticator remains;
• for sensitive accounts, an approved manager or security workflow in addition to strong user verification.

Do not ask a user to reveal:

• their password;
• a one-time passcode sent for a current sign-in;
• a recovery code;
• push-approval details that would allow you to reuse or validate a secret.

A legitimate support process should verify the user’s control of a method without collecting reusable secrets in a ticket, chat, or call recording.

---

Independence matters: choosing an out-of-band method

An out-of-band (OOB) verification method uses a communication path separate from the primary support interaction. For example, a user may call the help desk on an unknown phone number, while the analyst calls back the mobile number already registered for that account. The known number, rather than the incoming call, is the evidence channel.

The diagram shows an important security property: the verifier uses a secondary channel that is not simply the same browser session or support conversation. But “different” is not automatically “independent enough.” Consider these examples:

Proposed method	Is it suitable?	Reasoning
Send a code to the new number supplied by the caller	No	The caller selected the destination; it is not trusted account evidence.
Call the mobile number previously registered in the identity system	Often, if policy allows	The organization selected the channel before the request.
Send a verification message to the user’s normal work email while they report losing account access	Usually no	If the account may be compromised or inaccessible, the email channel cannot establish trustworthy control.
Ask the caller for their manager’s name	Weak supplementary evidence only	It proves knowledge, not possession of a registered authenticator.
Ask the user to approve a prompt in their registered authenticator app	Stronger, subject to policy	It demonstrates control of an authenticator already bound to the account.
Ask a privileged admin to authenticate with an existing phishing-resistant method, then obtain a separate approval for a sensitive change	Appropriate for high-risk changes	It addresses both identity verification and authorization.

An OOB method also must be used carefully during a suspected compromise. If a user reports unexpected MFA prompts or a stolen phone, do not send another approval request and ask them to “just accept it.” Classify the case through the security workflow first, as covered in the previous lesson.

---

A practical selection procedure

Rather than memorizing a single verification script, use a consistent sequence. Your employer’s policy, identity platform, and service-desk tooling determine the permitted methods, but the reasoning remains the same.

1. Identify the requested action and account.
   Determine exactly what would change: an unlock, password reset, MFA replacement, recovery-address change, group membership update, or privileged-role action. Gather only the minimum information needed to locate the account.

2. Check for compromise indicators before verification.
   Look for repeated unsolicited MFA prompts, unexpected sign-ins, phishing reports, recent MFA changes, lost devices, or risk alerts. If present, pause routine fulfillment and use the security-incident process.

3. Estimate the impact of an incorrect action.
   Password and MFA actions are high impact because they establish or restore account control. Privileged, finance, HR, and executive accounts normally require an even stricter workflow.

4. Determine what trusted evidence remains.
   Does the user have a registered authenticator, a registered phone, a recovery code, an active managed device, or no usable method at all? Do not count a newly supplied email address or phone number as existing evidence.

5. Choose a policy-approved method at least as strong as the action requires.
   Prefer existing authenticators and pre-registered OOB channels. When all normal methods are unavailable, route the case to the formal recovery process rather than improvising.

6. Perform the action with safeguards.
   Apply only the minimum necessary change. Where policy requires it, force a password change at next sign-in, require MFA re-registration, revoke sessions, or use a time-limited recovery method.

7. Notify and document.
   Send an account-change notification through an independent existing channel where available. Record the verification method, action, timestamps, approvals, and any escalation—without copying secrets or unnecessary personal data into the ticket.

This procedure protects both the user and the support analyst. A caller who becomes urgent, hostile, or insistent that “the CEO needs this now” has not supplied stronger identity evidence. Urgency may affect ticket priority, but it should not lower the verification threshold.

---

Password reset, authenticator replacement, and true account recovery

These terms are often used interchangeably, but they represent different support situations.

If a user forgot a password but can still authenticate with a registered MFA method, the organization still has an established trust signal. In Microsoft Entra environments, this is typically handled through self-service password reset (SSPR) or an approved support process that uses that remaining method.

If the user has lost all registered authentication methods, trust must be re-established. That is account recovery, a more sensitive event than an ordinary password reset.

Microsoft’s account recovery model is designed to reduce a classic help-desk social-engineering weakness: a person persuading an analyst to bypass every existing control. It uses third-party identity verification, including identity-document checks and liveness verification, before resetting authentication methods.

NIST’s authenticator guidance provides a broader framework. It explains why replacement and recovery must be selected based on the assurance level and the authenticators still available.

NIST distinguishes these situations clearly:

• A remaining authenticator exists: A forgotten password can be replaced after the user authenticates with another bound method. The event is effectively binding a replacement authenticator, not full account recovery.
• No authenticators remain: Use an approved recovery method. NIST recognizes saved recovery codes, issued recovery codes, recovery contacts, and repeated identity proofing.
• Higher assurance is required: One weak fact is insufficient. At AAL2, NIST requires either two recovery codes obtained by different methods, one recovery code plus a bound single-factor authenticator, or repeated identity proofing.

NIST’s “shall” requirements apply to the credential service providers within its scope, not automatically to every help desk. In support work, use them as a rigorous benchmark while following your organization’s recovery policy.

---

Selecting a method in realistic support cases

The right response becomes clearer when you state what evidence is already trusted and what action the user wants.

Case 1: Standard user requests an account unlock from home

Facts: Jordan calls from an unrecognized number and says their account locked after several failed password attempts. There are no risk alerts or suspicious MFA reports.

Select: Use the organization’s approved OOB process, such as calling a phone number already registered in the authoritative identity directory, or have Jordan use an existing registered authentication method. After successful verification, unlock according to policy.

Do not select: “Tell me your department and manager” as the only proof. Those facts can be known by an attacker.

Case 2: User forgot a password but has their authenticator app

Facts: A user can still approve authentication in their registered app but does not know their password.

Select: Direct the user to the approved self-service reset flow or verify using the existing method before performing a support-assisted reset, according to policy.

Why: The user retains a bound authenticator, so trust has not been completely lost. Full identity-proofing recovery would be unnecessary friction in many environments.

Case 3: User lost their phone but has a second registered method

Facts: The user reports a lost mobile phone but can authenticate using a registered security key or another permitted authenticator.

Select: Verify through the remaining registered method, then follow the approved process to replace the compromised phone-based method. Send notifications through an independent channel and ensure the lost method is removed or revoked as required.

Why: A lost authenticator should be treated as potentially compromised. Do not leave it silently active just because the user has regained access.

Case 4: User has lost every method

Facts: The user has no phone, no security key, no recovery code, and cannot access any registered method.

Select: Formal account recovery or identity proofing through the organization’s approved recovery service. In Entra’s account-recovery model, this can include document verification, liveness checks, and validation against stored identity attributes.

Do not select: A help-desk password reset after several personal questions, or a code sent to a new contact method supplied during the call.

Case 5: Privileged administrator requests an MFA change

Facts: An administrator says their authenticator was replaced and asks for a new one to be enrolled immediately. The account has tenant-wide administrative capability.

Select: Follow the privileged-account recovery procedure. This commonly requires a high-assurance existing method where possible, separate authorization, security-team involvement, and carefully documented actions. If compromise is suspected, containment takes priority.

Why: The potential blast radius is much larger than for a standard user. Verification must be proportionate to that risk.

---

A concise support record

A ticket should show that you made a reasoned verification decision without retaining sensitive verification data.

A useful note might read:

Requested action: Unlock standard workforce account.
Verification: Completed approved callback to mobile number pre-registered in the identity directory; no codes, passwords, or recovery secrets collected.
Security screening: User denied uninitiated MFA prompts and no current compromise indicator was reported.
Action: Account unlocked under standard procedure; user advised to retry sign-in and report unexpected prompts.
Notification and audit: Account-action notification generated by the service; ticket updated with timestamp and analyst ID.

For a total lockout, the record should be different:

Requested action: Restore access after loss of all authentication methods.
Verification decision: Existing authenticator and registered recovery methods unavailable. No support-assisted MFA reset performed.
Action: Routed to approved identity-proofing account-recovery workflow.
Security handling: Lost device recorded; security escalation applied where required by policy.

The record should never include a password, OTP, recovery code, identity-document number, or more personal data than the process requires.

---

Key takeaways

Before performing any meaningful account action, match the verification method to the risk of the change and the trusted evidence still available.

• A claimed username and known personal or organizational facts identify a person’s claim; they do not reliably authenticate them.
• Prefer existing bound authenticators and pre-registered, independent callback channels.
• Never use a new phone number or email address supplied during the request as proof of identity.
• Password resets, MFA enrollment, and recovery-contact changes require stronger controls because they can transfer account control.
• If an existing authenticator remains, use the approved self-service or support flow. If every method is lost, use formal account recovery and identity proofing rather than improvised help-desk verification.
• Suspected compromise changes the path: pause routine recovery and follow the security-incident process.
• Document the method and outcome, but never store reusable secrets in the ticket.

Next, you will learn to recognize the social-engineering warning signs that often appear in password-reset and access requests—especially the signals that should make you stop and escalate rather than continue with verification.