What is Microsoft Defender for Identity? Differences between E3/E5 and On-Premises AD Protection
About this article
This article was created using an automated generation workflow utilizing generative AI. Based on Microsoft official information as of September 17, 2026, it organizes the role of Microsoft Defender for Identity, its positioning in Microsoft 365 E3/E5, and key initial check points from a practical perspective.Verification Status: 📘 Microsoft Official Information Verified / Physical Device Unverified
Microsoft Defender for Identity is a security product that uses signals from identity infrastructure such as Active Directory to detect and investigate compromised identities, suspicious authentication, lateral movement, and more. Integrated into the Microsoft Defender portal, it plays a role in tracking identity-based attacks that are difficult to spot using devices or email alone.
How do E3 and E5 differ?
| Item | Microsoft 365 E3 | Microsoft 365 E5 |
|---|---|---|
| Defender for Identity | Not included by default | Included |
| Microsoft Entra ID | P1 | P2 |
| Defender for Endpoint | Plan 1 | Plan 2 |
When using Defender for Identity in an E3 environment, consider additional licenses that cover the target users. Microsoft's official sensor requirements as of 2026 specify Microsoft 365 E5, EMS E5, applicable Security SKUs, or standalone licenses.
What does this product monitor?
Defender for Identity is not simply antivirus for AD servers. It collects identity-related activity from domain controllers and analyzes the relationships between users, devices, and authentication as an attack chain.
For example, you can investigate unusual authentications, unnatural privilege usage, credential-targeting activities, and lateral movement by combining information from other Defender products.
Try First: Check Status Only Without Making Changes
Instead of adding sensors from the beginning in a production environment, if the environment is already deployed, open Settings > Identities in the Microsoft Defender portal and verify sensor status and health.
Check points here:
Are the sensors Healthy?
Are there any monitored domain controllers missing?
Are there any remaining health issues?
Are identity signals associated with Defender XDR incidents?
For your initial check, do not modify settings or suppress alerts; limit your actions to observation.
Change One Thing
If you have a test environment, cross-reference sensor requirements and the current OS/update status for a single target server before changing alert settings. Microsoft's official information for 2026 recommends the newer v3.x sensor for domain controllers running Windows Server 2019 and later, while requirements for v2.x remain for Windows Server 2016 and earlier. Check version-specific prerequisites during migration.
Reading Basic AD Information via PowerShell
During pre-deployment investigations for Defender for Identity, identifying candidate domain controllers to monitor makes organization easier. If you are using a management terminal where the Active Directory PowerShell module is available, you can use the following read-only example.
Get-ADDomainController -Filter * | Select-Object HostName, Site, OperatingSystem, IPv4Address
This is not a command to configure Defender for Identity, but rather for taking inventory of target DCs. Cross-referencing the results with your sensor list serves as material for verifying monitoring gaps.
For Practical Work
Investigate signs of AD compromise alongside device alerts
View user-initiated attack paths through Defender XDR incidents
Prioritize checking anomalies in privileged accounts and critical identities
Continuously monitor sensor health
Verify supported sensor versions in configurations including AD CS, AD FS, and Microsoft Entra Connect
Points for Administrators to Verify
Licensing Eligibility
Being able to install a sensor and having users correctly licensed are two different things. Do not judge based solely on the tenant name (E3/E5); verify target user entitlements in the Microsoft 365 admin center and contract terms.
Sensor Requirements
By 2026, the deployment of v3.x sensors is progressing. Re-verify Windows Server versions, cumulative updates, Defender for Endpoint onboarding status, and network connectivity requirements in the official documentation at the time of deployment.
Permissions
Initial configuration and setting changes may require high privileges such as Security Administrator. For daily operations, segregate permissions down to the principle of least privilege, including Unified RBAC.
Criteria for Evaluating E5 from E3
You can operate the identity infrastructure itself on E3. However, if you want to bring identity attacks—including on-premises AD as well as endpoints—into the Defender XDR investigation pipeline, Defender for Identity is an area where the value of E5 becomes clear.
Having E5 does not mean everything is protected automatically. It only functions when licenses, sensor placement, health status, audit settings, and operational investigation procedures are all properly aligned.
Microsoft Official and Primary Information
Defender for Identity sensor v3.x prerequisites: https://learn.microsoft.com/en-us/defender-for-identity/deploy/prerequisites-sensor-version-3
Defender for Identity sensor v2.x prerequisites: https://learn.microsoft.com/en-us/defender-for-identity/deploy/prerequisites-sensor-version-2
Microsoft Defender for Identity documentation: https://learn.microsoft.com/en-us/defender-for-identity/
Defender for Identity is a product designed to view identities not as "account management," but as an "attack path." It is safest to start by using read-only checks to verify sensor health and monitoring scope.
