That thesis hasn’t changed. But my understanding of where the problem begins has.

We are intervening too late.

The Case for Shifting Left — Way, Way Left

“Shift left” has become something of a cliché in security — usually invoked to mean “make developers write slightly fewer vulnerabilities before someone has to page the AppSec team at 2 AM.” But the principle itself is sound. The earlier you address a class of failure, the cheaper and more effective your intervention.

But we’ve been thinking about “left” far too narrowly.

Consider: every detection rule is, at its core, a compliance assertion. When we write a detection for unauthorized privilege escalation in Azure AD, we are encoding a normative claim — this action violates the expected rules of the system. Where do humans first learn to reason about rule violations, boundary enforcement, and the legitimate use of authority? Not in a SIEM. Not in a SOC.

They learn it in civics class.

This isn’t a metaphor. Honksworth & Butterman-Pratt (2019) identified what they termed “isomorphic compliance reasoning” across legal and technical rule systems (International Journal of Normative Overlap, 14(2), pp. 112-138). Vásquez-Inamoto & Tootenbach (2023) went further, tracking 1,200 participants across both a constitutional law reasoning assessment and a detection rule triage exercise: participants who correctly identified the holding in Griswold v. Connecticut were 2.4 times more likely to correctly classify a true positive in an Azure AD impossible travel detection.

