Do You Still Need Standalone EASM? What Bundled Discovery Cannot See

A reasonable question, and one we get asked by people who have done their homework: our cloud provider already flags exposed resources, and our XDR vendor added external discovery last year. Why buy a separate tool?

Sometimes you should not. It depends on one thing, and it is not feature count.

The question that decides it

Bundled external discovery is scoped to what the platform already administers. Your cloud provider can enumerate exposure inside your accounts because it holds those accounts. Your XDR can see the assets running its agent. Both are genuinely useful, and within that boundary they are often better placed than an external tool, because they have privileged internal context an outside-in scan cannot get.

The boundary is the point. Bundled discovery inventories the estate you already know about, from the inside, using credentials you already hold.

So the question is simply: how much of your internet-facing estate sits outside the platforms you administer?

If the honest answer is "almost none", bundled tooling is probably sufficient and a standalone platform is a line item you do not need. Some organisations genuinely are in that position: single cloud tenant, disciplined provisioning, one team controlling DNS.

Most are not, and the reasons are structural rather than a failure of discipline.

Where the gap comes from

Acquisitions. You acquire a company and inherit its domains, its cloud accounts, its forgotten staging environments and its expired certificates. None of it is in your platform. It is attributable to you the moment the deal closes, and attackers make that connection from public records faster than most integration programmes do.

Subsidiaries and regional entities. A regional office procures a SaaS product and points a subdomain at it. Nobody is at fault. The asset exists, resolves to your brand, and appears in no console you own.

Marketing and agency infrastructure. Campaign microsites, landing pages, event registration systems. Frequently stood up on agency accounts, frequently outliving the campaign, almost never decommissioned deliberately.

Departed cloud accounts. The account opened with a personal card during a proof of concept, later expensed. It is not in your organisation, so it is not in your organisation's inventory.

Dangling DNS. A record pointing at infrastructure that no longer exists. The service was deleted, the record was not. Depending on the provider, that is a takeover waiting for someone to claim the target.

The common thread: every one of these is invisible to a tool that starts from your account list, and obvious to a tool that starts from your domain name.

What regulators assume

This is where the argument stops being a vendor preference.

The UK's Cyber Essentials Plus test specification requires the assessor to independently "identify all of the IP addresses currently in use by the Applicant", including infrastructure as a service. The assessor is explicitly not permitted to accept your list.

Consider what that implies. A certification body has decided that a self-declared scope, produced from the platforms an organisation administers, is not trustworthy enough to assess against. That is the same judgement an outside-in tool makes, written into an assessment procedure.

New Zealand's Minimum Cyber Security Standards scope themselves to "all business-critical and externally facing systems", and define externally facing as sitting outside the authorisation boundary the organisation established. Outside the boundary you drew, by definition.

Where bundled tooling genuinely wins

Worth stating plainly, because a vendor arguing that every alternative is useless is not arguing in good faith.

Inside its own boundary, a cloud provider's native tooling is better than an external scanner. It sees configuration rather than inferring it. It knows an S3 bucket's policy rather than probing for its behaviour. It links a finding to the account, owner and tag without attribution guesswork.

The same applies to XDR on agent-covered assets. Endpoint telemetry beats an unauthenticated port scan for anything the agent reaches.

If your estate is genuinely contained, use them and spend the budget elsewhere. The case for a standalone platform is not that bundled tooling is bad. It is that bundled tooling cannot see what it does not administer, and it will not tell you that, because it does not know what it is missing either.

The five-minute version

Rather than sitting through comparison demos, run this.

1. List the internet-facing assets from your cloud consoles and XDR.
2. Have someone enumerate your organisation from the outside, starting only from your primary domain. Any competent tool does this, ours included, and so does a consultant with public data sources.
3. Compare.

If the second list matches the first, you have your answer and it saves you a purchase. If it does not, the delta is the part nobody has been patching, monitoring or renewing certificates for, and its size is the size of your decision.

We are comfortable with that being the basis of the conversation, including when it goes against us. An organisation that runs this test and finds nothing was never going to get value from us anyway.

Further reading

On the related distinction between discovery and assessment, see EASM versus vulnerability scanning. For how the obligation appears in specific markets: Australia, New Zealand, the United Kingdom, Malaysia, Saudi Arabia and the UAE.

EASMLens discovers and attributes internet-facing assets from the outside and monitors them continuously. See Australia, New Zealand, the United Kingdom, Singapore or the Gulf.