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

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](../attack-matrix/index.md) 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)[^2] |
| **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)[^3][^9] |
| **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)[^4] |

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 Setting[^1][^6].

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

==- 1. Microsoft Entra ID: sign-ins, audit, and Graph activity logs

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 center[^5].

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 tenant[^5][^6]. 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.

==- 2. Microsoft Purview: Unified Audit Log (UAL) & mailbox auditing

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)[^2].
* **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 available[^2]. 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:

   ```powershell
   Get-OrganizationConfig | Format-List AuditDisabled
   ```

   You want `AuditDisabled : False`[^8]. 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** users[^7], **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`).

==- 3. Exchange Online Message Trace: your lifeline without Defender for Office 365

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.

==- 4. Microsoft Defender XDR: Advanced Hunting & license dependencies

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 days**[^3][^9]. 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 tenant[^10]:

| 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** |

!!! Special note
Microsoft removed `AADSignInEventsBeta` and `AADSpnSignInEventsBeta` from the Advanced Hunting schema in **December 2025**, replacing them with `EntraIdSignInEvents` and `EntraIdSpnSignInEvents`[^11]. Any older KQL query copied from a repository or blog post referencing those `*Beta` names will fail until updated.
!!!

==- 5. Azure Activity Logs: catching the pivot from Entra ID to Azure

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.

==- 6. Microsoft Sentinel, Log Analytics & Storage Accounts: retention, tiers, and the OfficeActivity trap

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 charges**[^12]. **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 plan**[^4]:
   * **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 days[^3][^4].

===

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

Starting points for the key techniques covered in the [attack matrix](../attack-matrix/index.md), along with the exact fields or events to inspect first.

| Technique | Open first | What to look for |
|:--- |:--- |:--- |
| [Tenant and domain discovery](../attack-matrix/index.md#tenant-and-domain-discovery) | *No tenant log* | Passive external recon (`openid-configuration`, `getuserrealm.srf`) leaves no tenant event |
| [Brute forcing & credential stuffing](../attack-matrix/index.md#bruteforcing-and-credentials-stuffing) | Entra `SigninLogs` + `AADNonInteractiveUserSignInLogs` | High error counts (`50126`, `50053`, `50056`) spread across accounts from rotating IPs |
| [Spearphishing](../attack-matrix/index.md#spearphishing) | Defender `EmailEvents` & `UrlClickEvents` (or Exchange Message Trace) | Malicious sender/URL delivery, ZAP status, and who actually clicked |
| [Direct Send abuse](../attack-matrix/index.md#direct-send-abuse) | Exchange Message Trace / Defender `EmailEvents` | Unauthenticated inbound SMTP hitting your MX while spoofing an internal address (`SPF`/`DMARC` failures) |
| [AiTM phishing](../attack-matrix/index.md#aitm-phishing) | Entra `SigninLogs` + `AADNonInteractiveUserSignInLogs` | Same `SessionId` or `CorrelationId` hopping between victim IP and unfamiliar IP/ASN |
| [Device code phishing](../attack-matrix/index.md#device-code-phishing) | Entra `SigninLogs` + `AADNonInteractiveUserSignInLogs` | `AuthenticationProtocol == "deviceCode"` targeting Office/Azure CLI client IDs |
| [ConsentFix](../attack-matrix/index.md#consentfix) | Entra `SigninLogs` + `AADNonInteractiveUserSignInLogs` | Standard business user suddenly getting tokens for *Microsoft Azure CLI* (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) |
| [Malicious OAuth application](../attack-matrix/index.md#malicious-oauth-application) | Entra `AuditLogs` (`Consent to application`) | App ID, granted Graph scopes (`Mail.Read`, `offline_access`), and publisher verification status |
| [Teams vishing](../attack-matrix/index.md#teams-vishing) | Purview UAL (Teams) + Defender `UrlClickEvents` | External tenant federation chats/calls followed rapidly by Remote Help / Quick Assist / MFA activity |
| [Golden SAML](../attack-matrix/index.md#goldensaml) | Entra `SigninLogs` + `ADFSSignInLogs` / MDI | Unexplained federated token claims missing a matching AD FS issuance event or anomalous `ImmutableId` logins |
| [Device registration & PRT](../attack-matrix/index.md#device-registration-and-primary-refresh-token) | Entra `AuditLogs` + `DeviceEvents` | `Add registered owner to device` / `Add device` closely trailing a suspicious login |
| [MFA settings](../attack-matrix/index.md#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](../attack-matrix/index.md#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](../attack-matrix/index.md#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](../attack-matrix/index.md#actor-tokens) | Entra `AADServicePrincipalSignInLogs` + `MicrosoftGraphActivityLogs` | First-party app identities acting for users with missing interactive/non-interactive user trace |
| [Audit & log export tampering](../attack-matrix/index.md#audit-and-log-export-tampering) | Purview UAL + Entra `AuditLogs` + `AzureActivity` | `Set-MailboxAuditBypassAssociation`, `Set-AdminAuditLogConfig`, or Diagnostic Settings deletion |
| [Infostealers and token theft](../attack-matrix/index.md#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](../attack-matrix/index.md#users-apps-and-groups-enumeration) | `MicrosoftGraphActivityLogs` + `AADGraphActivityLogs` | Burst of GET requests to `/users`, `/servicePrincipals`, `/directoryRoles` from one identity |
| [Hiding emails](../attack-matrix/index.md#hiding-emails) | Purview UAL (`OfficeActivity`) / `New-InboxRule` | `New-InboxRule`, `Set-InboxRule`, `UpdateInboxRules`, or `Set-Mailbox` forwarding rules |
| [Beyond the tenant (GDAP / Azure)](../attack-matrix/index.md#beyond-the-tenant) | Entra `SigninLogs` (Cross-tenant) + `AuditLogs` + `AzureActivity` | MSP/GDAP operator logins, cross-tenant sync pushes, and root-scope `User Access Administrator` elevation |
| [Microsoft Graph & Copilot](../attack-matrix/index.md#microsoft-graph-and-copilot) | Purview UAL (`CopilotInteraction`) + `MicrosoftGraphActivityLogs` | Bulk `/messages` / `/search` Graph calls or Copilot prompts digging for passwords and payment threads |
| [AI agent hijacking](../attack-matrix/index.md#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](../attack-matrix/index.md#business-email-compromise-and-fraud) | Purview UAL (`MailItemsAccessed`, inbox rules) + Message Trace | `Bind`/`Sync` reads paired with sent emails deleted from *Sent Items* |
| [Extortion & mass wipe (Intune)](../attack-matrix/index.md#mass-device-wipe-with-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 playbooks[^8] 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 tables[^12]—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

[^1]: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
[^2]: https://learn.microsoft.com/en-us/purview/audit-solutions-overview
[^3]: https://learn.microsoft.com/en-us/defender-xdr/data-privacy#data-retention
[^4]: https://learn.microsoft.com/en-us/azure/sentinel/log-plans
[^5]: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-diagnostic-settings-logs-options
[^6]: https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview
[^7]: https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts
[^8]: https://learn.microsoft.com/en-us/security/zero-trust/security-operations-playbook-phishing
[^9]: https://learn.microsoft.com/en-us/defender-office-365/mdo-data-retention
[^10]: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-tables
[^11]: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes
[^12]: https://learn.microsoft.com/en-us/azure/sentinel/billing#free-data-sources