13 min read

External Attack Surface Management: Seeing What Attackers Already See

External Attack Surface Management: Seeing What Attackers Already See
Photo by Glen Carrie / Unsplash

July 2026


For years, security ran on a simple mental model: build the walls high, dig the moat deep, and defend the perimeter. That model is done. The castle is broken. Cloud, SaaS and agentic tooling moved much of the estate outside the walls, and there is no longer a clean inside and outside to defend.

The exposures that now do the most damage are the ones no inventory ever recorded: a trusted OAuth token, a secret leaked to a public repository, a third-party integration authorised and forgotten. Across the 2025 breach data, these external-trust exposures are both the most expensive to resolve and the slowest to detect, with supply chain compromise taking 267 days to contain on average, the longest of any attack vector (IBM Cost of a Data Breach, 2025). External attack surface management (EASM) is the discipline built to close that gap, by discovering and reducing an organisation's internet-facing exposure the way an attacker sees it, from the outside in.

It matters more now than at any point in the last decade, because the surface it maps is expanding faster than the inventories meant to track it.

Get analysis like this delivered to your inbox. Subscribe to CyberDesserts for practical security insights, no fluff.


What Is External Attack Surface Management?

External attack surface management is the practice of finding and reducing the assets reachable from the public internet under an organisation's name: exposed applications, forgotten cloud services, misconfigured storage, edge appliances, and the third-party integrations connected to all of them. It maps what an attacker sees before they ever touch an internal system.

EASM is not vulnerability management pointed outwards. Vulnerability management scans the assets you know you have for the CVEs you know to look for. EASM starts from the attacker's side of the wall and asks a wider question: what is reachable, and what could an attacker do with it? That surface is more than unpatched software. It is exposed secrets, over-permissioned third-party integrations, services nobody remembers standing up, and the assets that never made it onto any register in the first place. A CVE is one item on that list, not the list.

The two are complementary, not competing. Vulnerability management assesses the weaknesses in what you already track. EASM finds the surface those assets sit on, including the parts you did not know were yours. Both sit inside the wider programme of continuous threat exposure management, which the final section returns to.

Why the External Attack Surface Is Outpacing Visibility

Twenty years of watching organisations buy and deploy security tooling has taught me one thing about asset inventories: they describe the network someone drew, not the one that exists today. The assumption built in is that you own a perimeter and a periodic scan captures it. There is no perimeter to capture any more in the traditional sense, only a surface that grows faster than the cycle meant to track it. Four forces are driving that gap.

Cloud footprints keep expanding. Flexera's State of the Cloud Report found organisations expect cloud spending to rise by 28% year on year, with enterprise workloads climbing from 52% to 54% and small-business workloads from 55% to 63%. Every one of those workloads is a potential internet-facing asset that may never enter a traditional inventory.

APIs have become the default way software is built. Postman's 2025 State of the API Report, its seventh annual survey of more than 5,700 developers, found 83% of organisations have adopted some level of API-first approach, up 12% on the previous year. Each published API is a reachable endpoint, and each endpoint is surface.

Then there are the agents consuming those APIs. The same Postman survey found 51% of organisations have already deployed AI agents, with a further 35% planning to within two years, and those agents now call APIs autonomously at machine speed. The surface is not just larger, it is being probed and connected by software that operates without a human in the loop.

The consequence of all this expansion is visible in the breach data. IBM's X-Force 2026 Threat Intelligence Index found that exploitation of public-facing applications became the leading initial access vector, up 44% year on year. Every asset added to that surface is something an attacker can find, probe and study at their leisure, long before anyone inside the organisation notices it is exposed.

The SaaS surface: trusted connections nobody inventories

The clearest illustration of the visibility gap is what happens when the exposure lives inside a trusted third-party connection. In August 2025, the threat actor Google tracks as UNC6395 used compromised OAuth tokens from the Salesloft Drift application to reach the Salesforce environments of more than 700 organisations. (Source: Google Threat Intelligence Group advisory, 26 August 2025; scale confirmed by FINRA cybersecurity alert.)

The mechanism is the point. A stolen OAuth token acts as standing authentication, so the attacker bypassed multi-factor authentication entirely and queried Salesforce data through its APIs as if they were the trusted integration. Google's investigation found the actor's goal was credential harvesting, searching the exfiltrated data for AWS access keys, passwords and Snowflake tokens to enable follow-on compromise. Google confirmed this did not stem from a vulnerability in the core Salesforce platform.

