Security teams should centralize discovery, track every certificate regardless of issuing CA, and continuously monitor where each certificate is installed, who issued it, and when it expires. The practical goal is to eliminate blind spots, including shadow certificates introduced outside standard processes. A complete inventory supports renewal planning, reduces outages, and gives teams a defensible view of certificate risk across the environment.
What a Complete Certificate Inventory Has to Capture
A useful inventory is more than a list of hostnames and expiration dates. Security teams need a record that ties each certificate to its installation points, issuing CA, subject, key type, validity window, owner, and business service. That is what makes the inventory actionable for renewal, incident response, and audit.
The inventory also has to cover both internal and external certificates, because blind spots usually come from certificates that sit outside the standard procurement or platform process. A certificate found in a load balancer, API gateway, reverse proxy, mail system, or developer-managed environment is still part of the same control problem if it can affect trust or availability.
One practical benchmark is visibility into service-account-style assets and other machine-managed trust material, since this category is often the source of the hidden inventory gap. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which illustrates how easily certificate ownership and placement can drift when inventory is not centralised.
How to Discover Certificates Across Internal and Public-Facing Systems
Discovery should be continuous, not a one-time campaign. Teams usually need to combine active scanning, passive inspection of traffic and configuration data, endpoint or cloud asset collection, and platform integrations with PKI, load balancers, ingress controllers, certificate managers, and CI/CD systems. No single discovery method will reliably find everything.
Coverage should include certificates issued by public CAs, private CAs, self-signed certificates, test certificates, and certificates embedded in application bundles or automation workflows. The question is not whether the certificate is “official”, but whether it creates a trust relationship that could affect confidentiality, integrity, or service availability.
Discovery quality improves when the team correlates certificates with the systems that present them and the teams that own those systems. A central inventory without ownership data becomes a reporting exercise; a central inventory with owner, environment, and installation data becomes a control system.
- Scan externally exposed services for every TLS endpoint, including alternate ports and legacy front doors.
- Pull certificate metadata from internal load balancers, ingress layers, reverse proxies, mail relays, VPNs, and application servers.
- Ingest data from cloud, container, and configuration management tooling so ephemeral deployments are not missed.
- Record whether the certificate is active, staged, or retired so the team can separate true exposure from historical noise.
How to Operate the Inventory So It Stays Trusted
A certificate inventory only works if it is treated as a living source of truth. That means automated refresh, expiration alerting, renewal workflow ownership, and a defined process for removing retired certificates from the active set. If those steps are manual, the inventory will lag behind reality and outages will reappear at every renewal cycle.
Teams should also track abnormal placement, such as certificates deployed outside approved tooling, certificates with no clear owner, and certificates that appear in unexpected environments. Those are often the earliest indicators of shadow deployment, weak change control, or an unmanaged service path.
For public certificate management, issuance and revocation policy matter as much as discovery. The CA/Browser Forum defines the baseline expectations for publicly trusted certificate issuance and revocation, while NIST SP 800-57 Key Management helps teams think about certificate lifecycle, cryptoperiods, and replacement before expiry creates service risk.
CA/Browser Forum is especially useful where public trust is involved, and NHIMG’s lifecycle guidance is a strong fit for the operational side of discovery, ownership, rotation, and offboarding. For teams that want a broader control baseline, CIS Controls v8 reinforces the need for asset inventory, account management, and secure configuration discipline around the systems that present those certificates.
Risk and Threat Considerations
Certificate inventory gaps create both outage risk and trust risk. The most common failure mode is not cryptography breaking, but a certificate expiring, being renewed on the wrong host, or remaining active in an unexpected location after a change. That can interrupt customer-facing services, break internal trust chains, or leave orphaned certificates available for misuse.
Failure mechanism: When certificates are not centrally tracked, teams lose visibility into where trust is established, who controls renewal, and whether a certificate still belongs in production. That makes expiry, duplication, and shadow deployment much harder to detect before they affect service or security.
Impact: A missed renewal can cause an outage, while an untracked certificate can expose an organisation to unauthorized use, weak governance, or unplanned trust relationships across internal and public-facing systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 1 — Inventory and Control of Enterprise Assets | Certificate inventory depends on knowing every system that can present TLS trust material. |
| 5 — Account Management | Certificate ownership and renewal accountability often depends on clear system and admin ownership. | |
| 6 — Access Control Management | Certificates create trust paths that need controlled placement and approved use. | |
| Recommendation — Maintain authoritative asset inventory coverage for every certificate-bearing system. Assign and review ownership for every certificate and its managing system. Restrict certificate deployment paths to approved systems and workflows. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | A complete certificate inventory is an asset visibility and tracking problem. |
| PR.AA — Identity Management, Authentication and Access Control | TLS certificates establish trust and authentication for services and endpoints. | |
| PR.PT — Protective Technology | Certificate monitoring and renewal controls are protective technologies that reduce outage and trust risk. | |
| Recommendation — Catalog all certificate-bearing assets and keep the inventory continuously updated. Tie certificate issuance and use to controlled authentication and access policies. Automate certificate discovery, expiry monitoring, and renewal safeguards. | ||
| NIST SP 800-63 | 6 — Federation and Assertions | Public certificate trust underpins federated trust and assertion validation for many services. |
| 7 — Remote Authentication and Session Management | Public-facing TLS endpoints often support remote authentication and session trust. | |
| Recommendation — Validate certificate-based trust chains for systems that depend on federated authentication. Protect remote sessions by tracking the certificates that secure those endpoints. | ||
| NIST Zero Trust (SP 800-207) | 4 — Identity and Access Policies | Zero trust relies on explicitly managed trust relationships, including service certificates. |
| Recommendation — Explicitly govern certificate trust relationships as part of zero-trust policy enforcement. | ||
| DORA | ICT risk management — ICT Risk Management | Certificate inventory supports operational resilience by reducing avoidable service outages. |
| Recommendation — Include certificate inventory and expiry monitoring in ICT risk controls. | ||
Practitioner Guidance
What to prioritise: Start with the certificate sources that can break production first, public edge services, load balancers, ingress layers, VPNs, mail, and shared application gateways. Then expand into developer-managed, cloud-native, and automation-managed locations where shadow certificates are most likely to appear.
What to verify: Every record in the inventory should have an owner, an installation point, an issuing authority, an expiry date, and a renewal path. If any of those fields are missing, the item is not yet operationally trustworthy, even if the certificate itself is valid today.
Practitioner takeaway: The goal is not to collect certificate metadata for reporting, it is to maintain a continuously trusted map of where certificate-based trust exists so expiry, drift, and shadow deployments can be handled before they become outages or exposure.
Related resources from NHI Mgmt Group
- How should security teams implement TLS across customer-facing and internal systems?
- How should security teams build a cryptographic inventory across cloud and CI/CD systems?
- How should security teams build and maintain an accurate API inventory across cloud and microservices environments?
- How should security teams implement SSL/TLS certificate lifecycle management across web servers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
