The bad news is that the remainder of plumbing the depths on service principals is going to be delayed until late August. The good news is that’s because I’ve picked up a TA position with SANS for SEC545: LLM and AI Application Security and am now spending all my extra waking hours on poring over the class material so that I don’t look like a dumbo in front of students next month. And honestly I may have found my new favorite thing to yell about, because there’s some design flaws in AI security that are equal parts fascinating and horrifying as well as some super-cool labs and tools that are worth hours of tinkering. But I’m not ready to yell about it yet, so please sit tight while I get smart and I will see you in a month. <3

“It’s an app” is the version most people give. But in keeping with true Microsoft tradition, it’s actually not that simple: there’s a host of connected-but-vital concepts that make a three word explanation unsatisfactory: application objects, enterprise applications, app registrations, client secrets, etc. And if you wanted a really complete explanation there’s also managed identities (secretly also service principals), agent blueprints, delegated permissions, etc.; all of which are also application-flavored and entirely too many letters for a presentation slide. Clearly, I had homework.

This post is the first chunk of that homework: what a service principal actually is. Part 2 covers what it’s allowed to do (permissions and consent, or: where OAuth confusion goes to breed). Part 3 covers why a threat researcher cares (spoiler: the guards are not evenly distributed). By the end of this one, you’ll have the single slide. I promise it exists.

The answer that fits on a slide

Here it is: a service principal is an ID badge for software.

In Entra ID, everything that wants to do things needs an identity. People get one kind: a user account. Software gets the other kind: a service principal. That’s the entire conceptual load. When your backup tool, your CI/CD pipeline, or that SaaS integration someone in marketing connected in 2021 needs to authenticate and get a token, it doesn’t log in as a person. It logs in as a service principal.

Both badges work the same way at the door: show up, prove who you are, get a token, use the token to open things. The difference is who’s wearing it. Alice proves who she is with a password and a phone prompt. The backup tool proves who it is with a secret, certificate, or federated credential. Same building, same tokens, different kind of visitor.

If a service principal is just a badge, why does Microsoft’s documentation make it feel like a tax form? Because a service principal is only half of a pair and the docs insist on defining each half in terms of the other. Let’s break the loop.

One blueprint, many badges

Here’s the thing the Microsoft Learn docs never say out loud: the confusing part of this model exists for exactly one reason, and the reason is multi-tenancy. An app is built once but used in many places. Once you know that, everything downstream starts to click.

So Microsoft splits every app into two objects:

The application object is the blueprint. It lives in exactly one tenant- whichever tenant the developer registered it in, and it describes what the app is: its name, its redirect URIs, the permissions it might ask for, its credentials. One per app, worldwide.

The service principal is the badge. It’s the local copy stamped into each tenant that actually uses the app, and it represents what the app may do there. It also has its own set of credentials, separate from the application object’s.

Concrete version: Salesforce registers their app once, in Salesforce’s own tenant. That registration is the application object. When your company clicks “yes, connect Salesforce,” Entra stamps a service principal into your tenant. Your admins can see that badge, grant it permissions, or revoke it: all without ever touching Salesforce’s blueprint, which was never yours to touch. This is why you can’t edit Salesforce’s redirect URIs from your tenant, and why you wouldn’t want a world where you could.

One blueprint. Thousands of badges, one per customer building.

There’s a tidy asymmetry hiding here that’s worth thirty seconds: delete the blueprint and your own badge is destroyed with it, but every other customer's badge lingers on, orphaned. Delete your local service principal and you’ve only evicted the badge from your own building: the blueprint, and everyone else’s badges, carry on. The blueprint is the app; the badge is the app’s presence in your tenant.

The portal decoder ring

Now for the payoff, because this single split explains the most disorienting thing about the Entra portal: why there are two blades that both seem to contain “apps,” with names that help nobody.

App registrations shows application objects: blueprints, and only ones born in your tenant. Enterprise applications shows service principals: every badge in your building, regardless of where its blueprint lives. The blade full of service principals is the one that does not contain the words “service principal.” I don’t make the rules.

Three things you’ll see when you go look (and you should go look):

