If your business suspects that someone has used a stolen access token, involve the people responsible for incident response and preserve the available records while they contain the incident. The useful evidence may sit across identity systems, email services, cloud applications and employee devices.
Start with three questions: which account or application was involved, when the suspicious activity occurred, and which records are still available. Do not paste tokens or confidential evidence into a public contact form.
Why tokens matter
Applications use tokens as part of granting access to resources. Misused or stolen tokens can put that access at risk. On September 15, 2026, NIST announced finalized guidance on protecting tokens and assertions from forgery, theft and misuse. Although aimed primarily at federal agencies and cloud providers, the guidance is relevant to other organizations using these technologies. NIST announcement
A suspicion of token theft is a starting point for an analysis, not a conclusion about who accessed data or how much information was taken.
Start with identity and sign-in records
Ask the authorized administrator or response team to identify the accounts, applications and time window involved, then preserve available identity and sign-in records. Microsoft describes Entra sign-in logs as a source for analyzing sign-in activity and application usage. Microsoft sign-in documentation
Record the source of each export, the time range, applied filters, export date and timezone. Keep the original exports and work from copies. A screenshot can provide context, but it should not be the only record when an export is available.
Check email and account changes
For suspected Microsoft 365 email compromise, the response team should review relevant audit information and account changes as well as securing access. Microsoft’s response guidance covers account recovery and analysis steps. Microsoft account-compromise guidance
Useful questions for the analysis include whether mailbox settings changed, whether suspicious messages were sent, and whether activity extended into connected services. Which records can answer those questions depends on the environment and its logging.
Do not delay urgent containment to complete an ideal collection. Coordinate preservation and containment, and record the timing of response actions so later analysis can distinguish them from the suspicious activity.
Check what still exists
Retention is not the same across every Microsoft service. Entra audit and sign-in logs generally have default retention of seven days with the Free license and 30 days with P1/P2, subject to the service’s current options. They are separate from Microsoft 365’s Unified Audit Log. Previously configured archives may retain more history; a license upgrade does not recreate expired data. Microsoft retention documentation
Ask the administrator to confirm the actual licenses, retention settings, enabled logging and exports. Do not assume that a product name alone guarantees a particular evidence history.
Keep a record of the response
Create a simple timeline recording the initial alert, affected systems, actions taken and people involved. Identify relevant endpoint alerts and any existing security-platform archives for the response team to assess.
Keep collection notes with the records. Document any known gaps, collection failures or unavailable sources. A clear account of the limits is more useful than implying that the record is complete.
What can the evidence establish?
A forensic review can assess whether available records support a timeline of access and activity. The strength of the conclusion depends on the sources, coverage and corroboration.
An unfamiliar address or unusual sign-in alone does not identify a person. Missing logs do not establish that nothing happened. Reports should separate observed activity, reasonable interpretations and questions the available evidence cannot resolve.
Practical questions about a compromised account
I approved a Microsoft sign-in prompt after a call from IT. What should we check?
A sign-in prompt alone cannot tell us what happened. We compare sign-in history, newly added authentication methods, and available mailbox and cloud activity to assess access and use of the account. Keep the caller’s number, messages and the approximate time of the request so they can be compared with those records. Microsoft describes this type of help-desk impersonation in its September 2026 identity-compromise analysis.
We changed the password. Could someone still have access?
Changing the password is only part of the response. Your authorized IT or security team should also review active sessions, unfamiliar sign-in methods, app permissions and email-forwarding rules, and revoke or remove unauthorized access. Preserve available records while containing the compromise; do not delay containment just to collect evidence. See Microsoft’s account-recovery guidance.
Can you tell whether someone read our email or downloaded our files?
Available records may show mailbox access, message operations or file downloads. They do not necessarily prove that a person read every message. What can be established depends on the services, logging, licensing and records still available. We distinguish recorded activity from conclusions the evidence cannot support. Microsoft explains the limits of mailbox-access records in its mailbox auditing guidance.
Discuss an email or cloud evidence review
GDF’s Email and Microsoft 365 Forensics service provides a starting point for discussing the relevant accounts, available records and analysis scope.
For the first contact, share a brief description of the business need and how to reach you. Arrange secure evidence transfer separately.