The Certificate Transparency Ecosystem in 2026: Log Operator Shifts, MMD Changes, and What They Mean for CLM

The Infrastructure That Almost Nobody Watches Directly

Certificate Transparency (CT) was designed to be invisible to end users and mostly invisible to enterprise administrators. When it works, browsers accept certificates and everyone moves on with their lives. When it doesn't — when a log is disqualified, when a CA fails to include an SCT, when a certificate is issued for a domain the owner does not control — it produces some of the most instructive incidents in the PKI ecosystem.

For most of CT's history, enterprise CLM teams treated it as somebody else's problem. Browsers required it, CAs handled it, and the logs themselves were operated by a small number of trusted parties on a mostly stable roster. That comfort is no longer warranted. Through 2024, 2025, and into 2026, the CT ecosystem has undergone a series of consequential changes: log operator turnover, tightened Maximum Merge Delay (MMD) enforcement, evolving root program requirements, and new practical use cases for CT data in enterprise security programs.

This article walks through the state of the CT ecosystem in 2026, the changes CLM teams need to understand, and the operational practices that turn CT from a compliance line item into a proactive security signal.

Certificate Transparency, Briefly

CT is a public logging system for TLS certificates. Every publicly trusted CA is required by major browser root programs to submit newly issued certificates (or pre-certificates) to a set of qualified CT logs. Each log returns a Signed Certificate Timestamp (SCT), which the CA includes in the issued certificate. Browsers verify the SCT is present, valid, and issued by a qualified log — otherwise the certificate is not trusted.

The result is a public, append-only, cryptographically verifiable record of every publicly trusted certificate ever issued. This enables:

• Domain owners to detect certificates issued for their domains without authorization.
• Researchers to study CA behavior and identify systemic problems.
• Browser root programs to hold CAs accountable for the certificates they issue.
• Attackers — this is worth acknowledging — to enumerate subdomains and infrastructure that certificate owners may prefer to keep obscure.

The mechanism is elegant. The operational reality is more complex.

The Log Operator Landscape in 2026

Historically, a small handful of organizations operated most CT logs: Google, Cloudflare, DigiCert, Sectigo, and Let's Encrypt, with a rotating set of smaller operators. The economics were unclear — logs are expensive to run at scale, generate no revenue, and expose their operators to significant reputational risk if they fail.

Through 2024 and 2025, that landscape shifted. Google's announcement that it would wind down operation of its Argon and Xenon log series marked a pivotal moment: the largest and most reliable log operator was stepping back. Cloudflare expanded its Nimbus logs to fill some of the gap. Let's Encrypt continued its Oak logs. Sectigo and DigiCert continued their operations. New entrants — Trust Asia and others — brought regional diversity.

The practical result for 2026 is:

• A more diverse but potentially more variable log roster. More operators reduce concentration risk but increase the chance that any given log has an availability or compliance issue.
• Greater importance of the browser root program vetting. Chrome, Apple, and Mozilla each maintain independent qualification processes for logs; a log qualified for one root program may not be for others.
• More attention to log disqualification history. Logs are occasionally disqualified — for compliance failures, availability problems, or operator issues. CAs and enterprise monitoring should track disqualifications in real time.
• Increased focus on log sharding. Modern CT logs are typically sharded by year (or shorter periods) to keep individual log sizes manageable. Enterprise monitoring must follow log shards, not just log operators.

Maximum Merge Delay (MMD) in Practice

CT logs are required to merge submitted certificates into the log tree within a Maximum Merge Delay — historically 24 hours. This bound gives certificate owners a predictable window for detecting fraudulent issuance. It also constrains log operators: they must maintain infrastructure that can absorb submission bursts and keep pace with global CA issuance rates.

MMD enforcement has tightened as issuance volume has grown. In 2026, several practical consequences follow:

• Some logs enforce MMD stricter than the baseline. Operators publish target MMDs shorter than 24 hours; missing that target may be an internal alert even if it does not disqualify the log.
• Log availability during MMD windows matters. A log that has an outage during a peak submission window can violate MMD across many CAs at once.
• CA behavior interacts with MMD. CAs typically submit to multiple logs to get redundant SCTs. When one log is slow, CAs may fall back to others; when the fallback pool is small, MMD violations become more likely.

For enterprise CLM teams, the practical rule is: don't assume every issued certificate will be visible in CT within the first hour. Reliable CT-based monitoring should tolerate up to the full MMD window before treating a "missing from CT" observation as a signal.

Root Program Requirements Update

The major browser root programs — Chrome, Apple, Mozilla, and Microsoft — each maintain their own requirements for what certificates must include CT proofs. These requirements have converged toward:

• SCT count and log diversity requirements. Multiple SCTs from logs operated by different organizations are required for most certificate lifetimes.
• One-shot log requirements. Some root programs require at least one SCT from a browser-operator-approved log (e.g., a Google-approved or Apple-approved log).
• Post-2026 CT requirements for private CAs consumed by public browsers. As root programs extend policy into edge cases (private CAs distributed through public trust stores, cross-signed hierarchies), CT expectations follow.
• Alignment with shorter certificate lifetimes. As the SC-081 timeline drives certificate lifetimes down to 47 days, some CT-related requirements are being reconsidered — shorter certificates provide less time for monitoring to detect issues.

