Attack surface management vs vulnerability scanning

Attack surface management vs vulnerability scanning: which one to choose first

Start with attack surface management if you do not trust your asset list, and start with vulnerability scanning if you do. Attack surface management discovers internet-facing assets you did not know you had, while vulnerability scanning tests the assets you already know about for known weaknesses. Most mature programs end up running both, because a scanner can only check what it has been told to check, and discovery without follow-up scanning produces a list nobody fixes. The first question to answer is whether your inventory of public IP ranges, domains, cloud accounts and third-party hosted services matches what your teams actually operate. If it does not, scanning a stale list gives you false comfort about coverage you do not have.

If you are a US federal civilian agency, the choice is largely made for you. CISA's BOD 23-01, issued on 3 October 2022, requires automated asset discovery every 7 days covering at least your entire IPv4 space, and vulnerability enumeration across discovered assets every 14 days. Check the directive's scope rules and excluded asset types, such as ephemeral containers and third-party SaaS, against your own estate before assuming discovery covers them. If you hold PCI DSS scope, the requirements point the other way. Vulnerability scans must run at least once every three months, and requirement 11.3.1.2 expects internal scans to use authenticated scanning with sufficient privileges, with systems that cannot accept credentials documented. Confirm with your qualified assessor how your cardholder data environment is defined before you rely on discovery alone, since PCI scope is set by your data flows, not by what a discovery tool happens to find.

How the two approaches differ on goals, scope and cadence

This table compares external attack surface management (continuous discovery of assets you may not know about) with vulnerability scanning of a known asset list. Read each row as a question to ask your team: what you start with, what you cover, and how often the work must run. The main takeaway is that discovery and scanning answer different questions, so the cadence you need depends on your regulator, your framework and how much of your estate is unknown to you today.

Dimension	Attack surface management	Vulnerability scanning
Primary goal	Find internet-facing assets nobody has inventoried, then decide which ones belong to you	Detect known weaknesses on assets already on the inventory
Starting input	Seed domains, IP ranges or organization identifiers; the tool builds the asset list	A maintained asset list, with credentials where authenticated checks are used
Asset coverage	Mainly internet-facing hosts, with some tools reaching cloud and roaming assets	Internal and external assets on the list, including internal networks and cloud hosts you name
Authentication	Usually unauthenticated outside-in observation	Unauthenticated or authenticated; PCI DSS 11.3.1.2 expects authenticated internal scans where possible
Cadence reference	CISA BOD 23-01 sets automated discovery every 7 days for federal civilian agencies	CISA BOD 23-01 sets enumeration every 14 days; PCI DSS 11.3.1 and 11.3.2 set scans at least every three months
Typical operator	Security operations or an external monitoring service, often with asset owners reviewing new findings	Vulnerability management team or a scanning service, with system owners remediating
Output used for	Triage of unknown assets, ownership assignment and feeding the asset inventory	Remediation tickets, patch prioritization and evidence for scan requirements
Confirm before buying	Which cadence your regulator or framework requires, and whether ephemeral assets are in scope	Which PCI DSS or CISA requirements apply to your environment and the credential access your scanner needs

How discovery feeds scanning and why the asset list decides the result

A scanner can only test what is on its list, so the asset inventory sets the ceiling on what any vulnerability scan can find. In a working pipeline, discovery builds and refreshes that inventory, enumeration checks each discovered asset for its services and versions, and detection signatures are then applied to the enumerated results. If discovery stops or lags, the scanner keeps running on a stale list and reports a clean result for hosts it never sees. A new virtual machine, a forgotten staging host or a marketing site on a new IP address will be missed until something adds it. Check how often your scanner's target list is refreshed from discovery and who owns that feed, not only how often scans run.

Discovery without authenticated checks produces thin findings. An unauthenticated probe can tell you that a port is open and a banner says a product is present, but it cannot see installed patches, local configuration or missing hardening settings. PCI DSS requirement 11.3.1.2 makes this point for internal scans by requiring authenticated scanning with sufficient privileges and a documented list of systems that cannot accept credentials. Decide early which assets will receive credentialed scans, which will be external-only, and who approves the exceptions. Ask any vendor how credentials are stored, which accounts they need and what they can do on the target.

