The cheapest identity attack to survive is the one your own configuration never left open. Detections earn their keep against the attacker who is already inside, but posture is the work you do before anyone tries, and hour for hour it is the better investment, because a misconfiguration you close is a whole class of alert you never have to triage. Defender for Identity turns that idea into a standing set of assessments that read your directory and tell you, continuously, which of the attacks from the previous article your environment has left standing open. The discipline is not running them. It is fixing them in an order that reflects what an attacker would reach for first.
What the assessments actually cover
There are around fifty posture assessments now, grouped into six families, and the grouping is a useful map of where identity risk actually accumulates. There is a family for accounts, the largest, covering the credential-hygiene failures that make the rest of the attacks easy: dormant privileged accounts, unsecured account attributes, reversible or ancient passwords, the replication right handed to accounts that should not hold it, delegation left unconstrained. There is a family for the identity infrastructure itself, the print spooler left running on a controller, local administrators on the tier-zero servers, the domain configurations like signing and the machine-account quota that quietly enable escalation, and the controllers or identity servers that are not being monitored at all. There is a family for the certificate authority, which productizes the well-known certificate-services escalation chains into named findings you can actually close. There is a small group-policy family, a family for the hybrid seam where the sync accounts live, and a family for cloud identities where the Okta assessments sit.
The detail that governs how much of this you can see is coverage, and it ties straight back to the sensor pillar. Some assessments are computed from directory data any deployment can read, so the certificate-template findings, for instance, surface for anyone with a certificate authority in the forest. Others require a sensor on the specific server that holds the role: the authority-side certificate findings want a sensor on the certificate authority, the hybrid findings want a sensor on the sync servers, the cloud findings want the Okta connector. This is why the infrastructure family opens with assessments about unmonitored servers. Until the fabric is instrumented, posture is reporting on a partial view, and a partial view of your identity attack surface is the kind of reassurance that gets people breached. Coverage first, always, because every other number depends on it.
Where posture surfaces, and where it is going
The assessments roll up in more than one place, and it is worth knowing which surface is the durable one. The primary and long-standing home is Microsoft Secure Score, where the identity recommendations sit filtered under the product and where the whole set refreshes on a daily cadence. Alongside it, the assessments now feed the identity initiative inside Exposure Management, the newer posture surface that scores your identity security as a metric you can track and target over time. And there is a newer unified recommendations experience, still arriving, that spans on-premises Active Directory alongside Okta and the other providers. How those surfaces aggregate across the whole suite, and how identity posture rolls into the wider exposure picture, is properly the subject of the exposure and vulnerability pillar rather than this one, so I will name the touchpoint and stop. For operating Defender for Identity itself, the working answer is Secure Score for the daily list and the identity initiative for the trend, reviewed on a regular cadence rather than admired once and forgotten.
The honest account of lateral movement paths
If you carry one piece of outdated knowledge about this product, it is probably the lateral movement path, and it deserves a straight correction rather than a quiet omission. For years the product computed and drew lateral movement paths by collecting local-administrator membership from endpoints, showing you the chain from an exposed non-privileged account to a sensitive one. That collection was disabled in the middle of 2025, the maps stopped updating, and the documentation and the associated posture assessment were removed. A couple of adjacent assessments went with it in the same period. The feature you may remember configuring the collection for is simply not the feature it was, and guidance that tells you to set up that collection is guidance to ignore.
What replaced it is better but lives elsewhere. The successor is the attack-path analysis in Exposure Management, which computes paths across the whole environment graph rather than from local-admin membership alone, and a newer graph-based explorer on the identity page that requires a Sentinel data lake entitlement to light up. Both of those belong to the exposure pillar, and the mechanics are its story to tell. What matters for operating this product today is the correction itself: do not go looking for the old lateral movement path view as a live feature, do not plan around it, and treat any lingering reference to it in the tooling as a remnant of a transition still in progress rather than a function you can rely on. Tell the history so nobody wastes an afternoon reconstructing a feature that was retired, and hand the successor to the pillar that owns it.
Tagging is not decoration
The tags you place on accounts, devices, and groups are not cosmetic labels, they are inputs the detections and the posture logic actually consume. Marking an account as sensitive changes how the product weighs activity against it, because a technique that is unremarkable against an ordinary account is an alarm against a domain administrator, and the sensitivity tag is how the product knows the difference. The product auto-tags the obvious high-privilege groups for you, but the accounts your own organization treats as crown jewels and Microsoft has no way to recognize are exactly the ones worth tagging by hand. The honeytoken tag from the previous article lives in the same place and does the opposite job, marking an account as bait so that any use of it is suspicious. In the wider fabric the modern expression of this idea is critical-asset classification in Exposure Management, which carries the notion of what matters most across products, but within Defender for Identity the tags are the lever, and they are worth setting deliberately at the very start because everything downstream weighs them.
One connector note that belongs here and is shared with the cloud-apps pillar: if you connect Okta to Defender for Identity, an integration still in preview, and you also run the Okta connector in Defender for Cloud Apps, you will see the Okta data duplicated across the portal. Pick one connector as the source for Okta identities rather than running both and reconciling the double vision by hand.
An order that reflects the attacker
Fifty findings will not all get fixed this quarter, so the value is in the sequence, and a defensible sequence follows what an attacker reaches for rather than the order the console happens to list them. Tag the sensitive and critical accounts and plant a honeytoken or two first, because that costs nothing and makes everything after it sharper. Close the coverage gaps next, the unmonitored controllers and identity servers, because until they are instrumented the rest of the list is computed on a partial view. Then the domain-compromise primitives, the unconstrained delegation and the replication rights and the residual permissions on the directory’s protected objects, because those are the findings that turn a foothold into ownership. Then the certificate-services escalation chain, which is cheap for an attacker and often wide open. Then the hybrid seam, the sync-account passwords and permissions that are the pivot from on-premises to cloud. Then the broad credential-hygiene cleanup, the key rotations and the unsecured attributes and the stale accounts, which is high-volume but rarely the thing that gets you owned this week. And having done all that, run the attack-path analysis against your tagged critical assets to see what chain survives, because the residual graph is the honest final grade. The order is the product of the whole pillar: coverage from the sensors, primitives from the detections, and the graph from the exposure work that comes later.
Where this goes next
The anchor, the sensors, the detections, and the posture together are the design of this pillar. What remains is to stand the thing up, and standing up the sensor estate is concrete enough to deserve its own build: the activation and installation steps for each generation, the service account where the previous one still needs it, the action-account setting that saves a silent failure, the auditing choice, and an end-to-end test that proves a detection actually reaches the queue you just learned to read. That is the build sheet, and it is where the design becomes an estate. The assessments here read the on-premises directory and the accounts synced from it; the newer posture over the identities you never deployed, the service principals and the agents that authenticate on their own, belongs to the cloud end, where those non-human identities are inventoried and, in preview, scored.
Defender XDR
‹ Previous: [D 3.2] Detections and Response: Operating the Identity Alert Queue
Next: [D 3.4] The Cloud End: What Lights Up Without a Sensor ›