CAs implement these requirements. Enterprises rarely need to change anything to comply, provided they use compliant CAs. What enterprises should track: which logs their CAs are actually using, and whether those logs remain qualified.

Using CT Data for Enterprise Security

The most valuable — and underused — role of CT in enterprise CLM is as a security data source. Any CT data platform (crt.sh, Google's CT search tools, Cloudflare Merkle Town, or specialized commercial services) can produce answers to questions enterprises actually care about:

Have any certificates been issued for our domains that we didn't authorize?

This is the classic CT monitoring use case. Every domain in scope for the enterprise should have automated monitoring of CT for new issuance. When a new certificate appears, it should be matched against the enterprise's expected CAs, expected purposes, and expected requesters. Unmatched issuances should generate immediate alerts.

Have any certificates been issued for our subdomains that we didn't know about?

Shadow IT often reveals itself in CT. A team that spun up a service on an unmanaged subdomain and got a Let's Encrypt certificate appears in CT logs whether or not they told the CLM team. Regular CT sweeps of parent domains discover shadow infrastructure that other discovery methods miss.

Which CAs are actually issuing certificates for our domains?

CA diversity is a security concern. If policy says "we only use DigiCert and internal CA," CT will confirm or contradict that policy. Certificates from other CAs — whether authorized exceptions or unauthorized issuance — should be investigated.

What is our certificate footprint over time?

CT logs are the most comprehensive external view of an enterprise's public certificate posture. Time-series analysis reveals growth in certificate count, changes in CA usage, and shifts in domain patterns that internal inventories may not show clearly.

Where CT Monitoring Falls Short

CT is powerful but not omniscient. Enterprise CLM teams should understand its limits:

• Only publicly trusted certificates. Private CA certificates for internal use are not in CT. Internal PKI requires its own inventory and monitoring.
• Only certificates the CA logged. A rogue CA that intentionally did not log certificates would not appear in CT. Root program requirements make this unlikely for compliant CAs, but the possibility exists.
• Not real-time. MMD provides a maximum bound, but observation typically lags issuance by minutes to hours in practice.
• Not all monitoring platforms are equal. Some platforms lag behind others in indexing new logs, and coverage of newly qualified logs can be uneven.
• CT does not tell you about deployment. A certificate in CT may or may not be deployed anywhere. Marrying CT data with deployment data (via active scanning or CLM inventory) is where the real value comes.

Practical CT Program Elements

A functional CT program in an enterprise CLM operation includes:

Domain scope definition

Maintain a canonical list of domains the enterprise owns or is authorized to operate. Include acquired brands, marketing domains, and subsidiary domains. Refresh regularly.

Continuous CT ingestion

Ingest CT log data continuously — either through commercial services, open-source tools, or in-house integrations. Match every new certificate against the domain scope.

Alerting and triage

Alerts should distinguish between certificates issued by expected CAs (log-and-verify), certificates from unusual CAs (investigate), and certificates for unexpected purposes (escalate).

Integration with CLM inventory

Every CT-observed certificate should be reconciled against the CLM inventory. Certificates present in CT but absent from the CLM inventory represent either shadow IT or a governance gap.

Retrospective analysis

Regular retrospective analysis of CT patterns supports strategic decisions: consolidation of CAs, deprecation of unused domains, and validation of policy compliance.

The 2026 Watchlist

Enterprise CLM teams tracking CT developments in 2026 should watch:

• Log operator turnover. Announcements from Google, Cloudflare, DigiCert, Let's Encrypt, and others about new logs, retirements, and shard rollovers.
• Root program policy updates. Chrome, Apple, Mozilla, and Microsoft publish CT policy in different cadences; small changes have large downstream effects.
• MMD trends. Movement toward shorter MMD windows would tighten monitoring requirements.
• New log entrants. Regional operators (Asia-Pacific, EU-based) bring diversity but require enterprise monitoring platforms to keep up.
• CT + short-lifetime interaction. As 47-day certificates approach, the interplay between CT visibility and rapid rotation will drive further policy discussion.

How TigerTrust Uses Certificate Transparency

TigerTrust incorporates CT as a first-class data source in its discovery and monitoring pipelines:

• Continuous CT ingestion: All major qualified logs are monitored continuously; new shards and new operators are added automatically.
• Domain scope matching: Every certificate in CT is matched against your defined domain scope, with unmatched issuances raised as alerts.
• Shadow IT discovery: Certificates for unmanaged subdomains surface in your CLM inventory as candidates for enrollment.
• CA policy verification: Alerts fire when certificates are issued for your domains by CAs not on your approved list.
• Reconciliation with active discovery: CT data is cross-referenced with active scanning to identify certificates that are logged but never deployed, and certificates that are deployed but somehow missing from CT.
• Log operator watchlist: TigerTrust tracks log operator status and disqualification history so your team is informed when the underlying CT infrastructure changes.

Certificate Transparency is the largest public dataset about your own certificates that most enterprises never fully use. Talk to TigerTrust about turning CT into a proactive security signal at tigertrust.io.