Identity Exposure in a CTEM Program

Every ransomware crew, every state-sponsored intrusion set, and every insider incident of the last five years eventually converges on the same object: a credential. Continuous Threat Exposure Management gives security teams a disciplined, five-stage rhythm for finding and closing exposure before it is exploited — and identity is where that rhythm earns its keep fastest, because identity exposure is rarely a single vulnerability, it is a chain of small, individually tolerable misconfigurations that add up to a domain-admin path.

Why identity exposure breaks the old exposure-management playbook

Traditional vulnerability management assumes a stable inventory of hosts, a CVE database, and a patch cadence. Identity does not behave like that. An identity attack surface is made of accounts, group memberships, role assignments, OAuth grants, service-account secrets, session tokens, federation trusts, and the transitive relationships between all of them. None of these has a CVE. None of them shows up in a traditional vulnerability scanner. Yet Verizon's DBIR and Mandiant's M-Trends have both reported, year over year, that credential abuse and valid-account usage are the top or near-top initial access vectors in confirmed breaches — consistently ahead of exploited software vulnerabilities.

The reason identity resists the old playbook is structural. A CVE is a static fact about a piece of software: it exists or it does not, and a patch either remediates it or does not. An identity exposure is a fact about a graph: whether a low-privilege service desk account can, through three or four hops of group nesting, delegation, or password reuse, reach a domain controller or a cloud organization root. That graph changes every time someone is added to a group, an OAuth app is granted a scope, or a contractor's temporary access is left active after their contract ends. Static, point-in-time scanning cannot keep pace with a surface that mutates with every onboarding, offboarding, and access request.

This is precisely the gap Continuous Threat Exposure Management (CTEM) was designed to close. Gartner's CTEM model does not ask "what vulnerabilities exist," it asks "what can an adversary actually reach, right now, given everything we know about our environment." Applied to identity, that reframing is transformative: instead of auditing Active Directory once a quarter, you continuously map who can become who, continuously score which of those paths matter, and continuously validate that the paths you closed stay closed. Programs that treat identity as a CTEM discipline — rather than a periodic access review — consistently show shorter dwell times and materially fewer lateral-movement incidents, because the exposure backlog is being burned down every week rather than surfaced once a year in an audit finding.

The five CTEM stages, mapped to the identity attack surface

Gartner's CTEM framework defines five stages: Scoping, Discovery, Prioritization, Validation, and Mobilization. Each stage has a distinct identity-specific interpretation, and skipping any one of them is where identity-focused exposure programs typically fail. A team that only discovers (runs BloodHound once) without prioritizing drowns in ten thousand theoretical attack paths. A team that prioritizes without validating chases paths that were already mitigated by a control the graph tooling did not model, such as a Protected Users group membership or a conditional access policy. A team that validates without mobilizing produces beautiful attack-path reports that never turn into a closed ticket.

What makes identity CTEM different from a generic vulnerability-management CTEM instance is that the stages are far more interdependent. In infrastructure CTEM, discovery and prioritization can run largely independently of each other, using CVSS and EPSS as loosely coupled inputs. In identity CTEM, discovery is a graph-construction problem, and prioritization cannot happen without walking that graph to compute reachability to Tier-0 assets. This is why most mature identity exposure programs converge on graph-based tooling — whether that is an open-source engine like BloodHound, a commercial Identity Threat Detection and Response (ITDR) platform, or a purpose-built module inside a broader exposure management or agentic SOC platform such as Algomox's exposure management CTEM capability, which correlates identity graph data with the same asset and vulnerability context used across the rest of the CTEM lifecycle.

Stage 1 — Scoping the identity attack surface

Scoping in a generic CTEM program means deciding which business systems and processes matter enough to bring under continuous exposure management. For identity, scoping is where most programs under-invest, because the instinct is to scope to "Active Directory" and stop there. That is a 2015 scope for a 2026 identity estate.

A properly scoped identity exposure program in 2026 spans at minimum five identity planes, and each plane has to be explicitly enumerated rather than assumed:

