An account-recovery request can feel urgent and familiar at the same time. A user says they lost access to a device, cannot receive a code, and need to get back into an account. The details may sound plausible. Plausibility, however, is not the same as evidence.
That distinction is useful for early-career defenders to practise before they face a real request. A short tabletop can make the reasoning visible without touching a production system or real personal data.
Begin with a fictional request
Use a deliberately incomplete scenario:
A caller says they are a regional manager whose phone was replaced after being damaged. They cannot use the registered authenticator. They know the account name, describe a recent work project, and ask the service desk to change the recovery address immediately because a deadline is approaching.
Label the exercise fictional. Do not use a real employee, customer, account, ticket, phone number, or recovery code. The goal is not to guess whether the caller is honest. It is to record what the available evidence supports and what it does not.
Build a five-column evidence table
Ask participants to complete five fields:
- Claimed identity: What does the requester claim about who they are and which account they control?
- Evidence observed: What information or approved authenticator evidence has actually been presented?
- Evidence missing: What required evidence is absent or cannot be verified through the current channel?
- Escalation trigger: Which condition in the organisation’s documented procedure requires a different reviewer, channel, delay, or recovery method?
- Unsupported claim: What conclusion would go beyond the evidence?
For example, knowing an account name and a recent project may be consistent with the claimed identity. It may also be information available to a colleague, contractor, or attacker. The table should not silently turn contextual familiarity into proof of control.
Separate policy from improvisation
The exercise should use the organisation’s approved recovery procedure as the decision boundary. It should not train a junior analyst to invent a new identity-proofing method during a stressful call.
NIST Special Publication 800-63B describes account recovery as regaining access after losing control of the authenticators needed for the desired assurance level. It recognizes saved or issued recovery codes, recovery contacts, repeated identity proofing, and documented application-specific methods based on risk analysis. It also requires account-recovery notifications. Those details are useful reference points, but they do not replace an organisation’s own approved process, risk assessment, and legal obligations.
In the fictional scenario, the right next step may be to preserve the request, refuse the unsupported address change, and escalate through the authorized channel. The tabletop should identify the exact procedure rather than reward the fastest improvised answer.
Write a bounded decision note
After completing the table, ask each participant to write a three-part note:
- Observed: “The requester provided the account name and contextual information but did not demonstrate control of an approved recovery method.”
- Decision: “Do not change the recovery address through this channel. Preserve the request and follow the documented escalation path.”
- Limit: “This note does not determine whether the requester is legitimate or whether the account is compromised.”
The final sentence matters. It prevents a limited service-desk observation from being promoted into an incident conclusion. The note can support the next authorized decision without pretending to settle questions it cannot answer.
Debrief the reasoning, not just the answer
Compare participants’ tables. Which items were facts? Which were explanations? Did anyone treat urgency, job title, or familiarity as identity evidence? Did the proposed step preserve the ability of a qualified reviewer to examine the request? Did the note expose uncertainty clearly enough for another person to challenge it?
A useful debrief also asks what additional evidence could change the decision. That keeps the exercise from teaching reflexive denial. The objective is a justified, reviewable response: neither granting access on a plausible story nor rejecting a legitimate user without following the approved recovery path.
This tabletop does not validate an account-recovery system, qualify someone to operate one, or prove that a control will stop an attack. It practises a narrower skill: recording the difference between what is claimed, what is observed, what remains unknown, and who is authorized to decide what happens next.
Reference: NIST, Special Publication 800-63B, Account Recovery.
____
About Ryan
Ryan Corey represents READY, which develops independent career-training materials and career-development resources.
Join our LinkedIn group Information Security Community!
