What is attack surface management (ASM)?

Key takeaways

• ASM is asset discovery, not vulnerability assessment. It tells the organization what it has; vulnerability management tells the organization what is wrong with what it has.
• For mid-market manufacturers, the most material ASM findings are usually shadow assets the organization did not know existed: forgotten subdomains, orphaned cloud resources, vendor-managed infrastructure, M&A-inherited environments.
• Continuous cadence is non-negotiable. New assets appear daily; weekly-or-slower mapping misses the window during which an exposed asset is most likely to be exploited.
• ASM alone is not security. The data has to feed exploitation testing, control validation, and remediation; otherwise it is inventory for its own sake.
• ARG uses ASM data as one input to continuous adversarial simulation, not as a standalone deliverable.

What does attack surface management actually do?

An ASM program does four things on a continuous cadence.

1. Discover assets. Find everything the organization has, not just what is in the official inventory. External: domains, subdomains, public IP ranges, SSL certificates, cloud-hosted services, SaaS tenants, partner-hosted infrastructure. Internal: workstations, servers, virtual machines, containers, identity records, OAuth grants, API keys, repositories.

2. Inventory and attribute. For each asset, capture metadata: owner, function, technology, last seen, exposure level, business criticality. Attribute assets to the organization through DNS, certificate chains, organization records, network ownership, and (where active probing is appropriate) banner and behavior matching.

3. Monitor for changes. Detect new assets appearing, existing assets changing posture (a service newly exposed, a certificate renewed with a wider scope, a subdomain redirecting somewhere new), and assets disappearing (was it intentional, or was it taken over by an attacker).

4. Triage and act. Flag findings that represent material risk: exposed services that should not be public, vulnerable software versions, expired certificates, expired domain registrations that an attacker could acquire, subdomain takeover vulnerabilities, leaked credentials.

The deliverable is a continuous dashboard plus an alerting feed. Day-zero discovery (the first time the program runs against an environment) typically surfaces dozens to hundreds of assets the organization did not know it had.

External, internal, and third-party attack surface: how each one is mapped

The attack surface has three layers; each is mapped with different techniques.

External attack surface (EASM). Everything reachable from the public internet. Mapped through DNS enumeration, certificate transparency log monitoring, passive infrastructure scanning, search-engine indexing of exposed services, and breach corpora correlation. The output is a list of assets the attacker can reach without any access yet.

Typical EASM findings include forgotten marketing-campaign subdomains pointing at orphaned cloud resources, dev or staging environments accidentally exposed, expired domain registrations, vendor-managed subdomains the organization did not realize it owned, public-facing applications running outdated software, and SaaS tenants visible through misconfigured sharing.

Internal attack surface (CAASM). Everything inside the organization's logical boundary. Mapped through integrations with cloud providers (AWS, Azure, GCP), identity providers (Entra, Okta, Google), endpoint management tools (Intune, Jamf), SaaS administration consoles, and source control. The output is a unified inventory across surfaces that traditionally lived in different tools.

Typical CAASM findings include unmanaged endpoints, identity records without active owners, OAuth grants to apps no one remembers authorizing, public S3 buckets, unfederated SaaS tenants, source code repositories with sensitive material, and shadow IT subscriptions on corporate cards.

Third-party attack surface. The infrastructure of vendors, partners, and supply chain entities whose compromise would enable an attack on the organization. Mapped through vendor disclosures, public security ratings, certificate chain analysis, and (in mature programs) coordinated assessment with the vendors themselves.

Typical findings include vendors with exposed remote-access infrastructure, vendor employees with weak authentication on shared collaboration tools, vendor-managed subdomains pointing at the manufacturer's environment, and SaaS providers with broad access to internal data. See What is third-party risk for manufacturers?.

A complete program covers all three. Most mid-market ASM programs start with external, expand to internal in year two, and add third-party in year three.

Why ASM alone does not equal continuous security

ASM is necessary but not sufficient. Four limits matter:

1. Discovery without exploitation testing produces inventory, not security. Knowing an asset exists does not equal knowing whether an attacker can compromise it. Continuous human-led testing on top of the ASM inventory (continuous penetration testing) closes the gap.
2. Asset coverage does not equal behavior coverage. ASM inventories things; it does not measure whether existing controls catch attacker behavior against those things. Breach and attack simulation sits in the gap.
3. Technical surface does not cover human or physical surfaces. ASM tools do not inventory who is susceptible to phishing or which physical entries are exploitable. Adversarial simulation covers the human and physical surfaces.
4. Findings without triage capacity become noise. Many mid-market organizations have ASM data that no one acts on. The program runs; the alerts fire; the backlog grows; nothing changes. ASM with triage capacity is a security input; ASM without it is theater.

The right framing: ASM is the inventory layer. It feeds testing, control validation, and remediation. On its own, it is not a security program.

Examples of attack-surface findings missed by vulnerability scanners

Findings ASM surfaces that vulnerability scanners typically do not:

• A retired marketing-campaign subdomain pointing at an orphaned cloud bucket. Scanner does not know the subdomain exists; it is not in the official inventory. ASM finds it through certificate transparency logs. The bucket is takeable; an attacker can register a replacement and serve content from the original subdomain.
• An expired domain registration the organization forgot it had. Original domain used for an old project; registration lapsed; attacker registers it; emails to that domain now arrive at the attacker. Scanner only checks domains it is told about.
• A SaaS tenant created by a department, federated to corporate identity, not in any official inventory. Identity provider records show the federation; ASM surfaces it; security has not heard of the tool. Scanner does not test SaaS tenants.
• An acquired company's subdomains still pointing at acquired-company infrastructure. The acquisition is complete on paper; the DNS migration is incomplete in practice. Attacker reaches the old environment through the new organization's branding.
• A vendor case study that names a hostname an attacker can reach. "Acme Manufacturing's portal at portal.acme.example/customer-x" - the hostname is now reachable and indexable. Scanner does not crawl marketing material.
• Sub-tier vendor exposure. A vendor of a vendor has exposed infrastructure that reaches into the organization through an integration. ASM with third-party coverage catches this; scanners do not.
• Persistent OAuth grants to apps no one remembers. Identity-side CAASM coverage catches this; endpoint and network scanners miss it entirely. See What is consent phishing (OAuth phishing)?.