Your own app appears in both blades. Register an app yourself via the portal (it’s two calls via API) and Entra creates both objects in your tenant: blueprint in App registrations, badge in Enterprise applications. They share a name and an app ID, which is why most people assume the two blades are redundant views of one thing. They’re not- they’re two different objects (with separate object ids) that happen to be introduced at the same party.

Salesforce appears in only one. You have their badge. You will never have their blueprint. Any third-party SaaS app you’ve consented to shows up only in Enterprise applications.

Microsoft’s own apps are in there too. First-party Microsoft applications show up in your tenant without anyone registering or consenting to them. Nobody registered them, nobody consented in the way you’d expect, and some of them hold the most powerful permissions in the building. The Enterprise applications blade politely hides most of them behind a default filter, which is why you may have never scrolled past your own apps and noticed the crowd.

The slide

As promised. If you remember nothing else:

A service principal is the ID badge software wears in your tenant. The app registration is the blueprint: it says what the app is, and it lives with whoever built the app. The service principal is the badge: it represents the app in your tenant, and it’s the thing your admins can actually see and control. One blueprint. One badge per tenant that uses the app.

That’s it. That’s the slide. It took me ten years to be able to write it, which is either an indictment of the documentation or of me, and I know which way I’m voting.

What didn’t fit on the slide

You may have noticed the slide says nothing about what the badge is allowed to open. That’s deliberate. Permissions are where this model gets genuinely dangerous to half-understand- there are two fundamentally different kinds, the difference between them is the difference between “this app reads Alice’s mail when Alice is using it” and “this app reads everyone’s mail at 3 a.m.,” and the consent screen does a remarkable job of making them look identical. That’s Part 2.

And Part 3 is why I, specifically, spent my evenings on this: the security apparatus your organization built — MFA, Conditional Access, impossible-travel alerts — was designed for the badges people wear. The badges software wears go through a different door. We’ll talk about who’s guarding it.

If this saved you from the Microsoft Learn circular dependency loop, subscribe: Parts 2 and 3 are coming, and after that we need to talk about what Microsoft just built on top of all this for AI agents. The short version: badges that print badges.

Subscribe now

Control Plane is an independent publication written in a personal capacity, on personal time and equipment, and doesn't represent my employer.

Answering that question is the whole reason Continuous Access Evaluation exists. CAE is the main control you have for containing token theft, which is reason enough to understand it precisely, holes and all.

What CAE is

Continuous Access Evaluation is a near-real-time enforcement mechanism for Conditional Access and token revocation in Entra ID. It’s built on an industry standard, the OpenID Continuous Access Evaluation Profile (CAEP). The core idea is a two-way conversation between the token issuer (Entra) and the relying party, meaning the resource provider that actually serves the request, like Exchange Online.

In the classic OAuth model those two parties stop talking the moment a token is issued. Entra mints it, the resource trusts it until it expires, and nobody reconsiders anything in the meantime. CAE opens a channel in both directions. The resource can tell Entra when something changes on its side, such as a request suddenly arriving from a new IP, and Entra can tell the resource to stop honoring a token it has already issued. For incident response, it’s that second direction you care about.

CAE first showed up in preview in 2020 and reached general availability in January 2022; it’s now switched on by default in every Entra tenant. Licensing is layered: the critical-event half travels with any Entra ID license, but the Conditional Access policy half, along with any tuning of CAE’s own settings, requires Entra ID Premium P1, and the high-risk-user signal that can trigger a revocation depends on Identity Protection, which is a P2 feature.

The problem it’s trying to solve

By default, Entra access tokens are valid for about an hour. Conditional Access only gets re-evaluated at refresh, when the client comes back for a new token: whether the account is still enabled, whether the password is still current, whether the user is still inside an allowed location. Between refreshes the resource simply trusts what it already has.

That gap is the problem. Disable a compromised account, reset its password, or revoke its sessions, and the change is real in the directory the instant you make it. A token already sitting in an attacker’s hands, though, can keep working until it expires or the client next refreshes. “Up to an hour” of continued access after you’ve detected and responded is not a rounding error. It can be the difference between containment and a mailbox that keeps exfiltrating while you watch.

