Where are my logs? A field guide to Microsoft 365 & Entra ID log sources

Published 2026-11-14
Field guide to Microsoft 365, Entra ID, Purview, Exchange, Defender XDR, and Sentinel log sources, retention pitfalls, and architecture recommendations.

When you respond to an incident on Microsoft 365, the hardest constraint hits in the first ten minutes: do we still have the telemetry to trace what happened?

Unlike an on-premises network where you can pull a disk image or grab months of firewall logs off a local NAS, cloud forensics depends on four choices made long before anyone clicked a phishing link: which log categories were turned on, where they were exported, how long they are kept, and which license each user holds. If sign-ins rolled off after seven days or mailbox auditing was bypassed, no post-incident license upgrade will bring that history back.

This guide is the foundation for every investigation article on this blog. Every technique in the attack matrix points to a specific log source under Where to look—and every one of those log streams lives in one of the five planes below.

The five places where tenant telemetry lives

Plane What it records Default retention (without export)
Microsoft Entra ID Interactive/non-interactive user logins, app/MI logins, directory changes, provisioning, Graph HTTP calls 7 days (Free), 30 days (P1/P2; 90 days for risky sign-ins); Graph activity logs are not kept in the portal at all
Microsoft Purview Audit (UAL) What authenticated identities did inside workloads: Exchange, SharePoint, OneDrive, Teams, Entra, Power Platform, Copilot 180 days (Audit Standard); 1 year on Entra, Exchange, SharePoint & OneDrive with Audit Premium (E5)1
Exchange Online Native Email flow telemetry (Message Trace) and per-mailbox audit flags 10 days interactive / Get-MessageTraceV2; up to 90 days via Extended Message Trace CSV
Microsoft Defender XDR Threat & endpoint/email/identity hunting tables (Email*, CloudAppEvents, EntraIdSignInEvents) 30 days in Advanced Hunting & Threat Explorer (alerts/incidents stay 180 days)2
Azure Monitor / Sentinel AzureActivity control-plane logs, plus long-term Log Analytics storage and SIEM correlation AzureActivity 90 days free; Sentinel Analytics includes 90 days (up to 2 years interactive, 12 years Archive / Data Lake)3

Keep one rule in mind whenever someone suggests buying E5 during an incident: Microsoft cloud log retention is never retroactive. Upgrading from Entra ID Free to P1/P2 today starts counting 30 days from today forward; it will not recover sign-ins from two weeks ago, and MicrosoftGraphActivityLogs only exist from the day you wire up a Diagnostic Setting4.

Deep dive by source (and the traps you hit in the field)

Entra ID collects several distinct log categories, and the biggest beginner mistake in an M365 incident is stopping at the first tab (User sign-ins (interactive)) in the Entra admin center5.

In modern attacks—AiTM phishing, device code phishing, ConsentFix, or Primary Refresh Token (PRT) replay—the victim often completes the initial interactive sign-in themselves (or hands over an OAuth code). After that, the attacker replays refresh tokens, session cookies, or app permissions silently. If you only check interactive logins, you see a clean login from the user's home IP and miss all the attacker's token refreshes in the Non-interactive sign-ins tab.

Log stream What it records Log Analytics / Sentinel table
Interactive user sign-ins User enters a password, Passkey, MFA prompt, or hits Conditional Access interactively SigninLogs
Non-interactive user sign-ins Client app or attacker silently redeems a refresh token / session cookie on the user's behalf AADNonInteractiveUserSignInLogs
Service principal sign-ins Confidential client applications signing in using a client secret or certificate AADServicePrincipalSignInLogs
Managed identity sign-ins Azure workloads authenticating using platform-managed identities AADManagedIdentitySignInLogs
Audit logs Directory mutations: user/app creation, role assignments, MFA registration, Conditional Access & device joins AuditLogs
Provisioning logs Account creation/updates driven by SCIM, HR connectors, or cross-tenant synchronization AADProvisioningLogs
Microsoft Graph activity logs Every HTTP request hitting graph.microsoft.com (URIs, methods, app IDs, IPs, response codes) MicrosoftGraphActivityLogs
Legacy & hybrid identity logs Retired Azure AD Graph (graph.windows.net) fallback calls and AD FS sign-ins (via Entra Connect Health) AADGraphActivityLogs, ADFSSignInLogs

How to pivot across Entra ID logs

