The NCSC published a call for research partners this week as part of their Active Cyber Defence 2.0 programme. The focus: External Attack Surface Management. Ollie Whitehouse, the NCSC's CTO, described it as helping organisations understand their internet-facing exposure — a problem that feels like it should be solved by now but is more nuanced than it appears.
It prompted us to build SP-046 External Attack Surface Management and to think carefully about where the discipline actually stands. The controls framework is mature. The operational reality is still catching up.
What Is Already Solved
The foundational techniques of EASM are well-established and widely available in commercial tooling:
- DNS enumeration: Subdomain discovery, WHOIS lookups, zone transfer attempts, and passive DNS analysis have been standard practice for over a decade. Tools like Amass, Subfinder, and their commercial equivalents reliably enumerate domain infrastructure.
- Certificate transparency monitoring: Since Google mandated CT logging in 2018, every publicly trusted certificate is discoverable. Monitoring CT logs for your domains is effectively a solved problem — the data is public and the tooling is mature.
- Port scanning and service fingerprinting: Nmap turned 29 this year. Shodan and Censys have made internet-wide scanning accessible to anyone. Knowing which ports and services are exposed on your IP ranges is a commodity capability.
- Cloud posture assessment: CSPM tools from AWS, Azure, GCP, and third parties can enumerate publicly accessible resources within a cloud account. If you have the account credentials, finding your exposed storage buckets and databases is straightforward.
- Vulnerability scanning of known assets: Qualys, Tenable, and Rapid7 have been scanning external assets for two decades. If you know the asset exists, scanning it for vulnerabilities is mature.
The Gartner EASM category was defined in 2021 and is already consolidating. Mandiant was acquired by Google, Randori by IBM, RiskIQ by Microsoft. The market has matured past the early-stage land grab into integration with broader security platforms. CISA's Binding Operational Directive 23-01 mandated asset visibility for US federal agencies in 2022 — a signal that the capability is considered baseline, not cutting-edge.
At the control framework level, NIST 800-53 provides solid coverage. CM-08 (System Component Inventory), RA-05 (Vulnerability Monitoring and Scanning), CA-07 (Continuous Monitoring), and SC-20 (Secure Name/Address Resolution) collectively address the core EASM requirements. SP-046 maps 28 controls across 11 families — the architectural foundations are in place.
Where It Gets Interesting
If discovery of known assets on known infrastructure is solved, what is the NCSC actually researching? The developing areas — the ones where tooling, methodology, and operational practice are still evolving.
Cloud Ephemeral Surfaces
Containers, serverless functions, and auto-scaling groups create attack surface that exists for minutes or hours. A Lambda function spun up for a batch job, a Kubernetes pod serving traffic during a load spike, a temporary VM for a CI/CD pipeline — each is internet-reachable while it exists and invisible to any scan that runs after it terminates.
Traditional EASM tools scan on intervals: daily, weekly, or on-demand. The gap between scan cadence and infrastructure lifespan means that 20-40% of the external surface in cloud-native organisations is transient and potentially unmonitored. The solution is event-driven discovery — subscribing to cloud provider event streams (CloudTrail, Azure Activity Log, GCP Audit Log) to detect resource creation in real time. Some EASM vendors are building this, but it is not yet standard.
API Discovery
Enumerating REST and GraphQL endpoints from the outside is fundamentally harder than finding web servers. APIs do not announce themselves through DNS records or certificate transparency logs. They do not listen on well-known ports. They may share a hostname with a web application but respond only to specific paths with specific HTTP methods and headers.
The primary discovery methods — crawling, traffic analysis, and hunting for exposed Swagger/OpenAPI specification files — provide incomplete coverage. Internal APIs accidentally exposed through misconfigured API gateways are a growing source of breaches, and they are precisely the assets that resist outside-in discovery. API sprawl is outpacing the tooling designed to find it.
Attribution and Ownership
Discovering an asset is the easy part. Determining who owns it, why it exists, and whether it is authorised is where operational EASM programmes spend most of their time.
In a large enterprise, the EASM tool discovers 3,000 internet-facing assets. The approved inventory lists 1,200. The remaining 1,800 need to be investigated: M&A remnants on legacy infrastructure, shadow IT deployed by business units on personal cloud accounts, partner-hosted services under shared domains, test environments that were never decommissioned. Each requires manual triage — often involving conversations with people who have left the organisation.
Manual attribution of discovered-but-unowned assets consumes 40-60% of EASM operational effort in large enterprises. Graph-based approaches that link assets to identity, billing, and CMDB data are promising but early. This is a people and process problem as much as a technology problem.
National-Scale EASM
This is what makes the NCSC research genuinely novel. Running EASM for a single organisation is a solved problem at the technology layer. Running it for an entire nation's critical infrastructure is not.
The challenges are qualitatively different: jurisdictional boundaries between government scanning and private infrastructure, consent models for monitoring assets you do not own, false positive management at a scale of millions of assets, notification workflows that must work across thousands of organisations with different security maturity levels, and the political sensitivity of a government agency telling private companies their infrastructure is exposed.
The NCSC's ACD 1.0 programme demonstrated the value with services like Web Check and Mail Check. ACD 2.0 is extending this to full attack surface management — and that requires research into scalability, automation, and governance models that do not exist in the commercial EASM space because no commercial customer operates at country scale.
Supply Chain Surface
Your attack surface does not end at your boundary. Your CDN serves content under your domain. Your DNS provider resolves your hostnames. Your SaaS vendors process your data through infrastructure you cannot see. Your marketing team's WordPress microsite runs on a hosting provider you have never assessed.
The MOVEit, SolarWinds, and Okta incidents showed that compromise through third-party surfaces is not theoretical — it is a primary attack vector. But mapping transitive exposure through supply chain relationships is early-stage. Most EASM tools can assess the direct surface of a vendor you name; none can reliably map nth-party dependencies or assess the infrastructure serving content on your behalf without explicit configuration.
Standardised supply chain surface disclosure — analogous to SBOMs for software — does not yet exist. Until it does, organisations are blind to a significant portion of their effective attack surface.
Metrics
Unlike vulnerability management (which has CVSS, however imperfect) or compliance (which has audit pass/fail), EASM lacks an industry-standard measurement framework. Organisations cannot answer the question: what does good look like?
Proposed metrics include total discovered assets over time, mean time to discover new assets, mean time to remediate findings by severity, shadow IT ratio (discovered vs. approved inventory), and attack surface reduction trend. These are useful internally but impossible to benchmark externally because discovery scope and methodology vary widely between tools and programmes.
A CISO reporting to the board that the organisation's attack surface grew by 15% this quarter needs context: is that because the business expanded, because shadow IT increased, or because the EASM tool got better at finding things? Without standardised measurement, this question is unanswerable.
What We Built
SP-046 External Attack Surface Management maps 28 NIST 800-53 controls across 11 families to the EASM capability. The pattern covers the full lifecycle: discovery sources (DNS, cloud, APIs, certificates), the EASM platform (asset inventory, continuous assessment, risk prioritisation, threat intelligence), and remediation integration (vulnerability management, incident response, supply chain assurance).
The pattern captures what is mature as control mappings and what is developing as implementation challenges. The 10 threat scenarios include shadow IT exposure, DNS hijacking, certificate transparency blind spots, cloud storage misconfigurations, and supply chain compromise vectors.
Critically, we have included a Developing Areas section in the pattern that explicitly flags the six developing areas described above. Security architecture patterns should capture not just best practice but the limits of current practice — where the gaps are, where the tooling falls short, and where the research is still active.
Why This Matters for Practitioners
If you are a security architect, EASM is increasingly a capability you need to design for, not buy as an appliance. The developing areas — ephemeral cloud surfaces, API discovery, attribution, supply chain mapping — are architectural problems. They require integration between EASM tooling, cloud event streams, API gateways, CMDBs, and vulnerability management platforms. That integration does not come out of the box.
If you are a CISO, the maturity frontier tells you where to set expectations. Asset discovery is a reasonable demand; fully automated attribution of every discovered asset is not, yet. Continuous monitoring of known infrastructure is achievable; complete visibility of your supply chain's attack surface is aspirational.
If you are involved in the NCSC's ACD 2.0 programme, the pattern provides a structured control framework for EASM that maps directly to NIST 800-53 — useful for aligning research outputs with international standards.
Explore SP-046 | NCSC Active Cyber Defence | CISA BOD 23-01
Russell Wing — Co-founder, Open Security Architecture