• On-premises directory services — Active Directory forests and domains, trust relationships, Group Policy, and legacy NTLM/Kerberos configuration that most organizations still run for line-of-business applications.
• Cloud identity providers — Entra ID (Azure AD), AWS IAM Identity Center, Google Cloud Identity, and Okta or Ping as an overlay federation layer, each with its own role model, conditional access engine, and API surface.
• Cloud infrastructure entitlements — the IAM policies, roles, and resource-based permissions inside AWS, Azure, and GCP that Cloud Infrastructure Entitlement Management (CIEM) tooling normally covers, including cross-account trust and assume-role chains.
• SaaS and application identities — OAuth app grants, API keys, and delegated admin roles across Microsoft 365, Salesforce, Workday, GitHub, Snowflake, and the dozens of other SaaS platforms that accumulate their own local user directories.
• Non-human identities (NHI) — service accounts, CI/CD pipeline tokens, workload identities, and machine-to-machine secrets, which now outnumber human identities in most enterprises by a factor of ten to forty-five, and which are systematically under-rotated and over-privileged.

The scoping exercise should also explicitly define the Tier-0 asset list — domain controllers, certificate authorities, PAM vault masters, identity provider admin consoles, cloud organization root accounts, and backup infrastructure — because every downstream prioritization decision in the program is measured as distance-to-Tier-0. Without an explicit, agreed Tier-0 list, prioritization scoring has no anchor and every team will argue about what "critical" means using a different mental model.

One scoping decision that pays off disproportionately: including break-glass and emergency-access accounts in scope from day one. These accounts are, by design, exempt from MFA and conditional access, which makes them simultaneously essential and radioactive. Programs that scope them out because "they're only used in emergencies" routinely find, on their first discovery pass, that a break-glass account has been used for routine administration for months because it was simply easier than requesting normal privileged access.

Stage 2 — Discovery: building the identity attack path graph

Discovery is where identity exposure diverges most sharply from asset and vulnerability discovery. Instead of enumerating a flat list of accounts, the objective is to construct a directed graph in which nodes are principals (users, groups, computers, service accounts, roles, applications) and edges are the relationships that let one principal act as, or gain control over, another: group membership, ACL grants such as GenericAll or WriteDACL, session-hosting relationships (a user with an active session on a computer that a lower-privileged account has local admin on), Kerberos delegation, OAuth consent grants, and cloud IAM trust policies.

What discovery collectors actually pull

For Active Directory, this typically means SharpHound- or similar collector-style ingestion of every object's ACL, group membership, GPO links, and session data via LDAP and SMB, feeding a graph database (Neo4j is the de facto standard underneath most tooling, including BloodHound Community and Enterprise editions). For cloud identity, discovery pulls the full IAM policy document tree — not just directly attached policies but every inherited, inline, and resource-based policy — and resolves wildcard actions and conditions into effective permissions, because a policy that reads Action: "s3:*" combined with Resource: "*" under a permissive condition is a very different exposure from the same action scoped to one bucket.

For SaaS, discovery has to walk OAuth consent grants and app registrations, because a benign-looking "Mail.Read" scope granted to a marketing automation tool three years ago, combined with an admin-consent grant that nobody revisited, is functionally a standing backdoor into every mailbox in the tenant. Modern discovery tooling increasingly treats SaaS OAuth graphs with the same rigor BloodHound applies to AD, because the abuse pattern is structurally identical: enumerate principals, enumerate grants, compute reachability.

Non-human identity discovery is the newest and least mature of the five, but arguably the highest-yield. It requires correlating secrets scattered across code repositories, CI/CD pipeline variables, Kubernetes secrets, and cloud secret managers with the identities those secrets authenticate as, then asking the same reachability question: if this CI pipeline token is exfiltrated, what can it reach? The answer is frequently "the production cloud account," because pipeline service accounts are chronically over-scoped relative to what a single build actually needs.

Discovery must run continuously, not as a point-in-time sweep. Group memberships and OAuth grants change constantly, and a graph snapshot from last quarter's audit is stale within days. Mature programs run incremental collection daily or even hourly against directory services and cloud IAM APIs, and reserve full re-crawls for weekly cycles to control API rate-limit and licensing cost.

Stage 3 — Prioritization: scoring identity exposure, not just counting findings

