Exposure Management Buyer's Guide: CTEM Platforms

Exposure management platforms are sold as the answer to an overwhelming vulnerability backlog, but many simply re-sort the same scanner findings under a new score and add another licence to the stack. The market labelled exposure management or CTEM (continuous threat exposure management, a term that originated with an analyst firm) spans aggregation and prioritisation platforms, external attack surface tools, attack path and identity graph analysis, and adversarial validation. This vendor-neutral guide helps security leaders, vulnerability management leads and procurement teams decide which category they need, write requirements and an RFP, compare platforms on evidence rather than demos, understand pricing models and run a proof of concept. It goes deeper on buying than the programme guide; for the five CTEM stages and how to run the cycle, see the Exposure Management and CTEM Guide.

Key takeaways

Buy for a scope, not for "everything". Decide which CTEM scopes (external surface, identity plane, cloud, a crown-jewel application) the platform must serve first, and test it there.
The best exposure management platform is the one that fits your data. Its value depends on the asset, identity, ownership and ticketing data it can join; integration depth matters more than the feature list.
Prioritisation must be explainable. Insist on visible inputs: CISA KEV status, FIRST EPSS, CVSS v4.0 with Threat and Environmental metrics, SSVC-style outcomes, reachability and asset criticality.
Identity exposures are part of the scope. Standing privilege, overprivileged service accounts and leaked secrets create attack paths with no CVE; a platform blind to them misses the shortest routes.
Connectors are privileged non-human identities. A platform that reads every cloud, directory and scanner is a high-value target; require federated, read-only, vaulted access.

Define requirements

Choosing an exposure management platform starts with these decisions, written down before the first vendor meeting. They decide which category you are buying and stop the evaluation drifting toward whichever demo looked best.

Scopes and outcomes: list the first two or three CTEM scopes and what success looks like for each, such as fewer attack paths to the domain controllers or a shorter exposure window for internet-facing KEV vulnerabilities. A platform that cannot be scoped to a business service will reproduce the vulnerability backlog.
Existing sources: inventory the scanners, endpoint agents, cloud posture tools, identity providers and directories, external attack surface data, CMDB and ticketing you already run. Exposure platforms consume these; gaps here become gaps in the platform. See the Attack Surface Management Guide.
Asset visibility baseline: CISA's BOD 23-01 calls "Continuous and comprehensive asset visibility" "a basic pre-condition for any organization", and requires federal agencies to run automated asset discovery every 7 days and vulnerability enumeration every 14 days, with privileged credentials where feasible. Use those cadences as a sanity check on any platform's refresh rate.
Prioritisation policy: agree internally how KEV listing, EPSS, CVSS, SSVC outcomes, internet exposure and asset criticality combine, before vendors propose their own score. BOD 22-01 remediation windows for KEV entries (two weeks, or six months for CVEs assigned before 2021) are a useful reference point even outside government.
Mobilisation path: which ITSM and engineering tools receive work, who owns each asset class and identity, and how risk acceptance is approved. NIST SP 800-40 Rev. 4 frames responses as accept, mitigate, transfer or avoid; the platform should record which was chosen and by whom.
Constraints: data residency for findings and attack graphs, whether a hosted service may hold internal topology, OT safety limits on active testing, and who may hold connector credentials. The NCSC notes that a hosted solution is not suitable for air-gapped networks or those holding highly sensitive information.

Size changes the answer. A small organisation with one cloud and a single directory usually gets most of the value from its existing scanner with KEV and EPSS enrichment, an open-source attack path tool for the directory and a disciplined quarterly cycle. A large enterprise with several scanners, clouds and identity providers needs an aggregation layer that de-duplicates findings, maps them to owners and feeds ticketing, and is more likely to buy validation as a separate category.

Capability areas and evaluation criteria

Products sold as exposure management usually lead with one of the categories below and partner or integrate for the rest. Decide which you need now; comparing an aggregation platform with a validation tool on the same scorecard produces a meaningless exposure management platform comparison.