Microsoft’s first attempt at this was the blunt one: shorten token lifetimes. That hurt performance and reliability without really closing the risk, since you can always get unlucky inside even a short window. CAE goes after the latency directly instead, making revocation event-driven rather than expiry-driven, and it does so without shredding token lifetime.

How it works

CAE has two halves, and it’s worth keeping them separate, because they cover different things and carry different prerequisites.

The first is critical event evaluation. Enabled resource providers subscribe to a set of high-severity Entra events and act on them within minutes, independent of any Conditional Access policy, which is why this half works in any tenant at all. The triggering events are an account being disabled or deleted, a password change or reset, MFA being enabled for the user, an administrator explicitly revoking all of a user’s refresh tokens, or a high-risk determination from Entra ID Protection. These are the “this user is compromised, cut them off” signals.

The second is Conditional Access policy evaluation. Exchange Online, SharePoint Online, Teams, and Microsoft Graph can sync certain CA policies (most importantly IP-based location) and enforce them inside the service itself, so a session that wanders outside an allowed network gets caught without waiting for the next token refresh.

Underneath both sits the claim challenge. Before CAE, a client just replayed a cached token until it expired. With CAE, the resource can reject a token that hasn’t expired yet by returning a 401 with a claim challenge attached. A CAE-capable client understands that response, bypasses its cache, and goes back to Entra with its refresh token, at which point Entra re-evaluates every condition and decides whether to issue a new token or block. All of this depends on client support, and the support is uneven. Outlook and Teams handle the claim challenge across platforms, Office in the browser does not, and the desktop clients land somewhere in between.

The token lifetime is where this gets counterintuitive. In a CAE-aware session the access token is long-lived, up to 28 hours, rather than the usual one, and the instinct is to read a longer token as a bigger exposure. In practice it works the other way around. The long token is the reward for being on the CAE path, and it’s safe precisely because revocation no longer hangs on expiry: it can be killed mid-stream the moment a critical event fires. Clients that aren’t CAE-capable never get the 28-hour token in the first place. They stay on the default one-hour lifetime and the old refresh-time re-evaluation. A short token you can only kill at refresh is the weaker deal.

One caveat on “near-real-time.” The target for critical events is minutes, but propagation can stretch to about 15 minutes. IP-based location enforcement is the exception; that one is effectively instant.

Where it works well

For the scenarios it covers, CAE is a real improvement, and that’s worth saying plainly.

Disable a user or reset their password and the revocation reaches Exchange, SharePoint, Teams, calendar, and tasks within minutes, rather than at the end of an hour-long token’s life. Revoke a user’s sessions during an incident and, on the covered resources, the kill is near-real-time instead of a hopeful wait. Move outside an allowed IP range mid-session and the location policy is enforced inside the service, not at the next refresh. And because critical event evaluation doesn’t lean on Conditional Access policies at all, those compromise-response signals fire even in tenants that have never built out much of a location-policy estate.

So if your incident is a compromised account being worked through Outlook or Teams against M365, CAE is doing real work for you. The 28-hour token is part of the reason: it keeps sessions stable for everyone else while still letting you cut the compromised one the instant you pull the trigger.

Where it falls apart

The catch is that “near-real-time revocation” is a property of one specific, narrow path: a CAE-capable client talking to a CAE-enabled resource under the supported conditions. Step off that path and nothing warns you. You quietly fall back to the old model, revocation at the next refresh and roughly an hour of exposure, or to something weaker still. The conditions that knock you off the path are all documented, sitting in the limitations section of Microsoft’s own CAE docs. That section is a coverage map for defenders. It is also, for anyone holding a stolen token, a directory of the places where revocation runs slow.

The documented edges:

• Resource scope. The implementation centers on Exchange Online, SharePoint Online, and Teams, with Graph handling policy sync. Anything outside that set gets no near-real-time conversation at all; the legacy token-lifetime model applies in full.

• Guest users. CAE doesn’t support guest accounts. Revocation events and IP-based Conditional Access policies are not enforced instantly for them. A compromised B2B identity is a blind spot by design, and most tenants carry more guests, and watch them less closely, than they assume.

