# MSP help desk identity verification - acceptance cases

Guide: https://mspshortlist.com/guides/help-desk-identity-verification/

These are proposed editorial scenarios, not results from supplier tests. Use only owner-authorized synthetic identities and contact routes. Leave actual observations blank until the exercise occurs. Never place authentication secrets or real customer identity documents in this brief.

## Scope and authority

- Buyer and policy owner: __________
- Approved procedure and revision: __________
- Authorized synthetic accounts and client aliases: __________
- Permitted action and account population: __________
- Accepting approver and backup: __________
- Agreed exercise window and channels: __________

## Password request with an available authenticator

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-working-factor

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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## Lost phone and no available enrolled factor

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-lost-authenticators

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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## A new destination supplied during recovery

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-new-contact-route

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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## A privileged or otherwise sensitive account

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-privileged-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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## The same display name in two client tenants

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-wrong-tenant

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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## Verification or the accepting approver is unavailable

Case reference: https://mspshortlist.com/guides/help-desk-identity-verification/#identity-case-unavailable-approver

Authorized setup: During an authorized out-of-hours case, make the normal verification route or designated approval contact 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.

- Actual observation and ticket reference: __________
- Outcome (pass / fail / not observed): __________
- Accepting owner and next action: __________
- Correction and retest outcome, if required: __________

## Review and next action

- Scope accepted by owner: __________
- Open failed or unobserved actions: __________
- Review date and next action: __________

Primary references:
- NIST SP 800-63B-4: https://pages.nist.gov/800-63-4/sp800-63b/events/
- Microsoft roles: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
- Microsoft Temporary Access Pass: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass
- July 29, 2025 joint advisory: https://www.cisa.gov/sites/default/files/2025-08/aa23-320a-scattered-spider-508c.pdf