Attack Path Management Buyer's Guide: Evaluation Criteria

Attack path management tools all draw impressive graphs in a demo, but the graph is only as good as the edges it collects, and most of the edges that matter in a real intrusion are identity relationships the product may not model at all. Attack path management (APM) builds a graph of identities, groups, permissions, sessions, hosts and cloud resources, then finds the chains that connect a realistic foothold to a critical asset and the few nodes that most of those chains cross. This vendor-neutral buyer's guide gives identity, cloud and security operations teams the requirements, evaluation criteria, vendor questions, red flags and proof of concept plan for choosing a product, whether standalone, part of an exposure management platform or a module of an identity threat detection tool. It assumes you know the concepts: the Attack Path Analysis vs Attack Surface Management comparison explains how path analysis differs from outside-in discovery, and the Identity Attack Paths Guide explains the techniques. This page is about how to buy.

Key takeaways

Edge coverage is the product. Ask for the list of relationship types collected per platform (Active Directory, Entra ID, AWS, Google Cloud, Kubernetes, SaaS, CI/CD) and test it; a node count tells you nothing.
Non-human identities decide the answer. Service accounts, service principals, roles that can be passed or impersonated, and pipeline tokens form many of the shortest paths, so a tool that models only people and groups misses them.
Choke points beat path counts. The useful output is a short list of edges whose removal cuts the most paths to your critical assets, with the scoring inputs shown.
Remediation is where tools fail. A finding must name the exact membership, ACL entry, role assignment or permission to remove, the owner who can remove it, and the impact of removing it.
The collector is a crown jewel. An APM product holds a map of your weakest points and read access to every directory and tenant, so judge its own security as hard as its features.

Define requirements

Critical assets first: list the targets paths should end at: domain controllers and Tier 0 groups, identity provider global administrators, cloud organisation administrators, production data stores, signing keys and secrets managers, backup consoles. A tool cannot prioritise against assets you have not named, and its "critical asset" defaults will not match your business.
Realistic starting points: decide what an attacker starts with in your threat model: any domain user, any Entra ID member or guest, a phished help desk agent, a compromised build agent, a leaked cloud access key. A tool that assumes only "any authenticated user" will understate risk from non-human footholds.
Platforms in scope: on-premises Active Directory (including certificate services and delegation), Entra ID and other identity providers, AWS, Microsoft Azure, Google Cloud, Kubernetes clusters, SaaS administration planes and source control or CI/CD systems. Rank them by where your privileged access actually lives.
Who fixes: path findings are fixed by directory, identity and cloud platform teams, not by the asset owner. Decide which teams will receive findings and in which ticketing system before you shortlist.
Deployment and data residency: SaaS, customer-hosted or hybrid; where the graph is stored; whether collected data includes password hashes or secrets (it should not); retention and deletion on exit.
Relationship to what you own: check what your exposure management platform, identity security posture management tool or identity threat detection product already computes. The Exposure Management Buyer's Guide covers the broader platform category; buy a specialist APM tool only where its graph is materially deeper.

Capability areas

Graph coverage across identity planes

The tool should collect relationships, not just objects, from every plane where privilege can be gained. The edges below are documented by the platform owners and appear repeatedly in real intrusions; ask each vendor to show which ones it models.

