The common year one mistakes in external attack surface management are starting without owners, accepting a noisy scope, measuring asset counts, scanning without a fix path, and treating the first report as done. Each is avoidable with a few decisions made before the tool is switched on.
External attack surface management, or EASM, means finding and reviewing your internet-facing assets from the outside. The programs that stall tend to stall for organizational reasons, not technical ones.
Mistake 1: No owner mapping
The first scan returns hundreds of assets, and nobody knows whose they are. Findings sit in a queue. The fix is to decide, before launch, how ownership is determined: cloud tags, DNS zones, repository names, a registry maintained by team leads. Unowned assets get a default owner, usually the platform or IT lead, who must either claim or retire them.
Mistake 2: Accepting a noisy scope
Discovery tools attribute assets by inference. Some will be a vendor's, some a former employee's side project, some unrelated. If analysts spend week two chasing assets that were never yours, trust in the tool drops. Sample the first results, record the false attribution you see, and tune scope with explicit includes and excludes. Keep a list of confirmed non-assets so they do not return.
Mistake 3: Measuring asset count
A growing count can mean discovery improved or sprawl worsened. Report what you fixed and how fast, instead. Useful measures are assets with owners as a share of assets found, exposed services removed, and time from finding to fix by team.
Mistake 4: Scanning without permission or care
Active testing of systems you do not own, or that belong to a third party hosting provider, can break terms or laws. Settle the rules: test only assets you own or have written permission for, and check your hosting providers' testing policies. This is a legal and ethical line, not a detail.
Mistake 5: Ignoring context when ranking
An exposed login page on a test site with dummy data is different from one in front of customer records. NIST SP 800-53 control RA-3 asks for risk assessment, which includes the impact side. Rank with data sensitivity, login strength and exploitation evidence, and use public inputs like CISA's Known Exploited Vulnerabilities Catalog and FIRST's EPSS scores where relevant.
Mistake 6: No process for acquisitions and new projects
Assets appear when a team launches a campaign site or when the company acquires another. The year one program often catches the old estate and misses the new. Add two checkpoints: a registration step before any new public domain or cloud account goes live, and an attack surface review in acquisition due diligence.
Mistake 7: Forgetting dependencies behind the public page
EASM shows the web application is reachable. It does not show which libraries it ships. A public app with a vulnerable dependency that its code never calls is a different problem from one where the call is live. Connect EASM findings to your application inventory and reachability data so teams fix the right things first.
Mistake 8: Treating the first report as the finish
Attack surfaces change daily. A first report gives a baseline, and then comes the ongoing work: reviewing new assets, retiring old ones, closing exceptions. NIST SP 800-137 describes continuous monitoring as an ongoing program with a strategy and assessment, and EASM belongs in that frame. Put a review on the calendar and name who runs it.
A constructed illustration
A company runs its first scan and finds 340 assets. Sixty belong to a marketing agency's old campaigns, thirty are test sites, ten are real production systems nobody had on the list. The team that treated all 340 equally burned a month. The team that sorted by owner and data, fixed the ten, retired the thirty and wrote to the agency about the sixty, had a safer estate in two weeks. These numbers are made up for the example.
What to do
- Define ownership rules and a default owner before launch.
- Sample first results and tune scope with includes and excludes.
- Report owned share, removals and time to fix, not raw counts.
- Write down testing rules and respect hosting provider policies.
- Rank by data, login strength and exploitation evidence.
- Add registration checkpoints for new domains and acquisitions.
- Link exposed apps to dependency and reachability data.
- Schedule recurring reviews with a named owner.
Where Safeguard fits
Safeguard does not offer EASM and does not replace it. It works on the application side, with dependency inventory and reachability analysis that help decide which vulnerable libraries in an exposed application deserve attention first.
Quick check
What is the first thing to fix in year one?
Ownership. Without an owner for each public asset, findings do not turn into fixes.
How often should the attack surface be reviewed?
At least monthly for a small company, with checks triggered by new domains, launches and acquisitions.
Sources
- NIST SP 800-53 Rev. 5, control RA-3 (OSCAL catalog)
- NIST SP 800-137, Information Security Continuous Monitoring
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System
Last reviewed: 18 October 2026.