Named victims confirmed the blast radius through their own disclosures: Cloudflare, Palo Alto Networks, Zscaler, Fastly, Toast and others. The reach ran far beyond the technology sector. Education publisher McGraw Hill was among the downstream victims, with 13.5 million records later distributed and indexed by Have I Been Pwned, the verified figure, not the larger number the extortion group claimed. (Source: Have I Been Pwned; extortion attributed to the ShinyHunters brand, which Google tracks separately from the UNC6395 data-theft activity.)

That is the EASM problem in one campaign. Most security programmes were watching their own perimeter that August. The exposure walked in through a chat widget's OAuth grant that few had thought of as an asset, let alone one worth defending. For 700 organisations, the most damaging thing on their external surface was a connection they had authorised themselves and forgotten.

The secrets surface: exposure that stays exploitable for years

Underneath the SaaS campaign sits a broader problem: the credentials themselves are leaking into the open at scale. GitGuardian's State of Secrets Sprawl 2026 report detected 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-on-year increase and the largest single-year jump on record.

A leaked secret in a public repository is an internet-facing exposure that no asset inventory catches, and it does not expire on its own. GitGuardian found that 64% of secrets confirmed valid in 2022 were still valid and exploitable as of January 2026, standing access sitting in public code for four years without being rotated or revoked.

The exploitation window on the other end is measured in seconds. Our own research on exposed credentials found that a leaked cloud credential is validated against live APIs in under 90 seconds of exposure in most cases, with abuse continuing long after the asset was thought to be decommissioned. Seconds to exploit, four years to expire, and no inventory entry the whole time. That is the shape of the modern external surface.

The Cost of an Unmanaged External Attack Surface

Nine months is how long the average supply chain compromise goes undetected, and that delay is the external surface's defining problem. At a combined 267 days it took the longest of any attack vector to detect and contain in IBM's data, because the traffic looks legitimate and the asset was never on the list of things to watch. An unknown internet-facing asset does not announce itself, and by the time it surfaces the data has usually already gone.

Cost follows the delay. IBM found third-party vendor and supply chain compromise carried an average breach cost of USD 4.91 million, second only to malicious insider attacks at USD 4.92 million and ahead of vulnerability exploitation and phishing. That expense stands out because the global average breach cost fell 9% to USD 4.44 million over the same period. The United States bucked the decline entirely, with its average hitting an all-time regional high of USD 10.22 million.

The pattern is consistent: the exposures that come through external trust relationships cost the most and take the longest to catch. That is precisely the surface EASM exists to make visible before the clock runs down.

How to Regain Visibility of Your External Attack Surface

Regaining visibility is a discipline, not a purchase. It runs as a continuous loop of four steps, and the reason it has to be continuous is the same reason the surface outran the inventory in the first place: it keeps moving. Take the un-inventoried third-party integration behind the Salesloft Drift campaign as the worked example, and walk it through the four steps.

Discover, from the outside in. Start where the attacker starts: what is reachable from the public internet under your name? That includes the assets no inventory lists, the connected apps and OAuth grants that were authorised once and never recorded. The Drift integration was exactly this kind of asset, a live connection with API access that most of its 700 victim organisations had no inventory entry for. Discovery here means enumerating connected applications and third-party grants, not just scanning your own IP ranges. Our research on internet-facing exposure covers how these assets get found by attackers in the first place.

Attribute. Discovery produces a list; attribution answers which items are genuinely yours and what each one can reach. This is the hard step in a cloud and SaaS estate, because ownership is blurred: the Drift integration could read Salesforce Cases, Accounts and Users, so the real question was not "do we use Drift" but "what could Drift touch." An asset you cannot confidently attribute is an asset you cannot defend.

Prioritise by exposure, not by score. A non-human identity with standing API access and no multi-factor authentication is high-exposure by definition, whether or not it carries a CVE. The Drift token carried none, so a CVSS-driven process would have ranked it nowhere. That is not a failure of CVSS. CVSS was built to score software flaws, and a standing OAuth grant is not a software flaw, which is exactly why the external surface needs a prioritisation logic of its own: reachability and blast radius, not severity score.

