External attack surface,
seen the way an attacker sees it.

• Subdomain discovery from Certificate Transparency logs
• Certificates that are expiring or use wildcards
• Hostnames that suggest exposed AI, LLM or MCP endpoints
• Lookalike and typosquat domains that already have certificates issued
• Exposures feed attack-path analysis, so a forgotten host shows up in the paths it opens

External attack surface monitoring is the continuous discovery of the internet-facing assets that belong to you, including the ones nobody remembered: a forgotten staging subdomain, a marketing microsite, an AI demo on a test hostname. You cannot secure, patch or include in an audit scope an asset you do not know exists.

Certificate Transparency makes a good starting point because it is complete for anything served over HTTPS: a public certificate cannot be issued without being logged.

1. Read the public certificate logsThe platform queries Certificate Transparency through crt.sh for every certificate issued to your domain and its subdomains. No API key, agent or DNS access is needed, and nothing is sent to your hosts.
2. Collapse certificates into hostsMany certificates can name the same host. They are merged into one entry per hostname with its most recent expiry date and issuer, so the list reads as an inventory, not a log dump.
3. Flag what an attacker would try firstEach host is tested against simple, explainable rules: is its certificate expired or close to expiry, is it a development, staging or admin host, does its name suggest AI, model or MCP infrastructure, and is a wildcard certificate in use.
4. Look for lookalike domainsThe platform generates likely lookalikes of your domain, such as other top-level domains, character swaps like o to 0, added words with hyphens and dropped letters, and checks which of them already have a certificate issued.
5. Score and route the findingsEach finding gets a severity, a plain explanation and the host it concerns. Open exposures feed attack-path analysis and the network segmentation part of the Zero Trust score, so they show up where they change risk.

A lookalike domain with a certificate already issued is often the first visible step of a phishing campaign against your customers or staff. Seeing it early gives you time to warn users and file a takedown before the emails go out.

Certificate Transparency is reliable for HTTPS assets because a publicly trusted certificate cannot be issued without being written to public, append-only logs. Browsers reject certificates that are missing from them. That makes the logs close to complete for anything you serve over HTTPS, including the hosts nobody remembers launching.

It is also the first place an attacker looks. Searching the logs for a company's domain takes seconds and needs no permission, so a staging host or an old campaign microsite that appears there is effectively public knowledge. Monitoring the same source means you see your surface as it is already seen.

The limit is equally clear. A host with no public certificate, such as an internal service, a plain HTTP site or something reached only by IP address, does not appear in the logs. Those belong in your asset inventory directly; this monitoring does not claim to find them.

Attack surface monitoring mainly evidences asset inventory and vulnerability management. ISO/IEC 27001:2022 Annex A 5.9 asks for an inventory of information and associated assets; a host you did not know about is a gap in it by definition. Annex A 8.8 asks you to identify technical vulnerabilities, and an expired certificate or an exposed admin host is one.

For SOC 2, the 2017 Trust Services Criteria ask you to identify and manage the assets and changes that create risk (CC3.2 and CC7.1). A dated record of discovery, triage and resolution is what makes that demonstrable across an observation period rather than on one day.

Under India's DPDP Act, section 8(5) requires reasonable security safeguards to prevent a personal data breach. A forgotten staging host holding a copy of production data is exactly the kind of gap that clause is about.

Start with anything critical: an exposed MCP endpoint or an expired certificate on a host that still answers. Confirm whether the host is meant to exist, who owns it, and whether it holds real data. A host that should not exist is decommissioned; one that should is put behind authentication or an allow-list and given an owner.

Next, renew certificates inside the 21-day window and move development and admin hosts off the public internet. Then work through lookalike domains: decide which to buy defensively, which to report for takedown, and tell your users and support team which domains are genuinely yours.

Record the decision on each finding. An exposure you investigated and marked accepted or mitigated, with the date recorded, is evidence of a working process. The same exposure left open with no note reads as one nobody looked at.

Check it at least weekly, and after any launch, migration or marketing campaign that creates new hostnames. New certificates appear in the logs within minutes of issue, so a weekly run catches a new host within days rather than at the next annual review.

Lookalike domains move faster around events that attackers can exploit: a product launch, a funding announcement, a data breach in the news. Running a check then is cheap and gives your team time to warn customers before the emails arrive.

• An asset inventory that includes internet-facing hosts, with an owner for each
• Evidence that the inventory is reviewed on a schedule, not assembled for the audit
• How newly discovered hosts are triaged, and the decision recorded for each
• Certificate management: how expiry is monitored and who renews
• How non-production and admin systems are kept off the public internet
• What you do about lookalike domains and how staff and customers are warned

• It does not port-scan, probe or send any traffic to your hosts; discovery is passive
• It does not find hosts that have no public TLS certificate, such as internal or plain HTTP services
• It does not file takedown requests for lookalike domains; that stays with you or your registrar
• It does not test whether a discovered host is vulnerable; use web security testing for that
• It does not decide which hosts are yours; a person confirms ownership and records the decision

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: web security testing and attack paths.