Most M365 tenants are configured to detect threats that Microsoft decided are worth detecting. The gaps — the attacks Microsoft does not build detection rules for — are invisible until an incident exposes them.
This is not a criticism of Microsoft's detection capabilities. Defender XDR and Sentinel provide hundreds of built-in detections. The problem is that organizations treat those built-in detections as complete coverage. They are not. They are a starting point that covers the most common attack patterns and leaves everything else to you.
Where the gaps are
Three categories of activity consistently lack built-in detection in default M365 configurations:
Legitimate feature abuse. Inbox rules, mail flow rules, OAuth application consent, SharePoint sharing permissions, Teams external access — these are business features that attackers exploit. Microsoft cannot ship rules that alert on every inbox rule creation or every OAuth consent because the false positive rate would be unmanageable. The detection requires organizational context: which users normally create forwarding rules, which applications are approved for consent, which SharePoint sites should never be shared externally.
Slow-burn attacks. Built-in detections are optimized for speed — detecting an attack in progress. Attacks that unfold over days or weeks evade time-window-based rules. An attacker who accesses a mailbox once per day for two weeks, reading 10 emails each session, does not trigger volume-based alerts. Detecting this requires baseline comparison over time, which requires custom analytics rules with longer lookback periods.
Cross-workload attack chains. An attacker compromises an identity in Entra ID, uses it to access a mailbox in Exchange Online, downloads files from SharePoint, and exfiltrates through OneDrive. Each step uses a different M365 workload. Built-in detections in each workload see their piece. No built-in detection correlates the full chain across workloads. Defender XDR's incident correlation helps, but the correlation is only as good as the individual alerts feeding it — if the individual steps do not trigger alerts, no correlation occurs.
What visibility actually requires
Fixing the visibility problem is not about buying more products. It is about configuring what you already have.
Audit logging. Unified audit logging must be enabled — it is on by default in most tenants, but verify it. Mailbox auditing must cover MailItemsAccessed events, which requires E5 licensing. Without MailItemsAccessed, you cannot determine whether an attacker read emails in a compromised mailbox. This single audit event is the difference between "the account was compromised" and "the attacker read emails containing customer PII" — which is the difference between a security incident and a reportable data breach.
Log retention. Default retention for many M365 log sources is 30 days. Sign-in logs, audit logs, and Defender data expire. If you investigate an incident discovered on day 31, the evidence is gone. Sentinel ingestion with 90-day or longer retention is the fix, but the data connector configuration determines which logs flow to Sentinel. Most organizations enable the Entra ID and M365 connectors but miss Exchange Online audit logs, SharePoint access logs, and Teams activity.
Custom detection rules. The built-in detections are the floor, not the ceiling. Five custom analytics rules can close the most exploited gaps:
A rule that detects inbox rules created through non-Outlook clients — catching API-based rule creation that attackers use because it bypasses the user's visible rule list.
A rule that detects OAuth application consent for applications not on your approved list — catching consent phishing before the application accesses data.
A rule that detects bulk file downloads from SharePoint or OneDrive above a threshold — catching data staging for exfiltration.
A rule that detects new MFA method registration following a sign-in from a non-trusted location — catching post-AiTM persistence.
A rule that detects privileged role assignment in Entra ID outside of PIM — catching privilege escalation through direct role assignment.
These five rules take less than a day to write, test, and deploy. They cover attack patterns that appear in the majority of M365 compromises investigated by incident responders. They are not theoretical — they are derived from real investigations where the absence of these detections delayed discovery.
The audit you should run this week
Open your Sentinel workspace. Count the active analytics rules. Subtract the Microsoft-provided templates you enabled without modification. The remainder is your organization's custom detection capability.
If the number is zero, your detection posture is entirely dependent on Microsoft's judgment about what is worth detecting in your environment. Microsoft does not know your environment. They do not know which users handle sensitive financial data, which applications are approved for OAuth consent, which SharePoint sites contain regulated information, or which external domains your organization legitimately communicates with.
Check your data connectors. Are Exchange Online audit logs flowing to Sentinel? SharePoint access logs? Teams activity? If only Entra ID sign-in logs and Defender alerts are ingested, entire workloads are invisible to your detection rules.
Check your audit configuration. Is MailItemsAccessed being logged? Are you on E5, or do you have the compliance add-on that enables it? Without it, every email compromise investigation will hit the same wall: you can prove the account was accessed but not what the attacker read.
The Ridgeline Detection Engineering course covers building the custom detection rules that close these gaps, and the Endpoint Security course covers the endpoint telemetry configuration that feeds them. Both include free foundation modules — start with the detection gap analysis in DE0.