The pattern across these findings: they are about assets the organization does not know it has, not vulnerabilities in assets the organization is tracking. The information-asymmetry between attacker and defender is what ASM addresses directly.

How to evaluate an ASM tool or service

For a mid-market manufacturer evaluating an ASM offering:

1. Discovery breadth. External plus internal plus third-party. A tool that does only external is half the answer.
2. Discovery freshness. New assets surfaced in hours or days, not weeks. The attacker's window is the time between asset appearance and asset awareness; the program should minimize it.
3. Attribution accuracy. Asset-to-owner mapping that is right most of the time. Wrong attribution produces noise that destroys triage capacity.
4. Triage workflow. Each finding routes to a clear owner with a clear next step. Integration with ticketing and chat is table stakes; without it, the program lives in a portal nobody opens.
5. OT awareness. For manufacturers, the tool either inventories OT/ICS assets through passive observation or explicitly stays out of that surface. A tool that actively scans OT without authorization is operationally dangerous.
6. Compliance integration. Output that supports NIST CSF 2.0, NIST SP 800-171, and CMMC evidence requirements. The same data should serve compliance and security.
7. Total cost of operation. Licensing plus internal time. A program that requires a dedicated FTE may not be the right shape for a 200-person manufacturer; a managed service may be a better fit.
8. Out-of-scope honesty. Vendors that claim ASM replaces penetration testing or red teaming are not credible. The right vendor is clear about what ASM does and does not do.

Best practices for acting on ASM data

1. Triage by exploitability and business impact, not asset count. A handful of high-impact exposures should drive the backlog; a hundred low-impact findings should not.
2. Set time-to-decommission targets for shadow assets. Forgotten subdomains, orphaned cloud resources, and expired registrations should be retired or transferred within a defined window after discovery.
3. Tie findings into incident response readiness. Each ASM finding is a scenario for the incident response plan. Did the path matter? Could the response handle it?
4. Feed findings into adversarial simulation. Exposed assets identified by ASM are the prime targets for the next round of continuous penetration testing and adaptive simulation. The pipeline produces measurable security, not just inventory.
5. Coordinate with marketing and procurement. Many shadow assets are produced by marketing campaigns, procurement-driven SaaS adoption, and M&A. Earlier coordination reduces the shadow asset rate.
6. Maintain owner accountability. Every asset has a named owner; ownership changes are tracked; orphaned assets surface immediately.
7. Report cadence that matches triage capacity. Daily alerting for material findings, weekly summary for triage, quarterly trend for executive view. Match the cadence to the team's ability to act.

Attack surface management FAQs

Is ASM the same as vulnerability management?

No. Vulnerability management identifies known weaknesses in assets that are already inventoried. ASM identifies the assets themselves, including assets the organization did not know it had. ASM feeds vulnerability management; vulnerability management does not produce ASM data on its own.

How often should attack surface mapping run?

Continuously. New assets appear daily in mid-market environments: a new SaaS tenant, a new vendor integration, an acquired company's domains, an experiment that got published. Quarterly or annual mapping is structurally too slow; the attacker is mapping continuously, and the defender needs to match the cadence.

Does ASM include OT and ICS assets?

Some ASM products do; most do not. The internal scanning required to inventory OT/ICS systems carries operational risk if done without OT-aware tooling. Mature ASM programs for manufacturers treat OT/ICS as a separate inventory, mapped through passive observation and engineering-team coordination rather than active scanning. See What is operational technology (OT) security?.

What is the difference between EASM and CAASM?

EASM (External Attack Surface Management) inventories assets reachable from the public internet: domains, subdomains, public IPs, exposed services, third-party-hosted infrastructure. CAASM (Cyber Asset Attack Surface Management) inventories internal assets across IT, identity, cloud, SaaS, and endpoint. Mature programs run both.

How ARG uses ASM data as input to adaptive simulation

ARG treats ASM as one layer of the continuous adversarial simulation program, not as a standalone deliverable. The output is a constant feed of newly-discovered assets that targeted testing then exercises.

The ASM pipeline is operated by James Wall on infrastructure ARG owns and controls. External discovery runs continuously through DNS, certificate transparency, passive scanning, and third-party-data integrations. Internal discovery runs through identity-provider and cloud-provider integrations where the client grants access. Third-party discovery starts from the client's vendor list and the corporate-reconnaissance output, expanding through certificate chains and partner disclosures.

Findings feed three downstream processes. First, continuous penetration testing targets newly-discovered exposed assets immediately, with human-led exploitation testing within days of discovery. Second, adaptive simulation uses asset findings as pretext context: a newly-discovered SaaS tenant becomes a consent-phishing pretext for the relevant team. Third, the client's monthly operational packet includes a triage-ready summary of new findings, ownership, and recommended action.

Findings are scored by exploitability and business impact, not by asset count. A small number of high-impact findings drives the actionable backlog; the long tail is monitored without producing noise.

For founding clients, continuous ASM is part of the monthly retainer alongside the rest of the program.

Apply as a founding client or see how the engagement works for the full delivery cycle.