A detection is only half a control. The other half is what you are able to do the moment it fires, and on this product that turns out to be two different surfaces that people run together at their peril. There is the queue of identity alerts, organized around the stages of an attack, and there is the set of actions you can take against an account, which is not one menu but two with different owners and different reach. Operating this product well is mostly a matter of reading the first surface calmly and knowing exactly which of the second two you are standing on when you act.
Two catalogs, and why the old map is gone
The alerts live in two catalogs now, and knowing that saves you from chasing a name that moved. There is the classic catalog, the one with the numeric external identifiers that veterans still recite from memory, and there is the newer catalog in the unified Defender format, with descriptive detector identifiers and a structure aligned to the attack framework. Microsoft is steadily converting detections from the first shape into the second, and every genuinely new detection now ships only in the newer format. The consequence for anyone carrying knowledge forward is that the old five-phase kill-chain pages have been retired, alerts get renamed as they convert, and the numeric identifiers do not appear on the newer reference at all. Pull the current tables when you are actually writing a detection into a runbook rather than trusting a name you memorized, because on this product the naming is genuinely in motion.
The other thing the newer catalog reflects is the two-ended shape from the anchor. It is no longer an on-premises Active Directory catalog with a few cloud additions. It carries detections for Entra ID, for Okta, and for other identity providers alongside the domain-controller detections, which is the alert-queue expression of the point that this product hunts in the cloud directory and not only on the wire.
The stages still frame it
Even with the catalogs in flux, the shape of an identity attack is the right way to hold the detections, because it maps to how an intrusion actually unfolds. Early on there is reconnaissance, the quiet enumeration of accounts, groups, and the directory itself, and it is worth noting that attackers moved from ordinary directory queries toward the Active Directory Web Services protocol to evade the older monitoring, and the detections followed them there. Then there is credential compromise: brute force and password spray, Kerberoasting and its stealthier variants, roasting of accounts that never required pre-authentication, and the theft of the directory replication right itself, which the product classes here rather than later because a successful replication attack is a credential heist even though it ends in total control. Then lateral movement, the reuse of stolen tickets and hashes across machines, relay attacks, and the abuse of delegation. And finally domain dominance, the forged tickets and shadow controllers and directory-object tampering that mean the attacker no longer needs the credential because they have become the authority that issues it. Newer entries slot into the same frame, including the certificate-services abuses that productized the well-known escalation chains and the service-account abuses that follow the directory’s newer features. You do not need to memorize the catalog. You need to know, for any alert in front of you, which stage it belongs to, because the stage tells you how much time you have.
Learning, thresholds, and the temptation to silence
Some detections carry a learning period, a window in which the sensor builds a baseline before it will call something anomalous, and the durations vary from days to weeks by detection. The tuning model around them changed: the old switch that removed a learning period wholesale is gone, replaced by per-detection threshold levels that let you trade sensitivity against noise on the specific detections where that trade is worth making. There is an evaluation mode that drops the thresholds low across the board so you can see everything a detection would fire on, and Microsoft caps it at sixty days with a mandatory end date precisely because it is a temporary lens and not a running configuration. One caution the documentation itself creates: the alert catalog and the tuning page do not always agree on whether a given detection learns, so where they diverge, trust the behavior the tuning page describes and do not quote a learning duration as gospel.
The deeper discipline is about how you quiet a noisy detection at all. The old reflex was an exclusion, and exclusions still exist, but Microsoft now steers you toward alert tuning rules in the unified portal instead, and the steer is correct. A tuning rule is granular, it is reviewable, and it leaves a record of what you suppressed and why, which an exclusion does not. The difference matters because the accounts and systems that generate the most benign identity noise, scanners, backup software, admin tooling, are exactly the ones an attacker most wants to hide behind, and a blunt exclusion on one of them is a hole you will not remember cutting. Tune narrowly, tune visibly, and treat every silence as something you will have to justify later.
Two surfaces for acting on an account
This is the part to get exactly right, because the two surfaces look similar and are not. The first is the manual remediation menu, the set of actions an operator takes deliberately from an identity in the portal. On an on-premises Active Directory account that menu is deliberately short: disable the account, enable it again, and force a password change at next sign-in. On an Entra ID identity the menu widens to include revoking sessions and marking the account as compromised. On an Okta identity, an integration still in preview, it offers revoking sessions, deactivating the account, and setting its risk. Note what is not on the manual menu at all: there is no “suspend in Entra” action here. That verb belongs to the other surface.
The second surface is automatic attack disruption, the fabric-level machinery that contains an attack without an operator present, and its action set is a different list that does include suspending a user in Entra ID alongside disabling the user through the sensor and containing the account at the endpoint. The mechanics of that machinery, what triggers it, how you scope and exclude it, how it reaches across workloads, are the capstone pillar’s subject and I will not pre-empt them here. The point that belongs in this article is the reconciliation: when you disable an on-premises account by hand, you are on the manual surface with its three verbs; when the fabric suspends an account on its own, you are watching the automatic surface with its larger set. Confusing the two leads to the reasonable-sounding but wrong belief that you can manually suspend an Entra account from the identity menu, and you cannot. Know which surface you are on before you reach for an action.
The plumbing underneath the on-premises actions is worth one sentence of respect, because it is where the sensor generations rejoin the story. An action against an Active Directory account is carried out by the sensor on a domain controller, running as that controller’s local system identity, and only domain-controller sensors perform these actions. The federation, certificate, and sync sensors never do. That is the same local-system model the previous article insisted you configure correctly, and it is why the group managed service account left configured for actions does not merely go unused on the current sensor but actively breaks these very actions. The cloud-side actions run through a Microsoft-managed application in your tenant and are authorized against the roles of the operator who invokes them, so who can disable a cloud account is a question of directory roles rather than a single blanket permission.
Deception, and the last honest control
One detection deserves separate mention because it is cheap, quiet, and high-signal: the honeytoken. A honeytoken is a dormant account or device you tag as bait, attractive enough to tempt an intruder and touched by no legitimate process, so that any authentication against it is by construction suspicious. It is a detection mechanism rather than a posture assessment, and it is worth deploying early because it costs nothing to run and catches exactly the enumeration-and-try behavior that precedes a real compromise. Worth noting for anyone reaching for the broader deception capability that used to live in the endpoint product: that feature was retired at the end of 2025, and the honeytoken tag in this product is what remains of deception in the suite. Name the bait realistically, place it where an attacker will find it, and let its silence be the point.
What the queue actually feels like
The daily reality of this queue is triage, not firefighting, and the alerts sort into two temperaments. There is a high-fidelity set where the right response to a true positive is to move immediately: replication attacks, shadow controllers, forged high-privilege tickets, skeleton keys, credential-vault theft. And there is a broader, noisier behavioral set, brute force and reconnaissance and remote-execution attempts, where a large share of what fires is benign-true, the legitimate administrator using the same technique an attacker would. The work is classifying each alert as a true positive, a benign true positive, or a false one, and feeding that judgment back into the tuning rules so the queue stays honest. A queue nobody prunes becomes a queue nobody reads, and an identity queue nobody reads is the most expensive kind of blind spot, because the attacks it was built to catch are the ones that end with the attacker owning the directory. Keep it pruned, keep the high-fidelity alerts loud, and keep the honeytokens silent.
Where this goes next
Detections tell you an attack is happening. Posture tells you which attacks your own configuration has left open before anyone tries them, and it is the cheaper place to spend effort, because a misconfiguration you fix is a detection you never have to work. That is the subject of the next article, along with an honest account of what became of lateral movement paths, which are not the feature they once were.
Defender XDR
‹ Previous: [D 3.1.1] Build Sheet: Standing Up the Sensor Estate
Next: [D 3.3] Identity Posture: Fixing What the Sensors See ›
