The Question
The CTEM framework was built to answer a specific question: which exposures in our environment would an attacker actually exploit? The framework's five stages — scoping, discovery, prioritization, validation, and mobilization — are designed to surface the answer more reliably than CVSS scores and patch compliance rates.
Yet most CTEM implementations in production today are built almost entirely around software vulnerabilities and network exposures. Vulnerability scanners, EASM platforms, and attack path analysis tools map the CVEs, the open ports, the misconfigured cloud resources. They do not map the compromised credential in a dark web dump that gives an attacker valid access to the VPN, or the API key committed to a public GitHub repository that provides direct access to the production database, or the service account with Domain Admin rights that exists solely because no one ever scoped it down.
These are identity exposures. They are measurable, discoverable, and prioritizable using the same CTEM logic applied to software vulnerabilities. They are also, by the data, a larger source of actual breaches than the CVEs that dominate most vulnerability management programs.
A CTEM program that covers software vulnerabilities and network exposures but not identity exposures is addressing less than half of the attack surface that attackers are actually exploiting.
Why This Matters Now
The Verizon Data Breach Investigations Report for 2024 found that credentials were involved in over 77 percent of web application breaches. The CrowdStrike 2024 Global Threat Report documented a measurable shift in adversary tradecraft: threat actors, particularly e-crime groups operating at scale, are increasingly using valid credentials for initial access rather than exploiting software vulnerabilities. The reason is straightforward — valid credentials do not trigger vulnerability scanners, are less likely to trigger EDR, and often provide a broader scope of access than a single CVE exploitation would yield.
The specific mechanisms are well-documented. Initial access brokers purchase credentials from large-scale breach datasets, validate them against corporate VPN and remote access portals, and sell working access to ransomware operators. The credentials are often legitimate enterprise credentials obtained from consumer account breaches — employees reuse passwords, or the credentials were captured in a phishing campaign that predates the current security program. The enterprise may have no visibility into the fact that valid credentials for their environment are available for purchase in underground markets.
The Change Healthcare ransomware attack in February 2024 — the largest healthcare data breach in U.S. history, affecting an estimated one-third of Americans — was enabled by compromised Citrix Netscaler credentials on a remote access portal that lacked MFA enforcement. The credentials were not obtained through a CVE exploitation in Change Healthcare's environment. They were compromised credentials, likely from a third-party breach, used to authenticate against an unprotected remote access entry point. No vulnerability scanner would have surfaced the specific risk that materialized. A CTEM program that included credential exposure monitoring and MFA gap assessment would have.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report evaluated the identity exposure management category across four sub-segments: compromised credential monitoring, secrets security, Identity Security Posture Management (ISPM), and Active Directory attack path analysis. These are distinct capabilities that address different aspects of identity exposure, and the market has not yet converged on a unified platform that covers all four at depth.
Compromised credential monitoring: SpyCloud leads on credential database coverage and enterprise workflow integration, with the most extensive breach data repository and the clearest remediation workflow for pushing compromised credential alerts to help desk and IAM systems. Flare competes strongly on dark web coverage breadth, including criminal forums beyond credential dumps. Constella Intelligence differentiates on attribution accuracy, particularly for executive and high-value account monitoring.
Secrets security: GitGuardian is the established leader for developer secrets scanning, with the broadest coverage of secret types and the deepest integration into CI/CD pipelines. Trufflehog (TruffleHog, now TruffleHog Enterprise from TruffleHog Security) covers the open-source use case effectively. Gitleaks is the high-performance open-source option for organizations building custom secrets detection pipelines.
Identity Security Posture Management: Semperis leads for Active Directory and Azure AD posture assessment, with strong recovery capabilities that extend beyond posture into resilience. Silverfort provides unified identity protection across on-premises and cloud identities. Authomize (now part of Delinea) focuses on cross-environment privilege analysis.
Active Directory attack path analysis: BloodHound Enterprise (SpecterOps) is the category leader, translating the open-source BloodHound research tool into continuous production monitoring with managed remediation guidance.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
Organizations that recognize identity as an exposure management problem often approach it as a point solution problem — buy a dark web monitoring tool, run a BloodHound assessment, configure MFA. These are the right interventions. What most programs miss is the integration of identity exposure data into the CTEM prioritization and remediation workflow.
Compromised credentials require a remediation workflow, not just an alert. Dark web credential monitoring tools find compromised enterprise credentials in breach data. The alert is the beginning, not the end. The remediation workflow requires: identifying which systems those credentials access, forcing a password reset through IAM, reviewing authentication logs for evidence of use, and assessing whether the account should be subject to additional controls (step-up MFA, privileged access workstation requirements). Without an integrated remediation workflow, credential monitoring becomes an alert backlog rather than a risk reduction program.
Secrets exposure is a continuous problem, not a point-in-time audit.
API keys, tokens, and passwords find their way into public repositories through the normal course of development work — a developer copies a working configuration with embedded credentials into a public repository, or a configuration file is accidentally committed before a .gitignore rule is applied. The half-life of exposed secrets in public repositories is measured in minutes before automated scanners find and attempt to use them. Secrets security requires continuous scanning of all code repositories, including historical commits, with near-real-time alerting and automated revocation workflows for the most sensitive secret types (cloud provider credentials, database passwords, private keys).
Overprivileged accounts are not an IAM problem alone — they are an exposure problem. An overprivileged service account represents the same class of risk as an unpatched high-severity vulnerability: if an attacker can reach it and authenticate, they gain a capability they should not have. ISPM tools that identify privilege exposure should feed directly into CTEM prioritization. A Domain Admin service account running an unmonitored scheduled task is a high-priority CTEM finding regardless of whether any CVE is associated with it.
AD misconfigurations are reliably exploited, not occasionally exploited. Kerberoastable service accounts, AS-REP roasting targets, and unconstrained delegation configurations are not theoretical risks — they are documented attack techniques that ransomware operators and penetration testers use as a matter of standard procedure. BloodHound Enterprise finds these configurations continuously; the finding is only useful if it drives remediation. The common failure mode is treating AD attack path findings as a penetration test output to acknowledge and defer, rather than as CTEM findings to prioritize and remediate with the same urgency as critical CVEs.
MFA coverage gaps are the credential exposure equivalent of an unpatched critical vulnerability. Every enterprise system with external access and without MFA enforcement is a candidate for credential stuffing attack using the billions of credentials available in breach datasets. MFA gap assessment — systematically identifying which external-facing systems, VPNs, and remote access portals lack MFA enforcement — should be a standard component of CTEM scoping. The Change Healthcare incident should have made this point definitively.
Questions Your Buying Team Should Be Asking
1. How do you integrate compromised credential findings into our existing IAM and help desk workflows? The operational question for credential monitoring is not "how many credentials do you find in breach data" but "what happens when you find one of ours." The platform should have direct integrations with your IAM platform (Okta, Microsoft Entra, CyberArk) to trigger automated password resets and account reviews without requiring manual ticket creation. Understand the end-to-end workflow before selecting a vendor — the platforms that require manual export and import into ticketing systems introduce latency that matters when credentials are actively being used.
2. What secret types do you detect, and how do you handle revocation of detected secrets? Secrets scanning capabilities vary significantly by secret type coverage. The critical categories are cloud provider credentials (AWS access keys, Azure service principal secrets, GCP service account keys), database connection strings with embedded credentials, private keys and certificates, and SaaS API tokens. For each category, understand whether the platform can trigger automated revocation, or whether it only alerts for manual action. Automated revocation for cloud credentials in particular dramatically reduces the window of exposure after detection.
3. How does your platform model attack paths from compromised low-privilege identities to high-value systems? Attack path analysis is the capability that distinguishes identity security posture management from identity governance. Any IAM platform can tell you which accounts have which permissions. The question is which combinations of permissions and misconfigurations create a path from an account an attacker can reasonably obtain (through phishing or credential purchase) to a system that matters. Ask the vendor to demonstrate attack path visualization using your own environment or a representative demo environment, and evaluate whether the path findings map to realistic attacker tradecraft.
4. How do you prioritize identity exposure findings in the context of asset criticality? Not all compromised credentials are equal. A compromised credential for a contractor account with access to a development environment represents a different risk than a compromised credential for an administrator account with access to the production domain controller. ISPM and credential monitoring tools should support asset criticality tagging that allows findings to be prioritized by the access level and business criticality of the affected identity. Without criticality context, identity exposure findings compete for remediation resources on equal footing regardless of their actual impact potential.
5. What is your coverage for non-Active Directory identity stores — cloud IAM, SaaS applications, developer platforms? Enterprise identity environments are no longer Active Directory-centric. Cloud IAM (AWS IAM, Azure RBAC, GCP IAM), SaaS application permission models (Salesforce profiles, GitHub organization permissions, Snowflake roles), and developer platform identities (CI/CD service accounts, container registry credentials) are all identity exposure surfaces. Ask each vendor where their coverage ends, and assess whether the gaps are covered by other tools in your stack or represent genuine blind spots in your identity exposure program.
The Stackcurve Take
Identity exposure is not an adjacent concern to CTEM — it is a core exposure category that belongs in CTEM scoping alongside external attack surface and software vulnerabilities. The data is unambiguous: attackers use valid credentials more than they use CVE exploits, particularly for initial access. A CTEM program that does not monitor for compromised credentials, exposed secrets, and identity privilege misconfigurations is optimizing against a threat model that does not match current attacker behavior.
The integration challenge is real. Identity exposure data comes from different sources — dark web intelligence, code repository scanning, Active Directory analysis, cloud IAM assessment — and requires different remediation owners (help desk for password resets, developers for secrets remediation, IAM teams for privilege reduction). The CTEM mobilization stage must map identity findings to the correct remediation owners with the same specificity it applies to CVE findings assigned to patch management teams.
The organizations that extend their CTEM programs to cover identity exposure fully will close the gaps that Change Healthcare, MGM Resorts, and Caesars Entertainment all had in common: valid credential access to critical systems through remote access portals, unmonitored by any program specifically designed to detect and respond to credential compromise.
The 2026 Stackcurve CTEM CURVE™ Report covers the full identity exposure management landscape, including compromised credential monitoring, secrets security, ISPM, and AD attack path analysis. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.