Certificate Transparency Monitoring: How to Monitor CT Logs for New Domains and Subdomains

By ScruteXPublished 27-08-2026Updated 03-09-2026

What if your security team could discover new internet-facing assets as soon as their TLS certificates were issued?

A new certificate can reveal more than just a website. It can expose previously unknown subdomains, staging environments, APIs, portals, VPN endpoints, or other internet-facing infrastructure that may not yet be present in your organisation’s asset inventory.

This is where Certificate Transparency (CT) monitoring becomes valuable for security teams. By continuously monitoring public CT logs, organisations can identify newly issued certificates associated with their domains and investigate potential changes to their external attack surface.

For security and IT teams, this provides an additional early-warning signal for subdomain discovery, shadow IT detection, attack surface monitoring, and external asset discovery.

But CT logs alone do not tell you whether an asset is legitimate, forgotten, misconfigured, or potentially suspicious. The real value comes from correlating certificate data with DNS, IP addresses, service information, asset inventories, and other threat intelligence sources.

In this article, we’ll look at how Certificate Transparency works, how security teams can monitor CT logs for new domains and subdomains, and how CT data can support continuous external attack surface discovery.

What Is Certificate Transparency?

Certificate Transparency is an open framework, defined in RFC 6962 and its successor RFC 9162, that records the issuance of TLS certificates in public, append-only, cryptographically verifiable logs. Its original purpose was to detect misissued certificates: if every certificate is publicly logged, a certificate authority cannot quietly issue one for a domain it should not.

The chain works like this. A CA prepares a certificate and submits it to one or more CT logs. Each log returns a Signed Certificate Timestamp (SCT), a receipt proving the certificate was accepted. The certificate, usually with SCTs embedded, is then served to browsers, and anyone can read the log entry. Chrome has enforced CT for publicly trusted certificates since 2018, and Firefox began enforcing it from version 135. Chrome's current policy requires SCTs from two distinct logs for certificates valid 180 days or less, and three for longer-lived certificates. A June 2026 update to the Chrome Root Program Policy went further: CAs must log every TLS precertificate to a recognised log before issuance. In practice, a certificate that browsers will trust is a certificate you can observe.

What Are Certificate Transparency Logs?

Certificate transparency logs are the public ledgers behind the framework. Each entry contains the full certificate or precertificate, which means every DNS name the certificate covers is readable: the Common Name, every Subject Alternative Name (SAN), and any wildcard entries. Entries also expose the issuing CA, validity dates and the certificate's cryptographic details.

Under the hood, each log is a Merkle tree: entries are hashed into a structure that lets anyone verify a certificate is included and that no past entry has been altered or removed. When a CA submits a certificate, the log promises inclusion and returns the SCT immediately, so observation lags issuance by minutes to hours, not days. One boundary matters for scoping expectations: CT covers publicly trusted certificates. Anything issued by a private or internal CA never touches the logs, so internal PKI stays invisible to this technique by design.

For a security team, three properties make certificate transparency logs useful. They are public, so no privileged access is needed. They are append-only, so history persists: a certificate issued for a long-decommissioned subdomain is still on record, which is valuable for reconstructing what an organisation once exposed. And they are near-real-time, because logging happens at issuance. With public certificate lifetimes now capped at 200 days, renewals are more frequent and the log stream moves faster than it did even two years ago.

How Certificate Transparency Monitoring Works

Monitoring converts the log stream into findings. The workflow:

A certificate is issued for a domain matching your watch criteria.
The certificate appears in one or more CT logs.
A monitoring system observing those logs picks up the entry.
Domains and subdomains are extracted from the CN and SAN fields.
The finding is enriched with DNS, IP and service context.
The organisation checks the hostname against its asset inventory.
Anything unexpected goes to an analyst for investigation.

The key distinction is continuity. A one-time certificate transparency search answers "what exists in the record today". Monitoring answers "what changed since yesterday", which is the question detection actually depends on.

How to Search Certificate Transparency Logs

A certificate transparency log search is where most analysts start. Public search services index the logs and let you query by root domain, subdomain, wildcard pattern and, in some services, organisation name. Useful searches include:

All certificates covering your root domains, to baseline what exists
Wildcard certificates, which often indicate shared or platform infrastructure
Certificates naming brand terms or product names, to spot lookalike registrations
Recently logged certificates for your domains, sorted by first-seen date

A workable first session looks like this. Query each root domain and export every certificate ever logged, including expired ones, because expired records still reveal hostnames that once existed. Sort by first-seen date and read the newest fifty entries: that alone often surfaces infrastructure the inventory missed. Then run the same queries for brand and product terms across TLDs you do not own, which is where impersonation domains tend to appear. Note what each query returned and when you ran it, because the delta on the next run is the real signal.