CISA's BOD 23-01, issued on 3 October 2022, sets the reference cadence for federal civilian agencies: automated asset discovery every 7 days covering at least the entire IPv4 space, and vulnerability enumeration across discovered assets every 14 days. The directive covers IP-addressable assets over both IPv4 and IPv6, including roaming and cloud assets, but it excludes ephemeral assets such as containers and third-party SaaS. For a buyer, that exclusion means the directive will not cover short-lived workloads or hosted services you do not operate. Your own tooling must inventory container platforms, cloud accounts and SaaS tenant configurations, and you should confirm with each vendor which asset types their discovery actually reaches.

What each approach finds and what it misses

Attack surface management and vulnerability scanning answer different questions: one asks what is exposed, the other asks what is wrong with what you already listed. Read each card with the other in mind, because the gaps of one are usually the job of the other.

Forgotten internet-facing hosts

Attack surface management discovers hosts, domains and services that nobody registered in a CMDB, often left behind after a project, an acquisition or a test environment went live. Ask the provider how it attributes assets to your organization, how it handles shared hosting and third-party SaaS, and how often it re-runs discovery. Illustrative example: a staging host with a public IP that was never added to the asset list would appear in discovery but not in a scan of your known ranges.

Shadow cloud resources

Cloud accounts, storage buckets, load balancers and certificates created by individual teams are the most common source of perimeter surprises. Discovery must reach assets that roam between IP ranges, which is why cloud coverage is a question to put in writing. Confirm whether the approach excludes ephemeral assets such as containers and third-party SaaS, because a scanner pointed at a fixed list will never see either unless someone adds them.

Exposed services and certificates

Discovery maps open ports, service banners, TLS certificates and their expiry dates, which tells you what an attacker sees before any exploit is attempted. A certificate that expires or a management interface reachable from the internet is a finding in its own right. Ask whether the tool reports change over time, so a new listening service triggers a review rather than sitting unnoticed in a monthly export.

Known CVEs and misconfigurations on listed assets

Vulnerability scanning checks assets on your list against vulnerability detection signatures, reporting known CVEs and configuration weaknesses such as default credentials or weak protocols. Its value depends on signature freshness, so ask how quickly the vendor adds coverage after a disclosure. Authenticated scans reach installed packages and local settings that an unauthenticated probe cannot see, which changes how many findings you get and how accurate they are.

Authenticated scanning and documented exceptions

PCI DSS requirement 11.3.1.2 asks internal vulnerability scans to use authenticated scanning with sufficient privileges, and to document any system that cannot accept credentials. Confirm that scan accounts have the privileges the scanner needs, that credential vault access is controlled, and that the exception list is kept current. Systems that cannot accept credentials still need a documented reason and a compensating view.

Gaps in both approaches

Neither approach finds deep internal flaws in custom code, broken business logic or chained misuse of legitimate functions, and neither proves that an attacker could exploit a finding. Discovery also misses anything without a public footprint, and scanning misses anything nobody listed. Plan scheduled penetration testing and internal review alongside both, and treat the findings from each as input to the next scan cycle.

Which approach fits which environment

Public cloud estates usually start with an incomplete asset list. Accounts, subscriptions, load balancers and storage endpoints are created by many teams, often outside the change process that keeps a CMDB current, so the inventory lags behind what is actually reachable from the internet. The likely gap is internet-facing assets nobody registered, which a scanner pointed at a known list will never test. Start with continuous external discovery across all public IP space and DNS, then feed the results into authenticated or agent-based scanning for the assets that persist.

Starting point: cloud account and DNS records, plus any existing cloud inventory export.
Likely gap: short-lived or forgotten endpoints that are reachable but absent from the scan list.
Start with: external attack surface discovery, then scheduled scanning of the discovered set.
Watch for: ephemeral containers and third-party SaaS, which discovery tooling may not treat the same way as persistent hosts.
Condition: if your cloud tagging and account structure are consistent, a known-asset scan can cover most risk sooner.

Ask the vendor or your own team which asset classes the discovery covers and how it handles assets that appear and disappear within a single cycle.

When PCI DSS and CISA rules call for scanning, discovery or both

If you handle cardholder data, PCI DSS sets a fixed scan rhythm that discovery alone will not satisfy. Requirements 11.3.1 and 11.3.2 call for internal and external vulnerability scans at least once every three months. Requirements 11.4.2 and 11.4.3 call for internal and external penetration tests at least every 12 months and after significant changes. Your attack surface inventory can tell you which external addresses exist, but the assessor will want dated scan reports tied to the in-scope systems in your cardholder data environment. Ask your QSA or assessor to confirm how they define in-scope and whether newly discovered hosts must join the scan set before the next quarterly cycle.

