Microsoft has enhanced Defender for Identity with the introduction of the new v3.x sensor, designed to simplify onboarding and streamline configuration. This update makes deployment faster and more efficient.

Previously, migrating from v2.x to v3.x was a complex process that often required downtime and significant manual effort. With the latest improvements, Microsoft now offers an automated migration experience that reduces operational overhead and minimizes disruption.

What is new?

You can migrate your Defender for Identity sensors from v2.x to v3.x directly through the Microsoft Defender portal. The migration process automatically handles the switchover while preserving your server configurations and security monitoring, with no downtime or data duplication.

Before performing the migration, the server must have the following prerequisites:

  • A domain controller, without additional identity roles running
  • Running a Defender for Identity sensor v2.x.
  • Running Windows Server 2019 or later.
  • Includes the March 2026 or later cumulative update.
  • Have Microsoft Defender for Endpoint deployed.

Without the cumulative update from March 2026 or later, it will not work, and the migration will end with errors. For the full list of v3.x requirements, see Defender for Identity sensor v3.x prerequisites.

3.x agent?

A few months ago, Microsoft announced the long-awaited unified identity and endpoint sensor, one of the most frequently requested features by customers. A common question over the years has been why Defender for Endpoint and Defender for Identity require two separate agents. Microsoft has been working to address this by moving toward a single, unified sensor for Defender.

Like many security solutions, Microsoft Defender relies on sensors to provide visibility into endpoints and on-premises identity infrastructure across your environment.

Differences?

When Microsoft refers to version 2.x, it is referring to the Defender for Identity sensor, which must be installed as a separate agent and configured on the system.

Version 3.x is the latest release and leverages the Defender for Endpoint (EDR) sensor instead. Defender for Identity v3.x introduces significant improvements and collects events in different ways, eliminating the dependency on name resolution.

V2.x agent:

How to start the migration?

The migration from sensor v2.x to v3.x can be initiated directly from the Microsoft Defender portal. The process automatically completes the switchover while preserving your server configurations and security monitoring, with no downtime or data duplication.

Before starting the migration, it is important to verify that the machine meets all prerequisites and is ready for the upgrade.

Machine not ready:

If the domain controller or sensor isn’t ready, the migration state will show: “Not ready for migration.”

Machine ready:

When the domain controller or sensor is ready, the status is shown as: “Ready for migration.”

If the sensor remains in the state “Not ready for migration,” verify that the machine meets all required prerequisites and is fully up to date. When the status is not changing, start by installing the latest cumulative update (CU) and ensure the following conditions are met:

  • The server is a domain controller without any additional identity roles installed.
  • It is running Microsoft Defender for Identity sensor v2.x.
  • The operating system is Windows Server 2019 or later.
  • The system includes the March 2026 (or later) cumulative update.
  • Microsoft Defender for Endpoint is deployed and active.

In some cases, the issue is caused by an outdated Defender for Endpoint sensor. Make sure the SENSE service is updated to the latest version. This is a scenario that has been observed across multiple customer environments.

Migration of the sensor

You can now perform the migration using the built-in migration wizard. Simply select the sensor and click the “Migrate” button to initiate the process.

Now select “Migrate“

Before the upgrade:

Before the update, the sensor version was 2.255.19201.14651. Once the migration is started, it typically takes around 20 minutes to complete, after which the v3.x sensor is installed.

During the migration:

During the migration, the following runtime behavior will be run as part of the migration progress:

  1. Migration state changes to Migrating
  2. Classic sensor stops on the machine and is disabled
  3. Unified sensor (v3) starts on the machines

After upgrade:

After the upgrade, the ‘migration state’ is showing the status “Already V3 sensor”. The following is visible:

  • Sensor version/ Service status and health reflect the new sensor
  • The classic sensor stopped on the machine

To validate of thew v3 sensor is running. On the local machine, the SenseIdentity.exe and Microsoft.Tri.Sensor.Updater.exe can be validated. Both new services must be in the running state. The old one: Microsoft.Tri.Sensor.exe must be in the stopped state.

Old servicesNew services
Microsoft.Tri.Sensor.exeSenseIdentity.exe
Microsoft.Tri.Sensor.Updater.exe

Post migration sensor steps

After the migration, a couple of items need to be validated and checked. For the agent, the following is important:

  • Uninstall Npcap
  • Remove Classic V2.x sensor (might require a restart on the machine)

Classic sensor can be deleted when the sensor is reporting version 3 and is healthy and running; all tests the removal first, since it can require a reboot.

Enable RPC auditing

Remote Procedure Call (RPC) is a foundational protocol in Windows environments, enabling communication between services, domain controllers, and client machines. While it powers critical functionality, it also creates a rich surface for attackers to exploit, especially in Active Directory environments.