Search is an investigation tool: excellent for incident response and building an initial inventory, poor for detection, because it depends on someone remembering to run the query. To monitor certificate transparency logs rather than sample them, the search has to become automated, continuous collection with alerting.

Using Certificate Transparency for Subdomain Discovery

CT data is one of the most productive passive sources for subdomain discovery, because SAN fields enumerate hostnames the certificate owner needed to cover. An organisation that officially tracks example.com may find certificate records naming:

api.example.com
staging.example.com
dev.example.com
portal.example.com
vpn.example.com

Each of these certificate transparency subdomains is a lead, not a confirmed asset. A hostname in CT data does not prove the host is currently online, that the organisation still controls it, that the service is publicly reachable, or that anything about it is vulnerable. Certificates outlive infrastructure, and third parties legitimately obtain certificates covering customer subdomains. The correct read is: this name existed in someone's deployment plan at issuance time, so verify what it points to now. That verification step is what separates useful discovery from noisy speculation.

Wildcard certificates cut both ways here. A record for *.example.com confirms the domain uses TLS at scale but hides the individual hostnames behind the wildcard, so wildcard-heavy organisations leak fewer names through CT. Some teams deliberately choose wildcards for exactly that reason, accepting a broader key compromise blast radius in exchange for less public disclosure. Either way, treat a wildcard entry as a prompt to apply other discovery methods, such as DNS analysis and internet-wide scan data, to fill the gap CT cannot see.

Why Security Teams Monitor Certificate Transparency

Attack surface discovery

New certificates can reveal newly deployed infrastructure within hours of issuance, often before scanners or inventory tools observe it.

Shadow IT detection

A certificate requested by a business unit outside the standard process may be the first evidence that unsanctioned infrastructure exists.

Subdomain discovery

CT records can surface hostnames that never appeared in DNS brute-forcing wordlists or existing inventories.

Threat intelligence

Certificates naming your brand on domains you do not own can become indicators during phishing and impersonation investigations. Phishing infrastructure needs TLS to look legitimate, and obtaining a free certificate takes minutes, so a certificate for a lookalike domain frequently appears before the phishing page goes live. Catching it at issuance gives the defender a window to verify the site and start a takedown before customers ever see the lure. The people protected by that window are not the security team: they are the customers who would otherwise have typed credentials into a convincing clone.

Early warning

Because logging happens at issuance, a certificate can act as an early signal of infrastructure that other methods will only find once it serves traffic. CT monitoring does not guarantee advance warning or detect attacks by itself; it supplies a signal that arrives early and costs little to collect.

How to Monitor Certificate Transparency Logs

A practical implementation workflow:

Step 1: Define monitored domains. Start with primary domains, key subdomains, product domains and brand-related terms.

Step 2: Collect CT events. Watch relevant log sources continuously for new certificates matching your criteria.

Step 3: Extract DNS names. Pull the CN, all SAN entries, wildcards and any hostname not previously observed.

Step 4: Deduplicate. One certificate can carry dozens of names, and one name recurs across renewals. Without deduplication, a 90-day renewal cycle turns the same asset into a fresh alert every quarter, and analysts stop reading the alerts.

Step 5: Compare against known assets. The single most important test: is this hostname already in the inventory?

Step 6: Enrich the finding. CT gives you a name and certificate metadata, nothing more. Resolve DNS, capture the IP, probe HTTP status, fingerprint technologies and record first-seen and last-seen dates as separate investigation steps.

Step 7: Prioritise. Push previously unknown subdomains, sensitive environment names, unexpected third-party infrastructure and certificates that match no known asset to the front of the queue.

Step 8: Investigate. Establish ownership and classify the asset: legitimate, newly deployed, forgotten, third-party managed, misconfigured, or suspicious enough to escalate.

One operational warning: untuned CT monitoring generates volume fast. Scheduled renewals, managed hosting providers and CDN-issued certificates account for most events, and none of them deserves an analyst's attention. Build suppression rules for expected issuers and known third-party patterns early, and measure the pipeline on one number: how long a genuinely new hostname takes to reach a human decision. If routine renewals are drowning that signal, the tuning, not the source, is the problem.

What Should You Do When a New Certificate Appears?

