An organisation can only assess the security of the systems it knows about. Internet-facing assets change as new applications go live and cloud services are reconfigured, and older systems often keep running after the project that needed them has ended. When those changes go unnoticed, the exposed asset stays outside the organisation’s security assessments.
One reason the risk persists is that organisations cannot always keep track of everything they have exposed. A vulnerability in a system the security team does not know about can be exploited without ever having been assessed. Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of breaches as an initial access vector, overtaking stolen credentials for the first time in the report’s nineteen-year history. An organisation therefore has to establish which assets are reachable from outside before it can assess the weaknesses on them.
Penetration testing determines whether weaknesses in defined targets can be exploited and what that would lead to. External attack surface management addresses the question that comes before it, by discovering internet-facing assets from outside the organisation and tracking how that surface changes.
Gartner defines external attack surface management as the processes, technology and professional services deployed to discover external-facing enterprise assets and systems that may present vulnerabilities. NIST, citing SP 800-115, defines penetration testing as testing that verifies the extent to which a system, device or process resists active attempts to compromise its security. Neither definition settles the practical questions, which are about scope, timing and what the output can be used for.
Dimension | EASM | Penetration testing |
Primary purpose | Discover internet-facing assets, maintain visibility and identify exposures | Assess vulnerabilities and exploitability within a defined scope |
Scope | Works outward from known assets to find related ones | Focused on targets defined and authorised in advance |
Timing | Regular or continuous monitoring, depending on the platform | Run periodically, after changes, or as needed |
Method | Automated discovery, service identification, correlation and exposure analysis | Manual review, automated testing, controlled exploitation and impact validation |
Nature of findings | Observed exposures and risk assessments at varying levels of evidence | Vulnerabilities and access paths confirmed in the scenarios tested |
Main contribution | Unknown assets and new exposures become visible | What a specific weakness can lead to in practice |
The table describes typical practice rather than fixed boundaries. Testing programmes can include automation, continuous components and change-triggered retests. Discovery platforms differ in how often they re-check and in how far they go towards validation.
A penetration test provides assurance about the assets and attack paths covered by its authorised scope. Testers routinely discover additional assets inside that scope, and many engagements include a reconnaissance phase for exactly that reason. What an engagement cannot account for is an internet-facing asset that is unknown, excluded, or discovered only after the work has finished. Scope documents are usually assembled from an existing inventory, so a gap in the inventory becomes a gap in the assessment without anyone making a mistake.
The sharpest version of this problem is an asset nobody needs any more. A domain that has outlived its purpose keeps resolving and keeps answering, carrying whatever weaknesses it had on the day it stopped being maintained. It usually drops out of the inventory long before it drops off the internet.
Noticing that such a domain is still exposed and no longer needed is a discovery question. Establishing whether the application behind it can be abused is a testing question. The two sit at different points in the same problem, and an organisation that answers only the second one never gets asked about the assets it forgot.
A forgotten domain is the extreme case. More commonly, assets join and leave the external surface through ordinary work rather than through error.
A product team needs a staging environment before a launch. The platform team creates a DNS record under an existing corporate domain. The environment comes up behind a cloud load balancer with a management interface reachable on a non-standard port, and the work is tracked on the project board rather than in the asset inventory. Nothing in that sequence is unusual. The asset is now internet-facing, it carries the organisation’s domain name, and the next scope document will be written without it.
The same thing happens in the other direction. A service is decommissioned and its DNS record outlives it. A campaign domain stays registered and pointed at infrastructure nobody maintains. A cloud address is released and reassigned to someone else. Each of these changes what is reachable under the organisation’s name, and none of them produces a ticket.
What continuous discovery offers is less a longer asset list than a current one. Knowing which assets and services respond today, including the ones no inventory records, is the baseline. The more useful output is the difference between one look and the next. A subdomain appears that was not there last week, or a host that was quiet starts answering on a new port, or an exposure being tracked disappears. Those differences are what a security team can work with, provided each observation carries enough context to decide what to examine first.
How often that comparison needs to happen is a question regulators have already had to answer for the environments they govern. CISA’s Binding Operational Directive 23-01 requires US federal civilian agencies to run automated asset discovery every seven days and to begin vulnerability enumeration across discovered assets every fourteen days. It binds those agencies and places no obligation on anyone else, but it does show the cadence one regulator considered workable for networks it is accountable for.
PCI DSS approaches the same issue from the testing side. Requirement 11.4.2 and 11.4.3 calls for penetration testing at least every 12 months and also after any significant infrastructure or application change, together with retesting of corrections. Meeting the second half of that obligation depends on noticing the change in the first place.
EASM output is a mixture of observation and inference, and the distinction matters as soon as a finding reaches a remediation queue. It helps to separate four levels of evidence.
Level | What it means | What it supports |
Observed exposure | An asset or service is reachable from the internet | Inventory and scope decisions |
Potential vulnerability | A version, configuration or other signal suggests a known weakness | Prioritisation and triage |
Validated vulnerability | The weakness is confirmed present under the relevant conditions | Remediation planning |
Demonstrated impact | Access or security effect proven within an authorised test | Risk decisions and reporting |
External discovery produces the first two levels well. The third and fourth belong to testing, and products differ in how far up the ladder they go. Reporting a second-level finding in fourth-level language is how an exposure programme loses the engineering teams it depends on. Three things keep findings lower on that ladder than they first appear.
Attribution errors are the most expensive of them. Discovery works outward from seeds such as registration records, certificates and name similarity, and each of those can attach an asset to the wrong organisation, whether a company with a similar name, a reassigned cloud address or a subsidiary divested years ago. A wrong attribution costs triage time and can mean probing infrastructure nobody authorised you to touch.
Version inference is the most common. A banner or version string suggests a known weakness without confirming it, and backported patches and custom builds are frequent enough that a version match belongs at the second level rather than the third.
The third concerns which layer answered at all, which we covered separately in our post on port scanning and service detection. An open port and a confirmed service are different facts. Where a CDN or reverse proxy sits in front of an application, the reply can come from that edge rather than from the origin, which establishes that the address is reachable on that port without establishing which system produced the answer. The observation on its own settles nothing in either direction about what runs behind the edge. Service detection narrows the question by examining what the responding side actually speaks.
Discovery sets the scope. A target list drawn from what is actually exposed covers more of the real surface than one drawn from a configuration database, and newly discovered login portals, administrative interfaces and APIs are reasonable candidates for the top of it.
Prioritisation comes next, and it is where most of the saved effort sits. An external view that separates what is merely reachable from what shows a credible weakness lets a team spend limited testing hours on the assets where a finding would change something. Testing then validates that part of the list, which moves second-level findings up a level or clears them out of the backlog.
Change alerts supply the trigger the standard already asks for, since a new domain or a newly exposed service is a concrete signal that a significant change has occurred. After remediation, the external view shows whether the exposure is still reachable from outside, while the tester retests the finding where the requirement calls for it. Monitoring after the fix is what distinguishes a closed finding from one that was only reported as closed.
Gartner’s continuous threat exposure management model arranges the same work in sequence: scoping, discovery and prioritisation, then validation, then mobilisation. EASM contributes mainly to the first three stages. Penetration testing, red teaming and breach and attack simulation sit in validation.
ThreatMon helps organisations build and keep a clearer picture of their internet-facing assets. Starting from an organisation’s domains and IP address space, the platform discovers external assets and identifies the services responding on them, which shows security teams what is exposed beyond the inventory they already hold.
That visibility is not an exercise completed once. External environments move as applications are deployed, services change and infrastructure is retired. The platform records what was observed on an asset and when, so a team can compare the current picture against earlier ones rather than working from memory of the last review.
The value of that view sits in the work it makes possible. Establishing who owns an asset, investigating why something is exposed, and drawing the scope of the next penetration test from the current surface rather than from a static list all depend on knowing what is actually reachable. When an asset or service appears that nobody recognises, it can be assessed on its own terms instead of surfacing during a later engagement.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
