How do you choose a CTEM tool or service? Buyer criteria

To choose a CTEM tool or service, score each option on five things: what scope it covers, how it validates exposure instead of listing it, who owns fixes, how it reports progress, and what you can export. Pick the option that matches the gaps you already have, not the longest feature list.

What are you actually buying?

CTEM stands for continuous threat exposure management. The term comes from Gartner, and their research is behind a paywall, so this post does not quote it. In practice, vendors use the label for products that combine asset discovery, vulnerability and misconfiguration findings, some form of validation, and a way to push work to owners.

That means "CTEM" on a datasheet can describe a scanner with a dashboard, a managed service with analysts, or a platform that sits on top of tools you already own. Ask which one you are looking at before you compare anything else.

Criterion 1: Scope you can name

Write down the asset types you care about before you take a demo. Laptops, cloud accounts, public web apps, code repositories, container images, SaaS tenants, identity systems. Then ask the vendor to show each one in a live environment, not a slide.

A useful test is to hand over one account you know well, including a few things you know are wrong, and see whether they show up. Gaps in a known account predict gaps in an unknown one.

Criterion 2: Validation, not volume

Exposure lists are cheap. The expensive part is knowing which findings an attacker could reach and use. Ask how the product decides that a finding matters. Does it use reachability, exploit evidence, network path, compensating controls, or only a severity score?

Public signals can help. FIRST publishes EPSS scores freely, and CISA maintains the Known Exploited Vulnerabilities Catalog. A vendor that ignores both is making prioritization harder for you. A vendor that uses only those two is still leaving out your own context. You want both.

Criterion 3: Who fixes things

Exposure management fails at the handoff. Check how a finding becomes a ticket, who it lands with, and what happens when nobody closes it. Look for owner mapping, due dates, and a way to mark an accepted risk with an expiry date.

For a managed service, ask who has permission to change your systems. If the answer is nobody, you are buying advice, which can be fine, but price it as advice.

Criterion 4: Evidence of progress

NIST SP 800-137 describes continuous monitoring as visibility into assets, awareness of threats and vulnerabilities, and visibility into whether controls work. Use that as a yardstick. Can the tool show you that an exposure was found, who was told, when it was fixed, and that the fix held on re-test?

Trend lines matter less than closed loops. A chart that shows findings dropping could mean you fixed things or that the scanner lost access.

Criterion 5: Data you can take with you

Ask for a sample export of findings, asset inventory and history. Check the format, the field names and whether history survives if you leave. Ask what happens to your data at contract end.

A simple scoring grid

Give each criterion a weight that reflects your own situation. A team with no owner mapping should weight criterion 3 heavily. A team with strong ticketing but poor asset knowledge should weight criterion 1. Score every vendor against the same live test, and write down the evidence for each score.

Red flags during evaluation

A vendor who cannot name what they do not cover. A demo that runs on sample data alone. Prioritization that boils down to a single color. No path from a finding to a named owner. An export that omits history. Any of these is worth a written follow-up question, and an evasive reply is information in itself.

What to do

1. List your asset types and mark which ones have no current coverage.
2. Choose one known environment for a proof of value, with a few seeded problems.
3. Ask each vendor to show validation logic on three real findings.
4. Trace one finding from discovery to closed ticket to re-test.
5. Request a sample data export and the contract exit terms.
6. Score with weights set before the demos, and record the evidence.

Where Safeguard fits

Safeguard focuses on the application and software supply chain side, with reachability analysis that shows whether a vulnerable dependency is actually called, and policies that can block risky changes at build and release. It does not replace a broad exposure management platform. It can supply validated application findings to one.

Quick check

Sources

• NIST SP 800-137, Information Security Continuous Monitoring
• FIRST, Exploit Prediction Scoring System
• CISA Known Exploited Vulnerabilities Catalog

Last reviewed: 18 October 2026.