The Recovery Ticket That Became an Identity Incident

At 09:40, an employee reports an authentication-method change they did not request. The help desk finds a completed recovery ticket. The identity team finds a later successful sign-in. The incident lead asks two questions: what was accessed, and what will stop the access that remains?

This fictional tabletop case uses invented people, timestamps, identifiers, and outcomes. Its plain-language evidence cards are teaching records, not vendor logs.

The sign-in evidence guide explains how to correlate identity and application records. This case takes that investigation further: one resource operation succeeds, another is denied, an existing session survives the first response action, and an alert reaches the wrong queue. Work out which owner needs to act at each point.

The recovery rules for this fictional case

Orchard Learning is a fictional training provider. Jordan manages course materials in Course Room. The case represents Jordan with a designated test account and harmless course documents. All times are UTC on the same fictional exercise day.

Orchard’s recovery procedure requires an approved reviewer when the employee cannot complete ordinary verification. The service-desk agent may initiate that route but cannot approve the exception alone. The identity team enables replacement-method registration only after the reviewer confirms the requester. A new delivery destination cannot be accepted solely because the unverified caller supplies it.

These are rules for this case, not Microsoft defaults. Give participants the rules first so they can assess the decision against an explicit requirement. The incident lead assigns the help-desk record to an analyst, account changes to an identity engineer, and resource activity to the Course Room owner. The lead retains responsibility for response priorities.

Decision one: documentation gap or failed verification?

Ticket T-17 records a request to replace an unavailable authenticator at 09:02 and approval at 09:10. The reviewer field is blank. A note says an exception was accepted without identifying who approved it.

That ticket alone establishes missing documentation. The associated interaction record supplies the next fact: the agent accepted the caller’s identity claim and initiated recovery without completing the required alternate verification.

Together, those records support a verification failure. The analyst retains both and asks the identity engineer what action actually ran. The review has not yet established method enrollment or application access.

This is the first decision for participants: would retrieving a missing approval attachment resolve the issue? In this case, no. The interaction record says the required check did not happen. The process owner needs to repair the approval decision, not just the ticket template.

Decision two: what changed, and who controls it?

Administrative record I-21 identifies the test account, the administrator, and a completed recovery action at 09:12. It retains T-17’s recovery reference. In this case, the administrator relied on the ticket’s approval flag and did not check for the required reviewer reference. The specified action allows the account to complete the case’s replacement-method workflow. It does not wipe a device or revoke an application session.

For an Entra investigation, retrieve the actual operation rather than relying on “MFA reset” in the ticket. Microsoft separates authentication-method management, re-registration, and session revocation. Audit records supply actor and target details and, where applicable, changed values. Authentication management, audit log details

Enrollment record E-08 shows Method R added at 09:16. The before-and-after inventory confirms the addition. The facilitator’s ownership card states that Method R belongs to the unauthorized side of the exercise; the legitimate employee’s intended replacement is Method L.

Method R and Method L are teaching labels, not vendor method types or event codes. Their ownership comes from an explicit case fact. In an actual investigation, a new method is not automatically attacker-controlled. Preserve the evidence identifying its owner, and retain uncertainty if that evidence is unavailable.

The team can now connect the unsupported approval to an executed account change and an unauthorized method. The lead asks the engineer to include Method R in the response and check for other method or device changes in the reviewed interval.

Decision three: which operation answers the access question?

Identity record S-31 describes a successful sign-in at 09:18 for Jordan’s test account, the Course Room client, and its resource. For this exercise, a controller record also confirms that Method R performed the authentication. The case supplies both facts; it does not assume every production sign-in log identifies a unique registered method.

In Entra, inspect the user, client, resource, and authentication details. Microsoft cautions that some authentication details may be incomplete while events are aggregated. Match records using the identifiers actually available, rather than a display name or time alone. Microsoft: sign-in details and considerations

The Course Room owner finds a session-start record with matching account and session references. Then she finds two operations:

The payment object contains no real payment data. It is a controlled authorization check with an expected denial.

Which sentence can the incident lead support? “All course and payment data was exposed” exceeds the evidence. “The application blocked access” omits the successful read. The useful finding is that the unauthorized test session read Course Outline One and the reviewed payment-document attempt was denied.

The owner checks the remaining application records and finds a collection gap from 09:24 to 09:27. Other operations in that interval remain unknown. Assign investigation of the gap without rewriting it as either confirmed activity or confirmed absence.

