You will run two generations of sensor at the same time, and that is not a transitional embarrassment to apologize for, it is the supported steady state. The current generation is the right answer for modern domain controllers and the previous generation is the right answer for the servers the current one cannot yet run on. The skill is not picking a winner, it is knowing which machine belongs to which generation and why, because the two are so different underneath that a habit carried from the old one will quietly break the new one.
Two generations, and what actually separates them
The previous-generation sensor is a product you install. It carries its own setup, a packet capture driver, a service account, a sizing calculation, and a service you update on a schedule. The current-generation sensor is none of those things. It is a capability of the Defender for Endpoint agent, activated from the portal on a controller that is already onboarded to Defender for Endpoint, updated through Windows servicing rather than a sensor updater, and governed by a resource ceiling the platform enforces for you. The difference is not a version bump, it is a change of substrate. The old sensor watches the wire through a capture driver. The new one reads Windows events and event tracing on a machine that is already an endpoint sensor. Everything downstream of that, the identity it runs as, the way you configure auditing, the way you plan capacity, follows from that one change and is why a mental model built on the old sensor misleads you on the new one.
Where each generation belongs
The line Microsoft draws is clean enough to design against. The current sensor runs on domain controllers, and as of 2026 it runs on domain controllers whatever else they host, including controllers that also carry the federation, certificate, or directory-sync roles. What it does not yet run on is a server that is not a domain controller. So a standalone federation server, a standalone certificate authority, a standalone sync server, and any domain controller still on Windows Server 2016 or earlier remain the previous generation’s territory. Read that boundary carefully, because the headline that the current sensor now supports all identity roles is true only for those roles when they sit on a domain controller. Move the same role onto its own box and you are back on the previous generation. The rule that survives contact with a real estate is short: current generation for every 2019-or-later controller, previous generation for standalone identity servers and the old controllers, and no guilt about running both. A question that surfaces the moment any of this runs in Azure is worth closing here: a domain controller hosted on an Azure virtual machine is a fully supported sensor target, because eligibility is a question of the Windows build and the endpoint onboarding rather than where the machine physically runs, and Azure Arc is simply irrelevant to it.
There is no deprecation clock on the previous generation. Microsoft has published no end-of-life for it, and the mixed estate is documented as a first-class arrangement in which both generations report to the same workspace. That matters for planning because it means you are not racing a countdown. You migrate the controllers that can move and you leave the standalone servers where they are, indefinitely if that is what the estate calls for.
Activation and migration are not the same door
This is the distinction that trips up an otherwise careful rollout. Standing up the current sensor on a fresh controller is activation, and activation supports controllers that carry the extra identity roles. Moving an existing previous-generation controller onto the current sensor in place is migration, and migration is documented as supported only on pure domain controllers, the ones with no additional identity roles. The two paths have different eligibility, and the migration path is the narrower one. A controller that also runs the sync role can be activated onto the current sensor directly but cannot be migrated onto it in place, which in practice means uninstalling the old sensor and activating the new one rather than clicking a migrate button. The documentation itself lags here, with the migration page still carrying an eligibility line the activation guidance has already moved past, so the safe habit is to treat activation and migration as separate decisions with separate rules and to read the current page for the machine in front of you rather than assume they behave alike.
The prerequisite that gates the current sensor is a recent Windows Server cumulative update, and the important thing about that floor is that it moves. Microsoft has walked it forward with sensor releases rather than fixing it to one build, so a cumulative-update requirement you saw quoted a quarter ago is probably already stale. Do not hard-code a build number into your runbook. Read the current floor off the deployment page at the time you deploy, because on this specific requirement the documentation is the moving part and your notes are not.
The identity the sensor runs as
Here is the change most likely to break a habit. The previous generation wanted a directory service account, ideally a group managed service account, and that account was load-bearing: it was how the sensor read the directory, reached the deleted-objects container, and queried across domains. The current generation uses none of that. It runs as the machine’s own local system identity for everything, directory reads and response actions alike, and it does not use a directory service account or a group managed service account at all. That is a genuine simplification, one fewer credential to create, rotate, and protect, but it has two sharp edges in a mixed estate.
The first edge is that the workspace-level service-account configuration is still validated against every sensor, including the current-generation ones that ignore it, so a stale credential left configured after you have moved on will raise false alarms on sensors that were never going to use it. Remove the workspace service account only once the last previous-generation sensor that needed it is gone. The second edge is sharper and quieter. If you have configured a dedicated group managed service account for response actions, the current sensor will not use it, and worse, leaving it configured breaks response actions on the current sensor, including the automatic containment that the wider fabric depends on. The setting to reach for is the one that tells the workspace to use the sensor’s own local system account for actions, and Microsoft documents it as required for the current sensor and recommended everywhere. On a mixed fleet, set it before you activate a single current-generation sensor, not after you notice containment silently failing.
Auditing stopped being a project
For years the least loved part of a Defender for Identity deployment was the audit-policy work: the advanced audit subcategories, the NTLM auditing, the object-level auditing on the directory, all of it delivered by Group Policy and all of it easy to get subtly wrong in a way that silently starved detections of the events they needed. The current sensor turns that into a toggle. It can configure and continuously maintain the required Windows auditing itself, checking and correcting the settings on a daily cadence and raising a health alert when something has drifted, and in 2026 that self-configuration extended to the federation, certificate, and sync roles as well. The previous generation still expects you to do that work by hand, through Group Policy or the configuration module, so auditing becomes one more axis on which the two generations differ: on the current sensor it maintains itself, on the previous one it remains your responsibility. Where the current sensor is eligible, letting it own its own auditing removes an entire category of quiet misconfiguration from the estate.
Capacity, connectivity, and the honest limits
Capacity planning is now a previous-generation concern. The old sensor sat inline enough that you sized it with a calculator against your busiest traffic; the current sensor reads events and governs its own resource use against a fixed ceiling, so the sizing tool simply does not apply to it. Scale rose in step: a workspace now carries far more sensors than the old limit, which removes a ceiling that used to matter for large forests. Connectivity is the same simplification the anchor pointed at, because the current sensor uses the very same service endpoints as Defender for Endpoint, including streamlined connectivity, so an estate that already sorted its endpoint egress has already sorted its identity egress. The previous generation keeps its own dedicated endpoint and its own proxy configuration, and it does not tolerate TLS inspection on that path, which is worth knowing before a network team helpfully points an inspection appliance at it.
Be equally honest about what the current sensor gives up, because the list is short and specific rather than vague. It does not support the VPN integration the previous sensor offered, it does not send syslog notifications, and it has limitations working over ExpressRoute. That is the entire documented gap. There is no published feature-parity matrix beyond those three items, which means the responsible phrasing is that nothing else is documented as missing, not that the two are identical. If your estate leans on the VPN integration or on syslog, those needs pin the affected coverage to the previous generation until Microsoft closes the gap, and that is a legitimate reason to keep a previous-generation sensor in place rather than a failure to modernize.
Where this goes next
Two generations, one fleet, split by machine rather than by preference: current sensor on modern controllers with its auditing and its identity handled for it, previous sensor on the standalone servers and the old controllers where it still earns its keep. That is the estate. Standing it up in practice, the activation and installation steps, the service account where the previous generation still needs one, the action-account setting that saves you a silent failure, and an end-to-end test that proves a detection actually reaches the queue, is the work of the build sheet. But an instrumented fabric is only worth the instrumentation if you know what it is telling you, so the next article turns from the sensors to the queue they feed: the detections, the way they are organized now, and what you can actually do about an account when one of them fires. That is where we go next.
Defender XDR
‹ Previous: [D 3] Defender for Identity: The Identity Fabric Has Two Ends
Next: [D 3.1.1] Build Sheet: Standing Up the Sensor Estate ›