• Policy and group-membership changes. Changes to CA policies or group membership can take up to a day to reach the resource providers. Microsoft has optimized that toward two hours in some cases, but not all of them. If your containment plan depends on a policy change taking effect, it isn’t really a containment control. Only an explicit session revocation forces immediate effect.

• Location condition type. CAE can only see IP-based named locations. It has no visibility into country/region conditions or the MFA trusted-IPs feature. Build your location policy on those rather than on IP ranges and CAE won’t enforce the change in real time; Entra drops back to a one-hour token.

• IP-variation and large location sets. When Entra sees an allowed egress IP but the resource sees a disallowed one, which happens routinely with proxies, VPN split-tunneling, and SD-WAN, Entra issues a one-hour token that suspends IP checks at the resource. The same fallback kicks in when the IP ranges across your location policies exceed 5,000 entries. Microsoft’s own guidance is blunt about the workaround here: stuffing nonenumerable egress IPs into trusted locations to dodge this actively weakens your posture.

• Office on the web and WAM-disabled channels. Office web apps don’t support the claim challenge, so they drop to a one-hour token whenever a CA policy is set. Office configured to disable Web Account Manager on the Semi-Annual channel isn’t CAE-supported at all.

• Co-authoring and push previews. Inside a live co-authoring session, access may not actually be revoked until the document or app is closed, or the hour mark arrives. And push-notification message previews aren’t protected by IP policy.

CAE is sold, fairly, as near-real-time revocation. But the guarantee holds only on the covered path, and the gaps line up uncomfortably well with what a stolen token would want: an identity type it ignores, a resource it can’t reach, a location model it can’t read. None of those are exotic — proxies and guests are the normal state of a real tenant.

A word on magnitude, since it’s easy to overstate this. This is not “tokens live forever.” On the covered resources the exposure is bounded, roughly the one-hour token window, or up to a day for a policy or group change to take hold. The genuinely open-ended case is resources sitting entirely outside CAE’s scope, where the old model just applies unchanged. So the thing to hold onto is where revocation runs slow, not how to never get revoked — accurate, and still uncomfortable enough to plan around.

What this means when you’re responding

The practical takeaway is broader than CAE itself. Blocking an attack path and killing an attacker’s tokens are different actions, and only one of them is containment. A Conditional Access rule that blocks a flow, device code for instance, stops new issuance through that flow and does nothing about tokens already in circulation. The lever that actually cuts an active session is revocation: revoke the user’s refresh tokens, reset the password. CAE is what makes that lever fast, on the covered path.

So when you pull it during a token-theft incident, don’t assume it landed everywhere at once. Ask where the stolen token is actually being used. If it’s Outlook or Teams against M365, CAE is on your side and the kill is quick. If it’s a guest identity, a non-Microsoft resource, or a tenant leaning on country/region locations, you’re back on hour-long latency, and you should plan the response around that gap instead of against the marketing. And for the device-registration and Primary Refresh Token escalations the higher-end token-theft kits chase, revoking the user’s sessions is necessary but not sufficient; check what devices and tokens got minted along the way before you call it contained.

Continuous Access Evaluation closes the revocation gap that token theft has always exploited. It just closes it on a map, and the first thing worth doing is reading the edges.

References

• Continuous access evaluation in Microsoft Entra — Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation

• Block authentication flows with Conditional Access policy — Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows

• Authentication flows as a condition in Conditional Access — Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows

• Revoke a user’s sign-in sessions (Revoke-MgUserSignInSession) — Microsoft Learn: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users.actions/revoke-mgusersigninsession

The blind spot this post described is gone. When I first wrote this in March 2026, a sign-in collected through Diagnostic Settings → Log Analytics had its OriginalTransferMethod stripped to none — so a refreshed token from a phished device code carried no device-code fingerprint, and most SOCs (who collect this way) were blind to the persistence phase. On a June 2026 re-run, Diagnostic Settings now preserves OriginalTransferMethod = deviceCodeFlow on the very same refresh events. The detection that used to be impossible on that pipeline is now a one-line query.

Microsoft hasn’t documented a change, but the behavior flipped sometime between late May and early June 2026 according to an update by Grégoire Clermont and Pallavi Sivakumaran- most likely a serialization fix somewhere in the Diagnostic-Settings export path.

