In my series “Detect threats using *GraphActivityLogs” I covered a lot of the basics on how to use different methods to detect certain reconnaissance tooling based on fingerprinting the specific sequence of requests or the volume of requests made to the Microsoft Graph endpoints. But one of the biggest detection gaps in all this was the Azure AD Graph, the old API on a retirement path that started before some of you might work in cyber security. All this changed in early May 2026 with the introduction of the AADGraphActivityLogs as a new log source. And don’t get me wrong, this table was in the official documentation since May 2025 but no data was flowing. After a long private preview Microsoft, almost silently released the log to all their customers and gave them crucial insights in one of the most abused protocols for reconnaissance. Notably toolkits like ROADtools and AADInternals use this API to gather deep insights into the tenant and attack vectors like the Intune Company portal Conditional Access bypass rely on the default grant to this resource.

In Entra ID, Conditional Access acts as the gatekeeper to any token material. Regardless of whether you want a bearer token or a refresh token, Entra ID will be the entity creating and signing them. But not before Conditional Access has checked your identity, device and network for different conditions. This is the reason why this security measure is the cornerstone of Microsoft’s zero trust architecture and any holes in this construct can have far reaching consequences.

When Nathan and I released XDRInternals one of the biggest shortcomings for me was the lack of workload identity support. Since we are using the native API of the Defender portal only delegated permissions are supported, which makes it very hard to automate things in a pipeline.

But the fact that it makes it very hard should not prevent you from doing it. Security considerations and common sense are the reasons you should not do it, but let’s throw them overboard for the fun of it.

In Microsoft Entra, Conditional Access is, after the Authentication itself, the most crucial part of defense against attackers. It’s referenced as “zero trust policy engine” and the idea behind is, that in addition to your username and password you can also enforce additional requirements when you access a specific resource.

This could be any combination of

• a second factor (2FA),
• a specific authentication method (e.g. passkey)
• a device that is in a “compliant” state
• a trusted or compliant network

and a lot more, depending on your specific use case.

This blog post is a sleeper. I documented it in 2023 and never came around to publish it. The post was always too short in my opinion, too niche. But today Jonathan Bourke reached out on Twitter and asked why he was getting this strange error message when trying to connect a new Sentinel workspace to his XDR instance.

For a long time now, defenders had the ability to monitor behavior of human- and workload identities in Entra tenants not only through AuditLogs but with high level of insight with the MicrosoftGraphActivityLogs logs. The last two articles of this series gave you detection ideas and hunting queries for this logs source and were meant as a kick starter for detection engineers. But in the end the high cost of this log prevented many companies from putting it into operation. This is about to change with the release of GraphAPIAuditEvents logs in the XDR portal.