Build external attack surface monitoring in house when your estate is small, stable and well documented. Buy when it changes weekly, spans many cloud accounts or companies, or when attribution is the hard part. Most teams end up with a hybrid: scripts for the known, a service for the unknown.
What would you be building?
An in house EASM is a loop. Gather seeds (domains, IP ranges, cloud accounts). Enumerate what hangs off them (subdomains, certificates, open ports, web fingerprints). Attribute each result to an owner. Compare with the last run. Alert on change. Each step is simple alone. The cost is in running the loop forever.
What can you build cheaply?
Certificate transparency monitoring, a scheduled DNS enumeration, a port scan of ranges you own, and a check of cloud provider inventories through their own APIs are all scriptable by one engineer in days. Run them from a scheduler, diff the results, and post changes to a chat channel. For a company with one domain and one cloud account this is real coverage.
Add vulnerability context cheaply too. CISA's Known Exploited Vulnerabilities catalog is public, and FIRST publishes EPSS scores daily with open access. Matching what you found against those lists is a day of work.
Where does building get expensive?
Attribution. Deciding that a host on a shared platform is yours takes evidence: certificates, tracking identifiers, registration records, hosting patterns. Wrong guesses either miss your assets or fill the queue with someone else's. Services that do this at scale have data you cannot easily reproduce, such as years of historical records.
Coverage drift. Scripts break when a provider changes an API, and nobody notices because silence looks like safety. A monitoring tool needs monitoring.
Scale and acquisitions. Each acquired company brings new registrars, clouds and naming habits. A script written for one DNS provider does not cover five.
Scanning ethics and limits. Active scanning must stay within what you own or are authorized to test, and cloud providers have rules about it. Read them.
People. The code is an afternoon. The weekly triage, the owner chasing and the maintenance are the bill. Count them honestly.
Where does buying disappoint?
Noise and misattribution if you skip the trial. Lock in if you cannot export. Duplicated cost if you already have cloud native inventory tools that cover half the need. And dependence: a vendor cannot know your internal naming, so you still maintain seeds and ownership data.
A decision test
Answer five questions.
How often does your external footprint change? Monthly or slower favors build. Weekly or faster favors buy.
How many domains, cloud accounts and business units? Under about a handful favors build. Dozens favors buy. The threshold is yours to set by testing, not a universal figure.
Do you have a person who will own it for years? If not, build is a trap.
How hard is attribution for you? Own cloud accounts and one registrar is easy. Brand names shared with partners is hard.
What does an audit or customer ask for? Dated, repeatable evidence of external monitoring is easier to produce from a managed service, though a well kept script with a log can serve.
A hybrid that works
Run scripts for known seeds and cloud inventories, which you control and which cost little. Buy a service for open ended discovery of assets you do not know about, and feed your sheet to it as ground truth. Hold the service to a trial like the one described in our two week plan. Review the split yearly.
What NIST adds
NIST SP 800-137 describes continuous monitoring as visibility into organizational assets, awareness of threats and vulnerabilities, and visibility into the effectiveness of controls. It does not say whether to build or buy, only that the capability must exist and be maintained. Judge either path against that.
Where Safeguard fits
External attack surface tooling is not a Safeguard product and we do not replace it. We focus on the application and software supply chain side. Whichever route you pick, dependency and reachability analysis tells you whether an exposed service's libraries are actually exploitable in your code.
What to do
- Write down your seeds, owners and how often the estate changes.
- Build the cheap loop first: certificates, DNS, owned port ranges, cloud inventories.
- Add known exploitation data from public sources.
- Trial a service on your seeds and compare findings.
- Keep what the scripts do well, buy the open ended discovery.
- Review the split each year.
Quick check
What is the hardest part of building EASM yourself?
Attribution and long term upkeep. Collecting data is easy, deciding which findings are yours and keeping the loop running is not.
Can a hybrid be a sound choice?
Yes. Scripts cover known assets cheaply and a service covers discovery of the unknown.
Sources
Last reviewed: 18 October 2026.