A mid-size enterprise AD forest will typically surface somewhere between two thousand and twenty thousand distinct paths to Tier-0 assets on first discovery. Reporting all of them to an operations team is functionally the same as reporting none of them — it produces alert fatigue and no action. Prioritization is the stage that turns a graph into a ranked, finite work queue, and it has to combine several signals that no single tool provides on its own.

The exposure scoring inputs that matter

First is path length and chokepoint density. A single account with GenericAll rights directly over a domain controller's computer object is a one-hop path and should always outrank a five-hop path through three nested groups, even if the five-hop path technically also reaches Tier-0. Chokepoint analysis — identifying the small number of nodes that sit on a disproportionate share of all attack paths — is where the highest leverage remediation lives, because fixing one chokepoint node (commonly an over-nested group like "Help Desk" or a shared service account) can eliminate hundreds of paths simultaneously.

Second is exploitability and exposure of the entry point. A path that starts from an account with a weak, crackable Kerberoastable service principal name and internet-facing exposure (for example, through a VPN or exposed RDP gateway) is far more urgent than the same graph topology starting from an account with no external footprint and phishing-resistant MFA enrolled. This is where identity exposure prioritization has to fuse with the broader external attack surface and vulnerability data that a platform like Algomox's continuous threat exposure management solution correlates — an identity path is only as urgent as the reachability of its starting point.

Third is business and blast-radius context. A path that terminates at a domain admin group is not automatically worse than a path that terminates at a single service account with write access to the ERP production database, if the ERP breach would trigger a material financial disclosure event. Asset criticality tagging — which data the target touches, which regulatory regime governs it, what downstream systems trust it — has to be layered onto the graph, not bolted on afterward.

Fourth is toxic combinations, which is the single most valuable concept identity CTEM has borrowed from cloud security posture management. A toxic combination is a set of individually low-severity conditions that, combined, create a critical exposure: a service account with local admin on ten workstations (low severity alone), combined with a domain admin who logs into one of those ten workstations for routine support (low severity alone), combined with credential caching being enabled on that workstation (a default, low severity alone). None of these three facts alone would appear on a priority list. Together, they are a textbook credential-theft path that has been used in the overwhelming majority of ransomware case studies published by incident responders over the last several years.

A practical formula many identity exposure teams converge on, roughly analogous to how EPSS augments CVSS in vulnerability management, is a weighted composite: ExposureScore = f(pathLength, chokepointCentrality, entryExploitability, assuranceGap, assetCriticality) × toxicCombinationMultiplier. The exact weights matter less than the discipline of having an explicit, auditable formula that the SOC and identity teams agree on in advance, rather than ad hoc severity judgment calls made ticket by ticket, which is how prioritization backlogs quietly become political rather than risk-based.

Stage 4 — Validation: proving the path is real and the fix actually holds

Validation is the stage most identity programs skip, and it is the stage that separates a CTEM program from a glorified audit report. A graph engine's output is a hypothesis, not a fact: it says "this sequence of relationships would allow account A to control asset B," but it does not confirm that the abuse primitive actually executes in your environment, that no compensating control silently blocks it, or that the fix you deployed genuinely closes it rather than just hiding the edge from the collector.

Techniques for identity path validation

The most rigorous validation technique is controlled, authorized attack simulation — a purple team or automated Breach and Attack Simulation (BAS) exercise that actually executes the abuse primitive the graph identified: performing a real DCSync against a lab replica, executing a Kerberoasting request against the flagged SPN account, or attempting the OAuth consent-phishing flow against a test tenant. This confirms three things a static graph cannot: that the credential material is genuinely obtainable, that no EDR, conditional access policy, or Protected Users group membership silently neutralizes the technique, and that the detection stack actually fires an alert when the technique is executed — which is arguably the more important finding, because an exposure with a working detection is a very different risk than the same exposure with a blind spot.