Microsoft Defender for Identity relies on deep visibility into authentication, authorization, and directory service behaviors. When the V3 sensor is installed, RPC auditing is not enabled by default and needs to be configured.

NOTE: RPC auditing is only available for the V3 sensor and needs to be enabled via the tagging mechanism.

How to configure?

Applying the Unified Sensor RPC Audit tag to a device improves security visibility and unlocks more identity detections. For RPC auditing the tag needs to be:

Unified Sensor RPC Audit

There are a couple of ways to apply the tag:

  • Manual via Defender assets
  • Via asset rule management
  • Via API

Personally, I would prefer to use the Asset Rule Management to automatically include existing and future devices. My best practice is to tag machines first with the tag “Domain Controllers” in Defender and use the “Domain Controllers” tag in the asset rule. The benefit of the Domain Controllers tag in Defender is visibility in Defender and as part of incidents. There are many ways to get the tag applied.

Asset rule

  1. In the Microsoft Defender portal, navigate to: System > Settings > Microsoft Defender XDR > Asset Rule Management.
  2. Select Create a new rule.
  3. Add the Unified Sensor RPC Audit tag to the selected devices.
  4. Define the condition

Make sure as action of the rule is the “apply a tag” action:

Event auditing

Defender for Identity is crucial for capturing events, alerting on MDI threats, and collecting information from on-premises systems through the installed sensor. For environments still running on-premises, ensuring Defender for Identity runs optimally is key to effective attack disruption and complete visibility into identity threats.

One of the most common issues with Defender for Identity is policy misconfiguration. While installing the sensor itself is straightforward, the real challenge lies in configuring the correct Windows Event audit policies to enable full detection capabilities. Without the correct Windows Event policies, it will not give full visibility.

For version 3.x auditing is still needed. One of the features as part of the 3.x agent is the automatic event configuration feature, this will automatically enable audit events without manual configuration.

Automatic event configuration

With the V2 sensor, all audit configs must be configured manually; this includes audit events, NNR, and a specific audit policy for additional detections. Automatic windows auditing performs all configuration tasks automatically:

  • Checks the current Windows event auditing configuration.
  • Identifies any gaps in the configuration.
  • The sensor applies any necessary changes, including all of the steps in the manual configuration:
    • Directory services advanced auditing: Adds audit entries to the domain root object’s System Access Control List (SACL) to enable required directory service auditing.
    • NTLM auditing – Uses standard Windows Registry APIs to configure the required NTLM auditing registry values.
    • Domain object auditing – Modifies the SACL on the Configuration partition to capture changes to directory service configuration objects.
    • ADFS auditing – Adds audit entries to the object’s System Access Control List (SACL) of the AD FS configuration container, to enable auditing of AD FS-related directory objects.
    • Windows audit policy – Configures the local Windows audit policies using the Windows Local Security Authority (LSA) audit policy APIs.
  • Applies auditing settings directly to the local system policy of the domain controller.

The good news; it is all deployed automatically, so no auditing policies via GPO anymore for V3.x versions. The audit policies are deployed directly via Defender as a local audit policy through the Defender agent.

How to enable automatic Windows auditing?

In the Microsoft Defender portal, go to Settings, and then Identities. In the General section, select Advanced features.
Turn on Automatic Windows auditing configuration.

If you don’t turn on automatic Windows auditing, you must configure Windows event auditing either manually or using PowerShell. Both V.2 and V.3 versions need to be configured with the correct audit policies. When automatic Windows auditing is enabled, V3 will be configured automatically.

gMSA action account !Important!

One important detail about Microsoft Defender for Identity isn’t clearly documented on Microsoft Learn, and it can have a real impact on security operations and protecting user accounts.

Historically, using a Group Managed Service Account (gMSA) for action accounts was optional. Microsoft has long recommended sticking with the default LocalSystem account, but organizations that preferred gMSA could still configure it without major issues. That situation has now changed with the introduction of the v3 sensor.

If you’re still using a gMSA configuration for action accounts, here’s the key takeaway: it no longer works with the v3 sensor. When gMSA is configured, response actions will fail. Because response actions are essential for capabilities like attack disruption, it’s critical to validate your action account configuration.

What this means:

  • gMSA for action accounts is no longer just “optional” – it’s effectively unsupported in v3 scenarios
  • Keeping a gMSA configuration in place will break response actions
  • To ensure full functionality, you must use the LocalSystem account

Not working: When the checkbox “Manually configure your management accounts” is checked the actions will fail

Working: When the checkbox “automatically use the sensor’s local system account” is checked it will work.

Sources

Microsoft: Migrate from sensor v2.x to sensor v3.x (Preview) – Microsoft Defender for Identity | Microsoft Learn