Because attackers split their footprint across login and API planes, knowing the join keys saves hours:

  • SessionId: Ties interactive and non-interactive sign-ins together for one session lifetime. In an AiTM attack, seeing the exact same SessionId switch from the victim's ISP IP to an unfamiliar VPS or VPN IP minutes later is your smoking gun.
  • UniqueTokenIdentifier → SignInActivityId: Links a specific token issuance in SigninLogs or AADNonInteractiveUserSignInLogs directly to the individual API calls made with that token in MicrosoftGraphActivityLogs (where the column is named SignInActivityId).
  • CorrelationId: Groups every related retry or step within a single authentication attempt or directory operation.
  • AuthenticationProtocol and IncomingTokenType: Lets you filter instantly for anomalies—for example AuthenticationProtocol == "deviceCode" for device code phishing, or IncomingTokenType showing primaryRefreshToken / refreshToken replay from an unmanaged device.

Retention and portal blind spots

Category Entra ID Free Entra ID P1 Entra ID P2
Sign-ins (all four types) 7 days 30 days 30 days
Audit logs & Provisioning 7 days 30 days 30 days
Risky sign-ins / Risk detections 7 days 30 days 90 days
MicrosoftGraphActivityLogs & AADGraphActivityLogs Not available 0 days in portal (must be exported) 0 days in portal (must be exported)

Exporting Entra categories to a Log Analytics workspace, Azure Storage Account, or Event Hub is configured under Monitoring & health → Diagnostic settings in Entra ID and requires the Security Administrator role alongside at least one Entra ID P1 or P2 license in the tenant4. Unlike SigninLogs, MicrosoftGraphActivityLogs has no built-in table view in the Entra portal: if you haven't created a Diagnostic Setting for it, no HTTP-level Graph telemetry is retained anywhere.

While Entra ID proves who authenticated and got a token, the Microsoft Purview Unified Audit Log (UAL) answers what they touched once inside: which emails were read, which inbox rules were created, which SharePoint files were downloaded or shared externally, and what prompts went to Copilot.

Two architectural facts govern UAL investigations:

  • It is independent of Entra licensing. Standard UAL retention is 180 days (historical records prior to October 17, 2023 were kept 90 days)1.
  • Premium retention follows the user's license, not the tenant. Audit (Premium) (included with Microsoft 365 E5 or the E5 Compliance add-on) extends Entra ID, Exchange, SharePoint, and OneDrive audit retention to one year—with a 10-year retention add-on available1. However, retention is stamped per acting user: unlicensed accounts, shared mailboxes without an E5-licensed actor, B2B guests, or frontline accounts on F1/F3 still fall under Standard rules.

Three traps you will hit in the field

  1. Tenant auditing on ≠ every mailbox covered. Checking the org-wide switch in Exchange Online PowerShell is step one:

    Get-OrganizationConfig | Format-List AuditDisabled

    You want AuditDisabled : False6. Even then, always check for mailbox-level bypasses (Get-MailboxAuditBypassAssociation | Where-Object { $_.AuditBypassEnabled -eq $true }), which attackers sometimes abuse to go silent. Also keep an eye on the three mailbox audit scopes—AuditAdmin, AuditDelegate, and AuditOwner: some AuditOwner events (like MailboxLogin or HardDelete) are not always enabled by default depending on mailbox configuration and tenant age.

  2. The MailItemsAccessed throttling cliff. MailItemsAccessed is the critical audit operation that records whether a session performed a folder Sync (desktop Outlook caching an entire folder—meaning Microsoft recommends treating the whole folder as compromised) or a Bind (opening specific messages identified by InternetMessageId in two-minute buckets)7. It is enabled by default for E3 and E5 users7, but Exchange Online throttles Bind logging for 24 hours if a mailbox triggers more than 1,000 Bind operations in 24 hours, emitting a throttling indicator instead of every individual message ID.

  3. Move off synchronous Search-UnifiedAuditLog on large queries. Search-UnifiedAuditLog in PowerShell breaks easily at 5,000 records per session and drops pages under timeouts. For real investigations, run asynchronous Purview Audit Search jobs in purview.microsoft.com or automate them via the Microsoft Graph Audit Log API (security/auditLog/queries).