Requirement 11.3.1.2 is the one most often under-planned. Internal scans must use authenticated scanning with sufficient privileges, and any system that cannot accept credentials must be documented. This became mandatory on 31 March 2025, according to PCI DSS v4.0 SAQ D. Practically, that means a scanner service account per segment, a record of which hosts refused logon, and a compensating explanation for each one. Confirm with your assessor whether they accept a documented exception list or expect a remediation plan for every unauthenticated host.

For US federal civilian agencies, CISA's directive sets a different cadence, and eligible smaller organizations can use the no-cost Cyber Hygiene Services program. That service continuously monitors internet-accessible assets on public, static IPv4 addresses and sends weekly reports plus ad hoc alerts for urgent issues. It does not cover internal networks, cloud assets without static public addresses, or ephemeral workloads, so it complements rather than replaces an authenticated internal program. This section does not replace your assessor's reading of scope. Confirm with your QSA or assessor, and with CISA for federal or eligibility questions, before you set your scan calendar.

What you receive from each approach

This table compares the artifacts each approach hands you: an external attack surface inventory on one side, scan reports and remediation evidence on the other. Read each row as what lands on your desk, then check whether your team can act on it without the other output. The main takeaway is that the inventory tells you what to scan, and the scan reports tell you what is wrong with it.

Deliverable	Attack surface management	Vulnerability scanning
Asset inventory	Discovered internet-facing hosts, domains and services, including assets nobody on your team registered	Known asset list supplied by you, checked for vulnerabilities; assets missing from the list are not reported
Change history and ownership	Records when an asset appeared, changed or disappeared, and whether ownership tags can be attached to it	Usually shows scan-to-scan result changes; ownership depends on tags you maintain in your own asset register
Exposure alerts	Alerts when new internet-facing assets or risky services appear between scheduled checks	Alerts when a scan finds a new vulnerability on a known asset; confirm alert routing with your vendor or service provider
Authenticated status per host	Generally not reported, because discovery does not log in to hosts	Each host should show whether credentials were used and what privileges applied; confirm this field in the report format
Documented exceptions	Assets you cannot scan or do not own should be marked as out of scope and kept in the register	Hosts that cannot accept credentials should be listed with the reason, as PCI DSS requirement 11.3.1.2 expects for internal scans
Remediation tracking	Tracks whether an unknown asset was approved, retired or brought under an owner	Tracks the status of each finding through fix, risk acceptance or false positive, usually in a ticketing or case tool
Retest evidence	Shows whether an asset is still exposed after a fix or takedown, based on the next discovery run	Shows a rescan result for each fixed finding; confirm that the retest covers the same authenticated scope as the original
Feeds the other output	Adds newly found hosts to the scan scope, so the next scan covers them	Identifies services that discovery should watch more closely, and flags unowned hosts for review

What drives cost and effort for each approach

Cost and effort in this comparison follow from how many assets you must track, how much access the scanner gets, and who acts on the output. Several of the drivers below apply to both approaches, but they hit each one at a different point in the cycle.

Asset footprint size and churn

Attack surface management spends most of its effort keeping an inventory current as hosts, domains and services appear and disappear. A large, fast-changing footprint raises the recurring cost of discovery runs, reconciliation and deciding which new assets belong to you. Ask the provider how discovery is priced against asset count, whether ephemeral assets are included, and how false attributions are removed.

Cloud accounts and IP ranges

Every cloud account, subscription and IP block you add widens the discovery scope and the list of ownership questions someone must answer. Onboarding is largely one-time work to map accounts and agree tags, but each new account adds recurring review. For BOD 23-01 style coverage, confirm whether the scope includes IPv6, roaming and cloud assets, and who approves changes to the scope.

Credentialed access and its administration

Authenticated scanning needs service accounts with sufficient privileges, vaulted secrets, rotation and a documented list of systems that cannot accept credentials. Designing the credential model is one-time work, while rotation, access reviews and exception records recur. Ask who holds the scanner credentials, how they are stored, and what the quote assumes about the number of hosts requiring credentials.

Signature update obligations

Detection coverage only holds if vulnerability signatures are refreshed quickly after vendor release, and that refresh is an ongoing operational duty. Scanner subscriptions, feed review and the time to apply updates to every scanning node all recur. Ask whether the quote covers feed licensing, how fast signatures are applied, and whether updates reach air-gapped or segmented scanners.