Monitor continuously. The Drift integration was authorised once and then never reviewed, which is how a trusted connection becomes a standing liability. Continuous monitoring of token use, new grants and configuration changes is what turns a point-in-time assessment into an actual defence. A surface that changes daily cannot be secured by a quarterly scan.

What Most External Attack Surface Programmes Get Wrong

The most common failure is treating external attack surface management as a one-time scan rather than a continuous discipline. A point-in-time assessment captures the surface on the day it runs. By the following week it is describing a network that no longer exists. The Salesloft Drift integration was, presumably, fine on the day it was authorised.

Then there is the confusion of discovery with attribution. Finding an asset is not the same as confirming it is yours and knowing what it can reach. A tool that returns 4,000 internet-facing assets without telling you which ones matter has produced noise, not visibility.

Prioritising by vulnerability count is a subtler trap. An asset with ten low-severity CVEs behind proper authentication matters less than a non-human identity with standing API access and no MFA, and the latter carries no CVE at all. Count-based prioritisation optimises for the wrong number.

The failure that undoes all the others is the attribution blind spot: assets that never enter the inventory at all. Cloud services spun up without review. SaaS integrations authorised by a business unit. Agent connections a developer wired in over a weekend, or the config files those agents read from, which we covered in our work on AI coding assistant persistence. You cannot protect what you never recorded, and the modern surface generates unrecorded assets faster than most programmes can find them.

Making the Case for External Attack Surface Management

The argument for investing in external attack surface visibility is not "we need a tool." It is "we cannot currently see a growing share of our own exposure, and that exposure is now the leading way attackers get in." Framed that way, it is a risk statement a decision-maker can act on, not a technology request.

The supporting evidence is the detection gap. When the exposure that takes longest to find (267 days, per IBM) is also among the most expensive (USD 4.91 million for supply chain compromise), the case for finding it earlier writes itself. Every week shaved off discovery is a week the attacker does not have.

What to measure and report matters as much as the ask. Track coverage: the percentage of known assets against discovered assets, and the trend over time. Track mean time to detect new exposure. These are numbers that translate directly into a board conversation, and our guide to security metrics for executives covers how to frame them for reporting. The pitfall to avoid is leading with tooling or with raw vulnerability counts, both of which describe activity rather than risk.

External Attack Surface Management, CTEM and Vulnerability Management

These three get conflated constantly, and the relationships are worth stating plainly. Continuous threat exposure management (CTEM) is the widest lens. It does not just scan more assets than vulnerability management does; it changes what counts as an exposure. A CVE is an exposure. So is a misconfigured admin portal, an over-permissioned service account, an identity provider with MFA unenforced, a control that was deployed but never worked. CTEM asks what an attacker can actually reach through any of those paths, not just which software is unpatched.

Vulnerability management answers a narrower question: what is broken in the software we scan? It is a necessary input, not the whole picture. External attack surface management sits at the boundary, owning the internet-facing portion of the attack surface specifically, the exposed services, secrets, misconfigurations and third-party connections an attacker sees from outside. EASM feeds discovery into the CTEM cycle for the external surface; vulnerability management feeds it the CVE layer; CTEM runs both, plus the identity and control-effectiveness exposures neither of them sees, as a continuous programme rather than a periodic scan.

Where the External Attack Surface Goes Next

The surface is still evolving, and the newest layer is already being breached. As cloud gave way to API-first architecture, and APIs to autonomous agents consuming them, the connective tissue between an AI model and everything it touches has become the Model Context Protocol. MCP went from nonexistent to cross-vendor standard with more than 10,000 active public servers and 97 million monthly SDK downloads in roughly twelve months, and it now sits under Linux Foundation governance. (Source: Anthropic ecosystem update, December 2025.)

Each MCP server is a new externally reachable endpoint bridging an LLM to internal systems, and the security model has not caught up. GitGuardian found 24,008 unique secrets already exposed in MCP configuration files on public GitHub, because official setup guides normalise hardcoding credentials into config. The exposure is not theoretical: IBM's Cost of a Data Breach 2025 found that supply chain compromise, through compromised apps, APIs and plug-ins, was the most common cause of AI-related security incidents at 30%, and that among organisations reporting an AI-related breach, 97% lacked proper AI access controls.

