An external incident often exposes an inventory problem before it exposes a novel technical problem. A certificate is issued for a hostname nobody recognises, a forgotten campaign site starts redirecting customers, or a vendor-managed login page survives long after the contract that created it. The security team can see the asset from the internet, but the internal register has no owner, purpose, or retirement date for it. Attack surface management exists to close that gap before an exposed service becomes the most expensive way to discover who was supposed to manage it.
A useful ASM inventory records more than a hostname. It separates assets the organisation controls from vendor dependencies, abandoned infrastructure, unrelated certificate-log entries, and candidates that still need investigation. Each accepted asset needs enough context to answer ordinary response questions: what service is exposed, which business process depends on it, who can change its DNS or hosting, and what would happen if it disappeared. Repeating discovery against that reviewed baseline then shows drift instead of producing another undifferentiated export.
DomScan can supply several pieces of that external evidence. Subdomain Discovery uses Certificate Transparency logs and can verify current DNS resolution. Hosting Detection identifies likely hosting, CDN, WAF, DNS, and mail providers. DNS History is a beta log of values observed during successful DomScan DNS lookups, not an internet-wide passive DNS archive. These results help an analyst investigate an asset, but they do not prove that the organisation owns it or that a detected provider relationship is authorised. Ownership still has to be confirmed against contracts, cloud accounts, repositories, and internal service records.
Quick path: Start with Subdomain Discovery to collect certificate-log candidates, verify resolution where useful, then use Hosting Detection to identify the infrastructure behind the hosts you decide to investigate.
Why attack surface management matters in practice
A domain is often the durable handle for infrastructure that changes underneath it. Teams can move an application between cloud accounts, replace a CDN, or hand a marketing site to an agency while the same hostname remains trusted by users and connected systems. That stability is useful, but it lets weak ownership survive several technical migrations. An attacker does not need the flagship domain if an old subdomain still has a dangling provider mapping, an exposed administration panel, or credentials nobody rotates because the service is absent from the official inventory.
External signals need cautious interpretation. A Certificate Transparency entry proves that a certificate was logged for a name, not that the hostname is live, reachable, or controlled by the expected team. A nameserver change can indicate a planned migration, registrar compromise, or simple cleanup. A provider fingerprint may describe a shared edge service rather than the origin. Analysts should combine these observations with DNS resolution, HTTP behaviour, internal ownership records, and change tickets before assigning severity. The uncertainty belongs in the finding instead of being hidden behind a confident asset count.
- Public exposure includes third-party branded SaaS and not just servers you knowingly run.
- Domains are durable discovery anchors even when infrastructure underneath them changes.
- Asset count is a weak metric if the team cannot prioritise or close what it finds.
- ASM gets stronger when security, platform, and brand teams share domain evidence.
How attack surface management works
Start with roots the organisation can defend as its own: registered domains, allocated IP ranges, cloud tenants, certificate accounts, and public applications. Expand from those seeds through DNS, certificate logs, redirects, shared infrastructure, and documented vendor relationships. Every newly discovered candidate then needs a disposition. Approve it as controlled, classify it as a dependency, keep it under investigation, or reject it with a reason. This prevents weak associations from quietly becoming accepted inventory and keeps the team focused on assets it can actually remediate.
Once the first baseline is reviewed, change becomes more informative than total size. A new hostname on an approved domain deserves a quick ownership check. A host that stops resolving may be safely retired, or it may leave a dangling record that needs cleanup. A certificate renewal is routine until it appears under an unfamiliar issuer or covers an unexpected name. Historical observations help frame those questions, but the collection method matters. DomScan DNS History only contains successful lookups made through DomScan, so an empty history means no recorded observation, not proof that a record never existed.
Where teams usually get it wrong
The most common failure is treating discovery volume as progress. Thousands of certificate names look impressive in a dashboard, but wildcard certificates, stale entries, shared services, and duplicate naming patterns can inflate the list without revealing a single remediable exposure. Another failure is automatic ownership attribution based on a loose infrastructure link. That can pull customer systems or unrelated shared-hosting tenants into scope. A smaller reviewed inventory with named owners and documented dependencies is more useful than a large list nobody trusts.
Exceptions need an expiry date of their own. If a vendor cannot meet the usual patching or authentication standard, record the affected hostname, the compensating control, the person accepting the risk, and the date for another decision. Otherwise temporary exposure becomes permanent through staff turnover. The same record should say how to shut the service down, because knowing that an asset is risky does little good when nobody knows which account or contract controls it.
A more reliable operating model
Give each asset two owners when the organisation is large enough to need the distinction. The business owner decides whether the service is still required; the technical owner controls DNS, hosting, certificates, and remediation. Classify the asset by function and exposure, then attach the controls that should be true for that class. A customer login should have a stricter certificate, authentication, logging, and response standard than a temporary public brochure. Retirement should be a tracked action that removes DNS, provider resources, certificates, secrets, and monitoring, not a label applied to an unresolved hostname.
A practical workflow
Build the first review around a handful of fields the team will maintain: root domain, hostname, observed service, business function, technical owner, provider account, exposure class, and disposition. Seed discovery from confirmed domains, examine certificate-log names, resolve the candidates, and inspect reachable services. Compare likely providers with procurement and cloud-account records. Open remediation work for assets that are exposed but unmanaged, and remove candidates that cannot be tied to the organisation. Record why each decision was made so the next scan can be compared with a defensible baseline.
After the baseline, schedule checks around changes that alter exposure: a new resolving hostname, certificate issuance for an unexpected name, nameserver or provider movement, a previously closed port becoming reachable, or a retired service returning. Route the alert to the owner recorded on the asset. If the change is planned, link the change record and update the baseline. If it is unexplained, preserve the first observations before modifying DNS or taking the host offline. Those early details are often the only clean view of what appeared.
Response tiers should reflect both exposure and consequence. An unknown login host or externally reachable administration surface warrants immediate triage. A new static campaign host may wait for the marketing owner to confirm it during business hours. A parked defensive domain usually needs renewal and nameserver oversight rather than application scanning. Tiering by asset function keeps routine certificate and campaign activity from drowning out changes on authentication, payment, support, and production API names.
What good monitoring looks like
A useful ASM alert is an evidence packet, not a sentence saying that something changed. It identifies the hostname, the previous and current observation, when each was collected, the discovery source, the recorded owner, and the service class. It also states what the collection cannot establish. For example, a certificate-log alert should not claim that a website is active until a separate check confirms it. With that context, the responder can approve a planned launch, assign an ownership check, preserve evidence, or escalate a real exposure without rebuilding the discovery trail.
Keep enough history to distinguish a launch from recurring drift. Repeated short-lived preview hosts may point to a deployment process that never removes DNS. Regular certificates for decommissioned names may reveal an automation account that still controls them. Frequent provider changes on a stable customer hostname deserve different scrutiny from a one-time migration with a change ticket. Observation history has blind spots, so record cadence and source beside the data. A change between two scans can be detected; several changes that happened between them may remain invisible.
Where DomScan helps
DomScan is useful for the domain-led portion of an ASM investigation. Use Subdomain Discovery for Certificate Transparency candidates, Hosting Detection for likely infrastructure providers, certificate checks for issuer and name coverage, and the DNS tools for current records. DNS History can show day-level values previously observed by DomScan, within its lookup-driven coverage. These views do not replace authenticated cloud inventory, vulnerability scanning, or ownership records. They give the team an outside-in starting point and a consistent set of public observations to reconcile with those internal systems.
Independent references: Review Microsoft Defender EASM and RFC 6962 for baseline details and neutral operational guidance.
The next unexpected hostname should not trigger a search through old chat threads. It should land against an inventory that says whether the name is known, who can confirm it, and which checks its service class requires. If the hostname is new, the team should be able to preserve the observation, decide whether the relationship is real, and either accept or remove it. That repeatable decision process is the practical measure of an ASM programme. The raw number of discovered names is only an input.