Shadow IT is not new. What has changed is how easy it has become to spin up internet-facing services — and how reliably those services leave a trace in Certificate Transparency logs. Every subdomain with a publicly trusted certificate has been logged. That log is permanent. And it is fully searchable by anyone, including your security team — if they know to look.

Why shadow IT is a certificate problem

Historically, shadow IT was mostly an internal problem — unauthorised SaaS tools, personal cloud storage, unapproved collaboration apps. These carry their own risks, but they typically do not create publicly reachable infrastructure under your domain.

Modern shadow IT is different. With cloud providers making it trivial to expose services to the internet, and Let's Encrypt removing the cost and process friction of obtaining a certificate, developers and teams routinely create internet-facing services under your domain without going through any formal approval or documentation process.

The result is that your external attack surface includes systems your security team has never reviewed, services running software versions nobody is patching, and endpoints that were never designed to be permanent but have quietly become so.

What the certificate record reveals

Every time someone obtains a certificate for staging.yourdomain.com, dev-api.yourdomain.com, or internal-tool.yourdomain.com, that issuance is logged in CT. The log entry contains:

  • The exact domain and all Subject Alternative Names
  • When the certificate was issued
  • Which CA issued it — revealing whether it went through your standard processes or was obtained ad-hoc
  • The certificate lifetime — short-lived Let's Encrypt certificates renewing automatically are a strong signal of an unmanaged service running in the background

A search of CT logs for your primary domain will typically surface dozens to hundreds of subdomains — many of which will be expected, but some of which will raise immediate questions. Who set up api-test-jan.yourdomain.com? Is it still running? What does it expose?

The lifecycle of an abandoned service

Shadow IT services tend to follow a predictable lifecycle that makes them progressively more dangerous over time:

Months 1–3: Active development. The service is under active use. Someone is (probably) paying attention to it. The risks at this stage are mostly process — the service has not been reviewed, documented, or hardened, but someone knows it exists.

Months 3–12: Background operation. The immediate project is over, but the service keeps running. Automated certificate renewal keeps it accessible. Nobody is actively monitoring it or applying updates. Dependency vulnerabilities accumulate.

12 months+: Forgotten infrastructure. The people who built it may have changed roles or left the organisation. The service is running on autopilot — often on an underlying runtime or framework that is now significantly out of date. If the service handles any data, that data may be sitting unprotected. If it has authentication, the credentials may be default or long since rotated everywhere except here.

At this stage, the service represents meaningful risk to the organisation. It is reachable from the internet, it is unpatched, and nobody knows it is there. An attacker who finds it — which is straightforward using CT logs — will find an easy target.

Common shadow IT patterns in CT logs

When reviewing CT log data for shadow IT, a few patterns stand out:

  • Personal or project name subdomains — johns-tool.yourdomain.com, project-alpha-api.yourdomain.com. These are almost always unofficial.
  • Environment labels on unexpected domains — staging, dev, test, demo subdomains that are not in any official infrastructure inventory.
  • Certificates from unexpected CAs — if your organisation uses a specific CA through a managed process, certificates from Let's Encrypt or other free CAs on your domain are a signal that someone went outside that process.
  • Rapidly cycling short-lived certificates — Let's Encrypt certificates are 90-day and renew automatically via ACME. A subdomain with a long history of 90-day certificates renewing automatically has been running continuously for months or years without anyone manually touching it.
  • Wildcard certificates on subdomains — *.team.yourdomain.com suggests someone set up their own subdomain namespace, potentially hosting multiple services under it.

From discovery to remediation

Finding shadow IT services is the first step. The harder part is deciding what to do with them. A few categories typically emerge from a discovery exercise:

Services that should be brought in from the cold. Some shadow IT turns out to be genuinely useful and used. These services should be documented, reviewed for security, brought into the standard patching and monitoring processes, and given proper ownership. The goal is not to shut everything down — it is to bring everything under managed oversight.

Services that should be decommissioned. Services that are no longer actively used should be shut down. The certificate should be allowed to expire and DNS should be cleaned up. Leaving an unused service running is unnecessary risk with no upside.

Services that reveal a process gap. Repeated patterns of shadow IT — especially in specific teams or around specific types of projects — indicate that the official process for setting up services is too slow, too complex, or too difficult. The right response is often to fix the process, not just shut down the services. Shadow IT is usually a symptom of friction, not malice.

How to get ahead of it going forward

Remediating existing shadow IT is a one-time exercise. The more valuable capability is ongoing monitoring — knowing about new certificates on your domains within minutes of issuance, rather than discovering them months later in a quarterly audit.

CT log monitoring for your domains means that new shadow IT surfaces immediately. When new-api-service.yourdomain.com gets its first certificate, you see it. When it starts getting renewed automatically six months later after the project ended, you see that too. The inventory stays current because the data source — the CT logs — is updated in real time.

How CertControl handles this

CertControl's external scanner uses Certificate Transparency logs as the primary input for discovering your external certificate footprint. When you add a domain, the platform queries CT log aggregation to find every certificate ever issued for that domain and its subdomains — giving you a historical map of what has been deployed under your name.

From there, active DNS resolution and port scanning determines which of those subdomains are currently live and reachable. The combination gives you two lists: things that exist in certificate history and things that are currently active. The delta between those two lists is often where the most interesting findings are.

Ongoing CT monitoring then alerts you to new issuances as they happen, so the inventory stays current without manual effort. New shadow IT surfaces immediately rather than accumulating between audits.

See the platform Book a demo