This is not a risk that has gone unnoticed. In May 2026 the NSA published a Cybersecurity Information Sheet on MCP security, and its central point maps onto the discipline this article argues for: securing MCP means treating the agentic environment as a continuum, not patching at the interface or endpoint level. (Source: NSA Artificial Intelligence Security Center, MCP Security Design Considerations.) The guidance arrived early, for a surface layer barely eighteen months old. That timing echoes the pattern of cloud, APIs and SaaS before it, where adoption tended to outpace the controls built for it. Organisations that cannot yet inventory their APIs will have even less visibility of their MCP endpoints, a surface we examine alongside the broader security risks of AI agents separately. The castle keeps growing new gates, and MCP is the newest one.

The Castle Is Broken. Map What Replaced It.

The perimeter did not fail. It changed. It is no longer a wall around the network but governance wrapped around each class of asset: a managed identity for every user, enrolment for every device, and now a control plane for every agent that understands what each agent is, what it connects to, and what it is allowed to reach.

That is the real shift underneath the metaphor. The unit of defence used to be a range of addresses. It is now the principal and what it can reach: every entity that can authenticate and act, a user, an application, a server, a device, an agent, a service account, and the trust relationships that grant each one access to the data and systems behind it. This is the principle behind zero trust, that no principal is trusted by virtue of where it sits, and it now has to reach beyond users and devices to every agent, token and integration in the estate. External attack surface management is the discovery half of that model, finding what is exposed from the outside before an attacker does. Per-asset governance is the other half, bringing each principal under attributable, least-privilege control. Neither rebuilds the moat, and neither needs to. The organisations that understand this shift, that the surface is now defined by principals and the trust between them rather than a boundary, are the ones that close the gap first.


CyberDesserts publishes practitioner-grade analysis grounded in primary research, no vendor spin. Subscribers get new analysis as the threat landscape shifts, plus the research behind it. No sales pitches, no fluff.

Subscribe

References and Sources

  1. IBM Security. (2025). Cost of a Data Breach Report 2025. Supply chain compromise took the longest of any attack vector to detect and contain at a combined 267 days; third-party and supply chain compromise averaged USD 4.91 million per breach; global average fell 9% to USD 4.44 million while the United States rose to USD 10.22 million; supply chain compromise was the most common cause of AI-related security incidents at 30%, and 97% of organisations reporting an AI-related breach lacked proper AI access controls. IBM and Ponemon Institute.
  2. IBM Security. (2026). X-Force Threat Intelligence Index 2026. Exploitation of public-facing applications became the leading initial access vector, up 44% year on year.
  3. GitGuardian. (2026). State of Secrets Sprawl 2026. 28.65 million new hardcoded secrets detected in public GitHub commits during 2025, a 34% year-on-year increase; 64% of secrets confirmed valid in 2022 remained valid as of January 2026; 24,008 unique secrets found exposed in MCP configuration files. Fifth annual edition, based on scanning of public GitHub activity.
  4. Postman. (2025). 2025 State of the API Report. 83% of organisations have adopted some level of API-first approach, up 12% year on year; 51% have deployed AI agents, with a further 35% planning to within two years. Seventh annual report, survey of more than 5,700 developers and API professionals.
  5. Flexera. (2025). State of the Cloud Report. Organisations expect cloud spending to rise 28% year on year; enterprise workloads climbing from 52% to 54% and small-business workloads from 55% to 63%.
  6. Google Threat Intelligence Group (GTIG) / Mandiant. (2025). UNC6395 Salesloft Drift OAuth token compromise advisory, 26 August 2025. Compromised OAuth tokens from the Salesloft Drift application used to access the Salesforce environments of more than 700 organisations between 8 and 18 August 2025, bypassing multi-factor authentication; attacker goal identified as credential harvesting; not attributable to a vulnerability in the core Salesforce platform. Scale corroborated by FINRA cybersecurity alert.
  7. Have I Been Pwned. (2025). McGraw Hill breach record index. 13.5 million records confirmed and indexed as a downstream victim of the Salesloft Drift campaign; extortion conducted under the ShinyHunters brand, which Google tracks separately from the UNC6395 data-theft cluster.
  8. NSA Artificial Intelligence Security Center. (2026). MCP Security Design Considerations (Cybersecurity Information Sheet), May 2026. Securing the Model Context Protocol requires treating the agentic environment as a continuum rather than patching at the interface or endpoint level.
  9. Anthropic. (2025). MCP ecosystem update, December 2025. More than 10,000 active public MCP servers and 97 million monthly SDK downloads; protocol governance under the Linux Foundation.