Triage and ownership effort

Discovery and scanning both generate findings that someone must confirm, deduplicate and assign to an owner. Attack surface lists often need more triage because the asset itself may be unknown to the team, while scan results need verification against known systems. Define who accepts new assets, who owns each finding, and how false positives are closed before you compare effort estimates.

Ticketing integration

Connecting outputs to a ticketing or service management system is mostly one-time configuration of fields, severity mapping and deduplication rules, followed by recurring maintenance when workflows change. Without it, both approaches end in spreadsheets and missed remediation. Ask what the quote includes for connectors, mapping, and tuning, and who maintains those integrations after handover.

How to combine them without duplicating work

The sequence turns a discovered asset list into a scoped scan schedule and a penetration test plan, so each tool checks what the other cannot see and nobody scans the same host twice without a reason.

Establish the inventory from discovery
Run external discovery against your public ranges, cloud accounts and known domains, then merge the results with your configuration management database and cloud inventory. The security or platform team owns the merged list. It is done when every discovered host either matches a known record or is flagged as unknown for triage. Ask your discovery vendor which address families, cloud accounts and ephemeral assets their tooling covers before you trust the count.
Classify assets by owner and scope
Assign each asset a named owner, an environment (production, staging, development), a data classification and an in-scope or out-of-scope flag. Third-party hosted services usually need a separate status because you may not be permitted to scan them. The asset owner or service owner confirms each record. It is done when no in-scope asset lacks an owner, and every out-of-scope asset has a written reason.
Set authenticated scanning where credentials can be granted
For hosts you own and can access, create scan accounts with the least privilege that still lets the scanner read patch levels and configuration. Record which hosts accept credentials and which do not. PCI DSS requirement 11.3.1.2 expects internal scans to be authenticated and expects systems that cannot accept credentials to be documented. The output is a credential coverage report that the scanning team reviews each cycle.
Document exceptions with a reason and a review point
Hosts that cannot be scanned, cannot accept credentials, or sit outside your authority, such as a vendor-managed appliance, go into a documented exception register. Each entry records the reason, the compensating check (for example, external-only scanning or a vendor attestation you request) and who approved it. The register is complete when every unscanned in-scope asset appears in it, and an owner has signed off on each line.
Route new exposures into scan scheduling
Feed new or changed discovered assets into the vulnerability scanner's target list automatically or through a ticket. Discovery results that cannot be matched to an owner go to triage before they are scanned. The check is that every new internet-facing host has a scan job or an exception entry within the period your policy sets. Confirm the cadence with your own policy, because the regulatory minimums are set per framework and your tooling may run faster.
Validate findings and retire duplicates
Compare scanner findings against discovery output and the exception register. Remove duplicate tickets created by the same weakness on the same host, and mark findings on assets that no longer exist. Vulnerability owners confirm the closed items. This step is done when the open findings list maps one-to-one to live, in-scope assets, which keeps the next penetration test scope accurate.
Schedule penetration tests against the verified asset list
Build the penetration test scope from the validated inventory, not from the original project list. Include the exposure history from discovery and the scanner results, so testers can focus on assets that changed or carry unresolved findings. The test lead and the security owner sign the scope before testing starts. Scanning does not replace this step: NIST SP 800-115 describes penetration testing as a separate technique that complements regularly scheduled scanning.
Feed penetration test results back into discovery
After each penetration test, add any newly found hosts, services or credentials-related gaps to the inventory and the scanner targets. Update the exception register where the test revealed assets that were not scanned. The check is that the test report's asset list matches the inventory, and every new item has an owner. That closing loop is what keeps the next cycle from duplicating earlier work.

Questions buyers ask before choosing attack surface management or scanning

Can one tool handle both attack surface management and vulnerability scanning?

Some platforms cover both, but the two jobs start from different inputs. Attack surface management begins with discovery and works out what you own on the internet, so it needs no asset list to start. Vulnerability scanning begins with a known list of assets and checks each one for weaknesses. Many buyers run discovery continuously and feed the discovered assets into scheduled scans. Check whether a product discovers assets it has not seen before, whether it scans them on a schedule you set, and whether it can run authenticated checks on internal hosts. Confirm each capability in writing rather than assuming a single product does everything.

How often should discovery and scanning run?

