The most common question we get is not about regulation. It is some version of "we already run vulnerability scans, so what does this add?"

It is a fair question, and the honest answer is that the two tools answer different questions. A vulnerability scanner answers what is wrong with the assets I told it about. External attack surface management answers what do I actually expose to the internet. If your answer to the second question is incomplete, the first is measuring the wrong denominator.

The denominator problem

A vulnerability scan is scoped. Someone supplies a range, a list of hostnames, or a cloud account, and the scanner works through it. The output is only ever as complete as that input.

That input almost always comes from a CMDB, an asset register or a spreadsheet, which means it contains the assets somebody remembered to record. It will not contain the marketing microsite a contractor stood up for a campaign in 2023, the staging environment that was never decommissioned, the subdomain pointing at a cloud bucket that was deleted last year, or the appliance a regional office bought on a corporate card.

None of those are hypothetical. They are the recurring findings of first discovery runs, and they share one property: nobody was looking at them, which is precisely why they are worth attacking.

This is not a criticism of vulnerability management. It is a scoping observation. A scanner given a complete inventory does an excellent job. The difficulty is that the complete inventory is the harder artefact to produce, and most organisations do not have one.

Why regulators reach for the external framing

The interesting signal is that this distinction now appears in regulation, and the drafting is specific about direction of view.

Australia's PSPF Requirement 0211 asks entities to "identify and manage the entity's internet-facing systems or services" with "continuous visibility and monitoring". New Zealand's Minimum Cyber Security Standards scope themselves to "all business-critical and externally facing systems". The UK's Cyber Essentials Plus test specification requires an assessor to independently "identify all of the IP addresses currently in use by the Applicant".

That last one is the clearest. The assessor is not permitted to accept your list. They have to establish the list themselves. A regulator has written the outside-in view into an assessment procedure, because it does not trust a self-declared scope. That is the entire premise of EASM stated by a certification body.

Discovery without validation is just a longer list

The counter-risk is worth naming, because it is the failure mode of this category.

A discovery tool that enumerates everything and validates nothing produces a longer worry list, not better security. If a platform hands you four hundred newly discovered hosts with no indication of which are genuinely exposed, which are exploitable and which are someone else's infrastructure that happens to resolve on your domain, it has moved work onto you rather than off you.

Two questions separate a useful platform from a noisy one:

Does it know what you own before it starts scanning? Attribution is harder than enumeration. A tool that cannot distinguish your subsidiary's infrastructure from a shared hosting neighbour will generate findings you cannot action and cannot dismiss.
Does it validate exploitability, or only presence? An open port is not a finding. A reachable service running a version with a known exploit is a finding. The gap between those two is where most alert fatigue is manufactured.

Where each tool belongs

The practical division is straightforward once the scoping question is separated from the assessment question.

Vulnerability management owns depth on known assets: authenticated scanning, configuration assessment, patch verification, internal estate. It is the right tool for the systems you administer and can log into.

External attack surface management owns the boundary and the unknowns: what resolves to you, what is reachable, what changed since last week, and what appeared without anyone filing a ticket. It runs unauthenticated and from the outside, because that is the vantage point an attacker starts from.

They are complementary, and the sequence matters. Discovery defines the scope that scanning then assesses. Running the second without the first means accepting that your coverage figure is measured against an inventory of unknown completeness.

How this lands in each market

The obligation arrives through different instruments depending on where you operate, and the specifics matter more than the category name:

Australia, where PSPF 0211, the SOCI enhanced CIRMP rules and the Essential Eight combine into the most explicit mandate in the region
New Zealand, where the requirement comes from MCSS Standard 3 rather than the NZISM most people cite
Malaysia, where Act 854 is prescriptive and the licensing regime catches vendors out
Saudi Arabia, where ECC-2:2024 is detailed and widely misquoted
the UAE, where we are deliberately careful because the public evidence base is thin
the United Kingdom, where the NCSC handed the category to the commercial market in writing and then retired Web Check

The test worth running

Before evaluating any platform, including ours, run this exercise. Ask whoever owns your asset register for the list of internet-facing systems. Then ask an outside-in tool the same question. Compare the two.

The delta is your answer. If it is small, your inventory discipline is genuinely good and vulnerability management alone may be sufficient. If it is not small, you have just found the assets nobody has been patching, and the size of that gap is the size of the problem.

EASMLens discovers internet-facing assets from the outside, the way an attacker enumerates them, attributes them to your organisation, and monitors them continuously for exposure and CVE risk. See how that applies in Australia, New Zealand, the United Kingdom, Singapore and the Gulf.

EASM vs Vulnerability Scanning: Why Your Coverage Figure Is Measuring the Wrong Denominator