Axelspire

Certificate Transparency Strategy: From Compliance Checkbox to Detection Surface

Certificate Transparency is one of the most powerful security mechanisms in the Web PKI — and one of the most underutilised. Since Google Chrome began requiring CT log inclusion for all publicly trusted certificates in 2018, every certificate issued for your domains is recorded in a publicly auditable, append-only log. Over 2.5 billion certificates have been logged since the system launched in 2013. Firefox joined Chrome in requiring CT compliance in February 2025.

Public CT logs record issuance for your names—an audit trail that exists whether or not your team consumes it.
Public CT logs record issuance for your names—an audit trail that exists whether or not your team consumes it.

That's the compliance side. Every public CA submits to CT logs. Your certificates are there. Box ticked.

The strategic question is different: are you consuming CT logs, or just publishing to them? Because the gap between those two activities is the gap between knowing a certificate was issued for your domain and discovering it six months later during a penetration test — or worse, from a customer who noticed your login page was being phished with a valid certificate.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

What Certificate Transparency Actually Gives You (and What It Doesn't)

CT is an audit mechanism, not a prevention mechanism. This distinction matters strategically because it defines what CT can and can't do for your organisation.

CT logs provide a near-real-time, cryptographically verifiable record of every publicly trusted certificate issued for any domain. When a CA issues a certificate, it submits the certificate (or a precertificate) to one or more CT logs and receives a Signed Certificate Timestamp (SCT) in return. That SCT is embedded in the certificate itself, proving it was logged before issuance.

This means CT can tell you after the fact that a certificate was issued. It cannot prevent issuance. If an attacker compromises a CA's validation process, or if a CA makes an error, the mis-issued certificate will appear in CT logs — but it will already be usable. The value of CT is that the window between mis-issuance and detection collapses from "maybe never" to "minutes, if you're watching."

The CT ecosystem is also evolving technically. The original RFC 6962 log architecture is being replaced by the Static CT API, a tiled Merkle tree structure that's faster to operate and more scalable. Let's Encrypt shut down its RFC 6962 logs in early 2026, moving entirely to Static CT API logs. Google Chrome updated its CT policy to accept SCTs from the new log format. This transition is largely invisible to certificate consumers, but it matters for anyone building or operating monitoring infrastructure — your tooling needs to support the new API format.

The Mis-Issuance Detection Gap

Here's the uncomfortable reality: most organisations that claim to "do" certificate transparency are actually doing nothing more than relying on their CA to submit certificates to logs. They have no monitoring in place. They would not know if a rogue certificate appeared for their domain until it was actively used in an attack — and probably not even then.

The mis-issuance scenarios that CT detects aren't theoretical. DigiNotar's compromise in 2011 led to fraudulent certificates for Google, Yahoo, and other major domains. In 2015, Symantec-affiliated CAs issued unauthorised test certificates for Google domains. Cloudflare has publicly disclosed instances of unauthorised TLS certificates being issued for 1.1.1.1 by a CA without their permission. These incidents were detected precisely because CT logs existed and someone was watching.

The detection gap exists because monitoring CT logs is operationally non-trivial at scale. The volume is enormous — billions of certificates across dozens of active logs. You need infrastructure that can continuously ingest log entries, match them against your domain inventory, and alert on unexpected issuance. You also need a team that can triage alerts, because false positives are common: legitimate certificates issued by CAs you forgot you authorised, or for subdomains managed by teams you didn't know existed.

Building a CT Monitoring Strategy

A CT monitoring strategy has four components: scope definition, monitoring infrastructure, alerting and triage, and SOC integration.

Scope definition starts with a complete domain inventory — and this is where most organisations first discover gaps. You can't monitor CT for domains you don't know you own. Shadow IT, acquired domains, legacy brands, test environments — all of these can have certificates issued without central IT's knowledge. Your CT monitoring scope should match your DNS asset inventory, which means building or updating that inventory is step zero.

Monitoring infrastructure can be built, bought, or delegated. On the build side, tools like Certspotter, Facebook's CT monitoring service (now Meta), and open-source projects provide the foundation. On the buy side, vendors including Cloudflare (through their CT dashboard on Radar), Sectigo, and several certificate lifecycle management platforms offer CT monitoring as a feature. The build-vs-buy decision depends on your organisation's scale and how tightly you want to integrate CT alerting into your existing security operations.

Whichever path you choose, ensure your monitoring covers all major log programs — both Google's and Apple's — and supports the Static CT API format that's replacing RFC 6962 logs. Tooling that only queries legacy APIs will have blind spots as the ecosystem completes its migration.

Alerting and triage is where CT monitoring either becomes operationally useful or degenerates into noise. The alert categories that matter are: certificates issued by CAs not in your approved list (possible mis-issuance or policy violation), certificates for domains or subdomains you don't recognise (possible shadow IT or compromise), wildcard certificates you didn't request (high-risk if unexpected), and certificates with unusual validity periods or key types.

False positive management is critical. A mature CT monitoring programme classifies alerts by severity, auto-closes known-good patterns (like renewals from your approved CAs), and escalates only actionable findings. Without this classification, your SOC will ignore CT alerts within a week.

SOC integration is what separates CT monitoring from CT compliance. CT alerts should feed into your SIEM or security operations platform with the same priority as intrusion detection alerts. A mis-issued certificate for your primary domain is at least as serious as a detected intrusion attempt — arguably more, because a valid certificate enables transparent interception of encrypted traffic.

The SOC response playbook for a confirmed mis-issuance should include: immediate revocation request to the issuing CA, CAA record review and tightening, domain validation method audit, communication to affected stakeholders, and incident documentation for compliance.

CT and CAA: The Combined Trust Framework

Certificate Transparency and CAA records operate at different points in the certificate lifecycle, and they're complementary rather than redundant. CAA acts before issuance — it tells CAs which authorities are permitted to issue for your domain. CT acts after issuance — it records what was actually issued.

The strategic value of combining them is layered defence. CAA prevents most routine mis-issuance by restricting which CAs can issue. CT detects anything that slips through — whether because of a CA that improperly validates CAA records (this has happened; Camerfirma was found to improperly validate CAA records in 2017, and Let's Encrypt disclosed a CAA validation bug in 2020 affecting over 3 million certificates), because of a CA compromise, or because your CAA records have gaps.

For a complete treatment of CAA as a strategic control, see CAA and DNS Chain of Trust Strategy.

Operational Maturity Model

Organisations typically sit at one of three levels of CT maturity, and the gap between where they think they are and where they actually are is usually one full level.

Level 1: Passive Compliance. Your CA submits certificates to CT logs. You have no monitoring. You would not detect a mis-issued certificate unless someone else found it and told you. This is where roughly 80-90% of organisations sit today, and it's the minimum required by browser CT policies. It provides zero detection capability.

Level 2: Active Monitoring. You monitor CT logs for certificates matching your domain inventory. You receive alerts for unexpected issuance. You have a defined process for investigating alerts, even if it's informal. You've discovered shadow IT through CT monitoring — most organisations do within the first month. This is where organisations should aim to get first. The tooling exists. The operational lift is modest. The detection value is significant.

Level 3: Integrated Response. CT monitoring feeds into your SOC with defined playbooks. Alert triage is partially automated. CT data is correlated with DNS changes, CAA records, and certificate lifecycle events to provide context. Mis-issuance response is rehearsed, not improvised. Very few organisations operate at this level, but it's where the most strategic value lives — especially for organisations in regulated industries or with high-value domains.

Moving from Level 1 to Level 2 is primarily a tooling and process decision. Moving from Level 2 to Level 3 is an organisational decision about where CT monitoring sits in your security operations model. Both moves are worth making. The first protects you from external threats. The second protects you from internal gaps you didn't know you had.

What CT Cannot Replace

CT monitoring is not a substitute for proper CA governance, certificate lifecycle management, or key management. It's a detection layer — valuable, but not sufficient on its own. Organisations that invest in CT monitoring while neglecting CAA records, revocation strategy, or certificate observability are building a burglar alarm without locking the doors.

CT also has inherent privacy implications for internal operations. Every publicly trusted certificate is visible in CT logs, which means your subdomain structure, service names, and infrastructure patterns are discoverable. For organisations that consider this a concern, private PKI for internal services avoids CT exposure entirely — but that's a separate strategic decision.

Sector context: issuance and monitoring pressures in financial services, healthcare, and manufacturing & OT observability.

Strategic CT: continuous monitoring and alerting for unexpected certificates, not only meeting browser inclusion rules.
Strategic CT: continuous monitoring and alerting for unexpected certificates, not only meeting browser inclusion rules.

← Back to Certificate Strategy: The Framework Most Organisations Skip

External References