Attack Surface Management Buyer's Guide: EASM, CAASM

Attack surface management tools are bought to find the assets nobody knew about, yet many evaluations are won by whichever product reports the largest asset count, including thousands of hostnames that are not yours. The market splits into external attack surface management (EASM), which looks at you from the internet, and cyber asset attack surface management (CAASM), which joins the data your own tools already hold, and both are sold as pure-play products or as modules bundled into wider platforms. This vendor-neutral guide helps vulnerability management, security operations and procurement teams decide which category they need, write requirements and an RFP, compare attack surface management tools on attribution accuracy rather than demo volume, understand pricing models and run a proof of value on their own estate. For discovery techniques, certificate transparency, subdomain takeover and running the programme, see the Attack Surface Management Guide.

Key takeaways

Decide the question before the category. EASM answers "what can an outsider see and reach?"; CAASM answers "what do we own, and which controls cover it?". Most estates need both views, but rarely from day one.
Attribution accuracy beats asset count. An EASM platform that cannot prove an asset is yours, with evidence and a confidence level, produces work for analysts rather than reducing exposure.
Pure play and bundled differ in depth, not just price. Bundled external attack surface management is convenient if you already run the parent platform; pure-play products usually go deeper on discovery and attribution. Test both on the same seed list.
Run a proof of value, not a demo. Seed known assets, plant a few you have hidden, and measure what each product finds, misattributes and misses over two to four weeks.
Connectors are privileged non-human identities. CAASM reads every cloud, directory, endpoint and scanner API; require read-only, federated and vaulted access before you connect anything.

Define requirements

Choosing an EASM platform or a CAASM platform starts with these decisions, written down before the first vendor call.

The gap you are closing: unknown internet-facing assets (acquisitions, marketing sites, decentralised cloud adoption) point to EASM. An inability to answer coverage questions, such as which servers lack an EDR agent or which cloud accounts are outside central logging, points to CAASM. If the gap is ranking findings across many sources, you may need exposure management instead; see the comparison below.
Seed data: registered domains and registrar accounts, IP ranges and autonomous system numbers, cloud accounts, subscriptions and projects, code hosting organisations, brand and subsidiary names. The NCSC lists "domain name registrations, IP address spaces and digital certificates" as part of an organisation's internet presence. The quality of the seed list sets the ceiling for every product you test.
Asset visibility baseline: CISA's BOD 23-01 calls continuous and comprehensive asset visibility "a basic pre-condition" for managing cyber risk and requires US federal agencies to run automated asset discovery every 7 days across their IPv4 space and vulnerability enumeration every 14 days, including roaming devices. Use those cadences as a floor when a vendor describes "continuous" discovery.
Control obligations: map requirements to NIST SP 800-53 CM-8 (an inventory that "Accurately reflects the system", "Includes all components" and avoids "duplicate accounting"), CM-8(3) automated unauthorised component detection, RA-5 vulnerability monitoring and RA-5(4) discoverable information; NIST CSF 2.0 ID.AM-01, ID.AM-02 and ID.AM-04 (inventories of hardware, software and supplier services); and CIS Controls v8.1 Control 1 (enterprise assets, including Safeguards 1.1, 1.2, 1.3 and 1.5) and Control 2 (software assets). Ask which reports evidence each one.
Ownership model: how assets map to teams today (cloud tags, DNS zone ownership, CMDB records) and who acts on an unattributed asset. NCSC guidance asks for an owner for the whole asset management system and for records to carry "a 'confidence' score or 'last seen' timestamp".
Testing limits: whether the product may actively probe your ranges, at what rate, from which source addresses, and whether any third-party infrastructure (shared hosting, agencies, suppliers) must be excluded. Active scanning of assets you do not own can breach contracts and law.
Data handling: where findings, screenshots and discovered credentials are stored, for how long, and whether a hosted service may hold a map of your internal environment (CAASM) or only internet-visible data (EASM).

Size changes the answer. A small organisation with a handful of domains often gets most of the value from a scheduled external scan of its own ranges, certificate transparency monitoring and free public repository secret scanning; eligible US public bodies can use CISA's free Cyber Hygiene Vulnerability Scanning, which "continuously monitors and assesses internet-accessible network assets" with weekly reports. A group with hundreds of domains, several clouds and regular acquisitions needs a platform that automates attribution, ownership and ticketing, and usually adds CAASM once the external view is under control.

Capability areas and evaluation criteria

EASM, CAASM and exposure management compared

Attack surface management tools and exposure management platforms are often sold to the same buyer. The difference is where they sit in the cycle: ASM discovers and inventories, exposure management prioritises and validates across all finding sources. The Exposure Management Buyer's Guide covers the second category.