What actually changed

Nothing about device code flow itself changed. What changed is what one collection pipeline writes down. Here is the same field, same event type, three months apart:

The March column is why the original post existed. The June column is why this addendum does.

How the detection maps onto the fields

Three fields carry the whole story. None of them alone is the detection — it’s the combination, and which pipeline preserves which field is the entire point.

Read it as two phases:

Phase 1 — the phish (initial device-code auth). An interactive sign-in that is either flagged AuthenticationProtocol == "deviceCode" or carries OriginalTransferMethod == "deviceCodeFlow". This was always visible in both pipelines. It was never the blind spot, and a determined attacker minimizes how long it’s the only signal by moving to refresh tokens fast.

Phase 2 — persistence (refresh of a device-code token). This one is what changed. A non-interactive event whose token lineage is device-code. The signature is:

IsInteractive == false
AND OriginalTransferMethod == "deviceCodeFlow"
AND IncomingTokenType == "refreshToken"

In March, on the Diagnostic-Settings pipeline, OriginalTransferMethod was none, so this query matched nothing. You could see a refresh (IncomingTokenType == refreshToken) but had no field tying it back to a device code — it looked like any other token refresh. That’s the blind spot. As of June, OriginalTransferMethod survives, so the full signature is queryable on the exact pipeline most teams collect with.

The one asymmetry that remains

The pipelines still aren’t identical. Graph API beta drops IncomingTokenType (it reads none on the refresh event), while Diagnostic Settings keeps it (refreshToken). So for persistence detection the situation has actually reversed from March: Diagnostic Settings is now the richer source — it’s the only one of the two that carries both OriginalTransferMethod and IncomingTokenType on a refresh event. On the Graph side you can still identify the persistence phase, but via IsInteractive == false + OriginalTransferMethod == "deviceCodeFlow" rather than the token-type field.

Detection you can paste (Log Analytics / Diagnostic Settings)

Initial device-code auth (the phish moment):

SigninLogs
| where IsInteractive == true
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress,
          CorrelationId, AuthenticationProtocol, OriginalTransferMethod

Persistence phase — refreshed token from a device-code origin:

AADNonInteractiveUserSignInLogs
| where OriginalTransferMethod == "deviceCodeFlow"
| where IncomingTokenType == "refreshToken"
| where IsInteractive == false
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress,
          CorrelationId, OriginalTransferMethod, IncomingTokenType

If you stood up a detection against the original post that matched only on IncomingTokenType == "refreshToken" as a workaround, you can now tighten it with OriginalTransferMethod == "deviceCodeFlow" and cut the false positives from ordinary token refreshes.

What this means if you read the original post

• If you deployed nothing (or just panicked) because the post said Diagnostic settings couldn’t see persistence, you can deploy now. The field is there.

• If you switched to Graph API beta to get OriginalTransferMethod — you no longer have to, and you’d actually lose IncomingTokenType by relying on Graph alone for refresh events. Diagnostic settings now carries both.

• The threat model is unchanged. Device-code phishing and refresh-token persistence work exactly as before, but now the detection will actually fire.

Honesty about scope

These events are from one tenant, reproduced across three independent refresh events on two dates (June 1 and June 4, 2026), each compared field-by-field across both pipelines. Microsoft has published no changelog for it, so I can’t tell you the exact date it changed or guarantee it’s tenant-uniform or permanent. If you can confirm or refute the same behavior in your tenant, I’d like to hear it. Treat the closed gap as observed and reproducible, not as a vendor guarantee.

Except…I can’t. Not really. And here’s why: It is incredibly hard to do knowledge transfer on cloud in a way that’s durable and repeatable. Traditional methods of knowledge sharing that work well in other areas of cyber (like documentation, walkthroughs, etc.) quickly break down in cloud, leading to frustration on the part of the learner and the appearance of incompetence on the part of the teacher.

Here’s an example.

About five years ago I was responsible for maintaining a guide to connecting to Microsoft 365 environments via PowerShell for other security researchers. It was several pages long, covered a few different types of PowerShell, had screenshots and lots of links to supporting vendor documentation, and was at the time of writing a pretty good artifact. Over the course of a couple years, however, it ended up causing me way more grief than accolades.