Cadence depends on how fast your footprint changes and on what your regulator or assessor requires. For federal civilian agencies, CISA's BOD 23-01, issued on 3 October 2022, requires automated asset discovery every 7 days covering at least the entire IPv4 space, and vulnerability enumeration across discovered assets every 14 days. PCI DSS requires internal and external vulnerability scans at least once every three months (requirements 11.3.1 and 11.3.2). Organizations with fast-changing cloud footprints often run discovery more frequently than the minimum. Ask any vendor to state the discovery and scan frequency they support and whether it can be set per asset group.

How much effort does the internal team need to keep these running?

The internal effort is mostly triage, ownership mapping and exception handling, not running the scanner itself. Discovery output needs someone to decide which newly found assets are yours, which are third-party, and which are out of scope. Scan results need an owner per asset, a route to remediation, and a documented process for systems that cannot accept credentials. Expect the load to rise with the number of discovered assets and with the rate of change in cloud and internet-facing services. Ask for a description of the alert volume and the triage workflow in any proposal.

Can we run attack surface management and scanning ourselves?

Yes, many teams do, provided they have people who can operate the tooling, maintain credentials for authenticated scans, and handle the output. The main risks of running it in-house are gaps in discovery coverage, scans that run without credentials and therefore miss local weaknesses, and reports that nobody acts on. Self-operation suits teams with stable footprints and staff who already manage scanners. Engaging an implementation partner usually focuses on setup, integration with ticketing and asset inventories, and documentation, after a written scope is agreed. Confirm which parts you will own after handover.

How long does setup take, and what drives that time?

Setup time depends mainly on how complete your asset inventory already is, how many network segments and cloud accounts need access, and how many credentialed scans you need. Discovery can start quickly against public address space, while authenticated scanning needs service accounts, network paths and approvals for each segment. Integration with ticketing, identity and asset management systems adds time, as does agreeing rules for systems that cannot accept credentials. No supplied figure sets a general duration, so ask the provider for a timeline tied to your scope and the dependencies listed above.

What should we ask for in a quote for this work?

A useful quote separates one-time work from recurring work. One-time items usually include scope definition, discovery baseline, credential setup, integration and documentation. Recurring items usually include scan cycles, triage support, reporting and any retained support. Ask the provider to list which asset ranges and cloud accounts are in scope, which scan types are included, how authenticated scanning is handled, what happens to assets that appear during the engagement, and how findings are handed over. Ask for the exclusions in writing as well, because they often determine the true effort.

Does attack surface management or scanning replace penetration testing?

No. Discovery and scanning find known weaknesses and reveal what is exposed, but they do not test whether an attacker can chain weaknesses to reach something valuable. NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning interspersed with periodic penetration testing, and PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes (requirements 11.4.2 and 11.4.3). PCI SSC's guidance also states that simply running an automated tool does not satisfy the penetration testing requirement. Use discovery and scanning to keep your inventory accurate and to make penetration tests more focused.

How DeployOpen scopes and runs discovery and scanning in your own infrastructure

DeployOpen is a Chainscore Labs company. It plans, implements, hardens and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it runs security testing and prepares compliance evidence for those same environments. It does not issue audit reports, attestations or certifications, so if an auditor needs to accept scan or test output, the reader should confirm with that auditor which format and evidence they expect before scoping any work. For discovery and scanning, the first decision is where the discovery engine and scanners run. Inside your network, an internal scanner can perform authenticated checks, while external discovery depends on what the public internet can see. Both should be defined in the written scope.

Most engagements are fixed-scope, with the asset boundaries, deliverables and timelines agreed in writing before work starts. For this topic, the scope should state which address ranges, domains and cloud accounts are in discovery, which ones are excluded, and how newly discovered assets are handled. Ask the delivery team to define the handover of the asset inventory into the scanning schedule, and to name who approves a new target before it is scanned. Quotes follow from that written scope, so the more precisely the boundaries and cadence are described, the more comparable the quotes will be. Ask each provider to itemize discovery, scanning, triage and reporting separately so that you can see which recurring costs remain after the initial build.

Ongoing discovery, scanning and retests are available as retainers, which suits the recurring cadence that a continuous program needs. Confirm in the statement of work whether the retainer covers re-running scans after patches, how alerts for newly exposed services are routed, and who maintains the scanner signatures and the discovery configuration when platforms are upgraded. Authenticated scanning requires credentials that are issued and rotated, so ask who holds those credentials, where they are stored and how their use is logged. Treat these as decisions to record now, because they determine whether the asset list and the scan results stay accurate after the first engagement ends.

Attack surface management vs vulnerability scanning