An employee changes a password after a suspicious sign-in. The team closes the ticket. Later, someone notices a forwarding rule or a supplier receives another fraudulent message from the mailbox.
The missing question is whether the response addressed the access an attacker already obtained and the changes made while inside. A password change is an action. Restored control is a conclusion that needs evidence.
Microsoft’s access revocation guidance distinguishes access tokens, refresh tokens, and application sessions. Revocation can involve delays, and Microsoft Entra ID cannot directly revoke a session token issued by another application. Do not promise that one button instantly ends every form of access.
Put One Person in Charge of the Response
Use the incident plan and an approved communication channel. Assign an incident lead who can coordinate identity administrators, messaging administrators, the affected employee, and business owners. If the account may be monitored, do not use its mailbox to share the response plan.
Record the discovery time, affected identity, observed behavior, and source of each observation. Preserve relevant logs promptly within your authorized retention and investigation process. A screenshot of an alert helps orient the team, but it is not a complete activity history.
Separate facts from assumptions. “Successful unfamiliar sign-in” is an observation. “No files were accessed” needs investigation, not confidence.
Contain Access and Look for Persistence
Authorized administrators should follow Microsoft’s compromised cloud email account procedure, adapting it to the tenant and incident. Avoid improvising administrative changes from a generic checklist.
| Area | What the responder should establish | Evidence to retain |
|---|---|---|
| Identity | Account containment, credential recovery, session actions | Time, administrator, exact action and result |
| Authentication | Whether methods or recovery details changed | Approved inventory and reviewed changes |
| Mailbox | Whether forwarding, rules, or delegation changed | Relevant configuration and audit events |
| Applications | Whether grants or connected apps need investigation | Application identity, permissions, and owner |
| Data and messages | What was accessed, shared, or sent | Available audit results and their coverage limits |
| Devices | Whether the user’s endpoint is trustworthy | Security review and remediation status |
Review legitimate business dependencies before removing access, but do not leave a confirmed attacker operating while waiting for a perfect inventory. The incident lead should make and document containment decisions with the right operational owners.
Follow the Business Impact Beyond the Login
A mailbox compromise can create work outside IT. Ask the business owner whether recent messages involved payment instructions, contracts, sensitive attachments, or urgent account changes.
Verify suspicious financial requests using a previously established contact method. A reply inside the same email conversation may reach the attacker. Preserve relevant messages and headers through your approved evidence process rather than casually forwarding them around the organization.
Have the designated legal, privacy, and communications owners assess notification obligations and recipient communications. A clean password reset does not determine whether information left the organization or whether notification is required.
Use a Response Record That Makes Gaps Visible
Copy this structure into the incident record, not a public document:
Incident ID and lead:
Affected identity and services:
First observed event and evidence source:
Containment actions, exact times, and results:
Authentication methods reviewed:
Mailbox changes reviewed:
Application access reviewed:
Messages, sharing, and data activity reviewed:
Known impact:
Unknowns, missing logs, and responsible owners:
Restoration criteria and approving owner:
Next review time:Never paste passwords, tokens, session cookies, or unredacted customer data into the record. Store sensitive evidence in the approved restricted location and reference it.
Restore Access Against Defined Criteria
Before reopening the account, confirm the approved authentication setup, investigated persistence paths, endpoint status, and business owner’s ability to work. Verify the intended policy applies with an authorized sign-in test. Record what the test proves and what remains unknown.
Continue monitoring relevant activity after restoration. An absence of new alerts is useful, but it cannot prove the full historical scope of the compromise. If available logs do not cover the suspected period, report that gap explicitly.
For prevention planning, use Z7 Cyber and our explanation of why MFA alone does not protect every Microsoft 365 access path.
Book a Microsoft 365 security conversation. Bring your response checklist and the evidence your team currently uses to close an account incident.