Certificate Transparency should be the key aspect of your cryptographic discovery strategy

Last updated: January 2026

In 1994, Netscape made a decision that became the foundation of trust on the Internet, and changed the world forever. Back then, their Navigator browser was taking off, but it was the early days of the Web when all communication was in plaintext. Netscape took initiative, built the SSL protocol, and with it, the trust model that we're still using today… for better or worse.

The trust model was simple: a) a selected group of organisations is allowed to issue certificates for web sites while b) we trust them unreservedly. The simplicity powered the explosive growth of the Web.

Things carried on for a while, but the ecosystem eventually became unmanageable. In 2011, there was an attack on a small certification authority (CA) called DigiNotar, which resulted in hundreds of fraudulent certificates for some of the biggest websites in the world. It was so bad that we couldn't even reliably track who had been affected. The situation was untenable, but it led to the creation of a new paradigm, that of transparency in security systems.

Designed at Google, Certificate Transparency (CT) is a mechanism that tracks all public certificates issued by CAs. The thinking is that, if we're going to trust these organisations to manage trust on our behalf, we might as well have full visibility into what they're doing. CT became mandatory for web sites in 2018 and shifted the balance of power back toward the centre.

Visibility made all the difference and enabled us to continue to improve and fine-tune how the public PKI is governed. Crucially, it enabled every organisation around the world to monitor issuance activity for their properties in real-time. Armed with a list of their registered domain names, they can now monitor the CT activity of the entire world to find certificates that apply to them. The benefits are two-fold: organisations can a) achieve visibility of their own activity and also b) have visibility into any mis-issuances should they happen.

CT isn't only providing visibility into what certificates are issued, but also, indirectly, into what services are running. This is possible because every certificate includes a list of domains it applies to. Thus, if you monitor CT activity for any certificate that matches your registrable domain names, the outcome will be a complete inventory of your certificates as well as all subdomains across your entire domain estate.

This simple fact is incredibly powerful, as most organisations of non-trivial size struggle to keep track of their own infrastructure. With CT, all of a sudden, we have a type of heartbeat mechanism that's telling us what subdomains we have. By monitoring these heartbeats you build a wider inventory of subdomains. When you actively probe them via network scanning, you build a comprehensive inventory of services. And—just like that—the dream of continuous automated asset inventory management becomes possible.

The flip side of public certificate logging and monitoring is, well, that it's public. Anyone in the world, not just you, can monitor your certificates as they're issued and, by extension, observe your subdomain activity. This functionality is often used for good, by cybersecurity companies such as Red Sift, to provide automated asset inventories for their customers. But it's often used by criminals to find new services to attack, often within minutes of their certificates being issued. For them, CT monitoring joins continuous network port scanning as a way to find more targets faster.

The fact that your obscure public services can be discovered is not new. Internet-wide network scanning for active IP addresses and open ports has been used for a long time, especially on highly sensitive ports such as 22 (SSH) and 3389 (RDP). The answer then and now is the same: don't put online services that are not secure.