Category	Question it answers	How it collects data	Typical output	Buy it when
EASM	What can an outsider see and reach?	Outside-in: DNS, certificate transparency, WHOIS and registry data, internet scan data, web crawling, code and package repositories, from a seed list	Attributed internet-facing assets, exposed services and admin interfaces, expiring certificates, dangling DNS, leaked secrets	Unknown internet assets, acquisitions, shadow IT, brand sprawl
CAASM	What do we own, and which controls cover it?	Inside-out: read-only API connectors to endpoint, cloud, identity, directory, CMDB, scanner and SaaS management tools	De-duplicated asset inventory, coverage gaps (no EDR, no patching, no logging), policy queries	Asset data spread across many tools; audit questions you cannot answer
Exposure management	Which exposures matter most, and are they exploitable?	Aggregates scanner, EASM, CAASM, cloud and identity findings; adds threat data and attack paths	Ranked, de-duplicated exposures routed to owners	Many finding sources and no single prioritised view
Vulnerability scanning	Which known flaws are on these targets?	Network and credentialed scans, agents, against a target list	CVEs, missing patches, misconfigurations	Inventory is known; depth of testing is the gap

CAASM does not discover what no connected tool knows about, and EASM does not see inside your network; that is why mature programmes feed EASM discoveries into the CAASM inventory and compare the two.

Pure play or bundled

EASM tools and CAASM tools are sold as standalone products and as modules inside vulnerability management, exposure management, cloud security, threat intelligence and security ratings platforms. Pure-play external attack surface management means a product whose core is outside-in discovery; a bundled attack surface management platform adds it to something you may already own.

Factor	Pure-play EASM or CAASM	Bundled module
Discovery depth	Usually broader pivoting (subsidiaries, certificates, registrant data, cloud IP attribution) and more frequent rescans	Often seeded from the parent platform's targets; may stop at known domains
Attribution evidence	Typically shows the chain of evidence and confidence per asset	Varies; some show only a flat asset list
Workflow	Needs integration with your scanner, ITSM and CMDB	Findings flow straight into the parent's scanning and ticketing
Cost and contracts	Another licence, connector set and supplier review	Lower incremental cost; lock-in to the parent's roadmap and pricing
Best fit	Large, fast-changing or acquisitive estates; teams that need evidence for disputed ownership	Smaller estates already standardised on the parent platform

Do not assume either is better. A bundled module that finds 90% of what a pure play finds, inside the workflow your teams already use, may close more exposures. Measure it in the proof of value.

Evaluation criteria

An EASM comparison or CAASM comparison is only fair when every product starts from the same seed list and is scored against the same ground truth. An illustrative weighting for an EASM-led purchase: 30% discovery and attribution, 20% exposure findings and validation, 20% workflow and integration, 15% platform and connector security, 15% commercial terms.

Criterion	What good looks like	Weak signs
Discovery breadth (EASM)	Pivots from the seed list to subsidiaries, new domains, certificates, cloud-hosted IPs, code repositories and exposed secrets; shows the source of each discovery	Only expands subdomains of domains you supplied
Attribution and confidence	Evidence chain per asset (DNS control, certificate, registrant, cloud account, content match), confidence score, analyst override with reason, handling of shared CDN and SaaS hosts	Large counts with no evidence; third-party CDN nodes listed as yours
Freshness	Discovery and rescans at least weekly, faster for high-risk services; first-seen and last-seen timestamps	"Continuous" meaning a monthly batch
Exposure findings	Exposed admin interfaces and remote access, expiring or weak certificates, dangling DNS, open storage and databases, leaked credentials, technology fingerprinting linked to known exploited vulnerabilities	Port lists with no context; CVEs inferred from banners with no confidence level
Safe active testing	Rate limits, published source IPs, scheduling, exclusions and a no-disruption commitment	Aggressive scanning that cannot be throttled or excluded
Correlation (CAASM)	Merges records across sources with clear matching rules, shows which source said what, flags conflicts	Each connector's assets become separate licensed objects
Coverage queries (CAASM)	Saved queries such as "servers without EDR" or "cloud accounts not sending logs", with alerting when results change	Static dashboards; queries need vendor services
Workflow	Owner routing from tags, DNS zones or CMDB, two-way ITSM tickets, exceptions with expiry, closure only after rescan	CSV exports; closure on ticket status
Interoperability	Full API, export of the asset inventory to CMDB and scanners, standard identifiers for software and platforms, as RA-5 expects	Proprietary formats; inventory cannot leave the platform

Pricing models

EASM pricing and CAASM pricing are rarely published, and the counting unit decides how cost grows. The NCSC observes that "Many vendors charge for their scanning services on a 'per asset' basis", which means counting your assets accurately before procurement.