Plane	Relationships the graph should model	Why it matters
Active Directory	Group nesting, ACL rights over users, groups, OUs and Group Policy objects, local administrator membership, sessions of privileged accounts on ordinary hosts, Kerberos delegation, service principal names, directory replication rights, certificate template permissions	The NSA and CISA joint advisory on the top ten misconfigurations describes attackers analysing nested groups to find accounts with more access than their role needs, and misconfigured certificate services leading to domain administrator
Entra ID and other identity providers	Directory role assignments, group ownership, application and service principal owners, credentials on applications, application permissions granted with admin consent, delegated permissions, administrative units	Microsoft documents that an application permission lets the application access any data the permission covers, without a signed-in user, so one over-granted app is a tenant-wide edge
AWS	Role trust policies and assume-role chains, iam:PassRole grants paired with services that run code, policy attachment and versioning rights, cross-account trust, resource policies	AWS states that a user who can pass a role to a service can have that service act with the role's permissions, which is privilege escalation if the role is broader than the user
Google Cloud	IAM bindings at organisation, folder and project level, service account impersonation rights (iam.serviceAccounts.getAccessToken, held in roles such as Service Account Token Creator), service account keys	Google notes that giving people the ability to run code as privileged service accounts creates privilege escalation and non-repudiation risks
Kubernetes	RBAC bindings, service account tokens mounted in pods, rights to create workloads, read secrets, use the escalate, bind or impersonate verbs, create service account tokens, access nodes/proxy	The Kubernetes RBAC good practices page lists each of these as a privilege escalation risk
Cross-plane links	Directory sync accounts, federation trusts, cloud roles assumed from on-premises identities, CI/CD tokens and workload identity federation into cloud accounts, secrets stored where an identity can read them	The most damaging paths cross from one plane to another, for example from an on-premises sync server to the cloud tenant, and single-plane tools stop at the boundary

Non-human identity coverage

Ask how the graph represents service accounts, managed identities, service principals, IAM roles, Kubernetes service accounts, API keys and pipeline tokens: as first-class nodes with owners, credentials, last use and the hosts or workloads that hold them, or as anonymous principals. A path that runs from an exposed build server, through a pipeline token, to a cloud role that can write production is only visible if the product joins those three objects. See the How to find service accounts with Domain Admin rights guide for the on-premises version of the same question.

Path analysis and choke point scoring

Configurable start and end sets: analysts must be able to define starting points (a group, a host class, an exposed workload) and targets, not only run fixed queries.
Choke point identification: the product should rank nodes and edges by how many paths to critical assets they carry, and simulate the effect of removing them before anyone changes production.
Transparent scoring: each score should show its inputs: number of paths cut, criticality of reachable targets, number of hops, exploitability of each edge (an ACL right is easier to abuse than a cracked password), and whether a start point is actually exposed.
Exploitability context: where a path step depends on a vulnerability, link it to known exploitation status; where it depends on a credential, show whether the credential is exposed, unrotated or protected by MFA. The Attack Path Management vs Vulnerability Management comparison covers how path context reorders a patch queue.

Remediation workflow

Exact fix: the finding names the object and the specific edge, for example "remove group X from the ACL on OU Y" or "remove the Token Creator binding for principal Z on service account W".
Impact preview: who or what currently uses the edge (sign-ins, API calls, scheduled tasks) so the fix does not break production.
Routing and verification: tickets go to the owning team with evidence, and the next collection confirms the edge is gone and the path count fell.
Exceptions: accepted risk recorded with an owner, a reason and an expiry date.

Change detection and monitoring

Paths reappear when someone adds a group membership or grants consent to an application. The product should re-collect frequently enough to catch this (daily at minimum for identity planes), alert on new paths to Tier 0 or tenant administrator roles, and feed those alerts to the SOC. For the detection side of identity threats, compare with the ITDR Buyer's Guide.

Collector security

The collector reads every ACL, role assignment and session in your estate. Require least-privilege read-only access documented per platform, federated or role-based cloud access instead of static keys, vaulted and rotated directory credentials, no collection of password hashes or secret values, encryption of the graph at rest, administrator MFA and role-based access inside the product, and an audit log of who queried which paths.

Evaluation criteria