If a tenant runs Microsoft 365 Business Standard/Premium or Office 365 E3 without Defender for Office 365, you will not have EmailEvents or Threat Explorer in Defender XDR. Exchange Online Message Trace becomes your primary source of truth for mail flow:

  • Standard Message Trace (Get-MessageTraceV2 in PowerShell or the Exchange Admin Center UI): near real-time query across the last 10 days of inbound and outbound mail flow.
  • Extended Message Trace (Start-HistoricalSearch or EAC downloadable report): reaches back up to 90 days, exporting a CSV with connector routing, TLS status, sender IPs, and message IDs.

Crucially, Message Trace lives at the transport pipeline, not inside the mailbox: even when an attacker hard-deletes phishing replies from Sent Items and clears Recoverable Items, outbound trace records remain intact.

People often mix up the two retention windows inside the Microsoft Defender portal: alerts and incidents stay visible for 180 days, whereas Advanced Hunting (and Defender for Office 365 Threat Explorer) only keeps raw event tables for 30 days2. If a BEC occurred six weeks ago and nobody exported Defender tables, Advanced Hunting returns empty results even while old incidents still appear in the UI.

Each hunting table also depends on which Defender workload is licensed and active on the tenant8:

Hunting table What it contains Populated by
EntraIdSignInEvents Interactive and non-interactive Entra sign-ins Microsoft Defender XDR / Defender for Identity cloud context
EntraIdSpnSignInEvents Service principal authentications Microsoft Defender XDR cloud context
CloudAppEvents Normalized M365, Entra, and connected SaaS app activities Defender for Cloud Apps (E5 / E5 Security)
EmailEvents, EmailUrlInfo, EmailAttachmentInfo Mail delivery verdict, threats, URLs, and attachments Defender for Office 365 (Plan 1 / Plan 2)
EmailPostDeliveryEvents Post-delivery ZAP actions and manual admin remediations Defender for Office 365 (Plan 2)
UrlClickEvents Safe Links verdicts when users click URLs in emails, Teams, or Office apps Defender for Office 365 (Plan 1 / Plan 2)
IdentityLogonEvents, IdentityDirectoryEvents On-prem Active Directory / AD FS logins and directory changes Defender for Identity (sensors on DCs / AD FS)
AlertInfo, AlertEvidence Cross-product alerts and involved users, IPs, files, and URLs Included in Microsoft Defender XDR

Because Entra ID and Azure RBAC use separate planes, M365 teams frequently forget Azure Monitor altogether. Yet every Azure subscription and management group emits AzureActivity logs with 90 days of free built-in retention—zero SIEM required to read them in the portal.

Whenever an attacker compromises a Global Administrator, toggles access elevation to grant themselves the User Access Administrator role at the root scope (/), grants themselves Owner on a subscription, reads Key Vault secrets, or wipes Azure backups and storage accounts (as documented in cloud extortion campaigns like Storm-0501), AzureActivity is where those subscription-level role assignments and destructive operations appear.

Think of Log Analytics / Microsoft Sentinel not as a primary telemetry generator, but as the consolidation layer where your Entra, Purview, Defender, and Azure logs sit side by side—and where you actually control retention beyond Microsoft's 7-to-30-day defaults.

Two nuances matter enormously for budget and coverage:

  1. The "free OfficeActivity connector" trap. Connecting Microsoft 365 to Sentinel (OfficeActivity), ingesting AzureActivity, and ingesting Defender product alerts (SecurityAlert) are free of ingestion charges10. However, the Sentinel Office 365 connector only streams four UAL record types: Exchange, SharePoint, AzureActiveDirectory, and General (including Teams). It does not ingest MailItemsAccessed—meaning you cannot determine which emails an attacker read from OfficeActivity alone and must still query Purview UAL directly—nor does it include Copilot interactions (CopilotInteraction), Power Platform / Copilot Studio events, Purview DLP, or eDiscovery actions.

  2. Choosing the right Log Analytics / Sentinel table plan3:

    • Analytics tier: includes 90 days of interactive retention when Sentinel is enabled on the workspace (extendable up to 2 years). Supports scheduled KQL analytics rules, fast joins, and UEBA.
    • Basic / Auxiliary Logs tier: discounted ingestion for high-volume, chatty streams where you rarely need 5-minute scheduled alert rules—ideal candidates are MicrosoftGraphActivityLogs and bulk AADNonInteractiveUserSignInLogs if budget is tight.
    • Archive / Sentinel Data Lake: low-cost cold retention up to 12 years for compliance and delayed incident response (e.g., investigating a fraud reported four months after the initial compromise).
    • Defender XDR raw tables: unlike SecurityAlert (free), streaming raw Defender XDR hunting tables into Sentinel incurs normal ingestion charges; keep their retention aligned with what you actually hunt past Defender's built-in 30 days3.