Run each interesting finding through a consistent set of questions. Is the domain ours? Was the certificate expected, for example a scheduled renewal? Is the hostname in inventory? Does DNS resolve, and to what? Is the host reachable, and what service answers? Who owns it internally? When was it first observed? Does the name include a sensitive marker such as dev, test, staging, admin or vpn? Does anything about the issuer, SAN list or hosting warrant deeper investigation? Answering these takes minutes once enrichment is automated, and the output is a decision: absorb the asset into inventory, assign remediation, request a takedown, or close as expected.

Could Your Organisation Be Missing Assets Revealed by CT Logs?

Ask your team:

Do we continuously monitor certificates issued for our domains, or do we search occasionally?
Do we know every hostname that appears in certificates naming our organisation?
Can we tell a known asset from a newly observed one automatically?
Do we track first-seen and last-seen dates for discovered hostnames?
Are discovered names enriched with DNS, IP and service context without manual effort?
Do CT findings correlate with our attack surface inventory?
Does an analyst actually investigate unexpected certificates?

Two or more "no" answers indicate a visibility gap that CT data can close cheaply.

Limitations of Certificate Transparency Monitoring

CT monitoring is valuable and incomplete. Not every certificate-related risk surfaces as a useful detection signal, and a log entry proves issuance, nothing else. It does not prove a hostname is live, that the asset is malicious, or that your organisation ever controlled it. Multi-SAN certificates demand careful deduplication, and vendors, CDNs and SaaS providers legitimately hold certificates covering customer domains, so third-party findings are common and usually benign. Every finding still needs DNS, HTTP, ownership and infrastructure validation, and the quality of the practice rests on how well findings correlate with what you already know. Two structural limits deserve their own mention. First, CT only records publicly trusted certificates, so anything on internal PKI, and any attacker infrastructure using self-signed or private certificates, never appears. Second, the logs are symmetric: attackers read them too, and CT is a standard reconnaissance source for enumerating a target's subdomains. Assume every hostname in a certificate is public knowledge the moment the certificate is issued, and never rely on an obscure subdomain name as a security control. Treat CT as one high-value input to external discovery, alongside DNS analysis, internet-wide scanning and passive data sources.

What a Good CT Monitoring System Should Provide

Whether built or bought, a workable system needs continuous collection rather than scheduled searches, new-certificate alerting for a defined domain scope, historical first-seen and last-seen visibility, deduplication across renewals and multi-SAN certificates, correlation against the asset inventory, automated enrichment, risk-based prioritisation, and enough context for an analyst to decide in one screen. Collection is the most straightforward part of this pipeline. Most of the operational effort goes into interpreting each finding in the context of the organisation's assets and ownership.

How ScruteX Approaches Certificate Transparency

Certificate Transparency was designed as an accountability mechanism for certificate issuance, but the same public records can support security detection: because CT-enforcing browsers require nearly all public certificates to be logged, issuance itself becomes observable, giving security teams an early and comparatively low-cost view of new domains, unknown subdomains and infrastructure associated with their name. Realising that value depends on running the full workflow described above: collection, deduplication, correlation, enrichment, prioritisation and investigation.

ScruteX supports this workflow as part of its external discovery. The platform's scan engine collects from certificate transparency logs alongside passive DNS, breach databases, domain registrations and app stores, using read-only techniques that generate no traffic against the monitored infrastructure. Setup is agentless and starts from a domain and keywords; ScruteX states that first findings from its free scan typically appear within about ten minutes.

To review the certificate records and external exposure currently associated with your domains, you can request a demo:

https://scrutex.ai/request-demo

FAQ

What is Certificate Transparency? Certificate Transparency is an open framework (RFC 6962, succeeded by RFC 9162) that requires publicly trusted TLS certificates to be recorded in public, append-only logs, so certificate issuance can be observed and audited by anyone.

What are Certificate Transparency logs? CT logs are public, cryptographically verifiable ledgers of issued certificates. Each entry exposes the certificate's domain names (CN and SANs), issuer and validity period.

How does certificate transparency monitoring work? A monitoring system watches CT logs continuously for certificates matching an organisation's domains, extracts the hostnames, enriches and compares them against a known-asset inventory, and routes unexpected findings to analysts.

How do I search Certificate Transparency logs? Use a public CT search service and query by root domain, subdomain or wildcard pattern. Search suits investigations; continuous monitoring is needed for detection.

Can CT logs reveal subdomains? Yes. SAN entries frequently enumerate subdomains such as api, dev, staging or vpn hosts. Each is a lead requiring validation, since a logged name may no longer resolve or be controlled by the organisation.

Does certificate transparency monitoring detect malicious domains? Not on its own. CT data shows that a certificate was issued, which can flag suspicious infrastructure early, but proving malicious intent requires further investigation of the domain, hosting and content.