For most of its life Defender for Identity was described as the on-premises member of the suite, the sensor you put on domain controllers to watch Active Directory while the cloud products watched everything else. That description is now wrong in a way that changes how you design with it. The product has two ends. One end is a fleet of sensors on the servers that make up your identity fabric. The other end is the cloud directory itself, where Defender for Identity now detects attacks with no sensor anywhere near them. Reason about it as one end and you will misjudge both what it covers and what it costs to run.
What the fabric actually is
The identity fabric is not one server role, it is four, and the sensor knows the difference between them. Domain controllers are the obvious ones, the authoritative store of accounts and the place Kerberos and NTLM authentication actually happen. Around them sit the servers that extend that authority outward: the federation servers that broker sign-in to relying parties, the certificate authority that issues the credentials a certificate-based attack forges, and the directory-sync servers that carry your on-premises accounts up into the cloud. Each of those is a distinct attack surface with its own class of abuse, and each is a place the sensor can be told to watch. When I talk about the fabric I mean that whole shape, controllers plus the federation, certificate, and sync infrastructure around them, because an attacker who cannot get a domain controller will happily settle for the certificate authority or the sync account instead.
The other end has no sensor
The change that dates the old description is that Entra ID is now a first-class detection surface for this product, not a signal it borrows from somewhere else. Through 2026 Microsoft shipped wave after wave of cloud-native identity detections that carry the Defender for Identity name and require no on-premises sensor at all: adversary-in-the-middle consent abuse, stolen session cookies replayed against the cloud, conditional access bypassed through a non-compliant device, a guest quietly promoted to member, an account created and handed Global Administrator in the same breath. Microsoft’s own definition now reads that the product monitors identity signals from on-premises Active Directory, from Entra ID, and from other identity providers such as Okta. The sensor is one end of the product. The cloud directory is the other, and it is not ambient context, it is a place the product hunts.
There is a subtlety here worth getting right, because it is the kind of thing that quietly corrupts a mental model. The cloud detections do not arrive through the sensor. Cloud sign-in telemetry reaches the identity picture through Defender for Cloud Apps and the wider correlation fabric, not up through a domain controller. So the accurate way to hold it is that the sensor reads the on-premises fabric, the cloud reads itself, and the two meet in the unified identity view rather than one feeding the other. Anyone still carrying the belief that the sensor ingests Entra ID sign-in logs is carrying a diagram that was never true and is now actively misleading.
The sensor became part of the endpoint
The second structural change is quieter and has larger consequences for how you deploy. The current sensor, the third-generation one, is not a standalone product you install. It is a capability of the Defender for Endpoint agent, delivered as a component of that agent and updated through the same Windows servicing channel. A domain controller that is onboarded to Defender for Endpoint can have the identity sensor activated on it from the portal, with no separate installer, no capture driver, no service account. Identity sensing has folded into the endpoint platform.
That fold is a design gift and a design obligation at once. The gift is that the sensor now rides the same onboarding and the same streamlined connectivity the endpoint estate already uses, so a controller becomes an identity sensor through machinery you stood up in the endpoint onboarding work rather than a second, parallel deployment. One agent, one network path, one servicing model. The obligation is that the identity sensor now inherits the endpoint’s prerequisites, including the requirement that the controller itself be onboarded to Defender for Endpoint, and inheriting the endpoint’s prerequisites means inheriting a licensing question the documentation has not cleanly answered.
The licensing shape, including the part nobody has answered
Defender for Identity is a per-user subscription. It rides in the E5 tiers, in the renamed Microsoft Defender Suite that used to be the E5 Security add-on, and as a standalone license. The detail worth stating out loud, because it is the exact inverse of the trap the suite anchor warned about for the endpoint product, is that Enterprise Mobility and Security E5 includes Defender for Identity. The endpoint pillar’s most common licensing error is the shop that says “we have EMS E5” and assumes it owns Defender for Endpoint, which EMS E5 does not carry. For identity the same sentence is true rather than false. An EMS E5 estate owns Defender for Identity and Defender for Cloud Apps and does not own Defender for Endpoint. Say it in both directions once and the asymmetry stops catching people out.
Then there is the question the current sensor creates and Microsoft has not resolved in writing. The third-generation sensor requires its domain controller to be onboarded to Defender for Endpoint. The endpoint product’s own rule is that onboarding a server, and a domain controller is a server, requires a server license rather than a per-user one. What no Microsoft source states plainly is whether the per-user Defender for Identity subscription satisfies that server-onboarding requirement on the controllers you run it on, or whether a separate server entitlement is also in play. The general availability announcement gestures at controllers onboarded to Defender for Endpoint for Servers; the licensing pages, the FAQ, and the service description are all silent. I flag this rather than paper over it because it is a real budget line on a real project, and the honest position is that the documented pieces point at a server entitlement while nobody has confirmed it. Confirm it through the Product Terms or your account team before you size a rollout on the assumption that the identity license covers the controllers outright.
One boundary to keep clean while we are here. Risk-based conditional access and the cloud identity risk engine belong to Entra ID Protection, which is an Entra ID P2 capability and the subject of the Entra ID Deep Dive, not this series. Defender for Identity does not require P2 and protects on-premises accounts that never sync to the cloud at all. The two products meet on the unified identity page and in the incident graph, but they are licensed and reasoned about separately, and this pillar is careful to stay on its own side of that line.
The map ahead
The rest of the pillar follows the two ends and the work between them. First the sensors: the current generation that rides the endpoint agent on modern controllers, the previous generation that still earns its place on the servers the new one cannot yet run on, and the deployment decisions that separate them, which is also where the build sheet for standing up the estate lives. Then the detections and the response actions, the alert queue an operator actually works and the two very different surfaces from which an account can be disabled. Then identity posture, the standing assessments that tell you which of these attacks your own configuration has left open, and the honest account of what happened to lateral movement paths, which are not what they were. The attack-disruption machinery that ties identity response into the wider fabric, and the way posture rolls up across the whole suite, belong to later pillars and are noted where they touch. The cloud end, the one with no sensor, gets its own treatment once the estate is built, both a map of what is automatic and what you still connect by hand, and the honest question of how you prove a surface you never had to install. We start with the sensors, because until the fabric is instrumented the rest of it is theory.
Defender XDR
‹ Previous: [D 2.5.1] Wiring Risk to Access: Connector, Compliance, and the CA Gate
Next: [D 3.1] Sensors: One Fleet, Two Generations ›
