At 6:40 a.m. in this imagined Modesto distributor, the operations lead is approving a vendor’s remote login to its order system before trucks leave. Attack surface management is the work of finding every reachable route into that business, deciding which are necessary, and reducing the rest without interrupting shipping.
The decision is not simply whether the login is safe or unsafe. The vendor may need access to resolve a shipping-label issue, while a forgotten test portal or an old remote-support account may have no current owner at all. Block every connection and the shipping workflow could stall; leave every route open and the team may be accepting access it no longer needs. Attack surface management (ASM) gives the organization a repeatable way to see those choices and assign someone to act on them.
What does attack surface management actually cover?
An organization’s attack surface is the collection of ways its technology and information could be reached or affected. That can include internet-facing systems, cloud services, user accounts, remote-access tools, vendor connections, and software that the organization depends on. ASM is the continuing work of identifying those assets and access paths, understanding their purpose and exposure, and reducing avoidable risk.
It is broader than running a vulnerability scan. A scan might report a service or software flaw; ASM asks whether the affected system is actually reachable, who owns it, what business process depends on it, and whether that exposure should exist. The NIST Cybersecurity Framework 2.0 describes understanding assets—including data, hardware, software, systems, suppliers, and services—as a basis for prioritizing cybersecurity efforts around risk and mission needs.1
That distinction matters in a business with 100 or more employees. An asset list can be technically accurate and still fail as a decision tool if it does not say whether a remote connection is required for payroll, order processing, an EHR workflow, or a school’s bell schedule. ASM connects the technical finding to the operational owner who can decide what to do next.
What belongs on the attack-surface list?
Start with what the organization controls, then look for what is exposed on its behalf. A practical first inventory can include:
- Public IP addresses, domains, DNS records, web applications, and externally visible certificates.
- Cloud-hosted systems, storage, and services that staff or customers can reach online.
- Remote access such as VPNs, remote-support software, administrative portals, and vendor connections.
- Important internal systems and accounts, especially where they connect to internet-facing services.
- Older, temporary, or third-party-managed assets that may not appear in the main IT inventory.
This is a working scope, not a demand to buy a new platform before doing anything. Use the information already held in network documentation, cloud consoles, endpoint tools, identity systems, and vendor records. Then compare it with what can be observed from outside. CISA’s internet exposure guidance recommends identifying internet-accessible assets, assessing whether exposure is necessary, and securing or removing access accordingly.2
External discovery also needs a boundary. Search only address ranges and systems your organization is authorized to assess, and coordinate active testing with the people responsible for those systems. A finding is a prompt to validate ownership and business purpose—not permission to probe a third party’s equipment or make a production change without review.
How do we turn findings into safe decisions?
A useful ASM process produces a decision and an owner, not just a longer spreadsheet. For each finding, record what was observed, who confirms it, what workflow depends on it, and the approved next action.
| Finding or condition | Question for the owner | Possible decision | Operational check |
|---|---|---|---|
| Vendor remote-support portal | Which vendor needs it, and for what task? | Retain with restricted access, or remove | Confirm support still works through the approved route |
| Public test or staging site | Is it still used by a team or customer? | Retire it, or restrict access | Check that no live workflow depends on it |
| Unexpected open service | Which system owns the service, and why is it reachable? | Close, limit, or document the need | Confirm the change does not interrupt a required connection |
| Known vulnerability on an exposed system | Is the affected system reachable and business-critical? | Patch, mitigate, restrict, or replace | Validate the fix and the service afterward |
A sensible review moves through five steps:
- Discover: Combine internal records with outside-in visibility. Include vendor and cloud connections, not just equipment in an office.
- Validate: Have a named technical contact confirm the asset and a business owner confirm its purpose. Mark uncertain ownership instead of quietly treating an unknown system as approved.
- Rank: Consider internet reachability, sensitivity, business impact, known exploitation, and available safeguards together. A high-severity finding on a disconnected test machine may call for a different sequence than a remotely reachable system supporting orders.
- Choose: Remove access that has no current purpose; otherwise restrict the path, strengthen authentication, patch or mitigate the system, and document why it remains exposed.
- Verify: After a change, check both sides of the result: is the unnecessary route actually closed, and can the required workflow still operate?
CISA recommends routine checks of public address ranges for accessible ports and services, investigating unexpected exposure, and closing or restricting ports without a documented operational need.3 For the Modesto distributor, that means the answer to an unexpected remote-support service is not automatically to shut it off during the morning shipping run. First confirm the owner and dependency; then make an approved change and test the order workflow.
Which attack-surface findings should we address first?
Prioritize findings that combine meaningful business impact with a real path to exposure. Useful questions include: Can someone reach this system from the internet? Does it handle sensitive information or support a critical service? Is the access still needed? Is there evidence the software flaw is being exploited? Can access be reduced while a permanent fix is prepared?
CISA maintains the Known Exploited Vulnerabilities (KEV) catalog and recommends that organizations use it as an input to vulnerability prioritization and prioritize remediation of listed vulnerabilities. In an ASM process, that gives a team a reason to look beyond a scanner’s severity score: an exposed system with a vulnerability listed in KEV deserves prompt attention, while the asset owner and operations lead help select a safe remediation window.
The response does not always have to be a full system replacement. Depending on the system and its role, the practical action may be to remove public access, put the service behind a managed gateway or VPN, require multifactor authentication (MFA), apply a vendor patch, or retire an unsupported asset. CISA’s exposure guidance recommends securing remote access and calls out MFA as a protection to enforce where possible. The choice should match the actual connection and the organization’s ability to support it.
How do we keep ASM from becoming a quarterly spreadsheet exercise?
Treat the inventory as something that changes when the business changes. A new cloud service, a vendor onboarding, a firewall change, a new public-facing application, or the closure of a project can alter the routes into the organization. Build an ASM check into those change processes so that someone confirms the asset’s owner, exposure, and intended lifetime before and after the change.
CISA also advises organizations to look for internet-exposed assets associated with their own IP space and for assets that may be exposed through vendor, contractor, or legacy infrastructure. That is especially useful when the asset list and the outside view do not match: the difference itself becomes a task to investigate, rather than an assumption that either list is complete.
Set a cadence that matches the rate of change and the available staff. A smaller organization might begin with a scheduled review and event-triggered checks after material network or vendor changes; a larger or more dynamic environment may need more frequent discovery. The important measure is whether new or changed exposure is reaching an owner quickly enough to get a decision—not whether a dashboard refreshes every hour.
Keep evidence lightweight but usable: date observed, asset and owner, business purpose, reachability, decision, person responsible, due date, and verification result. That record helps prevent a closed service from quietly returning during a later change, and gives leadership a clear view of what remains exposed and why.
What should a managed partner contribute?
ASM is not a product purchase that transfers accountability. A tool can surface candidate assets and exposures; people still have to decide whether those findings are real, identify the business dependency, coordinate a safe change, and confirm the outcome. Ask who will own those steps, how findings reach a decision-maker, and how your team will know that a remediation worked.
At Datapath, we connect that work to uptime and clear ownership—not a pile of alerts. We can help a business in Modesto build an asset and exposure review, or work alongside an internal team through co-managed IT. For broader security oversight, our managed cybersecurity and vCISO services can help turn findings into a prioritized plan with accountable owners.
For a first conversation, bring one recent change or one connection you are unsure about: a vendor login, an older public-facing service, or a cloud application whose owner is unclear. We can map the path, identify what needs validation, and agree on a safe first action. The goal is not to make every system unreachable; it is to know what is exposed, why it is exposed, who owns the decision, and how the business will keep working after the change.