Model	What is counted	Watch for
Per domain or seed	Root domains, brands or organisations monitored	Whether subsidiaries and newly discovered domains add cost
Per discovered asset	Hosts, IPs, web applications or certificates found	Paying for misattributed and duplicate assets; cost rising as discovery improves
Per employee or device	Headcount or managed devices (common for CAASM)	Whether servers, cloud resources and non-human identities count separately
Per connector or module	Data sources, active testing or secret scanning sold separately	Core features such as ticketing or API access in a premium tier

Ask for a three-year cost at today's estate and after a plausible acquisition, and confirm whether assets you mark "not ours" are removed from the count.

Where identity fits

Two identity questions belong in every ASM evaluation. First, leaked machine credentials are attack surface: an EASM product should find API keys, cloud access keys and tokens in public repositories, packages and web content, and route them for revocation rather than only report them. See the Secrets Management Guide. Second, a CAASM platform holds read access to every directory, cloud and endpoint console, which makes its connectors high-value non-human identities. Require role assumption or federated credentials instead of static keys, vaulted and rotated secrets where keys are unavoidable, one connector per environment and alerts on connector use from unexpected locations. See the Service Account Security Guide.

Questions to ask vendors

Put these in the RFP and ask every shortlisted attack surface management vendor the same set in writing, so answers can be compared. When you shortlist EASM vendors or CAASM vendors, ask for answers demonstrated on your data in the proof of value rather than a demo tenant.

Starting from our seed list, how do you pivot to new domains, subsidiaries and cloud-hosted assets, and what evidence do you record for each attribution?
How do you handle assets on shared CDNs, SaaS platforms and reused cloud IP addresses, and what is your measured false attribution rate?
How often is each asset rediscovered and retested, and how do first-seen and last-seen timestamps appear in the API?
Which exposure types do you detect natively: exposed management interfaces, remote access services, dangling DNS, open storage and databases, certificate issues, leaked secrets?
What does active testing do, from which IP addresses, at what rate, and do you guarantee that scanning will not disrupt the services being targeted?
For CAASM, which of our tools have native connectors, which fields do you take from each, and how do you resolve conflicts between sources?
What permissions does each connector need, can it be read-only and federated, and where are its credentials stored?
Where are findings, screenshots and discovered secrets stored, who at your company can see them, and how are they deleted at contract end?
How do findings reach our ITSM tool and CMDB, and does closure require a rescan?
What exactly is the licence unit, are misattributed assets excluded, and what does an acquisition doing 30% more domains cost?
If your EASM is a bundled module, what discovery does it perform beyond the targets already in the parent platform?

Red flags

Asset counts presented as value, with no evidence chain or confidence per asset.
Findings on infrastructure you do not own, and no way to mark them "not ours" so they leave the licence count and the scan schedule.
Discovery that never leaves the domains you supplied, which cannot find the forgotten tenant or subsidiary that matters. The Microsoft Midnight Blizzard breach began in a forgotten test tenant outside normal governance.
"Continuous" monitoring that rescans monthly, leaving a newly exposed database open for weeks between looks; the DeepSeek database exposure was an open ClickHouse database reachable from the internet, exactly the finding EASM exists to catch.
CAASM connectors that require administrative or write permissions, or a shared long-lived key.
Leaked secrets reported with no validation or owner routing, or stored in clear text in the vendor's console.
Pricing per discovered asset with no cap, which penalises better discovery.

Proof of concept

For EASM, call it a proof of value: the question is not whether the product works but how much it finds that you did not know, how much of it is really yours, and how fast it reaches an owner.

Agree scope and success: two to four weeks, the same seed list for every product, written authorisation for any active testing, and three or four measurable outcomes such as attribution precision above an agreed threshold.
Prepare ground truth: list your known internet-facing assets, then plant controlled test cases: a subdomain on a separate registrar account, a test host on an unannounced cloud IP, a harmless exposed admin login page, a deliberately expiring certificate and a disabled test secret in a public repository. Note which product finds each and when.
Connect with least privilege: for CAASM, read-only federated connectors to three or four sources (directory, endpoint, cloud, scanner). Log every permission requested and every connector sign-in.
Measure discovery: unknown assets found, share confirmed as yours (precision), share of your known assets found (recall), time to first detection of each planted case, and duplicates.
Measure operations: route ten findings to real owners through ITSM, fix two, and confirm the product rescans and closes them. For CAASM, run three coverage queries and check the results against a manual sample.
Check cost on real numbers: ask each vendor to price the estate the trial actually found, minus assets you rejected.
Roll back cleanly: stop active testing, revoke connector roles and keys, confirm in each source's logs that access has ended, and get written confirmation that trial data, including screenshots and discovered secrets, has been deleted.

Carry these measures into production: unknown asset rate and time to attribute, exposed management interfaces (target zero), mean time to remediate by exposure type, dangling DNS records open, valid leaked secrets and time to revocation, and, for CAASM, the share of assets missing EDR, patching or logging.

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.

Attack Surface Management Buyer’s Guide: Choosing EASM and CAASM Tools