Category	What it does	CTEM stage	Buy it when
Exposure assessment platform (aggregation and prioritisation)	Ingests scanner, cloud, endpoint, identity and attack surface findings; de-duplicates; scores and routes to owners	Discovery, prioritisation, mobilisation	Several finding sources and no single ranked view or owner mapping
External attack surface management	Discovers internet-facing domains, IPs, certificates, cloud services and exposed admin interfaces from the outside	Scoping, discovery	Unknown or acquired internet assets; shadow IT
Attack path and identity graph analysis	Models routes from entry points to critical assets across identities, permissions and network; finds choke points	Prioritisation	Directory and cloud privilege sprawl; need to know which fix closes most paths
Adversarial exposure validation	Breach and attack simulation and automated penetration testing to prove exploitability and test controls	Validation	Prioritisation already works and owners dispute findings
Posture tools (cloud, SaaS, identity)	Configuration and entitlement findings in their own domain	Discovery	Specific domain gaps; usually feeds the aggregation layer

Exposure management tools and CTEM tools overlap heavily with vulnerability management; if the gap is scanning coverage rather than prioritisation across sources, see the Vulnerability Management Buyer's Guide. Validation is covered in the Breach and Attack Simulation (BAS) Guide.

Weight criteria to your requirements. An illustrative split for an aggregation-led platform: 25% data coverage and integration, 25% prioritisation, 20% mobilisation and reporting, 15% connector and platform security, 15% commercial terms.

Criterion	What good looks like	Weak signs
Source coverage	Native connectors for your scanners, clouds, directories, identity providers, EDR, attack surface data and CMDB; documented field mapping	"Integrates with anything" via CSV upload; connectors that only pull severity, not evidence
Asset and identity correlation	Merges duplicates across sources, shows confidence and last-seen time, links human and non-human identities to assets	Every source's asset becomes a separate licensed object
Non-CVE exposures	Misconfigurations, excessive permissions, exposed secrets, missing MFA and missing security agents as first-class findings	CVE-only data model with configuration items bolted on
Prioritisation transparency	KEV flag, daily EPSS, CVSS v4.0 shown as CVSS-B, CVSS-BT or CVSS-BTE, SSVC outcome, reachability and criticality, each visible and adjustable	A proprietary risk number that cannot be decomposed
Attack paths	Paths to defined critical assets, choke points ranked by paths closed, refreshed after identity and network changes	Static diagrams; paths that ignore identity and permissions
Scoping	Scopes defined by business service, owner or tag, with separate reporting per scope	Only global dashboards
Mobilisation	Two-way ITSM integration, grouping by fix, owner routing, exceptions with approver and expiry, closure after verification	One ticket per finding per asset; closure on ticket status alone
Reporting	KEV exposure window, attack paths to critical assets, closure time by priority, owner coverage, exportable by API	Raw finding counts; static PDF reports

Ask how each signal is used, not only whether it is present. FIRST says EPSS estimates "the probability that a published CVE will be exploited in the wild in the next 30 days" and that "EPSS should never be treated as a risk score". The CVSS v4.0 User Guide says CVSS-B scores "should not be used alone to assess risk" and that "The application of Environmental and Threat metrics is the responsibility of the CVSS consumer." CISA says "Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework", and its SSVC model reaches Track, Track*, Attend or Act from exploitation status, technical impact, automatability, mission prevalence and public well-being impact. A platform that blends these into one number should still show each input.

Pricing models

Exposure management pricing is rarely published, and models differ enough to swing total cost several-fold for the same estate. The NCSC observes that "Many vendors charge for their scanning services on a 'per asset' basis", and exposure platforms extend that to identities, cloud resources and validation runs.

Model	What is counted	Watch for
Per asset	Hosts, IPs, cloud resources or devices	How duplicates across sources and short-lived workloads are counted
Per identity or user	Employees, or all human and non-human identities	Whether service accounts and workload identities count, which can multiply cost
Per module	Attack surface, attack paths, validation, reporting sold separately	The CTEM cycle needing three modules to function
Validation volume	Scenarios, test runs or targets	Pricing that discourages re-validation after fixes

Ask for a three-year cost at today's estate size and at 30% growth, including connectors, premium integrations and professional services.

Where identity fits

