The Discovery Problem No One Talks About
Ask any security team what keeps them up at night about certificates, and they'll say "expiration" or "renewal." But there's a harder problem hiding underneath: you can't renew what you can't find.
In 2026, the average enterprise has certificates scattered across dozens of environments — cloud providers, CDNs, Kubernetes clusters, load balancers, IoT devices, internal services, and SaaS platforms. Machine identities now outnumber human identities by 45:1, and that ratio is growing at 30% per year.
Issuing a certificate takes seconds with ACME. Finding every certificate your organization owns? That's the real challenge.
How We Got Here
The Certificate Sprawl Timeline
2015: Most enterprises managed hundreds of certificates
2018: Cloud adoption pushed portfolios to thousands
2020: Kubernetes and microservices multiplied certificates 10x
2022: Multi-cloud strategies created siloed certificate stores
2024: IoT and edge computing added thousands more
2026: Average enterprise has 10,000-100,000+ machine identities
Why Sprawl Accelerated
Several trends converged to make certificate discovery exponentially harder:
1. Cloud-Native Architecture
Every microservice needs its own identity. A Kubernetes cluster running 200 pods might have 200+ certificates managed by cert-manager, plus ingress certificates, service mesh mTLS certificates, and API gateway certificates.
2. Multi-Cloud Adoption
Enterprises now average 3-4 cloud providers. Each has its own certificate management:
- AWS: ACM, IAM server certificates, CloudFront distributions
- Azure: Key Vault, App Service certificates, Front Door
- GCP: Certificate Manager, Cloud Load Balancing, GKE
3. Shadow IT and Self-Service
Developers can provision certificates independently through Let's Encrypt, cloud provider consoles, or internal CA portals. These certificates often bypass central IT oversight.
4. IoT and Edge
Connected devices, edge computing nodes, and industrial control systems all require certificates. Many operate in environments with limited visibility.
The Discovery Gap
What You Know vs. What Exists
Most organizations have a significant gap between their known certificate inventory and their actual certificate footprint:
Known certificates (in CMDB/spreadsheets): ~60%
Certificates in cloud provider consoles: ~15%
Certificates on forgotten servers/services: ~10%
Developer-provisioned certificates: ~8%
IoT/edge device certificates: ~5%
Rogue/unauthorized certificates: ~2%
That ~40% gap represents certificates that could expire without warning, use weak cryptographic algorithms, or be compromised without detection.
Real-World Discovery Failures
The Forgotten Load Balancer
A financial services company experienced a 4-hour outage when a certificate on a legacy load balancer expired. The load balancer wasn't in any inventory because it was provisioned by a team that had since been reorganized. Traffic failed over to the backup, which also had an expired certificate.
The Wildcard in the Closet
A healthcare organization discovered — after a breach investigation — that a wildcard certificate's private key had been copied to 47 different servers across 3 data centers. None of these copies were tracked, and several servers were accessible from the internet.
The Multi-Cloud Blind Spot
A SaaS company managing certificates in AWS ACM had no visibility into certificates that their Azure-based acquisition was running. Post-merger, they discovered 3,000 certificates with no renewal automation, 200 of which were expiring within 30 days.
Why Traditional Approaches Fail
Spreadsheets and CMDBs
Manual tracking fails for three reasons:
- Stale on arrival: By the time someone updates the spreadsheet, new certificates have been issued
- Incomplete by design: Only tracks what someone remembers to add
- No enforcement: Nothing prevents certificate issuance outside the tracked system
CA-Centric Views
Relying on your CA's portal only shows certificates issued by that CA. Most enterprises use multiple CAs:
- Public CA for external certificates
- Internal CA (Active Directory CS, HashiCorp Vault, EJBCA) for internal services
- Let's Encrypt for developer and staging environments
- Cloud-native CAs (AWS Private CA, Azure managed certificates)
- Self-signed certificates in development
Network Scanning Alone
Port scanning finds certificates on listening ports but misses:
- Certificates in cloud key vaults and secret stores
- Certificates used for client authentication (mTLS)
- Certificates on internal-only services not reachable from the scanner
- Certificates stored in CI/CD pipelines and container images
- Code signing certificates
Modern Discovery: A Multi-Layered Approach
Effective certificate discovery in 2026 requires combining multiple techniques:
Layer 1: Network Discovery
Scan your network infrastructure to find certificates on active services:
network_discovery: techniques: - tls_handshake_scanning # Connect to ports, extract certificates - ct_log_monitoring # Monitor Certificate Transparency logs - dns_enumeration # Discover subdomains for scanning - service_mesh_inspection # Query Istio/Linkerd for mTLS certs targets: - internal_networks: "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16" - external_domains: "*.example.com" - kubernetes_clusters: "all-registered" - cdn_endpoints: "cloudflare, akamai, cloudfront"
Layer 2: Cloud API Integration
Query cloud provider APIs to discover certificates in managed services:
- AWS: ACM ListCertificates, IAM ListServerCertificates, CloudFront GetDistribution
- Azure: Key Vault GetCertificates, App Service ListCertificates
- GCP: CertificateManager ListCertificates, Compute SslCertificates
Layer 3: Agent-Based Discovery
Deploy lightweight agents to servers and endpoints to find:
- Certificates in local keystores and file systems
- Certificates referenced in application configurations
- Certificates used by middleware (Apache, NGINX, IIS, Tomcat)
- Private keys and their associated certificates
Layer 4: Integration-Based Discovery
Connect to infrastructure platforms through APIs:
- Kubernetes: Query cert-manager Certificate resources, TLS secrets
- HashiCorp Vault: List PKI engine certificates
- Configuration Management: Scan Ansible, Puppet, Chef for certificate references
- CI/CD: Inspect pipeline configurations for certificate usage
Layer 5: CT Log Monitoring
Monitor Certificate Transparency logs for certificates issued for your domains:
- Detect unauthorized certificate issuance
- Track shadow IT certificate provisioning
- Ensure all publicly trusted certificates are in your inventory
Building a Continuous Discovery Program
Discovery Is Not a One-Time Event
The old model — run a scan quarterly, update the spreadsheet — doesn't work when certificates are issued daily across dozens of environments. Continuous discovery means:
- Real-time CT log monitoring: Instant alerts for new certificate issuance
- Scheduled network scans: Daily or hourly scanning of known infrastructure
- Cloud API polling: Periodic sync with all cloud certificate stores
- Agent heartbeats: Regular inventory reports from deployed agents
- Event-driven discovery: Trigger scans on infrastructure changes
Metrics That Matter
Track these to measure your discovery program's effectiveness:
| Metric | Target |
|---|---|
| Discovery coverage (known vs. total) | > 95% |
| Time to detect new certificates | < 1 hour |
| Unknown certificates found per scan | Decreasing trend |
| Discovery scan frequency | Daily minimum |
| Cloud provider coverage | 100% of active accounts |
The 200-Day Catalyst
With 200-day certificate validity now in effect, discovery isn't just a security concern — it's an operational imperative. You need to discover certificates to:
- Renew them before expiration — certificates you can't find will expire and cause outages
- Validate their compliance — ensure all certificates meet the new 200-day maximum
- Automate their lifecycle — you can't automate renewal for certificates you don't know about
- Plan for 100-day and 47-day — accurate inventory is prerequisite for scaling automation
How TigerTrust Solves Discovery
TigerTrust's multi-layer discovery engine combines all five discovery approaches into a unified platform:
- Network scanning with TLS handshake analysis across internal and external infrastructure
- Cloud-native integration with AWS, Azure, and GCP certificate services
- Agent-based discovery for on-premises servers and endpoints
- Kubernetes-native cert-manager integration and TLS secret discovery
- CT log monitoring for real-time detection of new certificate issuance
All discovered certificates flow into a single inventory with automated lifecycle management — from discovery through renewal to deployment.
You can't secure what you can't see. Start discovering your complete certificate landscape today.