Security teams should start with a complete certificate inventory across servers, load balancers, applications, and IoT or embedded systems. The goal is to identify where each certificate is deployed, who owns it, when it expires, and whether it meets baseline requirements. Without visibility, organisations cannot assess exposure, reissue affected certificates, or manage renewal risk effectively.
How to find every SSL certificate in use
Discovery should be treated as an inventory problem first, not a renewal problem. Teams need to sweep infrastructure, certificate stores, application configuration, load balancers, reverse proxies, and embedded systems to find where certificates actually terminate, not just where they are documented. In practice, the most reliable view comes from combining active scans, configuration inspection, and ownership data so hidden or stale certificates do not remain outside governance.
That inventory has to include certificates used for server authentication, mutual TLS, internal service communication, and vendor-managed integrations. Certificates often exist in places that asset inventories miss, including containers, CI/CD pipelines, appliances, and legacy devices. A discovery process that only looks at public web endpoints will leave gaps in the very systems most likely to fail without warning.
What an inventory needs to capture for each certificate
Once a certificate is found, the useful question is not only whether it exists, but whether the organisation can act on it. A workable record should tie each certificate to a system owner, technical owner, environment, issuance source, expiration date, and renewal path. That lets security teams separate certificates that are business-critical from those that are redundant, duplicated, or no longer needed.
The inventory should also record baseline attributes that affect trust and operability, such as subject name, issuer, algorithm, key length, and whether the certificate is publicly trusted or privately issued. Those details matter because weak or inconsistent issuance patterns usually indicate fragmented management, and fragmented management is what turns certificate expiry into outages or emergency changes.
Which discovery methods work best in practice
No single method finds everything. Active network discovery helps locate externally reachable services, but configuration review is needed to find certificates stored in application settings, infrastructure-as-code, container images, and orchestration manifests. Discovery also needs to extend into nontraditional environments such as IoT and embedded systems, where certificate use may be undocumented but still operationally critical.
Teams should prefer methods that produce repeatable evidence, not one-off sightings. A certificate inventory becomes dependable when discoveries can be reconciled against authoritative sources like platform inventories, cloud accounts, certificate authorities, and deployment records. For certificate lifecycle expectations and renewal timing, CA/Browser Forum baseline requirements and the NIST SP 800-57 Key Management guidance help teams anchor the operational record to recognised trust and lifecycle practices.
Risk and Threat Considerations
Undiscovered certificates create exposure because they can expire, be reused outside policy, or remain active after the owning team has changed. That makes certificate discovery a control for both availability and trust, especially in environments with many short-lived workloads or delegated operations. The same blind spot can also conceal obsolete certificates that still authenticate to systems long after they should have been revoked.
Failure mechanism: Certificates are missed because they are stored in multiple layers of the stack, issued by different sources, or embedded in systems that are not covered by standard asset discovery. The result is incomplete visibility, which breaks ownership assignment, renewal tracking, and revocation planning.
Impact: Security teams lose the ability to anticipate expiry, detect shadow deployments, and assess whether a certificate is still appropriate for the system using it. That can lead to outages, unmanaged trust paths, and delayed response when a certificate must be replaced quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate discovery depends on lifecycle visibility for keys and cryptographic material. |
| Recommendation — Track certificate and key lifecycles so expiry, rotation, and replacement are governed before failure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate inventory supports managing authentication material across systems and services. |
| Recommendation — Inventory and control certificates as authenticators so renewal and revocation are not left to chance. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Discovering certificates in use requires a complete asset and environment inventory. |
| Recommendation — Extend asset inventory to certificate-bearing systems so hidden deployments are included in governance. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Certificate discovery is part of maintaining an accurate inventory of security-relevant assets. |
| Recommendation — Maintain an asset inventory that includes certificate-bearing systems and owners. | ||
Practitioner Guidance
What to prioritise: Start with externally exposed services and high-availability systems, then extend discovery into internal applications, container platforms, and device fleets. Those areas produce the highest operational consequence if a certificate is missed.
What to verify: Confirm that each discovered certificate has an owner, an expiration date, a renewal path, and a system location that matches what is actually deployed. If the record cannot be tied back to a real runtime endpoint, treat the inventory as incomplete.
Common mistake: Treating the certificate authority list as the inventory. Issuance data alone will not reveal where certificates are deployed, especially when teams reuse certificates or copy them into multiple environments.
Practitioner takeaway: The discovery goal is not just to enumerate certificates, but to make each one actionable, traceable, and renewably owned before it becomes an outage or trust failure.
Related resources from NHI Mgmt Group
- How should security teams prioritize PKI use cases when certificates are still managed manually across multiple systems?
- How should security teams limit control over Active Directory so attackers cannot use identity infrastructure to move across the environment?
- How should security teams decide whether to standardise load balancer SSL policies across cloud environments?
- How should security teams handle SSL/TLS certificates that are still using 1024-bit encryption keys?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