A lighter-weight but still valuable validation technique is control verification without live exploitation: confirming conditional access policy assignment against the specific account in question (not just the policy's existence), confirming that a service account's password was actually rotated after a remediation ticket closed, and confirming that a "removed" group membership did not silently persist through a nested group or a nested Azure AD dynamic group rule that re-adds the account on the next sync cycle. This category of validation catches an extremely common and demoralizing failure mode: remediation tickets get marked closed, but the underlying condition returns within a sync cycle or two because the fix addressed the symptom (a specific group membership) rather than the cause (a dynamic rule or a provisioning script that keeps re-granting it).

Validation also has to run on a cadence, not just once per finding. An identity exposure that was closed in March can silently reopen in June when an HR system re-triggers an automated provisioning workflow, or when a new employee inherits a role template that still contains the excessive entitlement. Continuous re-validation, ideally automated and running against the same graph snapshot cadence as discovery, is what makes the "C" in CTEM meaningful for identity specifically, because identity drift is faster and less visible than infrastructure drift.

This is also the stage where identity exposure management intersects most directly with detection engineering. Every validated attack path should produce, or verify the existence of, a corresponding detection rule — a Kerberoasting attempt against the flagged account, an anomalous sign-in from the flagged service account, an unusual OAuth consent grant matching the flagged app pattern. A SOC that receives identity exposure findings without matching detections is defending against yesterday's threat map with today's blind spots. Programs that route validated identity attack paths into their SOC's detection backlog, rather than only into an IT remediation queue, close this gap; this is the operating model behind pairing exposure management with an agentic SOC function, where validated exposure findings and detection coverage are managed as a single continuous loop rather than two disconnected programs.

Stage 5 — Mobilization: turning validated findings into closed tickets

Mobilization is where most of the organizational friction in identity exposure programs actually lives, because identity remediation almost always requires action from a team that does not report into security: the AD or Entra platform team, an application owner who provisioned an over-scoped service account years ago, a DevOps team that owns a CI/CD pipeline's secrets, or a business unit that "needs" the standing access being flagged for a legitimate but poorly-scoped reason.

Remediation patterns that actually close identity exposure

Most identity findings resolve to one of six remediation patterns, and knowing which pattern applies up front dramatically speeds mobilization because it tells you which team owns the fix and what SLA is realistic:

1. Entitlement right-sizing — removing an unused or excessive group membership, role assignment, or IAM policy statement. Usually the fastest to execute, often automatable with an approval workflow.
2. Privilege time-boxing — converting standing privileged access into just-in-time (JIT) elevation with an approval and automatic expiry, typically through a PAM platform. This is the highest-leverage remediation pattern because it does not just close one path, it structurally prevents new paths of the same shape from accumulating.
3. Chokepoint restructuring — splitting an overloaded group (a "Help Desk" or "IT Support" group with accumulated, mismatched permissions) into narrower, purpose-specific groups. Higher effort, but the highest path-count reduction per remediation.
4. Credential hygiene — rotating a stale or shared secret, enrolling phishing-resistant MFA, disabling a legacy authentication protocol like NTLMv1 or basic auth that bypasses conditional access.
5. Non-human identity governance — assigning an owner, an expiry, and a least-privilege scope to a service account or workload identity that currently has none of the three, then rotating its secret through a managed vault instead of a static config file.
6. Architectural segmentation — the highest-effort pattern, reserved for structural issues such as a flat AD forest with no tiering model, or a cloud account structure with no organizational unit boundaries between production and non-production workloads.

Mobilization needs the same rigor as any other exposure management workflow: a named owner per finding (not a team, a person), an SLA tied to the exposure score tier rather than a flat calendar cadence, and a feedback loop back into validation so that a closed ticket automatically triggers a re-check rather than being trusted at face value. Programs that route identity findings through the same ticketing and ownership discipline used for critical CVEs — rather than treating identity as a separate, softer governance conversation — see materially faster closure rates, because the finding inherits an existing operational cadence instead of waiting for a quarterly access review meeting.

Reference architecture: the identity exposure tooling stack

A working identity exposure management architecture has four functional layers, and the most common implementation mistake is trying to run all four out of a single tool that was designed for only one of them.

The collection layer needs connectors into every plane identified during scoping: an AD/Entra collector for the on-prem directory and hybrid identity bridge, a CIEM connector for AWS/Azure/GCP IAM, a SaaS security posture management (SSPM) connector for OAuth grants and SaaS admin roles, and API integration into whatever PAM and secrets-management platforms hold vaulted credentials, so the graph knows which "risky" accounts are actually already behind a vault with session recording and rotation, and which are not. This last integration point is frequently missed and produces a large volume of false-positive high-severity findings, because an account with GenericAll over a domain controller looks identical to a graph engine whether or not that account's password is a vaulted, rotated, one-time-use credential monitored by a PAM solution. Without that context, prioritization cannot tell the difference between a genuinely exposed standing credential and one that is already tightly governed.

The normalization and graph store layer is where a common identity data model matters most: a "principal" needs to be modeled consistently whether it originated in AD, Entra, AWS IAM, or a SaaS tenant, and the criticality tags applied to Tier-0 assets need to flow through consistently so that prioritization scoring works the same way regardless of which plane a path traverses. This is also where most homegrown, spreadsheet-and-script identity review processes fail to scale — they can model one plane well, but cross-plane paths (an on-prem AD account that is also a cloud admin through hybrid identity sync, for example) require a genuinely unified graph, not four separate reports stapled together.

The analysis and correlation layer is where the exposure scoring formula, toxic combination rules, and ITDR-style behavioral detections live. This layer benefits enormously from being fused with broader security telemetry rather than run as an identity-only silo — an identity path's priority should shift in real time if EDR telemetry shows the entry-point account was just involved in a phishing click, and this kind of fusion is exactly the design goal behind platforms that unify identity security data with XDR detection data rather than keeping them in separate consoles.

The consumption layer is where mobilization actually happens: ticketing integration with clear ownership routing, a JIT approval workflow tied directly to PAM elevation requests, and executive dashboards that translate graph complexity into a small number of trend lines a CISO can defend in a board meeting — total attack paths to Tier-0 over time, mean time to close a validated finding by severity tier, and percentage of standing privileged access converted to JIT.

Metrics: proving the identity exposure program is working

Identity exposure metrics fail most often for one of two reasons: they measure activity instead of risk reduction (number of scans run, number of findings generated), or they measure absolute counts instead of trend and velocity, which makes a program that is actually improving look identical to one that is standing still, because the finding count in a growing, changing environment rarely goes to zero.

The metrics that hold up under board and audit scrutiny share a common trait: they are either a reachability count to a defined Tier-0 asset set, or a time-to-close measurement segmented by severity tier. A useful minimum set includes:

• Attack paths to Tier-0, trended weekly — the single most important line on the dashboard; a rising trend means new exposure is accumulating faster than it is closed, regardless of how many tickets closed that week.
• Chokepoint count — the number of nodes responsible for the top 80 percent of path volume; a shrinking chokepoint count indicates structural improvement, not just individual finding closure.
• Mean time to remediate (MTTR), by severity tier — should be measured from validated finding to confirmed re-validated closure, not from ticket-opened to ticket-closed, to avoid the "closed but silently reopened" failure mode.
• Standing privileged access ratio — the percentage of privileged entitlements that are standing (always-on) versus JIT (time-boxed); this ratio should trend down over the life of the program.
• Non-human identity coverage — percentage of service accounts and workload identities with an assigned human owner, a defined expiry or rotation policy, and a least-privilege scope; most organizations start this metric near zero and it is one of the highest-value early wins.
• Toxic combination closure rate — distinct from generic finding closure, because toxic combinations require coordinated fixes across multiple teams and tend to sit longer in the backlog if not tracked separately.
• Detection coverage on validated paths — percentage of validated attack paths with a confirmed, tested detection rule, which measures whether the SOC can actually see the technique fire, independent of whether the underlying exposure has been closed yet.

Presenting these as absolute numbers to an executive audience is usually a mistake; presenting them as a burn-down trend against a defined target, alongside the two or three highest-impact chokepoints closed that quarter with a concrete before/after path-count reduction, is what makes an identity exposure report land as evidence of risk reduction rather than a compliance artifact.

A worked example: from discovery to closed ticket

Consider a scenario typical of a mid-size financial services organization. A discovery run on the hybrid identity environment surfaces the following chain: a marketing department SharePoint contributor account, svc-sharepoint-sync, has a cached, never-rotated password that was set during a migration project four years earlier. That service account is a member of a nested group, "SP-Admins," which was granted local administrator rights on a jump-box server as a temporary measure during the same migration and never revoked. A domain administrator regularly logs into that jump-box for unrelated routine maintenance, leaving cached credential material in LSASS memory. The jump-box has no LSA protection or Credential Guard enabled because it predates the organization's current hardening baseline.

Individually, none of these four facts triggers a high-severity alert in a conventional vulnerability scanner: a service account with an old password is a minor finding; a nested group with local admin on one server is routine; a domain admin performing maintenance is normal operations; and a missing hardening control on one legacy jump-box is a low-priority configuration gap in a sea of thousands. Graph discovery, however, resolves this into a one-hop-from-Tier-0 toxic combination: compromise the marketing SharePoint account through a phished or reused password, pivot through the nested group to local admin on the jump-box, dump LSASS to harvest the domain admin's cached credential, and walk directly to a domain controller.

Prioritization scores this at or near the top of the queue: short effective path length once cached-credential dumping is modeled as an edge, high chokepoint centrality because the SP-Admins group turns out to also grant access used by two other unrelated service accounts, and a toxic combination flag because none of the four component conditions alone would have surfaced. Validation, run through an authorized purple team exercise, confirms the LSASS dump succeeds against the un-hardened jump-box and confirms that the SOC's current detection stack does not fire an alert on the dump technique, only on subsequent lateral movement — a meaningful finding in its own right.

Mobilization splits into four parallel, appropriately-scoped remediation tickets rather than one vague "fix identity risk" ticket: rotate and vault the svc-sharepoint-sync credential and assign it a real owner (credential hygiene, IT operations, 5-day SLA); remove the nested SP-Admins group's local admin grant and replace it with a scoped, task-specific group (chokepoint restructuring, platform team, 10-day SLA); enable Credential Guard and LSA protection on the jump-box and add it to the domain admin tiering model so that no Tier-0 credential is ever cached on it (architectural segmentation, infrastructure team, 30-day SLA); and add a detection rule for LSASS access patterns consistent with credential dumping tools (detection engineering, SOC, 14-day SLA, tracked as a paired action alongside the exposure ticket rather than a separate backlog item). Re-validation two weeks later confirms the path is closed and stays closed through the next monthly re-crawl.

Common pitfalls and honest trade-offs

Identity exposure programs fail in recognizable, repeatable ways, and naming them up front saves months of false starts. The first and most common pitfall is treating discovery output as an action list rather than an input to prioritization: a team that hands a SOC ten thousand raw BloodHound paths with no scoring will generate exactly one outcome, which is that nobody acts on any of them, and the tool gets blamed for "producing noise" when the actual gap was a missing prioritization stage.

The second pitfall is scoping too narrowly to Active Directory and treating cloud and SaaS identity as a separate program with a separate team and separate tooling. Attackers do not respect that organizational boundary; a hybrid identity environment means an AD compromise frequently is a cloud compromise within one sync cycle, and a program that cannot see both halves of that path in one graph will consistently underestimate severity.

The third pitfall is skipping validation because it is organizationally harder than discovery — it requires purple team coordination, change windows, and sometimes production risk tolerance conversations that a pure scanning exercise avoids. Programs that skip validation tend to accumulate a credibility problem over time: business stakeholders start treating exposure findings as theoretical because a meaningful fraction of past findings, when investigated, turned out to already be mitigated by a control the graph engine did not model.

The fourth pitfall, and the most consequential trade-off, is over-rotating toward just-in-time access as a universal fix without accounting for operational friction. JIT elevation is genuinely the highest-leverage remediation pattern, but poorly implemented JIT — slow approval workflows, unclear emergency-access paths, elevation requests that require a ticket and a 24-hour wait — drives operators to build workarounds: shared local admin passwords, permanently cached service tickets, or shadow break-glass accounts that then become their own undiscovered exposure. The trade-off has to be designed deliberately: JIT approval latency needs to be fast enough that legitimate operational work is not blocked, typically measured in minutes for routine elevation and near-instant for pre-approved emergency scenarios, or the control will be circumvented and the exposure will simply move somewhere less visible.

Finally, many programs underinvest in non-human identity governance because it lacks an obvious human owner and a natural review cadence like a manager's quarterly access certification. NHI governance has to be assigned explicit process ownership — typically a platform engineering or DevOps function working jointly with security — or it will remain the largest, least-visible share of the identity attack surface indefinitely, since service accounts and workload identities do not naturally surface in the same offboarding or role-change events that trigger human identity reviews.

Frequently asked questions