The Security Bridge™️- Identity Threat Protection in Microsoft 365 - Part 4: How to Prove Defender XDR Can See Identity Attacks

In December 2024, Microsoft published results showing Defender XDR achieved 100% technique-level detection coverage across every attack stage in that year's MITRE ATT&CK Evaluations: Enterprise. In June 2025, Microsoft announced it would not participate in the 2025 edition, a decision it attributed to focusing resources on its Secure Future Initiative. SentinelOne and Palo Alto Networks made the same call three months later.

A test result, or a vendor's absence from one, is a statement about a lab environment running a specific attack chain, not about your own tenant. It doesn't describe whether your Defender for Identity sensors are actually seeing traffic from your domain controllers, or whether your SaaS connectors are actually connected. Enabled does not mean effective. Visibility must be validated.

Difference Between Enabled and Validated: While "Enabled" indicates an active license and deployed sensor, "Validated" requires end-to-end alert confirmation, highlighting the need for testing to confirm detection.

What "enabled" actually covers, and what it doesn't

Defender XDR unifies Defender for Identity, Defender for Endpoint, Defender for Cloud Apps, and Microsoft Entra ID Protection. Each component has its own coverage prerequisites: Defender for Identity needs sensors deployed on domain controllers and AD FS/AD CS servers, Defender for Cloud Apps needs SaaS app connectors configured per application, Entra ID Protection needs the tenant actually connected. A license being active across all four doesn't mean all four are reporting meaningful telemetry.

Microsoft's own industry-test documentation makes a version of this same point. It states that independent tests cover a fraction of the real threat landscape, and that isolating any single component from the rest of the security stack gives a partial picture of how the product performs in a live environment. That's the vendor's own documentation making the case for validating your own tenant instead of citing a score.

The native validation surface: Coverage and maturity

Defender XDR has a built-in answer to this, currently in preview. The Coverage and maturity page, under Identities in the Defender portal, scores identity coverage from 0 to 100 across four tiers: Connected (initial visibility, partial protection), Protected (sensors and connectors deployed, some gaps remain), Fortified (broad hybrid and multicloud coverage including non-human identities), and Resilient (full coverage across all identity types). It breaks the score down by identity providers, on-premises identities, SaaS identities, and PAM/IGA integrations, and ranks the highest-impact, lowest-effort setup tasks first. Accessing it requires a Defender for Cloud Apps or Defender for Identity license and at least the Security Reader role.

This is Microsoft's own acknowledgment that "deployed" and "protected" are different states with a measurable gap between them, and this page is built to close that gap.

Microsoft Defender's "Coverage & Maturity" dashboard displays a comprehensive view of identity protection across on-premises, cloud, SaaS, and partner environments. The maturity level is fully resilient at 100%, with all recommended improvement tasks completed. The coverage includes 8 protected human identities and 50 protected non-human identities from identity providers, and 432 protected human identities from SaaS applications, all achieving 100% coverage.

A sensor can be running and still not seeing what matters

Defender for Identity's Health issues page documents specific, named failure modes that don't stop a sensor from showing as active: "No traffic received from domain controller," "Some Windows events are not being analyzed," "Some ETW events are not being analyzed," required auditing (Advanced Auditing, NTLM Auditing, the Configuration container) not being enabled, and a network configuration mismatch on sensors running on VMware that limits how much traffic the sensor can capture. Every one of these is a documented health issue, not a sensor outage, so the sensor keeps showing as active while the actual signal reaching it is incomplete.

A sensor reporting healthy status answers "is it running." It doesn't answer "can it see the technique I'm worried about."

The Microsoft Defender dashboard highlights key Identity Security alerts, indicating three instances where sensors have ceased communication, flagged as medium severity and currently open for review.

What this looks like in production

It's a common pattern for organizations that license Defender for Cloud Apps to connect only the SaaS applications configured during initial rollout. Every application adopted afterward, plus anything shadow IT brought in on its own, stays outside that connector list. The Coverage and maturity page's SaaS card is built around exactly this gap: it scores connected apps against total apps discovered in the environment, so a tenant can carry the license for years while the score reflects a fraction of what's actually in use.

I worked with clients who had deployed Defender for Identity sensors to domain controllers and AD CS servers, which looks like a complete deployment from the sensor list alone. What hadn't been done was configuring the Group Policy Objects required to generate and correlate the audit events those sensors depend on, so the sensors were running with a fraction of the signal they needed. Separately, several of the virtual machines hosting sensors had a VMware network configuration issue that Defender for Identity documents as a known health issue, which limited how much traffic the sensor could actually capture. Both issues sat as open health issues rather than sensor outages, which is exactly why they went unnoticed as long as they did.

It's also common for a security team to treat "Defender for Identity is deployed and licensed" as equivalent to "this technique will generate an alert," without ever running a controlled test to close that gap. The assumption typically holds until an actual incident tests it for the first time, or until a deliberate purple-team exercise tests it on the team's own schedule instead.

Business case

A validated detection gap costs less to close on a Tuesday afternoon than during an active incident. A control that looks complete on a dashboard and a control that's actually been proven to work under test are two different levels of assurance, and the difference between them is exactly the gap an attacker operates in.

What to validate this week

• Review the Coverage and maturity page under Identities in the Defender portal and address the top-ranked setup tasks by impact and effort

• Check both the Global health issues tab and the Sensor health issues tab for Defender for Identity, not just whether sensors show as active

• Confirm required Windows and Active Directory auditing (Advanced Auditing, NTLM Auditing, Configuration container auditing) is actually enabled, since sensors depend on it upstream

• Run a controlled identity attack simulation against a known technique and confirm an alert fires end-to-end, not just that a log entry was generated

• Track maturity tier progression (Connected, Protected, Fortified, Resilient) as an ongoing operational metric, not a one-time deployment checkbox

• Treat vendor-reported test results as context for your decision, not proof of your tenant's own detection posture

Alert detail screen in Microsoft Defender showing a medium-risk threat labeled as "Suspected account enumeration (Kerberos, NTLM, AD FS)." The alert provides recommendations for validation, scoping the incident, and mitigating the breach, involving two devices.

The takeaway

Enabled does not mean effective. Visibility must be validated. A license, a deployed sensor, and even a strong industry test score all describe a product's capability. None of them describe whether your tenant will generate an alert the moment it matters. Part 5 turns this validation work into something repeatable: the Identity Threat Protection Scorecard, a framework for measuring where a program actually stands and making that case to the people who fund it.