Which log to open first (mapped to the Attack Matrix)

Starting points for the key techniques covered in the attack matrix, along with the exact fields or events to inspect first.

Technique Open first What to look for
Tenant and domain discovery No tenant log Passive external recon (openid-configuration, getuserrealm.srf) leaves no tenant event
Brute forcing & credential stuffing Entra SigninLogs + AADNonInteractiveUserSignInLogs High error counts (50126, 50053, 50056) spread across accounts from rotating IPs
Spearphishing Defender EmailEvents & UrlClickEvents (or Exchange Message Trace) Malicious sender/URL delivery, ZAP status, and who actually clicked
Direct Send abuse Exchange Message Trace / Defender EmailEvents Unauthenticated inbound SMTP hitting your MX while spoofing an internal address (SPF/DMARC failures)
AiTM phishing Entra SigninLogs + AADNonInteractiveUserSignInLogs Same SessionId or CorrelationId hopping between victim IP and unfamiliar IP/ASN
Device code phishing Entra SigninLogs + AADNonInteractiveUserSignInLogs AuthenticationProtocol == "deviceCode" targeting Office/Azure CLI client IDs
ConsentFix Entra SigninLogs + AADNonInteractiveUserSignInLogs Standard business user suddenly getting tokens for Microsoft Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46)
Malicious OAuth application Entra AuditLogs (Consent to application) App ID, granted Graph scopes (Mail.Read, offline_access), and publisher verification status
Teams vishing Purview UAL (Teams) + Defender UrlClickEvents External tenant federation chats/calls followed rapidly by Remote Help / Quick Assist / MFA activity
Golden SAML Entra SigninLogs + ADFSSignInLogs / MDI Unexplained federated token claims missing a matching AD FS issuance event or anomalous ImmutableId logins
Device registration & PRT Entra AuditLogs + DeviceEvents Add registered owner to device / Add device closely trailing a suspicious login
MFA settings Entra AuditLogs (Update user, Security info) New Authenticator app, FIDO2 key, phone number, or Temporary Access Pass added from an anomalous IP
Conditional Access settings Entra AuditLogs (Policy category) CA policy disabled/modified, user/group excluded, or attacker IP added to Trusted Named Locations
AI agents and connectors Purview UAL (Power Platform) + Entra AuditLogs Copilot Studio agent created, published without auth, or shared with maker credentials enabled
Actor tokens Entra AADServicePrincipalSignInLogs + MicrosoftGraphActivityLogs First-party app identities acting for users with missing interactive/non-interactive user trace
Audit & log export tampering Purview UAL + Entra AuditLogs + AzureActivity Set-MailboxAuditBypassAssociation, Set-AdminAuditLogConfig, or Diagnostic Settings deletion
Infostealers and token theft Entra SigninLogs + AADNonInteractiveUserSignInLogs + MDE Stolen session cookie replayed days later from a new IP/OS without a fresh MFA prompt
Users, apps & groups enumeration MicrosoftGraphActivityLogs + AADGraphActivityLogs Burst of GET requests to /users, /servicePrincipals, /directoryRoles from one identity
Hiding emails Purview UAL (OfficeActivity) / New-InboxRule New-InboxRule, Set-InboxRule, UpdateInboxRules, or Set-Mailbox forwarding rules
Beyond the tenant (GDAP / Azure) Entra SigninLogs (Cross-tenant) + AuditLogs + AzureActivity MSP/GDAP operator logins, cross-tenant sync pushes, and root-scope User Access Administrator elevation
Microsoft Graph & Copilot Purview UAL (CopilotInteraction) + MicrosoftGraphActivityLogs Bulk /messages / /search Graph calls or Copilot prompts digging for passwords and payment threads
AI agent hijacking Purview UAL (CopilotInteraction & connectors) Agent reading external email/SharePoint form right before triggering an unexpected Outlook/CRM write action
Business Email Compromise Purview UAL (MailItemsAccessed, inbox rules) + Message Trace Bind/Sync reads paired with sent emails deleted from Sent Items
Extortion & mass wipe (Intune) Intune Audit Logs + AzureActivity + SharePoint UAL Fleet-wide Wipe/Retire actions, Azure backup/storage deletion, and bulk SharePoint downloads