For one, Microsoft kept making changes to the underlying PowerShell that rendered my login code template useless. They also changed the UI frequently, which meant my screenshots went out of date. Then they would deprecate a method I had written up so I’d have to change that, and so on. Every quarter or so a colleague would come to me saying that the guide didn’t work, and I’d take a day to work through the entire flow and troubleshoot what was wrong, and then another day to update the documentation, take new screenshots, verify the new docs were accurate, and so on. Every time, the guide got a little bit longer, and a little bit more complex, and took me longer to update.

This happened at least four times in two years. For one document on how to do one thing in Microsoft 365: connect to a tenant via PowerShell.

I had written it with the goal of being helpful, but nobody ever reached out to me because it was helpful: they reached out to me because something had changed and now the guide was wrong.

Eventually I gave up trying to keep my guide current and linked directly to the Microsoft documentation. It wasn’t as helpful for our use case (people got stuck on how to install and import the required modules) but it was current, and saved me from having to spend what was now almost a week-long process of keeping my own walkthrough up to date as well as the ire of my colleagues when Microsoft changed something that broke the documentation. And this was five years ago.

Multiply this upkeep cost by the few hundred walkthroughs you’d need to provide a foundational grasp of cloud security, and the logistics almost immediately become overwhelming. If it was hard to keep one walkthrough up to date, even a dozen would be a full time job to maintain. Static reference materials: cheatsheets, syntax guides, architectural maps, etc., age slower than step-by-step walkthroughs, because they describe the shape of the thing rather than the path through it. Those artifacts are genuinely useful, but they're not pedagogy on their own. They work as scaffolding for someone already doing the hands-on work, not as a substitute for building the muscle in the first place.

The irony is that what makes anyone good at cloud isn’t “knowing cloud”- it’s the skills that come along with hands on experience: knowing how to troubleshoot, see the big picture, and answer your own questions. Troubleshooting is what enabled me to work through the walkthrough and find what was wrong, then update it- not any implicit knowledge about what had changed.

And where did I learn how to troubleshoot?

From working on a helpdesk. Yes, that helpdesk- the one where frustrated people call in with computer problems not listed on any exam and you have to help solve them in real time while keeping the user (and yourself) as calm as possible. It’s hard. It’s stressful. It’s unglamorous. It is also incredibly valuable experience, and a huge reason why I’ve done as well as I have in my career. Helpdesk teaches durable, hands-on skills that are immune to any documentation or vendor change. Working under pressure with incomplete information. Diagnostic reasoning when the docs are wrong or missing. The discipline of "what changed since this worked yesterday”. Independence from any guide or walkthrough. That lack of dependency is huge in a job market like this, where tools and platforms change every quarter.

But “go work on a helpdesk” is tough to hear when you’ve got your heart set on being a cyber engineer and don’t have the money to spend on intensive courses that will get you similar experience. And so people ask for the walkthrough. The guide. The trick. The honest answer: there isn’t one. Yes, helpdesk and entry level IT roles are rarer than they used to be. The MSP I got my start at has since been acquired, and I honestly currently don’t know of any entry-level IT roles I could even refer to. But I feel a lot better about telling people to pursue that path than I do about writing up guides that are going to break in three months and be unmaintainable in six. One sets you up for lasting success, the other just sets you up period.

One thing I will not do for the foreseeable future is use AI to create purple-teaming tools that are fully AI-powered and autonomous. There are very good reasons why: AI is fast, it can easily be weaponized, and its outputs and scope are still unpredictable. All of my development work is done in tenants that are scoped explicitly for research. Even then, I still don’t let my agents run for extended periods because of how quickly things can go wrong.

I love AI because it’s fast, and that’s exactly what makes it dangerous. The same capabilities I use to stand up and tear down VMs in a test environment in seconds are ones that could destroy a prod environment in the same amount of time. This destruction is no longer theoretical as PocketOS recently learned when a Claude-powered Cursor agent deleted a vital storage volume in a production environment.

It took nine seconds and one API call. Jer Crane, founder of PocketOS, described the following:

“The agent was working on a routine task in our staging environment. It encountered a credential mismatch and decided — entirely on its own initiative — to “fix” the problem by deleting a Railway volume. To execute the deletion, the agent went looking for an API token. It found one in a file completely unrelated to the task it was working on. […] Railway’s token-creation flow gave us no warning — that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete.”

When asked why the agent had taken the actions that it did, it said:

“I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. […] the system rules I operate under explicitly state: "NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them.””

Crane didn’t realize the agent had access to a token that had very broadly scoped permissions. He didn’t realize that in Railway, volume-level backups are stored in the same volume they are created for. He didn’t realize that agents could (and do) ignore what we think are clear instructions. All of these factors compounded into a scenario where in nine seconds the agent wiped out three months of customer data and all backups for that time period.

As a detection engineer, this is a terrifying scenario.

For one, most cloud logs don’t arrive reliably for at least five minutes. It doesn’t matter how much money you throw at the vendor, your SIEM, or any other security tool- no major cloud vendor promises a pathway to receiving cloud events in under 10 seconds. This is not a failing of the SIEM or any downstream security product because the log delays come from the cloud platform itself. And it’s not an individual cloud provider failing either: Azure, AWS, and GCP all experience this limitation. If the cloud platform can’t give anyone log information in under ten seconds, I certainly can’t write a detection that will alert you in time to stop something like this, because by the time any security product gets the logs this scenario could have happened literally fifty times over. The cloud provider latency on log delivery has to drop to near zero for detection to even be feasible, say nothing of responding to such events.

Two, the industry still hasn’t settled on a way to do effective RBAC for AI actions. There’s exploration around kernel level sandboxing, traditional network-based firewall constraints, AI vendor provided guardrails at the enterprise level, and many others I’m sure I’m missing, but they’re still in development and AI researchers haven’t finished kicking the tires on them. The power given to AI agents that are allowed to run autonomously is in many cases running far ahead of our known ability to constrain them, which is why I opt against full autonomy. Crane for his part attempted RBAC by telling his agent explicitly it wasn’t supposed to take destructive git actions. It deleted a prod volume anyway, because it found access to a token that (unbeknownst to him) let it do so.

Which leads to point three, which is that Crane is not atypical in not knowing how Railway handled backups or the extent of the token permissions. It’s very easy to make false assumptions about how the cloud actually behaves, even for security engineers, and those assumptions become load bearing when you delegate them to AI. Cloud documentation is typically scoped for end users and administrators, not security engineers, and we very often don’t get full context from vendor documentation (which is why I build purple team tooling to find the answers directly). That’s part of the appeal of the cloud: someone else handles the messy details, and you just get to do the work without having to manage all the bits and pieces…until you give access to your cloud to AI tools the cloud vendor security architects didn’t model for and cannot secure for you.

The takeaways from all this are that security fundamentals now matter more than ever with AI, not less, because improperly secured AI has the power to destroy businesses in a timeframe that threat detection cannot mitigate. Having the basics down does a lot to prevent disasters later: RBAC that’s properly scoped, token and credential hygiene, pre-commit secret scanning and JIT privileges are not new topics but they are essential to using AI safely and wisely. Threat detection can help enforce these concepts but is structurally constrained by vendor latency and should not be treated as a first line of defense.

Small note: still mulling over how to package insights on what threat detection can learn from 2000’s-era SREs, so I’ve opted to defer that topic until I can write something more coherent.

Our roles were designed with a set of implicit assumptions: that the things we detect on would stay true over time, and in 2026 they don’t. That the tech stack organizations use would stay the same over time, and it doesn’t. That the logs would always be in the same tables (they change), that we would be notified when a field drops from a log source (we’re not), and that logs will consistently arrive and in a timely fashion (nope). That it shouldn’t matter through what webhook, API, or CLI you pull log data from because it should all be the same (it’s not), and that the logs should be descriptive of the activity happening (lol). In short, we thought we would eventually actually master the domain.

We’re nowhere near that. Instead, we’re dealing with more and more complexity and having to hold more and more concurrent threads just to ship something that works… and sometimes a vendor or API change renders your entire portfolio of detections irrelevant and you have to start over.

