The directory is the floor everything else stands on

A directory rarely breaks. It drifts. A group gains a member on Monday, a delegation granted for a migration is never withdrawn, a service account keeps rights it needed once. Every one of those changes was approved by someone with a reason, and none of them shows up as a fault in the admin console. The question a buyer is actually deciding is which instrument is built to see the state those changes add up to.

The step that turns an incident into a rebuild

Ransomware operators do not have to reach every server. They have to reach the system every server already trusts. An account holding rights over domain controllers can authenticate to any domain-joined machine, reset any password, issue its own Kerberos tickets, switch off the logging that would record it, and reach backup infrastructure that authenticates against the same directory it exists to protect. At that point the question stops being which machines were encrypted and becomes which credentials can still be trusted. Six government agencies, among them the Australian Signals Directorate's Australian Cyber Security Centre and New Zealand's National Cyber Security Centre, say so in their joint guidance on detecting and mitigating Active Directory compromises, which states that responding to and recovering from a compromise involving Active Directory can be time-consuming, costly and disruptive.

Drift is what puts an account in that position, and Microsoft's own documentation shows how quietly it happens. Reducing the Active Directory Attack Surface records that a member of Enterprise Admins, Domain Admins or the built-in Administrators group can manipulate the directory to gain membership in the others, so in terms of potential privilege the three should be considered effectively equivalent. Taking an administrator out of one and leaving them in another changes the org chart and not the reach.

The same page describes what a cleanup leaves behind. When an account is removed from a protected group it keeps its adminCount attribute set to 1 unless somebody resets it by hand, and it still does not inherit permissions from the organisational unit it sits in. Your delegation model says that account is governed by the OU. It is not, and nothing on its property sheet says so. The same six-agency guidance names limited tools for diagnosing security issues as one of four properties that make Active Directory worth attacking, alongside permissive defaults, complex permissions and legacy protocol support. The console lists objects. An attack path is a relationship between objects.

A scan and a continuous assessment are different instruments

NIST defines information security continuous monitoring in SP 800-137 as maintaining ongoing awareness of information security, vulnerabilities and threats to support organisational risk management decisions, and the same document adds that data collection, however frequent, is performed at discrete intervals. Continuous is not a claim about constancy. It is a claim that the interval is short enough that a decision taken on the data is still about the estate you have.

That is why this is a product distinction rather than a scheduling one. A point-in-time scan measures the directory against a baseline and hands you a list. Purple Knight works that way, and on a directory nobody has audited it will return findings worth acting on. What a scan cannot hand you is a difference, because it holds nothing to subtract from. Semperis and Tenable Identity Exposure sit at the enterprise end of the same category, both built around Active Directory. The question to put to any product here is not how often it runs. It is what it keeps between runs, and whether it can tell you that a path which did not exist last month exists now, and name the change that created it.

The seam between a directory and a cloud

Adding a Microsoft 365 tenant to an estate that already has a directory creates a second identity system and a trust between them. Adding an AWS or Google Cloud account creates a third. Microsoft's incident response team writes in its lessons on preventing cloud identity compromise that it has worked on numerous investigations where on-premises Active Directory compromise led to Microsoft Entra tenant compromise, and that federated identity providers present an administrative blind spot, because hybrid identity is architecturally complicated with many moving pieces.

That blind spot is organisational before it is technical. The directory team and the cloud team review on different dates, and each can be right about the half it holds while the path runs across the join. A product that reads one side and not the other cannot see it, whatever its schedule.

The accounts that are not people

Non-human accounts are not new, but the category has changed shape. A service account was created deliberately, by an administrator, for a named system, through a request somebody had to approve. The identities now being issued to automated agents are created by developers and by the tooling itself. An agent framework registers an application, asks for a scope and receives a token, at the speed software is written rather than the speed a change board meets. Its scope is whatever was convenient at the time, because a faster route past a permissions error is a wider scope, and nothing brings anyone back to narrow it once the thing works. Then the project ends and the identity does not, because an agent never resigns and no joiner-mover-leaver process has a leaver to act on.

That is the same drift described above, arriving from a different direction and faster. Microsoft's incident responders report that workload identities are often granted much higher privileges than required, and that malicious activity from them goes unnoticed because detection logic is focused on user identities. An instrument that assesses human accounts and treats everything else as infrastructure is measuring a shrinking part of the attack surface. So the question to ask a vendor is not whether non-human identities are supported. Three narrower ones separate a product that handles them from one that lists them on a data sheet.

• Ask which non-human identities hold scopes they have never used, and how the product worked that out.
• Ask which of them have not authenticated in ninety days and still carry a live token or key.
• Ask which of them reach a privileged object through a chain of two or three grants rather than one.

IAM, PAM and posture assessment answer three different questions

IAM decides who should have access and provisions it as people join, move and leave. PAM governs how privileged access is used once it exists, by holding credentials in a vault, issuing them for a window and recording the session. Identity posture assessment reads the configuration those two produced, together with everything neither of them touches, and reports what that configuration currently permits. Owning two does not produce the third. An estate can run IAM and PAM properly and still contain a path from an ordinary account to domain rights, because that path is built out of group nesting, ACLs, delegations and certificate templates, which no provisioning workflow governs.

We carry the third and not the other two. ICM has an identity posture product and does not have IAM or PAM, which the identity area page also states. A buyer who needs a credential vault is better served by hearing that early than by reading to the end of a portfolio page.

Where this sits in our portfolio

Forestall reads Active Directory, Entra ID, Azure, Microsoft 365, AWS IAM, Google Cloud IAM and Google Workspace together, through read-only connectors, without an endpoint agent and without asking for Domain Admin or an equivalent. It maps accounts, groups, policies and the relationships between them, assesses the identities that are not people alongside the ones that are, and returns the escalation paths with the remediation step attached.