Certificate transparency is the earliest warning you get about a phishing site
A lookalike domain leaves a public record days before it serves a page. Here is how that window works, and why most brand protection programmes miss it entirely.
Most teams learn about a phishing site the same way: a customer forwards an email, or support notices three complaints in an afternoon about a refund nobody issued. By then the site has been live for days, it has already converted, and you are doing damage control rather than prevention.
There is an earlier signal, and it is public.
The gap between registration and attack
Standing up a convincing phishing site is several jobs, not one. Somebody has to register a lookalike domain, point it at hosting, obtain a TLS certificate so the browser shows a padlock, clone your pages, and then drive traffic to it. Those steps are usually days apart, sometimes weeks.
The certificate is the interesting one, because since 2018 every publicly trusted certificate has to be logged to certificate transparency logs, which are append-only and readable by anyone. That was designed to catch misissuance by certificate authorities. It has a useful side effect: the moment somebody obtains a certificate for a domain that looks like yours, they publish a timestamped record saying so.
The attacker cannot skip it. A phishing page served over plain HTTP gets a browser warning that destroys its conversion rate. Getting the padlock means getting logged.
What that window is actually worth
Between certificate issuance and a working phishing page you can:
- File with the registrar before anyone has been harmed, which is a much simpler request than a takedown after the fact
- Warn support and your fraud team that a campaign is being prepared, with the exact domain
- Pre-emptively add the domain to blocklists you contribute to
- Check whether the same registrant has other certificates, which usually reveals the rest of the campaign
None of that is possible once you are reacting to complaints.
Why programmes miss it
Not because the data is hard to get — it is free and unauthenticated. The reasons are more boring.
Volume. Any large brand generates a constant stream of certificate issuances for names that are technically similar. Without filtering against the domains you actually own and the names you have already cleared, the feed is unusable within a week.
Ownership. Certificate monitoring sits awkwardly between security, who own the domain estate, and brand protection, who own impersonation. Feeds that belong to nobody get muted.
No action path. Finding a lookalike certificate is only useful if it lands somewhere a notice can be drafted from. A Slack alert with a domain name in it is not a workflow, and it is why most of these integrations are quietly turned off within a quarter.
What to do about it
If you are building this yourself, the three things worth getting right are deduplication against your own estate, permanent memory of what you have already cleared, and a route from finding to notice that does not involve retyping the domain into a different tool.
If you would rather not, this is one of the six external exposure feeds TracBrand reads on every domain you register, graded by rule rather than by model, and deduplicated per brand so a long-standing finding does not re-alert every cycle. See threat intelligence for what the other five cover.