Reconstruct the evidence

Fictional case · UTC

Recovery and sign-in

• 09:10–09:16

  Recovery approved, account changed, Method R enrolled.

• 09:18

  Sign-in succeeds using Method R; resource access remains unproven.

Observed application activity

• 09:20 · Allowed

  Course Outline One is read.

• 09:22 · Denied

  Instructor Payments read fails.

• 09:24–09:27 · Unknown

  Collection gap; other operations cannot be ruled out.

Independent response checks

• 09:47 · Still allowed

  Existing session reads after the identity action.

• 09:50–09:52 · Now denied

  Application restriction completes; the read fails at 09:52.

• 09:54 · Method denied

  A separate Method R authentication check fails.

Correlate the case records. Session access and authentication are separate checks.

Decision four: has the first response action ended access?

At 09:45, the lead approves containment. The identity engineer removes Method R, checks the remaining inventory, and records the account-level response. The application owner begins the separate Course Room session action.

At 09:47, after the identity action but before the application action completes, the existing session still reads Course Outline One. That result answers a session question. It does not show that Method R can still authenticate.

Microsoft documents that Entra cannot directly revoke a session token issued by an application. The application controls that session, and the effects of an identity response depend on its integration and configuration. Microsoft: session tokens and emergency access revocation

At 09:50, the application-session restriction completes. At 09:52, the controlled document read is denied, with the application record attributing the denial to that restriction. At 09:54, a separate authentication check using Method R fails.

You can close those two checks for the tested session and method. Other application access still needs investigation. If the session distinction is unfamiliar, tokens and session cookies explains why these checks need different owners.

Decision five: fix detection or fix the handoff?

The facilitator now reveals alert D-06. It was created at 09:19 for the selected recovery-and-enrollment pattern, routed to a general support queue, and unopened by a security analyst before Jordan’s 09:40 report. The alert is part of the fictional case, not a deployed rule.

The signal existed 21 minutes before the employee report. The problem demonstrated by this case is delivery and handling, so “write a detection” would miss the immediate repair. The detection owner needs to correct the destination; the response owner needs to define acknowledgment and triage expectations.

For the follow-up exercise, record four timestamps separately: event collection, alert creation, delivery to the intended queue, and analyst acknowledgment. Also record the team’s agreed response expectation. A delivered alert with no acknowledgment leaves the required handoff incomplete within that observation window.

The first triage instruction should be specific enough to use: find the recovery ticket, confirm the affected account, and determine whether the method change was expected. It should point to the approved response process rather than authorizing an automatic destructive action from an ambiguous event.

Decision six: can the repaired process still recover the right account?

The service-desk owner proposes requiring the authorized reviewer reference before the account change can proceed. Test two outcomes against that proposal.

In the impersonated-request case, an unverified caller cannot obtain approval. The account remains unchanged and the ticket reaches the designated reviewer. In the legitimate case, the reviewer completes the approved alternate verification and the employee enrolls Method L through the expected process.

These are target outcomes for a future retest, not results already achieved. For a harder exercise, make the usual reviewer unavailable. The team should find a documented alternate route rather than depend on one person’s presence.

Use a closure record with the specific action, reviewer, intended recipient, and completed recovery reference. That lets another analyst reconcile a later method change without relying on the original agent’s memory.

Write up what happened and assign the open work

A supported account of the case reads:

An unverified caller obtained recovery approval. The resulting account change enabled enrollment of Method R, which the case evidence identifies as unauthorized. The associated session read Course Outline One; its attempt to read Instructor Payments was denied. Application activity between 09:24 and 09:27 remains unresolved because of a collection gap.

The response statement belongs alongside it:

Following the identity and application actions, the tested Course Room read and Method R authentication failed as expected. Other application access remains under review. Alert D-06 was created but misrouted; the revised handoff still requires a retest.

Each owner leaves with a different task: the help desk repairs exception approval, identity checks the method inventory, the application owner resolves session access and the collection gap, and detection repairs alert delivery. Preserve the payment-read denial as a control that worked in the tested case.

To run this with your team, use the account recovery tabletop guide for timing and facilitation. Reveal this case one decision at a time. Ask participants to write their conclusion and missing evidence before advancing. Assign disagreements to the owner who can supply the missing record or decide the next check.