My pre-incident readiness checklist

Before a crisis ever happens, these six checks are what I look at first during any tenant audit—drawn largely from Microsoft's incident response playbooks6 and field incidents where logs came up short:

  1. Confirm Unified Audit Log search and mailbox auditing are active (AuditDisabled : False), and check Get-MailboxAuditBypassAssociation to make sure no admin or service account quietly has bypass turned on.
  2. Verify Entra Diagnostic Settings export—at minimum SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs, and AuditLogs—alongside AzureActivity if the tenant runs Azure subscriptions.
  3. Turn on MicrosoftGraphActivityLogs (and AADGraphActivityLogs) export as soon as Entra ID P1/P2 is present, because zero history exists before you flip that switch.
  4. Align retention with realistic detection time. In SMEs without a 24/7 SOC, BEC and dormant OAuth apps are frequently discovered 60 to 120 days later—a 30-day default leaves you blind.
  5. Pre-assign read roles (Security Reader) on Entra ID, Microsoft Defender, Purview, and Log Analytics to the people who will triage incidents, rather than fighting PIM or MFA setup mid-breach.
  6. Actually query every source once. I have seen too many workspaces with a broken connector or missing MailItemsAccessed permissions discovered only on the day an investigator needed them.

What I deploy in the field (by license and budget)

In practice, designing log collection comes down to a simple question: how far back do we want to be able to investigate without blowing up the Azure bill on high-volume tables? Here is how I set things up across the three customer profiles I see most often:

  • Business Premium or E3, without a SIEM (Entra ID P1 included) You don't need a full SIEM to avoid the 30-day cliff on identity logs. I deploy a standalone Log Analytics workspace (without enabling Sentinel, so you only pay basic Log Analytics ingestion/retention) or an immutable Azure Storage Account to collect the Entra ID logs (SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AuditLogs) alongside AzureActivity. For the workload side, Purview Audit Standard gives you 180 days and Exchange Extended Message Trace covers 90 days of mail flow—for an SMB, the Azure bill stays at a few euros a month.

  • M365 E3 / Entra ID P1–P2, with Microsoft Sentinel Start with the free connectors (OfficeActivity, AzureActivity, and SecurityAlert). Keep the low-volume, high-signal identity tables (SigninLogs, AuditLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs) in the Analytics tier so you have 90+ days of hot retention and real-time KQL rules. The real budget question is what to do with AADNonInteractiveUserSignInLogs and MicrosoftGraphActivityLogs (plus AADGraphActivityLogs), which easily represent 80% of the volume: if the budget is tight, put MicrosoftGraphActivityLogs in Basic / Auxiliary Logs (with Archive for long-term retention) rather than turning it off, and remember that MailItemsAccessed still has to be queried in Purview UAL since OfficeActivity doesn't ingest it.

  • Microsoft 365 E5, with Defender XDR and Sentinel With E5, Purview Audit (Premium) already keeps Exchange (MailItemsAccessed), SharePoint, OneDrive, and Entra audit records for a full year, and Defender XDR gives you 30 days of Advanced Hunting across all workloads. When you connect Defender XDR to Sentinel to keep hunting data beyond 30 days, E5 includes a 5 MB/user/day data grant on Defender XDR tables10—but watch out for two classic traps:

    1. Don't ingest Entra sign-ins twice: if you already collect SigninLogs and AADNonInteractiveUserSignInLogs through the Entra ID connector, do not also forward EntraIdSignInEvents and EntraIdSpnSignInEvents from the Defender XDR connector into Sentinel.
    2. Don't burn the 5 MB/user/day grant on raw endpoint noise: forwarding email, identity, and cloud app tables (EmailEvents, UrlClickEvents, Identity*, CloudAppEvents) into Sentinel usually fits inside the E5 grant, whereas ticking raw endpoint tables like DeviceNetworkEvents or DeviceProcessEvents without filtering will eat the entire allowance and spike your bill.

If budget forces a compromise, never drop AADNonInteractiveUserSignInLogs and MicrosoftGraphActivityLogs completely—move them to Basic/Auxiliary logs or a Storage Account instead. They are the two noisiest tables in the tenant, and also the two you need first whenever an attacker replays a stolen token.

References