
A mid-market group, two acquisitions in, buys attack surface monitoring software and seeds it with the three domains everyone in the room agrees they own. Within a week the platform has surfaced a legacy marketing subdomain pointing at an expired staging server, and a forgotten test environment still serving an admin login page to the open internet. Neither appears in the CMDB. Nobody in IT recognises the hostname. That is the moment the purchase justifies itself, and also the moment the real work starts, because someone now has to decide whether those assets are genuinely yours and who is going to take them down.
Most articles on this topic are vendor listicles or definitions. This one is the buyer's side of the table: nine questions that separate continuous external attack surface management from a one-off scan with a subscription attached, and the failure each question is designed to expose.
Strip away the category language and there are four jobs. Discover the internet-facing assets associated with your organisation. Track how that footprint changes. Judge which exposures matter. Get them fixed by a named person. Tools tend to be strong at the first two, competent at the third, and quietly silent on the fourth.
A point-in-time scan tells you what was exposed on a Tuesday. A scheduled scan tells you what was exposed on a series of Tuesdays. Continuous monitoring of your internet-facing asset inventory means the platform is watching DNS records, certificate transparency logs, IP allocations and web-facing services as they change, and telling you when something new appears rather than when the next run is due. Ask for the actual discovery cadence per data source. Some vendors describe weekly full sweeps as continuous, which is defensible for infrastructure enumeration and much less defensible for domain registrations.
Three shapes exist. Infrastructure-only ASM maps hosts, ports, services and certificates. Ratings-style platforms score you and your suppliers from the outside, which is useful for procurement and rarely actionable for an engineer. External attack surface management in the fuller sense adds credential exposure, brand and domain abuse, supplier intelligence and people exposure, because attackers do not restrict themselves to your netblocks. Decide which shape you are buying before you compare price.
You have acquired a business and inherited infrastructure nobody has audited. Marketing spins up campaign domains without telling security. Your annual penetration test scopes the assets you told the tester about, which is a scope defined by your blind spots. Someone maintains a list of Shodan queries and runs them when they remember. Those are the conditions that make continuous, real-time monitoring worth paying for, and they are precisely the conditions in which shadow IT accumulates.
A good vendor will name the seeds: root domains, known IP ranges and ASNs, company names and registrant details, cloud tenant identifiers, SSL certificate organisation fields. Then they will explain expansion: certificate transparency, passive DNS, reverse WHOIS, cloud provider ranges. The question behind the question is change. When you buy a company or launch a brand, can you add a seed and have the footprint expand within days, without a professional services engagement? Ask what the onboarding looks like for a new subsidiary six months after go-live.
Attribution is the hardest part of discovery, not enumeration. Anyone can pull subdomains with a wordlist. The value sits in correctly deciding that a shared-hosting IP carrying forty other tenants is not your asset, that a CDN edge range is not your infrastructure to patch, and that a supplier's marketing platform hosting your branded landing page belongs to a supplier conversation rather than a patching ticket.
Ask two things. How is ownership confirmed, and how do you dispute an asset? A dispute workflow that removes an asset from your inventory permanently, with an audit trail, is the mark of a platform built for people who have to act on the output. An inventory with obvious errors gets ignored by engineers, and once ignored it does not recover.
Known assets are hygiene. Unknown internet facing assets are the reason you are buying. The platform should present newly discovered, previously unmanaged assets as a distinct view, not blended into a list of two thousand hostnames. Geographic mapping matters too: infrastructure appearing in a region where you have no operations is usually a reseller, a stale DNS record or something you genuinely need to know about. DarkInvader's asset discovery capability maps the external footprint from an attacker's perspective, which is the only view that matches how you are actually being enumerated.
The classic failure here is an inventory nobody trusts because a third of it belongs to someone else. Once the network team has disproved five assets in a row, the sixth genuine finding gets dismissed with them.
Duplicate findings, not missed findings, are what kill adoption. Run infrastructure scanning and web application scanning across the same estate and you will generate overlapping results by design: the same TLS configuration reported per host, per virtual host and per URL path. Deduplication and auto-resolution on rescan are functional requirements, not marketing lines.
Ask what the weekly net-new finding count looks like for an estate of comparable size, and ask whether a fixed issue closes automatically on the next pass or waits for someone to tick a box. A platform that raises hundreds of findings a week gets muted inside a month, and muting is permanent in practice.
Automated feeds miss context that only human research recovers. Hacker chatter naming your brand, ransomware group activity, a Telegram channel trading access to a sector you operate in, employee intelligence that connects an exposed asset to active interest in your organisation. A platform with a research team behind it produces fewer and better findings than a pure crawler.
So ask who the researchers are, what proportion of findings they touch, and what the turnaround is between automated detection and human validation. Then ask what a validated finding contains: what it is, how it was discovered on your asset, and whether it actually exposes you. Those are the three questions your engineers will ask, and if the report does not answer them the ticket bounces back.
Credential exposure is an attack surface problem now, not a separate product. Infostealer malware harvests browser-stored passwords, cookies and session tokens from personal devices, and a compromised home laptop can expose a live session for a corporate remote access portal. That matters far more than a ten-year-old password from a breached hobby forum, yet plenty of platforms present both with equal weight.
Useful OSINT and dark web monitoring classifies credential findings by whether the identity is internal or external, maps them against your actual login portals, and tells you whether the credential is plaintext, hashed or accompanied by a session cookie. Ask how dark web and Telegram sourced intelligence is filtered for relevance to your domains, because unfiltered combolists are noise wearing a threat intelligence badge.
Attackers research people before they touch infrastructure. Ask whether the platform monitors named individuals, applies per-person risk scoring, and distinguishes internal identities from external ones. A finance director with a exposed personal email address reused across breached services is a different problem from a marketing contractor listed on a supplier's site, and the response differs accordingly.
Domain monitoring without takedown capability creates work rather than removing risk. The scenario is familiar: a finance team receives an invoice from a domain one character different from your own, and DNS surveillance had already flagged the registration weeks earlier. Detection was step one. Evidence collection, registrar and hosting provider contact, and the follow-up until the domain is suspended is the part that actually removes it.
Most buyers only discover the difference during their first spoofing incident. Ask whether takedowns are included, capped by volume, or billed separately, and ask who writes the abuse report. Ask about newly available domains too, the permutations of your brand that are unregistered and cheap for an attacker to acquire.
Ask for the integration list, then ask a harder question: does a Jira ticket update when the finding is resolved in the platform, or does it become an orphan? Check whether Slack and Microsoft Teams notifications can be filtered by severity so a channel does not become unreadable. Confirm there is a documented API with self-service key management, because your reporting requirements will not match anyone's default dashboard forever. Continuous asset monitoring only changes outcomes when its output lands in the queue people already work from.
A completed questionnaire describes a supplier on the day they filled it in. Continuous supplier threat intelligence tracks their external posture, breach exposure and accreditation status over time, including whether an ISO 27001 certificate is current or lapsed. That language matters to procurement, and it maps to your obligations: UK GDPR requires due diligence on processors, and the NCSC's Cyber Essentials control themes give you a shared vocabulary for what "adequate"looks like across a supply chain.
A management report that lists 1,400 open findings tells a board nothing. A useful one answers four things: what changed this week, what was closed, what remains exposed, and why that matters commercially. VIP and executive exposure reports belong in the same pack. Check whether reports can be viewed on screen, exported as PDF and scheduled by email, because the person who needs them monthly will not log in.
A realistic onboarding sequence runs roughly like this: seed your known domains, review the discovered footprint with the network and cloud owners, agree and dispute ownership asset by asset, set severity thresholds so only what matters escalates, then wire up integrations. Skipping straight to integrations means piping an untrusted inventory into Jira, which is how a platform earns a reputation it never recovers from.
Decide who fixes findings before you sign. That is the commonest wasted spend in this category. Not the wrong tool, but the right tool with no named owner, producing a monthly report nobody reads.
Pricing in this market usually keys off the number of root domains and discovered assets, how many named people you monitor, the supplier count, the depth of human research included, and takedown volume. Ask which of those meter and which are flat, and confirm current pricing directly with the vendor, since published tiers change.
Use the stages in order. Start with a free scan or trial to see whether the discovery engine finds anything your CMDB missed, since that single test answers more than an hour of demo. Move to a self-serve tier to test noise levels over a few weeks. Only then consider a managed arrangement where researchers triage on your behalf. You can sign up for a free DarkInvader account to see the footprint before any commitment, and review the available plans when you know what scope you actually need.
A short evaluation scorecard, mapping the nine questions to evidence rather than assurances:
Two more questions worth asking any UK buyer's shortlist. Where is finding data stored and processed, and under what retention period? And how does the vendor handle intelligence concerning your staff, particularly credential exposure tied to personal accounts, which touches employment and data protection sensitivities that a purely technical demo will skip. If you want to talk through scope for your own estate, get in touch with the team.
At minimum, domains, subdomains, IP addresses, open ports and services, certificates, cloud services and public-facing web applications. Fuller external attack surface management platforms add leaked credentials and stealer log data, lookalike and newly registered domains, exposed documents and metadata, executive and employee exposure, and supplier posture. The scope varies enormously between vendors, so confirm it line by line rather than assuming.
A vulnerability scanner tests assets you already know about and have given it. Attack surface monitoring starts by finding the assets, including the ones missing from your CMDB, then assesses them from the outside as an attacker would. The two overlap on assessment and diverge completely on discovery, which is why organisations with mature scanning programmes still uncover unmanaged infrastructure on day one.
Pricing is usually annual and scales with the number of domains and discovered assets, monitored individuals, suppliers tracked, and whether human triage and takedowns are included. Self-serve tiers sit well below managed services with researcher involvement. Published prices change, so treat any figure you find in a comparison article as indicative and request a current quote scoped to your estate.
Yes. Monitoring gives you breadth and continuity: what exists, what changed, what is exposed. Penetration testing gives you depth against a defined scope, including business logic flaws, chained exploits and authenticated testing that external monitoring cannot reach. In practice, monitoring improves the test by ensuring the scope includes assets you would otherwise have forgotten to mention.
Initial discovery typically produces results within days of seeding. Trust takes longer, because it depends on working through attribution with the people who own the infrastructure and disputing what is not yours. Allow a few weeks of review before treating the inventory as authoritative, and expect ongoing adjustment as acquisitions, cloud deployments and marketing projects change the footprint.
Unlock full visibility of your external attack surface with DarkInvader’s continuous, real-time monitoring. Create your free account to discover unknown assets, detect emerging risks and stay ahead of potential threats before attackers can exploit them.
Create My Free Account