Many of the shortest attack paths contain no CVE: a standing Domain Admin, an over-privileged service principal, a CI token with organisation-wide write access, or a valid key in a public repository. Require the platform to ingest identity posture from your directories and identity providers, include non-human identities with owners and last use, and model identity edges in attack paths. See the ISPM Guide.

The platform is also a privileged non-human identity itself. Its connectors read every cloud account, directory and scanner, and an attacker who controls it has a map of your weakest points. Require read-only, federated cloud access by role assumption instead of static keys, vaulted and rotated directory credentials, separate connectors per environment, and alerts on connector use outside expected patterns. See the Service Account Security Guide.

Questions to ask vendors

Use these as the core of an exposure management RFP and ask every shortlisted vendor the same set, in writing, so answers can be compared. When shortlisting exposure management vendors or CTEM vendors, ask for answers demonstrated on your data in the proof of concept rather than on a demo tenant.

Which of our existing sources do you ingest natively, which fields do you take from each, and how do you de-duplicate assets and identities across them?
Show the inputs behind your priority for one finding: KEV status, EPSS, CVSS vector, SSVC outcome, reachability and asset criticality. Can we change the weighting and see the effect?
Which non-CVE exposures do you model: misconfigurations, excessive permissions, exposed secrets, missing MFA, missing security agents?
Do your attack paths include identity relationships from our directory, identity provider and clouds, and how often are paths recalculated after a group or role change?
How do we define scopes and critical assets, and what happens to path results when critical assets are not tagged?
What permissions do your connectors need in each cloud, directory and tool, can they be read-only and federated, and where are credentials stored?
Where is our data processed and stored, including attack graphs, and what is your retention and deletion process at contract end?
How do findings reach our ITSM tool, are they grouped by fix, and does closure require verification?
What exactly counts toward the licence, how are non-human identities and short-lived workloads counted, and what does 30% growth cost?
If you lead with one category, which partners cover the rest of the cycle, and what data is lost at each integration?
Which customer references run the platform in a scope like ours, and what metrics improved?

Red flags

A single exposure score that cannot be broken down into its inputs, or that ranks a non-reachable high CVSS finding above an internet-facing KEV entry.
Coverage claims for identity and SaaS that turn out to be CSV import.
Connectors that require write or administrative permissions, long-lived cloud keys, or a shared domain admin account.
"Continuous" refresh that turns out to be a weekly batch, or attack paths that are not recalculated after identity changes.
Validation sold before prioritisation works, so an unranked list is "proven" at great expense.
Licensing that counts every container, every service account or every duplicate asset, pushing you to connect fewer sources.
Remediation status driven by ticket closure rather than rescans or re-validation, the pattern behind long exposure windows on edge devices such as the CitrixBleed exploitation, where patching alone did not end sessions attackers had already hijacked.

Proof of concept

Pick one scope and define success: for example the external surface or the identity plane, with a critical asset list and two or three measurable outcomes agreed with the business owner.
Baseline: record current asset counts per source, KEV items open on reachable assets, known attack paths to critical assets and median time to close.
Seed ground truth: include a known KEV-listed flaw on an internet-facing test host, a misconfigured storage bucket, a test service account with excessive rights on the path to a critical asset, and a planted, disabled test secret. Note whether each is found and how it ranks.
Connect with least privilege: read-only, federated connectors with vaulted credentials. Log every permission requested and every connector sign-in.
Test prioritisation: export the top 25 items and check that KEV-listed, reachable and path-critical exposures come first and that analysts can explain each rank.
Run mobilisation: push a sample into ITSM grouped by fix, close one choke point, and confirm the platform re-validates and the attack path disappears. Raise and expire one exception.
Roll back cleanly: revoke connector roles and credentials, confirm access has stopped in each source's logs, and get written confirmation that trial data, including attack graphs, has been deleted.

Carry these measures into production: KEV exposure window on reachable assets, attack paths and choke points per scope, median closure time for validated exposures, share of assets and identities with an owner, and exceptions past expiry. NIST SP 800-40 Rev. 4 recommends measuring the percentage of assets patched by their maintenance plan deadlines with mean and median times, and warns that "Metrics that are too simple are generally not actionable".

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Exposure Management Buyer’s Guide: Choosing a CTEM Platform