Criterion	What good looks like	How to test it	Suggested weight
Edge coverage per plane	Published list of relationship types for each platform you run, including the NHI and cross-plane edges in the table above	Seed known paths in a test environment and check each is found	25%
NHI modelling	Service accounts, service principals, roles, Kubernetes service accounts and tokens as first-class nodes with owner, credential and last use	Pick ten known NHIs and confirm they appear with correct rights	15%
Choke point quality	Ranked edges with paths cut and scoring inputs shown; removal simulation	Compare the top ten choke points against your own expert review	15%
Remediation workflow	Exact edge, owner, usage impact, ticketing integration, verification on re-collection	Fix three findings end to end during the trial	15%
Freshness and alerting	Identity planes re-collected at least daily; alerts on new paths to Tier 0	Add a test membership and time the alert	10%
Collector and platform security	Read-only least privilege, no secrets collected, federated cloud access, product MFA and audit log	Review the permissions requested and the data stored	10%
Accuracy	Low rate of paths that cannot actually be traversed	Have a red team or assessor validate a sample of paths under rules of engagement	5%
Integration and export	API access to the graph, export to SIEM, exposure management and ticketing tools	Pull path data through the API into your reporting	5%

Adjust the weights to your estate: a cloud-only organisation can drop most Active Directory criteria; a hybrid estate should weight cross-plane edges higher.

Questions to ask vendors

Give us the full list of relationship types you collect for each platform we run, and the date each was added. Which are on your roadmap rather than shipped?
How do you model iam:PassRole, Google Cloud service account impersonation, Kubernetes escalate, bind and impersonate rights, and Entra ID application permissions granted with admin consent?
Can you follow a path across planes, for example from an on-premises account through directory sync or federation into a cloud administrator role, or from a CI/CD token into a cloud account?
How are non-human identities represented, and do you show the host or workload that holds each credential?
Show the scoring inputs for your top choke point in our environment. Can we change the weights and the critical asset list?
Exactly what permissions do your collectors need on each platform, and do you ever collect password hashes, secret values or token contents?
How often is each plane re-collected, and how quickly do you alert on a new path to a critical asset?
For a recommended fix, how do you show current usage of the edge so we know whether removing it breaks a service?
Where is our graph stored, who at your company can access it, and how is it deleted when we leave?
What is your licensing unit (identities, assets, collectors, tenants) and how does cost change when we add non-human identities, which may outnumber people many times over?

Red flags

Graphs without edge lists: the vendor cannot say which relationship types it collects per platform.
People-only identity model: service accounts, roles and service principals appear as anonymous principals or not at all.
Single-plane depth sold as coverage: excellent Active Directory analysis with cloud "support" that lists resources but not role trust, impersonation or pass-role edges.
Path counts as the headline metric: "1.2 million attack paths" with no ranking of which edge to remove first.
Black-box scores: a risk number you cannot decompose into inputs.
Write access or secret collection: collectors that request write permissions, domain admin rights or that store credential material.
No verification loop: findings close when a ticket closes, not when re-collection shows the edge is gone.

Proof of concept

Prepare: agree the critical asset list, starting points and success criteria in writing. Create collector identities with the minimum documented permissions in a non-production tenant or forest first, then production read-only.
Seed known paths: build five to ten test paths that mirror your threat model, for example a help desk group with reset rights over an admin, a pipeline role that can pass a privileged role, a Kubernetes service account that can read secrets, an Entra application with a high-privilege application permission. Record which each product finds.
Run on production read-only for two to four weeks: compare each product's top ten choke points with an internal expert review and count paths an assessor confirms are real.
Remediate three findings end to end: from finding to ticket, change, re-collection and verified path reduction. Time each step.
Test change detection: add and later remove a test edge to a Tier 0 group or administrator role and time the alert.
Review the collector: confirm permissions used, data stored, product access controls and audit logs with your security architecture team.
Exit and roll back: remove collector identities and credentials, revoke consents and confirm in writing that trial data has been deleted.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support across identity security posture, attack path management, PAM and NHI security. Browse vendors in our products directory or contact us.

Attack Path Management Buyer’s Guide: Criteria for Graph Coverage, Choke Points and Remediation