Establish who is directing the response
Choose an incident lead and a trusted communication channel. If the affected mailbox is still being used to coordinate the investigation, the intruder may see your decisions. Record the account, tenant, discovery time and the business processes it can affect. A finance mailbox and a test account create different immediate priorities.
Use the organisation's incident plan and authorised administrators. Capture available evidence alongside urgent containment; do not leave dangerous access open while waiting for a perfect export. If payments may be affected, involve finance through a verified channel. Our first 24 hours guide explains the separate decision and reporting workstreams.
Find out what “MFA succeeded” means
A successful sign-in record does not by itself explain how the current session was acquired. Examine authentication details, the applied policy, application, device information and surrounding events. A claim satisfied by an earlier authentication differs from a new interactive factor challenge. An unfamiliar IP address is an investigation lead, not sufficient proof of theft.
Build a timeline around the first suspicious action, not just the alert time. Include legitimate activity for comparison. Missing logs reduce what can be concluded. They do not demonstrate that no other access occurred. This is the practical distinction developed in MFA coverage and session protection.
Check four places where access can remain
| Area | Question to resolve | Record to retain |
|---|---|---|
| User authentication | Were credentials or registered factors changed? | Method changes, actor and time |
| Sessions | Which sessions were revoked and which resources enforce that event? | Revocation time and resource checks |
| Mailbox | Were forwarding, inbox rules or delegation changed? | Relevant configuration and audit events |
| Applications | Was consent granted or a credential added to an application? | Application identity, permissions and owner |
Have the administrator review the appropriate containment actions for each area. Avoid treating user session revocation as cancellation of every application's independent permissions. Also check privileged role changes where the account could make them. Removing a suspicious application without understanding its dependencies can interrupt a legitimate workflow; preserve the finding and coordinate the action.
Verify recovery from the affected resource
Microsoft documents differences between identity-provider sessions, application sessions and token lifetimes. Continuous access evaluation improves enforcement for supported scenarios, but coverage is not universal. Record where you checked and what happened. “The command completed” is not the same observation as “the protected resource rejected the previously available access.”
Use approved test accounts for planned validation, with agreed boundaries and a rollback route. Do not copy or circulate live stolen tokens to demonstrate a point. During an incident, combine resource-side observations with the provider's supported investigation and revocation procedures. If a resource cannot be tested safely, state that limitation and the compensating action.
Before restoring normal access, investigate the likely source of the compromise as well. Use a trusted device for administration and involve the endpoint team when browser or device compromise is suspected. Contain and remediate the affected device as appropriate; otherwise newly issued credentials or sessions may be stolen again. Record the evidence and any unresolved risk. Cloud account checks alone do not establish that an endpoint is clean. Microsoft’s token theft playbook connects identity actions with endpoint investigation.
A useful recovery record
Keep a small decision log: time, known facts, action, approver, result and unresolved question. Add the affected services, configuration changes, evidence locations, the person accepting restoration and the next review date. Separate confirmed facts from working hypotheses. A screenshot of an MFA setting should not become the final incident conclusion.
Consider a fictional example: the password is reset at 10:20, sessions are revoked at 10:24 and an unexpected forwarding rule is found at 10:40. The 10:24 action cannot establish what the rule forwarded before discovery. The investigation therefore needs a message and audit review as well as an access check. These times illustrate the reasoning; they are not a Dyasol client case or a guaranteed response schedule.
Download the incident access and recovery record and adapt it to your response plan. Keep sensitive evidence in your controlled repository, with references in the record rather than copied secrets.
What to commission after containment
A focused review can establish the affected access paths, the available evidence, the changes required and a repeatable acceptance check. Ask for named systems, required permissions and clear exclusions before testing starts. The outcome should distinguish a verified correction from a recommendation awaiting implementation.
Dyasol can agree a practical identity and access review. Our contact form is for arranging work and is not a monitored emergency channel. If an incident is active, use your contracted response contacts and escalation plan first.