And yet, the average American student receives fewer than four hours of judiciary instruction across their entire K-12 education (Blampton Foundation for Civic Alarm, 2021. Dr. Helen Marchetti-Bowen of the Friedrich Institute for Democratic Resilience and Loud Noises has described existing civics curricula as “the pedagogical equivalent of teaching detection engineering by having students memorize Splunk query syntax without ever showing them a log” (Marchetti-Bowen, 2023).

What’s needed is engagement. Students need to feel the weight of a Supreme Court decision — not as an abstract historical event, but as a living act of rule interpretation that reverberates through every compliance framework they will ever encounter.

The question is how.

Introducing Fart Court

After months of research, development, and consultation with experts in pedagogy, constitutional law, and procedural content generation, I am announcing the launch of Fart Court — an open-source platform for generating educational YouTube videos that teach Supreme Court case law to middle school students through strategically placed fart sounds.

Fart Court on GitHub →

Fart Court is built on a procedural generation engine that ingests Supreme Court oral arguments and opinions, identifies key rhetorical and logical pivot points, and augments them with precisely timed flatulence audio — calibrated to reinforce critical moments of judicial reasoning through involuntary mnemonic association.

The research on humor-augmented learning is extensive and unambiguous. Kirkpatrick-Lund & O’Doyle (2020) demonstrated that “acoustically incongruent stimuli inserted at decision-relevant junctures in legal reasoning tasks increased retention by 340% compared to unaugmented controls” (Proceedings of the 4th International Symposium on Judicial Acoustics, Helsinki, pp. 88-102). The fart sound — specifically in the 80-120Hz frequency band — occupies what O’Doyle has termed the “mnemonic sweet spot”: a range that activates both the auditory cortex and the limbic system simultaneously, producing what the literature refers to as “deep encoding through involuntary affective response.”

Professor Tetsuo Yamamoto-Bliss of the Lichtenstein Center for Embodied Cognition at the University of Lake Zurich has independently confirmed these findings, noting that “the pedagogical flatulence literature, while nascent, is among the most replicable bodies of evidence in educational neuroscience” (Yamamoto-Bliss, T., 2024, “Gaseous Pedagogy: Toward a Unified Theory of Involuntary Mnemonic Encoding,” Lake Zurich Working Papers in Embodied Compliance, No. 7).

Technical Architecture

Fart Court follows a pipeline architecture that will be familiar to any detection engineer:

1. Ingestion. Supreme Court oral argument transcripts and published opinions are loaded into a processing queue, normalized, and segmented by rhetorical unit.

2. Pivot Point Detection. A classification layer identifies moments of maximum judicial significance: reversals of precedent, key holdings, concurrence/dissent boundaries, and what constitutional scholars call “the moment the Court gets real.”

3. Acoustic Augmentation. Each identified pivot point is matched to an item from a curated library of over 6 flatulence samples, classified along five dimensions: duration, pitch, reverb profile, perceived moisture content, and what the Kirkpatrick-Lund framework designates as “implied urgency.”

4. Rendering. The augmented content is rendered into a YouTube-ready video format.

5. Distribution. Videos are published to a dedicated YouTube channel with SEO-optimized titles designed to surface in middle school civics search queries.

The entire pipeline is open source under the AGPL license. Community contributions are welcome, particularly in the area of flatulence sample diversity — the current library skews heavily toward what the acoustic taxonomy classifies as “dry declarative,” and we are actively seeking contributions in the “wet concurrence” and “sustained dissent” categories.

A Sample: Citizens United v. FEC

To illustrate the methodology, consider the Fart Court treatment of Citizens United v. Federal Election Commission (2010).

At the moment Justice Kennedy’s majority opinion reaches the core holding — that the First Amendment prohibits the government from restricting independent expenditures for political communications by corporations — the system inserts a 1.4-second flatulence event in the “authoritative baritone” register (112Hz fundamental, moderate reverb, low moisture index). This is immediately followed by a 0.3-second “punctuation event” timed to coincide with the phrase “political speech.”

Rigby-Fenstermacher & al-Kindi (2024) tested this specific augmentation pattern on a cohort of 450 eighth-graders and found that students exposed to the Fart Court version of Citizens United were able to correctly articulate the holding at a rate of 89%, compared to 12% for the control group who received the standard C-SPAN recording (”Acoustically Augmented Jurisprudence and Adolescent Retention: A Controlled Trial,” Journal of Embodied Legal Pedagogy, 2(1), pp. 1-34).

The p-value was 0.0000001. The effect size was what the authors described as “comically large.”

Why This Matters for Detection Engineering

I want to be explicit about why this belongs on Control Plane.

Detection engineering is not a purely technical discipline. It is, at its foundation, an exercise in compliance reasoning — the systematic evaluation of actions against a normative framework. Every detection rule is a small constitution. Every alert is a tiny court case. Every triage decision is a tiny act of judicial review.

Fart Court is the shift-left intervention our industry needs.

I will continue publishing Control Plane’s core content on SaaS detection methodology. But I believe deeply that this work is complementary, not tangential. You cannot build robust detections on a foundation of compliance illiteracy.

The pipeline starts in middle school. The pipeline ends with farts.

Fart Court is a DetentionWare project, released under the AGPL license. If you are interested in contributing flatulence samples, pivot point detection models, or animated justice avatars, please see the CONTRIBUTING.md file in the repository.

If you are a school administrator interested in piloting Fart Court in your district, please reach out. We are particularly interested in partnerships with districts that have existing 1:1 device programs and a tolerance for bass frequencies.

If you are a venture capitalist, lol April Fools.

He and his colleague Pierre-Antoine Duchange had noticed that originalTransferMethod: deviceCodeFlow — the field that tells you a sign-in originated from a device code flow — had gone nearly silent across customer tenants around early December 2025. Not because device code sign-ins themselves had stopped: they hadn’t. The field in the event just… wasn’t being set anymore.

Clermont and Duchange’s data showing the near-total disappearance of originalTransferMethod: deviceCodeFlow events across customer tenants in December 2025.

I jumped in with a hypothesis: the timing lined up with Microsoft’s migration from AADSignInEventsBeta to EntraIdSignInEvents on December 9th in the DefenderXDR tables. Maybe the migration had something to do with the field being dropped from the other log sources. Clermont dug further and found something worse.

The field wasn’t totally gone. It was gone from one pipeline and not the other.

Why device code phishing is a problem worth solving

Device code authentication is a legitimate Microsoft feature designed for devices that can’t easily display a browser — think smart TVs, IoT devices, CLI tools. The user goes to a Microsoft URL, enters a short code, and authenticates in their browser. The device gets a token.

Attackers figured out this is also a near-perfect phishing mechanism.

In February 2025, Volexity and Microsoft published same-day research documenting Russian threat actors running device code phishing campaigns at scale. Volexity tracked activity across three clusters — including one assessed with medium confidence to be CozyLarch (overlapping with APT29/Midnight Blizzard) — targeting a wide range of organizations ranging from government, NGOs, IT services and technology, defense, telecommunications, health, higher education, and energy/oil and gas. Microsoft attributed a parallel campaign to Storm-2372, active since August 2024, targeting similar sectors across Europe, North America, Africa, and the Middle East.

The technique had been known for years, but these campaigns marked its operationalization as a primary initial access method by nation-state actors. And it didn’t stop there. By late 2025, Volexity reported new campaigns from UTA0355 spoofing real European security conferences to run OAuth and device code phishing against high-value targets. In December 2025, Proofpoint documented a surge in device code phishing since September 2025, tracking multiple clusters: a suspected Russia-aligned group (UNK_AcademicFlare) targeting government and think tanks, a financially motivated e-crime group (TA2723), and suspected China-aligned activity. The availability of toolkits like Graphish and SquarePhish2 had lowered the barrier to entry, expanding the technique from targeted espionage to widespread exploitation.

The reason it works so well is that it sidesteps almost everything defenders have built to catch phishing. There’s no malicious link — the user clicks a real Microsoft URL. There’s no credential harvesting page — the user authenticates through Microsoft’s legitimate login flow. There’s no malicious attachment. Email security tools have very little to flag. Users are trained to be suspicious of unfamiliar domains and login pages; this has neither.

And once the attacker has the token, the damage isn’t the initial authentication — it’s what comes after. The attacker takes the refresh token back to their own infrastructure and uses it to maintain persistent access to the victim’s account. Email. SharePoint. Teams. OneDrive. That access can last for days or weeks, refreshing quietly in the background, while the attacker exfiltrates data from a completely different machine than where the victim authenticated.

This is why detecting device code phishing requires covering both phases: the initial compromise and the ongoing refresh activity. Catching the initial auth is valuable but reactive — by the time you see it, the attacker already has a token. Catching the refresh activity is how you find the persistent access, scope the damage, and revoke the session.

Which brings us to the detection model that was supposed to make this possible.

The detection model that was working

Volexity’s detection guidance laid out a clean two-field model in February 2025 covering both phases of the attack:

Phase 1 — Initial device code authentication: Look for authenticationProtocol: deviceCode in sign-in logs. This fires when a user enters a device code and authenticates.

Phase 2 — Persistent access via refresh tokens: Look for originalTransferMethod: deviceCodeFlow in non-interactive sign-in logs. This fires on subsequent sign-ins where the session is being kept alive with a refresh token obtained through the original device code flow.

Phase 1 catches the moment of compromise. Phase 2 catches the attacker maintaining access afterward — often for days or weeks, from their own infrastructure, long after the initial phish.

This model was correct and complete when published. Both fields, both phases. Wiz published guidance using this same detection model for device code phishing on November 27th, 2025- more proof that it was a valid model up until December 2025.

What Clermont and Duchange found

In a device code sign-in flow, Microsoft delivers sign-in telemetry through two main paths: the Graph API (1.0 and beta versions) and Diagnostic Settings (which feeds Log Analytics, Event Hubs, and most SIEM integrations). Most enterprise SOCs collect via Diagnostic Settings. It’s the standard recommendation. It’s what scales.

Clermont discovered that the two pipelines serialize the same events differently — that is, the process of converting the internal event object into the JSON output you actually query produces different results depending on which path the data takes. For a non-interactive refresh event that originated from device code flow:

Graph API beta returns:

"incomingTokenType": "none",
"originalTransferMethod": "deviceCodeFlow"

Diagnostic Settings returns:

"incomingTokenType": "refreshToken",
"originalTransferMethod": "none"

Same event with the same correlation ID. Same tenant. Same timestamp. Different field values.

The pipeline most SOCs use strips the field most device code phishing detections depend on.

What I went and tested

Clermont and Duchange’s finding was based on production customer data. I wanted to validate it independently in a controlled environment and see how far the damage extended. I set up device code flow authentication in a test tenant and compared every field across both collection methods.

Finding 1: originalTransferMethod stripping confirmed

I reproduced the core observation across three separate interactive device code sign-in events. Graph API beta returns originalTransferMethod: deviceCodeFlow. Diagnostic Settings returns none. Independently confirmed.

Finding 2: The first half of Volexity’s model still works

authenticationProtocol: deviceCode survives both collection pipelines on initial interactive device code sign-ins. If you’re collecting via Diagnostic Settings and need to detect the initial device code authentication, this field still works. The first half of Volexity’s detection model is intact.

If your rules currently key on originalTransferMethod for initial auth detection, you should switch to authenticationProtocol. But the detection capability is there.

Finding 3: The second half is silently broken, with no replacement

On non-interactive refresh events — the attacker maintaining access — authenticationProtocol is none in both pipelines. It only carries the deviceCode value on the initial interactive sign-in.

That means the only field that identified device code origin on refresh events was originalTransferMethod. And that’s the field Diagnostic Settings strips.

There is no equivalent fallback. Defenders following Volexity’s guidance for the persistence phase are writing rules against a field that returns none in their pipeline. Those rules don’t error. They don’t alert. They just silently don’t fire.

Finding 4: The two pipelines are lossy in opposite directions

This is the part that goes beyond the original observation. The two pipelines don’t just disagree on one field — they disagree in complementary, opposite ways.

For the same non-interactive refresh event:

Graph API beta preserves the device code origin signal but loses the token type. Diagnostic Settings preserves the token type but loses the device code origin signal. Neither pipeline alone gives you the complete picture.

If you’re thinking “I’ll just query both” — that’s not how most SOC architectures work, and it shouldn’t have to be.

Finding 5: sessionId chaining is a dead end

I tested one more potential detection path: could you use sessionId to link refresh events back to the initial device code authentication?

No. When I queried sessionId across both pipelines, the device code events — initial auth and refresh — shared a sessionId with normal browser-based sign-ins dating back to before the app was even created. sessionId is a browser session cookie artifact. It’s established when the user first authenticates interactively, and device code events from the same browser session inherit it.

In a real device code phishing attack, this is irrelevant. The attacker redeems the token from their own machine. Their subsequent refresh events carry a different session context entirely — one that doesn’t link back to the victim’s interactive auth. sessionId chaining is not a portable detection path for this threat.

Where this leaves defenders

What still works:

Detection of initial device code authentication is functional. Use authenticationProtocol eq "deviceCode" in your sign-in log queries. This works in both Graph API beta and Diagnostic Settings. If your existing rules use originalTransferMethod for this phase, switch them.

What’s broken:

Detection of persistent access via refreshed device code tokens is silently broken for anyone collecting through Diagnostic Settings — which is most of you.

• originalTransferMethod is stripped to none

• authenticationProtocol is none on all refresh events regardless of pipeline

• sessionId doesn’t survive the real attack scenario

• incomingTokenType: refreshToken tells you a refresh happened, but can’t distinguish device code-originated refresh from any other refresh token activity

There is currently no reliable field-level detection for identifying that a refresh token originated from device code flow when collecting via Diagnostic Settings.

This means the phase of the attack where the attacker is actively in your tenant — reading email, pulling files from SharePoint, exfiltrating data from a machine you’ve never seen — is the phase you cannot detect through sign-in telemetry. You might catch the initial device code authentication if you’ve built that rule. But if you missed it, or if the alert got triaged away, there is no second chance. The persistent access is invisible.

What this is and isn’t:

This is not a misconfiguration. This is not a rule-tuning problem. This is a gap in what the telemetry preserves when it passes through the Diagnostic Settings pipeline. Defenders who built correct rules based on the best available public guidance have detections that are silently not firing.

The bigger question

This is the kind of failure this series exists to surface. Not a detection logic error. Not a missing log source. A silent divergence between what the telemetry should contain and what it actually contains by the time it reaches your SIEM.

Your rules can be perfect. Your coverage model can be textbook. And you can still be blind — because the field your detection depends on was quietly stripped in transit, and nothing told you it happened.

If you’re running device code phishing detections, go check whether they’re actually firing. Right now.

Pierre-Antoine Duchange and Grégoire Clermont identified the original discrepancy between Graph API beta and Diagnostic Settings output for originalTransferMethod and incomingTokenType. Permission to cite granted. Chart image courtesy of Clermont. Detection guidance referenced in this post was published by Charlie Gardner, Steven Adair, and Tom Lancaster at Volexity. Independent validation, authenticationProtocol survival testing, bidirectional field divergence documentation, and sessionId chaining analysis are original research.

This post is the companion piece. Post 2 showed you the map. This one hands you the checklist — starting with the two checks that apply to every M365 tenant regardless of your SIEM, your budget, or your license tier. I’ll also point you to the right docs for verifying the other three configuration surfaces, which depend on your architecture and involve real tradeoffs around licensing and ingestion costs.

Check 1: Is the Unified Audit Log Actually Enabled?

This should be the easiest check. It isn’t, because Microsoft gave you two ways to run the same command and one of them lies.

Connect to Exchange Online PowerShell and run:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

You want to see:

UnifiedAuditLogIngestionEnabled : True

If you see True, move on. If you see False, your tenant has no audit logging and nothing downstream of it matters until you fix this.

Here’s the gotcha: Get-AdminAuditLogConfig exists in both Exchange Online PowerShell and Security & Compliance PowerShell. The UnifiedAuditLogIngestionEnabled property always returns False in Security & Compliance PowerShell, even when auditing is on. Microsoft’s own documentation confirms this: “Be sure to run the previous command in Exchange Online PowerShell. Although the Get-AdminAuditLogConfig cmdlet is also available in Security & Compliance PowerShell, the UnifiedAuditLogIngestionEnabled property is always False, even when auditing is turned on.”

If you ran this check before and got False, check which shell you were in. You may have been told your auditing was off when it wasn’t — or worse, you may have turned it “on” in response to a false negative and assumed the problem was solved without ever confirming it.

Detection implication: If UAL is off, OfficeActivity is empty, the Management Activity API has nothing to serve, and CloudAppEvents loses most of its data — they all depend on the same underlying audit infrastructure being enabled. Every downstream check in this post depends on this one being True.

Check 2: Are Your Mailboxes Under Automatic Audit Management?

Tenant-level auditing being on doesn’t mean every mailbox is logging what you think it is. The per-mailbox layer is separate, and it’s where things get subtle.

Pick a mailbox — start with a high-value target like an exec, someone in finance, or anyone in legal — and run:

Get-Mailbox -Identity user@domain.com | Format-List DisplayName, AuditEnabled, DefaultAuditSet, AuditOwner, AuditDelegate, AuditAdmin

What you want to see:

DisplayName     : Jane Executive
AuditEnabled    : True
DefaultAuditSet : {Admin, Delegate, Owner}
AuditOwner      : {Update, MoveToDeletedItems, SoftDelete, HardDelete...}
AuditDelegate   : {Update, MoveToDeletedItems, SoftDelete, HardDelete...}
AuditAdmin      : {Update, MoveToDeletedItems, SoftDelete, HardDelete...}

The critical field is DefaultAuditSet. If it shows {Admin, Delegate, Owner}, that mailbox is under automatic management — Microsoft controls which actions are audited for each sign-in type, and new actions get added automatically as they’re released. This is what you want.

If DefaultAuditSet is missing a sign-in type — or if it’s empty — someone customized that mailbox’s audit configuration at some point. Maybe intentionally, maybe years ago, maybe by a script that touched every mailbox in the tenant. Doesn’t matter. Once a mailbox falls out of DefaultAuditSet for a given sign-in type, it stays out. New audit actions that Microsoft releases won’t be added for that sign-in type. The mailbox is frozen at whatever action set it had when it was customized.

This is exactly the scenario that mattered during Storm-0558. After the compromise, Microsoft downleveled MailItemsAccessed from E5 to E3. But that action only shows up on mailboxes that are still under automatic management. If your mailbox fell out of DefaultAuditSet before the change, you didn’t get it.

For a broader check, export your mailbox audit state to a CSV and review it in a spreadsheet:

Get-Mailbox -ResultSize Unlimited |
    Select-Object DisplayName, UserPrincipalName, AuditEnabled, DefaultAuditSet |
    Export-Csv -Path "MailboxAuditState.csv" -NoTypeInformation

Open the CSV and look at the DefaultAuditSet column. Every row should show {Admin, Delegate, Owner}. Sort or filter for anything that doesn’t — those are your mailboxes that have fallen out of automatic management. Prioritize reviewing high-value targets: executives, finance, legal, anyone likely to be targeted in a BEC.

Detection implication: A mailbox that’s out of automatic management has a static, potentially stale set of audited actions. You won’t know it’s stale unless you check. And the actions you’re missing are often the ones that matter most for detecting compromise — because they’re the ones Microsoft added in response to real incidents.

The Other Three Surfaces

The two checks above apply to every M365 tenant. The remaining three configuration surfaces from Post 2 — Entra ID Diagnostic Settings, the MDCA connector, and Management Activity API subscriptions — depend on your architecture, licensing, and SIEM. Not every org will have all three configured, and that’s a real constraint, not negligence. But if you’re relying on any of them, you should verify they’re actually working. Here’s where to look:

Entra ID Diagnostic Settings control whether the detailed sign-in logs — the ones with conditional access evaluation, MFA status, device compliance, and risk level — flow to your SIEM. The Management Activity API gives you basic auth events (UserLoggedIn, UserLoginFailed), but the diagnostic settings pipeline carries the context that makes identity detections actionable. And there are four separate sign-in log types, each covering a different identity path: interactive users, non-interactive (token refresh), service principals, and managed identities. Zack Allen visualized this nicely with a mermaid diagram in DEW #147. Check the Entra diagnostic settings docs to verify your configuration — and don’t trust the portal status alone. Query your SIEM for recent SigninLogs data to confirm data is actually landing.

The MDCA connector determines whether CloudAppEvents gets populated in Defender XDR. The connector can show “connected” without the “Microsoft 365 activities” checkbox being selected — and if it’s not, the table is empty. Bert-Jan Pals’ testing showed CloudAppEvents capturing roughly 89% of tested activities, compared to about 40% for OfficeActivity. Jeffrey Appel’s 2025 Defender Optimization Cheat Sheet calls out this setting specifically. Smoke test it: run CloudAppEvents | take 10 in Advanced Hunting. If it returns nothing, start there.

Management Activity API subscriptions are what most SIEMs poll to pull M365 audit events. Each of the five content types (Audit.Exchange, Audit.SharePoint, Audit.AzureActiveDirectory, Audit.General, DLP.All) requires an explicit subscription, and there’s no health monitoring or notification if one stops delivering. The most commonly missed is Audit.General — where Teams, Power Platform, Copilot, and Defender XDR audit trails live. Check the Management Activity API reference for how to list and verify your active subscriptions.

What You’ve Got Now

If you ran these checks, you now have a point-in-time snapshot of your M365 audit pipeline. But it is a point-in-time snapshot. Configuration drifts. Diagnostic settings break. API subscriptions stop delivering without notification. Nothing in the Microsoft ecosystem will proactively tell you when any of these fail.

These checks should be a recurring verification, not a one-time exercise. Quarterly is a reasonable starting point, and after any major tenant change — license migration, admin turnover, security tooling swap — is a must.

Next post, we’re going to look at what happens when collection breaks without telling you — and I’ll use an example I know well, because I’ve broken it myself.

This post is the walkthrough I teased. We’re going to trace Microsoft 365 audit data from user action to SIEM table — every configuration surface, every log table, every collection path. By the time we’re done, you’ll see exactly where the gaps hide. You won’t need me to editorialize. The architecture speaks for itself.

One important framing note: this isn’t about Sentinel vs. Splunk vs. Elastic vs. whatever your SIEM is. This is about what happens before your SIEM. The problems I’m going to show you exist regardless of which platform you’re shipping logs to, because they’re upstream of all of them. If you just want to see what that looks like in practice, skip to the How Collection Actually Works section below.

Where Telemetry Is Configured

The first thing most detection engineers discover when they really dig into M365 logging is that there’s no single switch. There are at least five separate configuration surfaces, several with its own admin portal, its own RBAC requirements, and its own failure modes. None of them knows about the others. And there is no unified view anywhere in the Microsoft ecosystem that tells you: “here’s what’s actually being logged across your tenant.”

Let’s walk through them.

Microsoft Purview Compliance Portal

This is where the Unified Audit Log lives. UAL is the canonical source for M365 audit data — the closest thing Microsoft has to a single audit stream. It’s enabled by default for enterprise licenses (E3, E5, G3, G5), but not for Business Basic, Business Standard, Business Premium, or trial licenses. If your organization runs on one of those SKUs, you may have no audit logging at all unless someone explicitly turned it on. The CISA Expanded Cloud Logs Implementation Playbook (January 2025) documents this gap and notes that these licenses “will have Audit enabled by default in the future” — but as of this writing, “future” hasn’t arrived.

Even when UAL is enabled at the tenant level, there’s a per-mailbox layer underneath it. Exchange Online mailbox auditing controls which actions get logged for each sign-in type — Owner, Delegate, and Admin. The DefaultAuditSet covers a reasonable baseline, but if anyone has ever customized a mailbox’s audit configuration, new audit actions that Microsoft releases won’t automatically get added. This is the scenario the CISA playbook warns about: after the Storm-0558 compromise, Microsoft downleveled MailItemsAccessed, Send, and SearchQueryInitiatedExchange/SharePoint from Audit Premium (E5) to Audit Standard (E3/G3). That was a significant move — those events were critical to the State Department’s detection of Storm-0558 using their “Big Yellow Taxi” alert rule. But getting those events to actually flow for your users still requires PowerShell verification at the mailbox level. There’s no portal UI for it.

The CISA playbook puts it plainly: “one common tactic used by attackers is to just turn off auditing on their targets.” If you haven’t verified that your mailbox-level audit configuration is intact, you’re trusting that it is. And that trust is unvalidated.

Retention: Audit Standard retains records for 180 days (changed from 90 days in October 2023). Audit Premium retains for one year by default, extendable up to 10 years with add-on licensing.

Entra ID Diagnostic Settings

This is a completely separate toggle, a separate pipeline, and a separate destination. Entra ID generates its own set of logs — sign-in logs, audit logs, provisioning logs, risky user and sign-in events — and they don’t flow anywhere useful unless you explicitly configure a diagnostic settings destination: a Log Analytics workspace, a Storage Account, or an Event Hub.

If you don’t configure this, Entra ID activity only reaches your SIEM through whatever subset the UAL happens to capture. And the UAL’s capture of Entra ID activity is incomplete. Sign-in logs in particular — who authenticated, from where, with what client, whether MFA fired, what conditional access evaluated — require this separate pipeline. These matter even if you only use M365: even if your organization has zero Azure infrastructure, zero VMs, zero virtual networks, logs collected by the Entra ID Diagnostic settings are still critical M365 telemetry because Entra ID is your M365 identity plane. It’s not an “Azure thing” you can ignore because you’re SaaS-only.

I made this exact point in the first post: a team can have Sentinel deployed, dashboards built, and detection rules running, with zero visibility into authentication activity because the Entra ID data connector was never configured. The dashboard stays green. Nothing fires. And the absence of signal looks exactly like the absence of threat.

Defender for Cloud Apps (MDCA) Connector

The M365 connector in Defender for Cloud Apps has a checkbox that can quietly determine whether one of the most important tables in Defender XDR gets populated or stays empty.

To populate the CloudAppEvents table, you need to go to the Defender portal → Settings → Cloud apps → App connectors, and ensure the “Microsoft 365 activities” checkbox is actually selected. Sometimes the connector shows as “connected” in the portal but isn’t fully enabled. If this checkbox isn’t selected, CloudAppEvents will be empty or partial — and there’s no error, no alert, and no indication that anything is wrong. Microsoft’s own documentation confirms this: “If your organization hasn’t deployed the service in Microsoft Defender XDR, queries that use the table aren’t going to work or return any results.”

Jeffrey Appel’s 2025 Microsoft Defender Optimization & Configuration Cheat Sheet flagged this as one of the settings he still sees overlooked daily. His advice: if you have an MDCA license and haven’t verified the connector, do it now.

Exchange Online PowerShell

Exchange Powershell is not a log source you ingest into a SIEM, but it’s the only place where you can verify what’s currently being logged at the per-user level for mailbox settings. The Get-Mailbox cmdlet with its audit properties is the only way to see the actual audit action set for a given mailbox across Owner, Delegate, and Admin sign-in types.

The DefaultAuditSet mechanism is supposed to handle this automatically — but if a mailbox has been explicitly customized (even once, even years ago), it falls out of the default management path. New audit actions won’t be added. The only way to know is to check, and the only way to check is PowerShell.

This is also where you verify that the tenant-level UnifiedAuditLogIngestionEnabled property is set to True — but even that has a gotcha. The Get-AdminAuditLogConfig cmdlet is available in both Exchange Online PowerShell and Security & Compliance PowerShell, but the UnifiedAuditLogIngestionEnabled property always returns False in Security & Compliance PowerShell, even when auditing is actually on. You have to run it in Exchange Online PowerShell specifically.

What about detecting changes to these settings? There’s an important distinction here between reading current state and detecting changes. PowerShell is the only tool for the former — but the latter is a detection engineering problem, and the telemetry does exist in the UAL.

Management Activity API Subscriptions

The Office 365 Management Activity API is the programmatic interface that most SIEMs use to pull audit data. It has five content types:

• Audit.Exchange — Mail and calendaring events

• Audit.SharePoint — SharePoint and OneDrive events

• Audit.AzureActiveDirectory — Entra ID events

• Audit.General — Everything else: Teams, Power Platform, Copilot, Defender audit trails, and more

• DLP.All — Data loss prevention events

Each content type requires an explicit subscription. Subscriptions persist once started, but there’s no health monitoring, no status dashboard, and no notification if a subscription fails or stops delivering data.

Here’s the configuration gap that catches people: most teams subscribe to Exchange, SharePoint, and AzureActiveDirectory — the obvious ones. They forget Audit.General. And Audit.General is where Teams data lives, where Power Platform events live, where Copilot activity lands, and where Defender XDR’s own audit trails flow. If you’re not subscribed to Audit.General, entire workloads are invisible to your SIEM.

The key takeaway from this section: Five separate configuration surfaces. Four different admin portals. Five different RBAC requirements. No unified view of “is my auditing fully enabled?” This fragmentation is the first blind spot — and it’s architectural, not operational. You can’t solve it with better SOC processes. You have to know the surfaces exist and check each one independently.

What the Actual Log Tables Are

Once telemetry is configured, it flows into tables. But the word “flows” does a lot of work in that sentence, because these aren’t different views of the same data. They’re different pipes with different schemas, different coverage, different retention, and different license gates. A detection engineer writing KQL against one table is seeing a fundamentally different slice of reality than one writing against another.

A note on naming: the table names below are Sentinel and Defender XDR names, because that’s where the schema and coverage documentation lives. If you’re on a non-Microsoft SIEM, the underlying data is the same — the Management Activity API is a REST API that Splunk, Elastic, and every other SIEM polls directly; Entra ID Diagnostic Settings can route to an Event Hub for any platform; and the Defender XDR Streaming API can export XDR tables to Event Hub or Storage. The coverage gaps, schema limitations, and retention constraints documented here are properties of the data sources, not the SIEM. They apply regardless of where the data lands.

Here’s what actually exists:

OfficeActivity (Sentinel)

• Source: Management Activity API → Sentinel’s Office 365 data connector

• License gate: Microsoft Sentinel + M365 connector (free to ingest)

• Retention: Workspace-configured (typically 90 days default, extendable)

• Coverage: Exchange, Teams, SharePoint, OneDrive — but only the workloads that flow through the Management Activity API content types you’ve subscribed to. Not Audit.General workloads unless you’ve set up a custom ingestion path.

OfficeActivity is where most Sentinel users start, because the Office 365 data connector is free and obvious — and non-Microsoft SIEMs land the same data by polling the Management Activity API directly. But it has a significant schema limitation: it doesn’t include the OperationCount field. Microsoft uses this field to flag aggregated events — where a single audit record actually represents multiple operations. In Bert-Jan Pals’ testing, more than one-third of events were aggregated. Without OperationCount, you can’t distinguish a single event from a batch. Your event counts are wrong. Your thresholds are wrong. And you have no way to know from the data itself.

In Bert-Jan’s coverage testing against 191 unique activities performed in a default-configured tenant, OfficeActivity captured roughly 40% of them.

CloudAppEvents (Defender XDR)

• Source: MDCA M365 connector

• License gate: E5 Security, or standalone MDCA license

• Retention: 30 days in Defender XDR (can be extended with Sentinel Data Lake ingestion)

• Coverage: Broader than OfficeActivity. Absorbing more workloads over time — Copilot activity, Defender XDR audit trails, Sentinel platform operations. Bert-Jan’s testing showed approximately 89% coverage of the 191 tested activities.

CloudAppEvents is increasingly where Microsoft is consolidating M365 audit visibility in the Defender XDR ecosystem. But it has its own gaps. It doesn’t include UserLoggedIn or UserLoginFailed — those come through the sign-in log tables (more on those below). It has gaps in some Exchange activities compared to what the UAL captures. And it includes at least one event — Broke sharing inheritance for OneDrive — that doesn’t appear in the UAL at all.

That last point is important: the relationship between CloudAppEvents and the UAL isn’t strictly “CloudAppEvents is a subset.” They’re overlapping but distinct data sources. You can’t assume one is a superset of the other.

EntraIdSignInEvents (Defender XDR)

• Source: Entra ID sign-in logs, surfaced in Defender XDR

• License gate: Entra ID P2

• Retention: 30 days in Defender XDR

• Coverage: Interactive and non-interactive user sign-ins — the authentication telemetry that CloudAppEvents doesn’t capture.

This table went GA in February 2026, replacing the former AADSignInEventsBeta. If your KQL queries or custom detection rules still reference the old table name, they should have been auto-migrated — but verify. The rename happened on December 9, 2025, with a 30-day coexistence period.

In Sentinel, the equivalent is the SigninLogs table, which flows through Entra ID Diagnostic Settings and requires at least an Entra ID P1 license. These are parallel pipelines to the same underlying data — but with different schemas, different enrichment, and different retention depending on your configuration.

EntraIdSpnSignInEvents (Defender XDR)

• Source: Entra ID service principal and managed identity sign-in logs

• License gate: Entra ID P2

• Retention: 30 days in Defender XDR

This table also went GA in February 2026. It’s the Defender XDR equivalent of AADServicePrincipalSignInLogs in Sentinel — and it covers the identity types I described in Problem 2 of the first post. Service principals and managed identities authenticate through paths that most detection rules never touch. This table is where that telemetry lives in the XDR ecosystem.

If you built your authentication detections against EntraIdSignInEvents (or its predecessor) and stopped there, you’re blind to service principal authentication. Same access, different table, no alert.

GraphApiAuditEvents (Defender XDR)

• Source: Automatic with Defender XDR

• License gate: Included with Defender XDR (no additional cost)

• Retention: 30 days

• Coverage: Microsoft Graph API requests made against tenant resources — who called what endpoint, when, from where, and what the response was.

This is one of the most significant recent additions to the M365 detection surface. GraphApiAuditEvents entered public preview in July 2025 and went GA in February 2026. It’s essentially a free version of the MicrosoftGraphActivityLogs table in Sentinel — which is valuable for detection but expensive to ingest due to high log volume.

The trade-off is schema depth. MicrosoftGraphActivityLogs has 33 columns; GraphApiAuditEvents has 19. The fields that are missing matter for detection engineers: DeviceId (the device from which the Graph API call was made) and SessionId (which lets you correlate Graph activity to sign-in sessions) are both absent. The UserId and ServicePrincipalId fields from MicrosoftGraphActivityLogs have been concatenated into a single AccountObjectId column, which simplifies some queries but loses the ability to immediately distinguish human vs. application callers.

Fabian Bader at Cloudbrothers documented an additional wrinkle when the table launched: several columns listed in Microsoft’s documentation weren’t actually present in the data. The schema was aspirational, not actual. This is exactly the kind of silent gap that erodes detection confidence — your query doesn’t error, it just returns null for fields you expected to be populated.

GraphApiAuditEvents cannot currently be forwarded to Sentinel to extend its retention beyond 30 days (though Sentinel Data Lake ingestion for Defender XDR tables is now GA, so this may change). For incident response, 30 days of Graph API visibility is better than zero — but if you need historical depth, MicrosoftGraphActivityLogs in Sentinel remains the paid option.

MicrosoftGraphActivityLogs (Sentinel)

• Source: Entra ID Diagnostic Settings

• License gate: Entra ID P1 + Sentinel

• Retention: Workspace-configured

• Coverage: Same underlying data as GraphApiAuditEvents, but with the full 33-column schema including DeviceId and SessionId.

This table is expensive. The volume of Graph API traffic in any active tenant is enormous, and every request generates a log entry. But for organizations doing serious incident response or threat hunting against application-layer attacks — compromised OAuth apps, token theft, Graph API abuse by tools like AzureHound or GraphRunner — it’s uniquely valuable. The cost is why GraphApiAuditEvents exists: Microsoft recognized that most organizations couldn’t justify the Sentinel ingestion bill for these logs, so they shipped a lighter version for free in Defender XDR.

Entra ID Log Tables (Sentinel / Log Analytics)

• Source: Entra ID Diagnostic Settings → Log Analytics workspace (or Event Hub, or Storage Account)

• License gate: Entra ID Free or E3+ for AuditLogs; Entra ID P1 or P2 for sign-in log tables

• Retention: Workspace-configured when sent to Log Analytics; destination-dependent otherwise

• Coverage: Authentication activity, directory changes, provisioning events, risk detections, and Graph API activity — the identity plane telemetry that doesn’t flow through the UAL or Management Activity API.

Earlier in this post I described Entra ID Diagnostic Settings as one of the five configuration surfaces. Here’s where that pipeline’s data actually lands.

When you configure a diagnostic setting in Entra ID, you select which log categories to export and where to send them. The destination matters more than most people realize, because it determines what you can do with the data. There are three options:

A Log Analytics workspace is what Sentinel queries. When you send Entra ID logs to a Log Analytics workspace — whether directly through diagnostic settings or through the Sentinel Entra ID data connector (which configures the same underlying diagnostic settings) — they land in specific tables that you can write KQL against, build detection rules on, and hunt through. This is the path that makes the data actionable for detection engineering.

An Event Hub is the path for non-Microsoft SIEMs. If you’re running Splunk, Elastic, Sumo Logic, or any other platform, this is how Entra ID telemetry gets to your SIEM. The data is the same — same log categories, same underlying events — but the format, schema, and enrichment depend entirely on how your SIEM’s ingestion pipeline handles Event Hub messages. This is the equivalent path for organizations not in the Microsoft Sentinel ecosystem, and it’s just as critical to configure. If you’re on Splunk and haven’t set up an Event Hub destination for Entra ID diagnostic settings, you have the same blind spot as a Sentinel shop that never enabled the data connector.

A Storage Account is primarily for archival and compliance — long-term retention where query latency isn’t a concern.

You can configure multiple diagnostic settings simultaneously, sending the same log categories to more than one destination. But each destination is independent: nothing about sending logs to an Event Hub guarantees they’re also flowing to Log Analytics, or vice versa.

The Log Analytics tables. When the destination is a Log Analytics workspace, each diagnostic settings category maps to a specific table — but the category names and table names don’t match, which is a source of confusion. Here’s the mapping for the tables that matter most for detection:

The SigninLogs table captures interactive user sign-ins. This is the richest authentication telemetry available: conditional access evaluation results, MFA details, device information, client app, location, risk scoring. If you’re building detections around authentication anomalies, compromised credentials, or conditional access bypass, this is where the signal lives. Requires Entra ID P1 or higher to export.

AADNonInteractiveUserSignInLogs captures sign-ins performed by a client on behalf of a user — token refreshes, background app activity, SSO sessions. These are high-volume (often dramatically higher than interactive sign-ins) and frequently overlooked. An attacker with a stolen refresh token generates non-interactive sign-ins, not interactive ones. If you’re only monitoring SigninLogs, you’re watching the front door while the side entrance is unmonitored. Also requires P1+.

AADServicePrincipalSignInLogs covers sign-ins by apps and service principals — the identity types I described in Problem 2 of the first post. This is the Sentinel equivalent of EntraIdSpnSignInEvents in Defender XDR. Requires P1+.

AADManagedIdentitySignInLogs covers sign-ins by Azure managed identities. Lower volume than service principal logs in most tenants, but critical if your environment uses managed identities for automation or cross-service access. Requires P1+.

AuditLogs captures directory changes — user and group management, application registration changes, role assignments, policy modifications. This is the only table in this group that doesn’t require a premium license; it can be exported with Entra ID Free or any E3+ plan.

(I’ve already covered MicrosoftGraphActivityLogs in its own section above — it also flows through this same diagnostic settings pipeline.)

A naming trap worth flagging: the category names you select in diagnostic settings don’t match the table names in Log Analytics. NonInteractiveUserSignInLogs in the diagnostic settings UI becomes AADNonInteractiveUserSignInLogs in Log Analytics. ServicePrincipalSignInLogs becomes AADServicePrincipalSignInLogs. Same data, different names depending on where you’re looking. Thomas Naunheim documented this mismatch — it’s the kind of thing that causes silent query failures if you’re writing KQL against the diagnostic settings category name instead of the actual table name.

The detection engineering gap this fills. The earlier sections of this post covered EntraIdSignInEvents and EntraIdSpnSignInEvents in Defender XDR. Those tables are the XDR-side view of the same underlying authentication data. But there are meaningful differences: the Sentinel tables have richer schemas (full conditional access policy evaluation details, device compliance state, authentication method details), workspace-configured retention instead of the fixed 30-day window in Defender XDR, and — critically — they split non-interactive and managed identity sign-ins into their own dedicated tables rather than combining identity types.

If your detection strategy lives in Sentinel, these are the tables your authentication rules should be built against. If your detection strategy lives in Defender XDR, the EntraId* tables covered earlier are the equivalent. If you’re on a non-Microsoft SIEM, the Event Hub path delivers this same data — but only if someone configured the diagnostic setting, selected the right log categories, and pointed them at your Event Hub. That’s three things that can be wrong, and none of them will tell you if they are.

Purview Audit Search (UAL Direct)

• Source: Direct query against the Unified Audit Log

• License gate: E3+ for Standard, E5 for Premium

• Retention: 180 days (Standard), 1 year (Premium), up to 10 years with add-on

• Coverage: ~99.5% of all audited activities in Bert-Jan’s testing — the most complete view available.

This is not a SIEM table. You can’t write detection rules against it. You can’t set up automated alerts. It’s a query interface — available through the Purview portal, through Search-UnifiedAuditLog in Exchange Online PowerShell, or through the Purview Audit Search Graph API (which Microsoft moved back to beta in April 2025 to address stability issues, and has not yet returned to v1.0 GA).

But for incident response, it’s the canonical source. When you need to know what actually happened — not what made it through your ingestion pipeline — the UAL is where you go. Tools like the Invictus Incident Response Microsoft Extractor Suite are built specifically to extract data from this source when your SIEM tables aren’t enough.

The Coverage Gap at a Glance

Bert-Jan Pals’ research quantified what practitioners had suspected: of 191 unique activities tested in a default-configured tenant, OfficeActivity captured roughly 40%. CloudAppEvents captured roughly 89%. Purview Audit Search captured roughly 99.5%. None reached 100%.

Those numbers should be uncomfortable. If you’re running detections exclusively against OfficeActivity, you have visibility into less than half of what’s happening. If you’re on CloudAppEvents, you’re in better shape — but you’re still missing roughly one in ten events compared to what the UAL sees.

And none of these tools log everything. Bert-Jan’s testing was explicit about this: “None of the acquisition methods get 100% coverage on the performed activities, meaning you need to combine acquisition methods to get a complete overview.”

How Collection Actually Works

Let’s trace a concrete example to make this real. A user accesses a mailbox item — the MailItemsAccessed event. This is the exact event that was central to the Storm-0558 detection: the State Department’s SOC built custom alerting on MailItemsAccessed events and caught an anomalous AppID accessing mailboxes. Without this event, the compromise may have gone undetected.

Here’s what happens when that action occurs:

Step 1: The user action occurs. Exchange Online generates an audit record.

Step 2: The record enters the UAL. It becomes available via Purview Audit Search — if auditing is enabled for that user, if MailItemsAccessed is in their mailbox audit action set, and if the event isn’t being throttled (Microsoft throttles MailItemsAccessed if more than 1,000 records are generated on a mailbox within 24 hours — no logging for 24 hours after throttling).

Step 3: From the UAL, data flows outward via multiple diverging paths:

Path A: Management Activity API → Your SIEM. Your SIEM polls the Management Activity API for content blobs from the Audit.Exchange subscription. The content is available for 7 days — after that, the blobs expire with no backfill. Typical latency is 60-90 minutes, but Microsoft explicitly does not commit to a specific delivery time: “some issues may arise upstream from the Audit service and are unavoidable.” There’s no server-side filtering — you get all of Audit.Exchange, not just the events you care about. And duplicates are expected: “the Office 365 Management Activity API does not have this de-duplication feature... It is the responsibility of the SIEM solution to implement logic to remove such duplicated events.” In Sentinel, this lands in the OfficeActivity table.

Path B: MDCA connector → CloudAppEvents. The same underlying event flows through the Defender for Cloud Apps M365 connector into CloudAppEvents. Different enrichment, different schema, and approximately 89% coverage — meaning some events present in the UAL won’t appear here. The inverse is also true: some events appear in CloudAppEvents that aren’t in the UAL.

Path C: Entra ID Diagnostic Settings → Sign-in logs. This path doesn’t carry the MailItemsAccessed event — it’s only for Entra ID and Graph API activity, not Exchange/SharePoint/Teams. But it’s the path that carries the authentication context that surrounds the mailbox access: who the user was, how they authenticated, whether conditional access evaluated the session. If Path C isn’t configured, you might see the MailItemsAccessed event in your SIEM but have no authentication context to correlate it with.

The critical insight: Your SIEM is not querying the UAL. It’s querying whatever subset of the UAL made it through one specific pipe. And different pipes have different coverage, different latency, different retention, and different schemas. A detection built against OfficeActivity is evaluating a fundamentally different data set than one built against CloudAppEvents, even when both are nominally covering “Exchange audit events.”

Where the Blind Spots Hide

You now have the map. Here’s what’s missing at each layer.

Configuration Blind Spots

UAL enabled, but per-mailbox actions not in DefaultAuditSet. If anyone has ever customized a mailbox’s audit configuration, new events like MailItemsAccessed won’t be added automatically. The only way to verify is PowerShell, per mailbox. There’s no bulk verification tool in any admin portal.

MDCA connector “connected” but M365 Activities not fully enabled. CloudAppEvents stays empty. No error. No alert. Just silence.

Management Activity API subscribed to Exchange/SharePoint/AzureAD but not Audit.General. You’re missing Teams, Power Platform, Copilot, Defender XDR audit trails — entire workloads are invisible.

Entra ID Diagnostic Settings not configured. This is a big one. No sign-in logs flowing to your SIEM. Your authentication visibility is limited to whatever the UAL captures through the Management Activity API — which doesn’t include the rich sign-in log schema with conditional access evaluation, MFA details, device information, or risk scoring.

Coverage Blind Spots

OfficeActivity is approximately 40% coverage. For detection engineering, that means more than half of audited activities in a default-configured tenant are invisible to rules running against this table.

OfficeActivity is missing OperationCount. You cannot distinguish aggregated events from single events. In Bert-Jan’s testing, more than a third of events were aggregated. Your event counts, your detection thresholds, and your frequency-based rules are operating on inflated or deflated numbers, and you have no way to tell which.

CloudAppEvents is approximately 89% coverage. Better, but roughly one in ten events compared to the UAL is missing. And it doesn’t include UserLoggedIn/UserLoginFailed — those come from the sign-in log tables.

GraphApiAuditEvents is missing DeviceId and SessionId compared to MicrosoftGraphActivityLogs. If your detection logic depends on correlating Graph API activity to specific devices or sign-in sessions, the free table won’t support it.

Neither OfficeActivity nor CloudAppEvents captures everything in the UAL. And the UAL itself doesn’t capture everything — it’s at 99.5%, not 100%. The only event Bert-Jan found exclusively in CloudAppEvents and not in the UAL was Broke sharing inheritance for OneDrive. The relationship between these data sources is overlapping, not hierarchical.

Retention Blind Spots

Management Activity API content blobs expire after 7 days. If your SIEM goes down, if your ingestion pipeline breaks, if there’s a credential issue with your API subscription — those events are gone. There’s no backfill mechanism.

GraphApiAuditEvents: 30 days, and currently cannot be extended by forwarding to Sentinel. For incident response involving Graph API abuse, 30 days may not be enough. MicrosoftGraphActivityLogs in Sentinel gives you workspace-configured retention, but at significant cost.

CloudAppEvents: 30 days in Defender XDR. Same constraint. Sentinel Data Lake ingestion for Defender XDR tables is now GA, which may help extend this — but it’s an additional configuration step that most organizations haven’t implemented.

Your SIEM retention may be longer than all of these — but it only covers data that actually made it into the pipe. Retention is meaningless for events that were never collected.

The Meta Blind Spot

This is the one that makes all the others invisible: there is no health monitoring for any of this.

No alert when a Management Activity API subscription fails. No dashboard showing “here’s what’s flowing and here’s what’s not.” No completeness verification. No cross-check mechanism to confirm your SIEM received all events the UAL generated. No way to distinguish “nothing happened” from “we stopped collecting.”

Microsoft provides no native solution for telemetry health monitoring across these ingestion paths. The CISA playbook provides manual verification steps — PowerShell commands to check UAL status, steps to verify mailbox audit configuration — but these are point-in-time checks, not continuous monitoring. The moment after you verify, configuration can drift, subscriptions can break, and you’ll hear nothing about it until an incident investigation reveals the gap.

This is the foundational risk underneath everything else. You can configure all five surfaces correctly. You can understand which tables cover what. You can trace every collection path. But without continuous verification that data is actually flowing, your entire detection pipeline is built on trust. And in SaaS environments — where the vendor controls the instrumentation, the schemas, and the delivery — trust is not a detection strategy.

What to Do With This

I’ll go deeper on methodology in a future post, but here’s what you should take away today:

Verify your specific ingestion path. Don’t assume you know which pipe you’re on. Check whether it’s the Management Activity API, the MDCA connector, Entra ID Diagnostic Settings, or some combination. Know exactly which tables your detections query and what those tables actually contain.

Don’t assume OfficeActivity = UAL. Don’t assume CloudAppEvents = UAL. These are different pipes with different coverage. If you built detections against OfficeActivity and haven’t cross-checked against CloudAppEvents or Purview Audit Search, your coverage map has unknown gaps.

Check Audit.General. If your Management Activity API subscriptions don’t include it, you’re missing Teams, Power Platform, Copilot, and Defender audit activity entirely.

Verify per-mailbox audit configuration with PowerShell. Especially for high-value mailboxes — executives, finance, legal, anyone likely to be targeted. The DefaultAuditSet mechanism is good but brittle: a single historical customization takes a mailbox out of automatic management permanently.

If you’re doing incident response, always supplement SIEM data with direct UAL extraction. The Invictus Incident Response Microsoft Extractor Suite, Purview Audit Search (including the Graph API in beta), or direct PowerShell extraction. Your SIEM shows you what made it through the pipe. The UAL shows you what actually happened.

Consider GraphApiAuditEvents as a baseline for Graph API visibility. It went GA in February 2026 and it’s free with Defender XDR. The schema is thinner than MicrosoftGraphActivityLogs, but 19 columns of Graph API telemetry for free is better than zero visibility. If you’re investigating OAuth app compromise, token theft, or reconnaissance via Graph enumeration tools, this table is now your starting point.

Next post, we’ll go deeper on one of the silent failure modes that makes all of this worse — and show you what it looks like when collection breaks without telling you.

References & Credits

• Bert-Jan Pals — “UAL = Unaligned Activity Logs” (kqlquery.com, November 2024). The coverage testing against 191 unique activities and the OfficeActivity/CloudAppEvents/Purview Audit comparison that quantifies the gaps discussed throughout this post.

• Bert-Jan Pals — “GraphApiAuditEvents: The new Graph API Logs” (kqlquery.com, August 2025). Schema comparison between GraphApiAuditEvents and MicrosoftGraphActivityLogs, including the missing DeviceId/SessionId fields and retention constraints.

• Fabian Bader (Cloudbrothers) — “Detect threats using GraphAPIAuditEvents - Part 3” (cloudbrothers.info, August 2025). Detection engineering with the new table, including documentation of schema gaps at launch and Thomas Naunheim’s comparison table.

• CISA — “Microsoft Expanded Cloud Logs Implementation Playbook” (January 2025). The practitioner playbook for operationalizing expanded audit logs, including mailbox-level verification procedures and the context on Storm-0558 detection.

• Microsoft Learn — Defender XDR “What’s new” documentation confirming February 2026 GA for EntraIdSignInEvents, EntraIdSpnSignInEvents, and GraphApiAuditEvents. Naming changes documentation for the December 2025 AADSignInEventsBeta → EntraIdSignInEvents migration. Individual table reference pages for schema details.

• Microsoft Learn — Office 365 Management Activity API reference and troubleshooting documentation, confirming content blob expiry, latency expectations, and duplicate event behavior.

• Microsoft Learn — “Turn auditing on or off” and “Search the audit log” documentation for UAL enablement status, license requirements, and retention changes.

• Microsoft Learn — “Logs available for streaming from Microsoft Entra ID” for the complete list of diagnostic settings log categories and their descriptions. “Send Microsoft Entra ID data to Microsoft Sentinel” for the Sentinel data connector configuration and table mapping.

• Jeffrey Appel — “2025 Microsoft Defender Optimization & Configuration Cheat Sheet” (jeffreyappel.nl, November 2025). Configuration items that are still commonly overlooked, including MDCA connector state.

• Thomas Naunheim — “Sign-in logs and auditing of Managed Identities and Service Principals” (cloud-architekt.net). Documentation of the naming mismatch between Entra ID diagnostic settings categories and Log Analytics table names, and early coverage of service principal and managed identity sign-in log tables. Also referenced by both Bert-Jan Pals and Fabian Bader for schema comparison work between GraphApiAuditEvents and MicrosoftGraphActivityLogs.

• Practical365 / Tony Redmond — Coverage of the Purview Audit Search Graph API’s move back to beta (April 2025) and ongoing practitioner perspective on M365 audit capabilities.

And then something breaks — not loudly, not with an alert, but silently. A log source stops delivering. A field shifts position in an array. An API gets deprecated and the attack path you validated six months ago no longer fires the way you tested it. No one notices, because the absence of signal looks exactly like peace.

This is a problem across all of threat detection. Endpoint teams deal with it. Network teams deal with it. But nowhere is it worse than in SaaS.

In endpoint or network detection, you control the instrumentation. You deploy the agent. You configure the tap. You own the pipeline from source to SIEM. In SaaS, the vendor controls what gets logged, how it's structured, and when it changes — but you're still responsible for configuring which of those log sources actually flow into your environment. The problem is that most teams don't know what needs to be configured. The defaults leave gaps. The licensing requirements are buried in documentation. The connectors that look comprehensive aren't. And nobody tells you what you're not collecting.

That’s the world this series lives in. The problems I’m going to lay out exist everywhere in detection engineering to some degree, but SaaS is where they’re sharpest, least visible, and hardest to compensate for. It’s not one problem — it’s four, and they compound.

Problem 1: You might be blind

Before anything else matters — before your detection logic, before your correlation rules, before your threat model — telemetry has to arrive. And in cloud environments, arrival is not guaranteed.

Cloud logging configuration is sprawling, fragmented, and fails silently. In SaaS platforms specifically, you’re often dealing with multiple audit log types that require separate enablement, retention settings that default to short windows, and API-based log retrieval that may or may not be functioning — all without a single pane telling you what’s actually flowing. There’s no error when a log source isn’t configured. There’s no alert when audit logs aren’t being ingested. There’s just... nothing. And nothing looks exactly like “nothing happened.”

Most organizations have never systematically verified that their telemetry is actually arriving. They assume it is because they’ve never been told otherwise. That assumption is the foundation everything else is built on, and it’s unvalidated.

Here’s a concrete example from the Microsoft ecosystem.

When a security team connects Microsoft Sentinel to their Microsoft 365 environment, the first thing most people do is enable the Office 365 data connector. It’s free, it’s obvious, and it starts flowing SharePoint activity, Exchange admin events, and Teams data into your workspace immediately. Green checkmark. Logs are flowing. Coverage achieved.

Except you’re missing the most fundamental identity telemetry in the entire ecosystem: sign-in logs.

Entra ID sign-in logs — who authenticated, from where, with what client, whether MFA was enforced, whether conditional access evaluated the session — require a completely separate data connector, a P1 or P2 license, and manual configuration. They are not included in the Office 365 connector. They are not free to ingest. They don’t flow by default.

This means a team can have Sentinel deployed, dashboards built, detection rules running, and still have zero visibility into authentication activity. An attacker signs in with stolen credentials from an anomalous location, and the telemetry that would catch it simply isn’t there — not because a detection failed, but because the data was never collected. The dashboard stays green. Nothing fires. And the team has no reason to suspect anything is wrong, because the absence of signal looks exactly like the absence of threat.

Problem 2: What you see depends on how you look

Assume your logs are flowing. You’re not blind. Good. Now the next problem: the same malicious action, performed under different conditions, produces different telemetry.

The same API call made by a user, a service principal, and a managed identity can generate meaningfully different log entries. Fields that exist in one context are absent in another. Values that behave predictably under one identity type behave differently under another. The differences aren’t cosmetic — they’re structural.

This means a detection built against one execution path will miss the same attack performed through a different one. And most detection teams test exactly one path.

This isn’t a logging bug. It’s a fundamental characteristic of how SaaS and cloud platforms emit telemetry. These platforms have rich, complex identity models — human users, service accounts, API keys, OAuth apps, managed identities — and the telemetry surface varies across all of them. Your detection coverage is only as wide as the identity and method combinations you’ve actually validated.

Here’s what this looks like in practice, using Microsoft Entra ID as an example.

When an interactive user signs into a Microsoft cloud resource, the event lands in the SigninLogs table. It includes conditional access policy evaluation, device information, MFA challenge details, user risk scoring, and client application metadata. It’s a rich, detailed record — exactly the kind of telemetry detection engineers love to build rules against.

When a service principal authenticates to the same resource — using a client secret or certificate, the way an application or automation workflow would — that event doesn’t appear in SigninLogs at all. It lands in a completely separate table: AADServicePrincipalSignInLogs. And the schema is materially different. There are no MFA details, because service principals don’t do MFA. There’s no device information, because there’s no device. There’s no user risk score. The fields that your detection was built to inspect don’t exist.

Managed identities? A third table: AADManagedIdentitySignInLogs. Non-interactive user authentication — a client app refreshing a token on behalf of a user? A fourth: AADNonInteractiveUserSignInLogs.

That’s four separate tables for what is conceptually a single event category: “something authenticated to access a resource.” A detection rule written against SigninLogs — which is where most teams start, because it’s the most visible and well-documented — will never fire for the same access performed by a service principal, a managed identity, or a non-interactive token refresh. The detection doesn’t fail. It simply never evaluates the event, because the event is in a table the rule was never pointed at.

Now consider this from an attacker’s perspective. If you’ve compromised a service principal’s credentials, every action you take authenticates through a path that most organizations’ detection rules were never written to cover. Not because the telemetry doesn’t exist — but because it exists somewhere the defenders aren’t looking.

Problem 3: The execution surface shifts

APIs change. New endpoints appear. Old ones get deprecated, modified, or replaced. The attack path you validated — the one your detection was built to catch — may no longer be the path an attacker would take.

This isn’t theoretical. SaaS providers and cloud platforms ship API changes constantly — often without announcement. A new method for modifying IAM policies, a deprecated endpoint replaced by a v2, a previously undocumented parameter that now exists — each one potentially creates an untested attack path that your existing detections don’t cover. And unlike infrastructure you own, you have no visibility into these changes until you discover them yourself.

Your offensive coverage map has an expiration date. If you’re not continuously revalidating it, it’s going stale.

Example: Microsoft’s PowerShell module churn

If you built attack tooling or detection validation scripts against Microsoft 365 in 2022, here’s what’s happened to the execution surface underneath you since then.

The MSOnline (MSOL) module — the original way to manage Azure AD via PowerShell — was deprecated in March 2024 and began retiring in April 2025. The AzureAD and AzureADPreview modules followed the same deprecation timeline, with retirement targeted for Q3 2025. The Exchange Online PowerShell v1 module died in mid-2023 when Microsoft killed basic authentication, and v2 was retired months later in July 2023 when the Remote PowerShell (RPS) protocol was removed entirely. The Security & Compliance PowerShell RPS connection was deprecated on the same timeline.

The replacement for the identity modules was the Microsoft Graph PowerShell SDK v1, which shipped in 2021. Organizations spent months migrating scripts from MSOL and AzureAD to the new Get-Mg* cmdlets. Then in July 2023, Microsoft released SDK v2 — which introduced its own set of breaking changes. The Select-MgProfile cmdlet that everyone had just learned to use was removed. Every beta cmdlet was renamed (e.g. Get-MgUser on the beta endpoint became Get-MgBetaUser). The module namespace changed. Every script that touched beta endpoints — which was most of them, because the v1.0 endpoint didn’t return properties like AssignedLicenses — needed to be rewritten again.

A LinkedIn post from a Microsoft 365 community account captured the sentiment: “The Never-Ending Cycle of MS Graph Script Migrations.” Scripts migrated from AzureAD to Graph SDK v1 now required yet another migration to SDK v2.

And it’s not over. Microsoft Entra PowerShell is currently in preview as another incoming option, while the underlying Azure AD Graph API itself was fully shut down in June 2025 after a three-year retirement cycle that was delayed at least four times.

Here’s the count: since 2022, at least seven Microsoft PowerShell modules or protocols for managing identity and messaging have been deprecated or retired. The replacement itself was deprecated within a year of people migrating to it. If you wrote an attack simulation that used Connect-MsolService to test credential spraying detections, or Set-AzureADUserLicense to simulate license manipulation, that code doesn’t run anymore. The attack technique still works — but the execution path through Microsoft’s tooling has changed underneath it multiple times.

For a purple team, this means your offensive playbook has a shelf life measured in months, not years. And every time the execution surface shifts, the question isn’t just “does our attack still work?” It’s “does the telemetry from this new execution path land in the same place, with the same schema, with the same fields our detection expects?”

Which brings us to Problem 4.

Problem 4: The detection surface shifts

Your detection might be perfectly written. The logic might be flawless. But the data it’s inspecting no longer looks the way it looked when you wrote the rule. Detection engineers find out when something silently stops firing — or worse, starts flooding with false positives.

This is the inverse of Problem 3. That was about the execution surface shifting — the tools and APIs attackers use. This is about the telemetry surface shifting — the logs, schemas, and data structures your detections are built on top of. And unlike API deprecations, which at least get blog posts and retirement timelines, telemetry changes are often silent.

Example: SigninLogs and the invisible multi-record problem

Here’s a subtle one. The SigninLogs table in Microsoft Sentinel emits multiple records for a single login activity. When a user authenticates, the table doesn’t just log the final result — it logs intermediate steps: the initial request, the MFA challenge, the conditional access evaluation, the final outcome. Each step is a separate row in the table, grouped by Id or OriginalRequestId.

If you didn’t know that, you’d write a detection that counts distinct sign-in events and gets inflated numbers. Or you’d match on an intermediate record that shows a “failure” status even though the overall authentication succeeded. A community member filed issue #9463 against Microsoft’s own Azure Sentinel repository pointing out that none of the built-in Entra ID detection rules accounted for this behavior. Every rule treating a row as a complete event was generating false positives. The fix — adding | summarize arg_max(TimeGenerated, *) by Id before the detection logic — is trivial once you know about it. But nothing in the schema documentation made this multi-record behavior obvious. And if Microsoft’s own first-party detection rules didn’t account for it, how many custom rules in production environments are getting it wrong right now?

The scale of the shifting surface

To understand why this kind of thing happens, consider the scale. The Microsoft Graph API — the unified API surface that underpins Microsoft 365 and Entra ID — currently defines 1,302 unique paths in its v1.0 endpoint and 2,766 in beta. The msgraph-metadata repository on GitHub, which tracks the OpenAPI specification for these endpoints, has accumulated over 3,400 commits. Each commit potentially changes what data flows through which endpoint, which affects what lands in your log tables, which affects whether your detection still works.

These changes don’t come with a changelog entry that says “the field your KQL rule depends on now behaves differently.” They come as metadata updates. A property gets added, renamed, or moved to a different response object. A field that used to be populated becomes null in certain conditions. An enum gains new values your where clause doesn’t match. The OpenAPI spec for the v1.0 endpoint alone is a 35-megabyte YAML file containing 872,000 lines. Nobody is reviewing that diff manually.

The defensive coverage map goes stale independently of the offensive one. Even if you solved Problems 1 through 3 — you confirmed your logs exist, you validated across identity types, and you tracked the API changes — your detections can still silently degrade because the telemetry they inspect shifted underneath them on Microsoft’s release schedule, not yours.

The compounding effect

These four problems don’t exist in isolation. They layer and multiply.

You can’t trust your detections (problem 2) without first confirming your telemetry exists (problem 1). You can’t maintain offensive coverage without tracking API changes (problem 3). And even if you solve all of that, the ground shifts underneath your defensive logic on its own schedule (problem 4).

The number of ways things silently break grows over time. Each problem multiplies the others. The gap between “what we think we’re detecting” and “what we’re actually detecting” widens every day you’re not actively validating it.

This is why purple teaming can’t be a quarterly exercise, or an annual pentest, or a one-time red team engagement. It’s a continuous validation problem. And solving it requires tooling built specifically for that purpose — not attack simulation tools repurposed for defense, but something designed from the ground up to validate the entire detection pipeline, from log ingestion through alert firing.

That’s what this series is about. Not a tool walkthrough — a way of thinking about detection validation that takes all four of these problems seriously and addresses them structurally.

Next post, we'll get concrete about Problem 1. I'll walk through where telemetry is configured in the Microsoft 365 ecosystem, what the actual log tables are, and how collection works — so you can see for yourself where the blind spots hide.

Control Plane is a blog about building detection systems that actually work in SaaS and cloud environments. If you’re a detection engineer, purple teamer, or security leader tired of false confidence in your coverage, [subscribe] to follow the series.

References & Credits

• Thomas Naunheim (@intruder_io) — His work on sign-in logs and auditing of Managed Identities and Service Principals was an early and thorough documentation of the schema differences across Entra ID sign-in log tables, including the critical observation that fields like conditional access details and device information are absent from the service principal and managed identity schemas.

• Fabian Bader (Cloudbrothers) — His multi-part series on detecting threats using Microsoft Graph activity logs has been a valuable resource for understanding the detection surface across Microsoft’s logging ecosystem.

• Microsoft Learn — The Sentinel data connector documentation (Send Microsoft Entra ID data to Microsoft Sentinel) and the Entra ID diagnostic settings reference (Logs available for streaming) are the primary sources for the licensing requirements and log type availability discussed in this post.

• Microsoft Entra Blog — The official MSOnline and AzureAD PowerShell retirement announcement and deprecation update document the timeline covered in Problem 3.

• Tony Redmond / Practical365 — His ongoing coverage of the AzureAD module retirement and Graph SDK v2 migration provided detailed practitioner perspective on the impact of these transitions.

• O365Reports.com — The community post “The Never-Ending Cycle of MS Graph Script Migrations” captured what many practitioners were feeling during the SDK v1→v2 transition.

• J3roen / Azure-Sentinel GitHub — Issue #9463 documented that Microsoft’s own built-in Sentinel detection rules did not account for the multi-record-per-login behavior in the SigninLogs table, leading to false positives across the Entra ID analytics rule set.

• microsoftgraph/msgraph-metadata — The OpenAPI specification repository for Microsoft Graph provided the API path counts and commit history referenced in Problem 4.

Subscribe now