Give each provider the account owner's approved recovery procedure and the requests it must hold or escalate. Use the six cases below to prepare a bounded acceptance exercise with authorized test identities. They are proposed scenarios, not results from tests of any listed supplier.
Separate the operation before granting access
| Requested operation | Decision to settle with the account owner |
|---|---|
| Replace a forgotten password while another enrolled authenticator still works | Which authenticated route and permitted reset action apply? Changing the password does not automatically authorize a new MFA method. |
| Recover access after losing the required authenticators | Which prearranged recovery process, proof and accepting authority apply? An unavailable usual factor needs an agreed recovery route. |
| Register a replacement method or issue temporary access | Who may authorize and perform that enrollment, for which account types and under what delivery and expiry conditions? |
NIST SP 800-63B-4 (external website) distinguishes password replacement with another available authenticator from account recovery after loss of the needed authenticators. It also describes recovery and new-authenticator notifications. Use those distinctions as design references when the account owner sets the actual assurance and recovery policy.
Put three decisions in the service scope
- Correct account. Match the request to the approved client, tenant and target identity. Similar names across clients are a routing risk; the technician needs the permitted lookup and a way to resolve ambiguity before changing access.
- Approved verification. Define how the requester completes verification through the established process and how failure is handled. Familiarity with a user's name, employer or ticket history does not replace that process.
- Authority for the action. Identify who approves this operation on this account type, what the technician may perform and who accepts exceptions. An identity check alone does not approve a privileged change.
The July 2025 joint Scattered Spider advisory (external website) describes impersonation targeting contracted IT help desks, including efforts to induce password changes and MFA transfer. Write the response boundary before the first such contact reaches the outsourced queue.
Agree the contact route before a recovery call
Use the account owner's controlled contact and recovery information. Specify how the desk handles a caller who supplies a new telephone number or email address during the same request. That proposed destination cannot establish its own authority to receive access.
The procedure should name the verification method, allowed account population, accepting approver and fallback when the normal route is unavailable. If a callback is part of the process, define where its destination comes from and what additional verification the policy requires. Avoid an improvised exception based on urgency or a convincing conversation.
Client and privileged accounts can require different routes. Carry those distinctions into the support schedule, including nights and holidays, so a closed daytime approval route does not become an informal overnight bypass.
Limit authority by account and action
Microsoft's built-in role reference (external website) distinguishes Authentication Administrator access for nonadministrators and certain roles from the broader Privileged Authentication Administrator role. It also explains that a nonadministrator may hold sensitive application or resource ownership. A simple admin/non-admin label is therefore not a complete risk assessment.
Ask the supplier to map the actual permitted tasks and target accounts to its proposed access. Identify requests retained by your own authority, including sensitive accounts outside an obvious administrator list. The integration worksheet can hold the permission owner, scope and offboarding requirements alongside the ticket workflow.
Treat temporary access as a credential
Microsoft describes a Temporary Access Pass (external website) as a time-limited passcode that can allow single or multiple sign-ins and help enroll authentication methods. Its policy and issuing roles are separate controls. Creating a pass does not itself verify the person asking for it.
If temporary access belongs in the purchased workflow, agree the approving owner, eligible target account, issuing actor, approved delivery route, lifetime and permitted use. Define what happens after enrollment, expiry or suspected misuse. Keep the actual passcode out of ordinary ticket notes; document the authorization and action reference instead.
Use six authorized acceptance cases
Choose synthetic accounts and contact routes that the owner has authorized for the exercise. Agree the expected permitted action, held state or escalation before starting. Each case below is a proposed boundary check; leave the observed outcome blank until your own exercise occurs.
Password request with an available authenticator
Authorized setup: An authorized standard test account still has a working enrolled authenticator. Request a password replacement through the agreed support channel.
Expected boundary: Complete the owner-approved verification and permitted password action. Treat any new MFA enrollment as a separate authorization; do not ask the test user to disclose an authentication secret in ticket notes.
Observe: Account mapping, verification outcome, approved action and the notification or closure required by the policy.
Lost phone and no available enrolled factor
Authorized setup: The synthetic requester reports loss of the usual device and cannot complete the routine verification path.
Expected boundary: Use the preapproved account-recovery route or hold with accepted escalation. Do not grant a replacement method or temporary access merely because the normal verification is inconvenient.
Observe: Recovery decision, accepting authority, retained ownership and the status communicated to the requester.
A new destination supplied during recovery
Authorized setup: The test requester asks for recovery material to go to a phone number or email address introduced in that same contact.
Expected boundary: Treat the contact change and recovery authorization as separate decisions under the owner policy. The new destination does not verify its own entitlement; hold until the approved route authorizes the change.
Observe: Source of the trusted contact route, approval for any change and the allowed delivery disposition, without storing the secret.
A privileged or otherwise sensitive account
Authorized setup: An authorized exercise targets an account classified by the owner as requiring retained approval, including a sensitive account without an obvious administrator title.
Expected boundary: Verify identity and route the requested action to the designated authority. A routine queue permission or successful caller check does not substitute for that approval.
Observe: Account classification, requested operation, approving owner, acting role and any held state or accepted handoff.
The same display name in two client tenants
Authorized setup: Use synthetic client entries with a similar user name. Give the desk an intentionally ambiguous client/account reference.
Expected boundary: Resolve the approved client and tenant before a change. A correctly verified person in one client context does not authorize action on a similarly named account elsewhere.
Observe: Lookup and ambiguity resolution, target reference and whether any unintended action was avoided.
Verification or the accepting approver is unavailable
Expected boundary: Follow the agreed fallback and retain a held or escalated state until an authorized recipient accepts. Intake acknowledgement does not turn an unapproved action into completed recovery.
Observe: Contact attempts, fallback owner, accepted handoff, next action and the client update against the purchased service window.
Download the six-case identity verification brief (.md). Add the approved policy, owners and actual observations in your own working copy.
If a case misses a required identity or approval step, keep that failure visible and resolve it before accepting the affected action. Friendly communication or a quick response does not make that missing step pass. A case that was not observed remains not observed.
Keep a useful ticket trail
For the agreed task, retain the client/account reference, request type, verification outcome and method reference, approving owner, acting technician, permitted action and final disposition. For a held or escalated request, include the next action and the person who accepted it. Use the minimum detail your policy needs; avoid ordinary ticket storage of passwords, recovery secrets or unnecessary identity documents.
Acknowledging a call, verifying a person and completing recovery are different events. Keep the relevant clocks and waiting approvals separate in the SLA definitions. The help desk pilot adds technical accuracy, communication and retained effort to this narrower identity exercise.
Read the supplier's exceptions
Helpt's published service scope (external website) describes holding further work and escalating when its configured secondary verification fails or is absent. Its password-reset section also permits an explicit verification waiver. Ask who can authorize any exception, how it is logged and which requests must still be held; the existence of a waiver is not your approval to use it. The Helpt profile keeps its other work boundaries and plan questions together.
For every candidate, obtain the applicable procedure and incorporated order. Put the account types, permitted actions, identity process, approval route, exception authority, notification and ticket-trail requirements into the same RFP. Keep these requirements attached when comparing white-label help desk options.
Source notes
Primary references checked 19 October 2026: NIST's final SP 800-63B-4 authenticator-event guidance; Microsoft's authentication-role reference and Temporary Access Pass documentation; and the joint Scattered Spider advisory updated July 29, 2025. The scenarios are editorial acceptance examples. Their actual policy and observed outcomes belong to the account owner and the purchased service.