Frontrow Technology
← All insights & guides
Guide

Cyber — Defender for Identity

Microsoft Defender for Identity — what it catches that nothing else does, Australia 2026

Defender for Identity (formerly Azure ATP) detects on-premises Active Directory attacks invisible to Defender for Endpoint and Defender XDR. AU 2026 deployment guide, the attacks it actually catches, and licensing.

Daniel Brown · Last reviewed 18 May 2026 · 8 min read

Australian mid-market organisations on Microsoft 365 E5 are universally licensed for Microsoft Defender for Identity. About 30% have it deployed. Of those, perhaps half are operating it effectively. It's the lowest-deployment-rate component of the E5 Defender stack — and it's the only one that detects on-premises Active Directory attacks. Every breach report we see in 2026 includes at least one signal Defender for Identity would have caught hours earlier.

What Defender for Identity actually does

Defender for Identity (DFI; formerly Azure ATP) installs a sensor agent on every domain controller and every Active Directory Federation Services (ADFS) server. The sensor reads DC traffic, Windows event logs and ETW (Event Tracing for Windows) to detect identity-targeted attacks against the on-premises directory. It correlates with Defender for Endpoint signals from user devices to build attack chains across the identity surface.

What it catches that nothing else does

Eight detections Defender for Identity provides that no other Microsoft tool catches:

  1. 1Pass-the-hash and Pass-the-ticket — the credential reuse attacks that follow LSASS dumping. EDR catches the LSASS access; only DFI catches the subsequent ticket re-use against a different machine.
  2. 2Kerberoasting — extraction of service-account password hashes via TGS requests. The most common AD privilege escalation in AU breaches.
  3. 3Skeleton key — a custom domain controller patch that lets attackers authenticate as any user with a master password. Sophisticated APT activity; near-impossible to catch elsewhere.
  4. 4DCSync — replication request from a non-DC, which exfiltrates all credentials. Detectable only at the DC.
  5. 5DCShadow — registration of a rogue DC to push malicious replication changes. Same — only DFI sees it.
  6. 6Reconnaissance against AD — enumeration of users, groups, computers. Often the day-zero activity before an attack escalates.
  7. 7Lateral movement paths — DFI maps which user accounts could reach which sensitive accounts via inherited permissions. Pre-breach visibility on the path attackers will take.
  8. 8Account compromise via brute force / password spray against AD — different fidelity from the cloud sign-in equivalent because the on-premises lockout policy varies.

Why deployment rates are low

Three reasons AU mid-market under-deploys DFI despite being licensed:

  • The 'identity is moving to cloud' narrative — IT leaders assume on-premises AD is shrinking, so on-premises identity detection is lower priority. The reality: every M365 tenant still has AD as the source-of-authority for hybrid identity. The on-premises attack surface is not gone.
  • Deployment friction — DFI requires a sensor on every DC, including capacity to handle ETW. Mid-market DCs are often virtualised on under-provisioned hosts. Sizing the sensor is a real (small) project.
  • Tuning effort — DFI generates noise during the first 30 days as it learns the normal pattern. Without tuning, alert fatigue sets in and the platform gets ignored.

AU mid-market deployment plan

  1. 1Pre-flight — inventory domain controllers, ADFS servers and capacity on each. The DFI sensor needs 2 cores and 6 GB RAM minimum per DC, often more on busy ones.
  2. 2Service principal — DFI uses a Directory Service Account (gMSA recommended) to read AD. Create the gMSA before the deployment day.
  3. 3Sensor rollout — install the sensor binary on every DC. Microsoft Defender Identity workspace in the Defender portal shows when each DC is reporting.
  4. 4Honeytoken accounts — create one or more honeytoken accounts (a credential that should never be used) and configure DFI to alert on any use. Single highest-fidelity detection in the platform.
  5. 5Sensitive account classification — explicitly mark Tier-0 accounts (Domain Admins, key service accounts). DFI uses this to elevate detections.
  6. 630-day learning window — leave it running. Tune one rule a day for the first two weeks.
  7. 7Integration to Sentinel/XDR — wire the DFI alerts to your SOC workflow. The Defender XDR connector handles this natively.

Licensing in 2026

Defender for Identity is included with Microsoft 365 E5, E5 Security, EMS E5 and as a standalone $7.10 AUD per user per month SKU. The licensing trap: it's per-user, not per-DC — meaning every user account in AD needs an E5 or E5 Security or standalone DFI licence. Service accounts and disabled-but-not-deleted accounts can blow the licence count out if not cleaned up. Inventory user-account count carefully before sizing the licence cost.

Try it

Score the identity admin posture before deploying DFI

DFI is most effective in tenants with a tight admin model. Audit Entra admin posture first.

Want us to run this with your team?

30 minutes. No deck. We'll walk through your tenant, your priorities, and the next sensible move.