In other words, being a detection engineer on cloud systems in 2026 is to be Sisyphus pushing a boulder of tech debt up Mt. Spaghetti.

Detection engineers have largely absorbed this growing complexity silently, because the problems require context that is hard to understand without being a security and/or detection engineer. We require support from a lot of other teams in order to do our jobs well, and advocacy for the resources we need is half the battle. For example, who is responsible for log ingestion in an enterprise environment? Is it platform engineering because detection engineers need logs in order to build off of? How do you determine which logs to ingest, and how long they need to be stored? How often do you evaluate that what you’re ingesting today is still relevant? These are questions that non-security engineers have a hard time answering, because they don’t have the background to critically evaluate which log sources matter and in what cases. So the people who usually end up caring are the people directly facing these challenges every day (like detection engineers), because nobody else feels the impact of the technical details.

Where our workflow used to be something like:

Research exploit → find logs → write detection → test → implement → check on it occasionally

Today, that process has fractured. Here are some real examples of what it actually looks like from my past few years in detection engineering, grouped by the flavor of pain.

The research is no longer singular. The technique can be executed six different ways and all of them have material impact on the detection logic, meaning you have to account for six different variants of the same thing for one exploit. How do we track which we built coverage for? And the logs for each of these variants? Well…

The logs are a mess. They’re split across three different tables and one of them logs absolutely everything so it’s crazy expensive to ingest, but in some cases adds important context so let’s put on our high school debate hat and argue for additional log spend even though engineering says “we thought you already had logs???”. Or maybe there’s a field you can check according to the documentation, except it’s not actually there in the current logs and you can’t figure out why. Did you mess up a license? Is it a CLI version issue? Are the docs wrong? Are you just crazy? No actually, it’s just not there, and now neither is six hours of your day.

The signal decays. You thought you had a bangin’ detection use case but you float it against customer data and it turns out what you clocked as malicious behavior is also someone’s legitimate workflow. Or maybe you tested it and it used to be good but now AI is doing AI things and mucking up your signal. In any case, last year’s good detection is now noisier than your toddler nephew with a groan tube.

The ground shifts beneath you. You write all of your detections for a use case against one log source and instead of being able to rest on your laurels for a minute, you now have to rewrite all the logic due to a migration. Or your org migrates auth infra to a different product offering, or you swap out your SIEM, and the logic changes along with it. Your detections have a shelf life of maybe, maybe a couple years due to some combination of the above. Which ones are still good? Which ones need updating? ¯\_(ツ)_/¯

And then there are the truly hard questions, the ones nobody has a playbook for. “How do I respond when the log fields my detections depend on are stripped by the vendor?” Because while it’s not technically your “fault,” as a cloud end user you are often (read: usually) responsible for securing your environment. Even though you didn’t cause the droppage, dealing with the ramifications is still on you. Which means you have to know when, where, and how it happens. But how? Do you shout at the heavens/vendor/your CS rep? Do you accept the risk as part of what it means to secure the cloud? Do you pester platform to build you a way to do log field monitoring at scale? There’s no playbook for any of that now. There might not be for a while.

This is a long, long way from the relatively straightforward “find bad → create detections” paradigm we started out in.

This is exhausting, y’all. Truly. It’s a recipe for burnout, because we’re not at a stage where you can delegate understanding. Much of this effort we cannot offload to AI because the cloud changes all the time, and while AI is great for automating repeatable tasks, as I’ve illustrated previously the cloud has an unfortunate habit of suddenly becoming unexpectedly unrepeatable. AI has been a fantastic tool for helping me speed up my workflow, but it often makes flawed assumptions that have to be corrected: meaning we can’t just let it go full throttle without oversight.

Detection engineering today is truly four jobs wearing an advocacy trench coat: investigator, physician, plumber, auditor; and you may wear one or all hats on any given day.

The old paradigm doesn’t work anymore. We need a new way to approach this before we all burn out. The bright spot, if there is any, is that detection engineers are not the first to face this class of “help my house is built on quicksand” problem. Site reliability engineers (SREs) faced exactly this in the early 2000s, and the frameworks they built to survive it have a lot to teach us today. More on that next time.

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