A honeytoken account in Defender for Identity catches attackers cheaply

In a lot of the Active Directory environments I look at, Microsoft Defender for Identity is deployed but only partly used. Honeytoken accounts are a good example. They give you an early warning system that costs almost nothing and takes minutes to set up, and still most tenants I review don't have one. You create an AD account that looks real, never use it, and tag it as a honeytoken in the Defender portal. When an internal or external attacker tries it, you know. For anyone tired of chasing false positives, that kind of clean signal is worth a lot.

A honeytoken is an unused AD account that Defender for Identity watches

The concept could hardly be simpler. You create an Active Directory user account with a believable name and never use it for anything legitimate. I usually go for names like “svc-backup-admin” or “legacy_ops_lead”, the kind of thing that catches an attacker's eye while harvesting credentials. Give it a strong password, deny interactive logon via GPO and keep it out of all groups. After AD replication has finished, open the Defender portal, go to System → Settings → Identities → Entity tags → Honeytoken and tag the account. From that point on, every authentication attempt against it, successful or not, raises an instant alert in Defender for Identity.

Real-world tip: On honeytoken accounts I always set “Password never expires” and explicitly deny local logon rights. That way the bait stays in place and can never be used by accident.

You can do all of this in under five minutes, and the detection value is huge compared to the effort. Attackers who come across these credentials, often through credential dumping or automated scripts, trigger an alert the moment they try them. And because the account has no real purpose, false alarms basically don't happen.

Lateral movement paths show where attackers could move next

The lateral movement paths are another feature people tend to overlook. You find them on the identity pages of sensitive users in the Defender portal. They map out the routes an attacker could take from a compromised system or user to a sensitive account.

I treat these maps as a concrete to-do list for security hygiene, not as nice-looking graphics. Even in mature AD environments I regularly find local admin rights handed out far and wide, usually left over from "just in case" decisions years ago. Cleaning up that sprawl closes attack paths and also cuts down on unnecessary triggers for your honeytoken traps.

flowchart TD
  Attacker["Attacker"] --> Workstation["Compromised workstation"]
  Workstation --> Honeytoken["Honeytoken account"]
  Honeytoken --> Defender["Defender for Identity Alert"]

Figure: A compromised device attempts to use the honeytoken account, and Defender for Identity raises an alert.

The official documentation on lateral movement paths explains the analysis in more detail and shows how to use it in practice.

The Sensitive tag gives your SOC context on critical accounts

Besides honeytokens, I recommend applying the "Sensitive" tag to the accounts that really matter: domain admins, highly privileged service accounts, and backup and automation identities. Tagging them in the Defender portal gives your SOC important context, and any activity involving these accounts shows up immediately. In client projects the tagging is often incomplete, which is a shame, because it makes incident response and alert triage much easier.

Good tagging also helps when you need to document and review possible attack paths, for example during audits or in reports to management.

Honeytoken alerts arrive with full context for admins

I'm still surprised by how well a honeytoken account works. I've watched real attackers, penetration testers and red teams all fall for it. Defender for Identity records the alert immediately, with full context on the device, the method used and what happened afterwards. The prerequisite is that Defender for Identity is deployed (usually through Microsoft 365 E5 or a Defender for Identity licence) and that sensors are installed on all domain controllers.

For most security teams, watching these alerts in the Defender portal covers daily operations. If you need deeper forensics, open the identity page of the honeytoken account and go through all linked activities. Microsoft's documentation on entity tags has further details.

A small effort here pays off far beyond its cost

A honeytoken account in Defender for Identity won't solve AD security or privileged account management on its own. As an early warning tool, though, it does far more than its size suggests. What I like most is that it needs no extra budget or architecture. Anyone with AD admin rights and access to the Defender portal can set it up quickly, provided the sensors are running and the licence is in place.

If you want to take it further, pair honeytoken accounts with a cleanup of local admin rights (see also PIM for managing admin privileges in Entra ID) and apply the Sensitive tag to your most critical identities. Together that gives you layered, practical defense that exposes attackers before they can do serious damage, with almost no added operational overhead.