You Cannot Secure What You Cannot See: The Case for a Machine Identity Inventory

When a certificate expires on a load balancer at 2 AM and takes down authentication for a business-critical application, the incident response process almost always surfaces the same root cause: no one knew that certificate existed. Not because the team was careless, but because the certificate was issued two years earlier by a developer who left, deployed to infrastructure that was later modified, and never transferred to central management. It was invisible, and invisible identities cannot possibly be managed.

This is the foundational problem with machine identity in most enterprises today. Organizations have reasonably mature processes for managing human identities, including provisioning, access reviews, and deprovisioning workflows. But the equivalent discipline rarely exists for the credentials that authenticate servers, workloads, containers, and APIs to one another. Machine identities are cryptographic credentials, such as X.509 certificates, SSH key pairs, and API tokens, that enable non-human entities to authenticate and communicate securely without human intervention.

In most enterprises, they vastly outnumber human identities. According to a 2026 Cloud Security Alliance whitepaper on non-human identity governance, the average enterprise ratio sits near 45 non-human identities to every human identity, reaching 144 to 1 in cloud-native environments.

NIST SP 800-207, the Zero Trust Architecture standard, explicitly covers non-person entities (NPEs) alongside human users when defining identity as the primary trust signal. Under zero trust, every entity requesting access to a resource must present a verifiable identity, regardless of network location. That principle is difficult to apply in practice without an authoritative record of which machine identities exist, where they are deployed, who owns them, and when they expire.

A machine identity inventory is the prerequisite for everything else: certificate lifecycle management, cryptographic agility, zero trust enforcement, and post-quantum migration readiness. This blog explains why building that inventory is harder than it looks, what a complete inventory actually contains, and how to approach the problem systematically.

What Machine Identities Are and Why Are They Everywhere

Every server, workload, container, API, and automated process that communicates across a network needs a way to prove it is what it claims to be. That proof comes from machine identities: the cryptographic credentials that systems use to authenticate themselves to one another without any human intervention in the loop.

The most common form is the X.509 digital certificate. When a web server presents a TLS certificate, when a microservice authenticates to another service over mutual TLS (mTLS), when a CI/CD pipeline signs a software artifact before deployment, each of those is a machine identity in use. SSH key pairs serve the same function for privileged access to servers and network devices. Code signing certificates authenticate the origin and integrity of software packages and firmware. API tokens and service account credentials authenticate automated processes to cloud platforms, SaaS tools, and internal services.

What makes machine identities different from human identities is that they have no fallback. A human user who loses access to their account can call the help desk, verify identity through a secondary channel, and recover. A machine identity has a cryptographic lifecycle: it is issued with a fixed validity period, it must be renewed or replaced before expiration, and if it is compromised, the only remediation is revocation and reissuance. If the certificate expires, the service breaks. If the private key is stolen, the only question is how quickly someone can detect it and replace the credential.

The population of machine identities in most enterprises has grown faster than the tooling to manage it. A single Kubernetes cluster can generate and rotate hundreds of short-lived workload certificates per day through a service mesh. A DevOps pipeline issues code signing certificates for every build. Cloud infrastructure spins up and tears down workloads with certificates attached, often without those certificates ever appearing in any central CA’s issuance records.

The result is an environment where the number of active machine identities is unknown, the ownership of most of them is undocumented, and the tooling that manages human identity has no visibility into any of it. The same inventory gap extends to IoT and operational technology environments, where device certificates for industrial controllers, network equipment, and connected devices are often the least visible and most overlooked category of machine identity.

Understanding what machine identities are is only the beginning. The next challenge is discovering every identity across an environment where certificates and other credentials are created from many different sources.

Why the Inventory Problem Is Harder Than It Appears

Most organizations start with the Certificate Authority (CA) when trying to figure out where their certificates are. If a certificate was issued through a centralized enterprise CA, there is a record of it. That logic holds in a tightly controlled environment, but it breaks down quickly in practice.

Certificates in most enterprises can come from multiple sources: an internal Microsoft AD CS hierarchy for domain and device authentication, a public CA for external TLS, cloud-native CAs for workload certificates, developer-provisioned endpoints that bypass central issuance entirely, and self-signed certificates created directly by application teams or tools that never touched a managed CA at all. As a result, organizations rarely have complete visibility into all machine identities across their environments.

NIST SP 1800-16, the NCCoE practice guide on TLS server certificate management, identifies this directly. The guide describes scenarios where certificates are deployed to servers but never registered with any inventory system, where the absence of an expected certificate goes undetected, and where rapid replacement becomes operationally infeasible because no one has mapped where certificates are installed. These are not theoretical failure modes. They are the documented preconditions for the category of outages that NIST SP 1800-16 is designed to prevent.

Cloud and container environments make the problem structurally worse. Modern workload orchestration platforms issue short-lived certificates automatically, with lifetimes measured in hours or days rather than months. These certificates can complete their entire lifecycle before a quarterly audit ever detects them. The same pattern exists in service mesh environments, where mTLS certificates are issued and rotated automatically through workload identity systems.

Automated issuance is the correct operational model, but when it occurs outside the visibility of a CLM platform, it creates a blind spot. This lack of centralized visibility allows machine identities to continue operating across the environment without monitoring, governance, revocation, or lifecycle control.

What a Complete Machine Identity Inventory Actually Contains

A machine identity inventory is not a spreadsheet listing certificate common names and expiration dates. That is a starting point, but it is incomplete in ways that matter operationally. A complete inventory captures the identity itself, the infrastructure context around it, and the ownership information that makes lifecycle management actionable.

For each certificate-based identity, the inventory needs to record:

• Issuing CA and the full chain of trust
• Subject and Subject Alternative Names (SANs)
• Key algorithm and size (RSA-2048, ECDSA P-256, and so on)
• Validity period and expiration date
• Deployment location at time of discovery (server hostname or IP, port, application)
• Protocol context (TLS, mTLS, code signing, S/MIME, device authentication)
• Owning team or individual

The last field is often the hardest to populate and the most important. A certificate without a documented owner is an unmanaged certificate, and unmanaged certificates are the ones that expire unexpectedly or get overlooked during a forced replacement event.

NIST SP 800-130, the framework for designing cryptographic key management systems, establishes that any CKMS must account for all keying material in use, including metadata about each key’s state, purpose, and assigned roles. That requirement maps directly to what a certificate inventory needs to provide: not just the artifact, but the governance metadata that makes it manageable.

For SSH key pairs, API signing keys, and other non-certificate machine identities, the same principle applies. An SSH key deployed to a production server that grants privileged access to a service account represents a machine identity. If that key was generated three years ago, has never been rotated, and its corresponding private key is stored on a developer’s laptop, it is a material security exposure. You cannot remediate an exposure you cannot see.

This makes it clear that visibility challenges are not limited to certificates alone, but extend equally to other machine identity types across the environment.

Discovery Methods and Where Each One Falls Short

Building a complete inventory requires active discovery. Application teams can provide valuable context, but self-reported inventories are rarely comprehensive. The real challenge is combining discovery methods effectively while understanding what each one can and cannot see.

Network scanning is the most common starting point. A scanner reaches out to IP addresses and ports, initiates a TLS handshake, and records the certificate presented. This works well for externally reachable services and for internal network segments that are fully scanned. But it misses certificates that are only used for inbound client authentication (mTLS client certificates are not presented to a scanner initiating a connection), certificates on systems that are firewalled off from the scanner, and certificates embedded in application code or configuration files that are never negotiated over the network.

CA log analysis pulls the issuance records from every CA in scope. This catches every certificate that was issued through managed infrastructure, but will not find self-signed certificates or certificates issued by CAs that were not included in the scan scope. It also will not tell you where a certificate was deployed after issuance, only that it was issued.

Agent-based host scanning goes deeper. An agent deployed to a host can scan the local file system, key stores, Windows certificate stores, Java keystores (JKS and PKCS12), and application-specific directories to find certificates that are installed but may not be in active use on a network port. This method catches dormant certificates that present a different kind of risk: an attacker with access to the file system can use a certificate that a network scanner would never discover.

Directory and configuration file scanning complements host scanning for certificates distributed through Active Directory, LDAP, or infrastructure-as-code systems. Many certificates for endpoint authentication and smart card logon are deployed through Group Policy or configuration management tools and do not appear in traditional network scans at all.

Certificate Transparency log querying provides a fifth method that requires no network access and no agent deployment. Every publicly trusted TLS certificate has been logged to the public CT infrastructure since April 30, 2018, following Chrome’s enforcement of the CT policy for all newly issued certificates. Querying CT aggregators such as crt.sh against your organization’s registered domains and subdomains will surface certificates from public CAs that were never registered with your internal inventory, including developer-provisioned certificates, certificates obtained through cloud provider integrations, and any certificate issued for a domain your organization controls.

CT logs cover only publicly trusted certificates, not private PKI, and they reflect issuance rather than deployment location. For the external TLS surface, however, they provide near-complete passive coverage at no cost and with no dependency on internal infrastructure access.

No single method is sufficient. A complete discovery program uses multiple methods in combination and reconciles the results against CA issuance records to identify certificates that were issued but not found during scanning, which may indicate deployment to unmanaged or out-of-scope infrastructure. This limitation reinforces that discovery alone is not enough without a continuously maintained, reconciled source of truth.

The Inventory as the Foundation for What Comes Next

A machine identity inventory is not a one-time project. It is the operational foundation for every subsequent capability in certificate lifecycle management. Automated renewal requires knowing which certificates exist and where they are deployed. The ACME protocol (RFC 8555) is the de facto standard mechanism for that automation, enabling certificates to be requested, validated, and renewed programmatically without human intervention. Revocation in response to a CA compromise or key exposure requires knowing every deployment location so nothing is missed.

Cryptographic agility is the ability of a system to transition between cryptographic algorithms, key types, or parameters as security requirements, standards, or threats evolve. The post-quantum migration problem makes this especially concrete. Organizations will eventually need to replace RSA and ECDSA certificates with quantum-resistant alternatives. NIST finalized three post-quantum standards in August 2024: ML-DSA (FIPS 204) for digital signatures, ML-KEM (FIPS 203) for key encapsulation, and SLH-DSA (FIPS 205) for hash-based signatures. The success of that transition depends entirely on the quality of the inventory.

An incomplete inventory leads to an incomplete migration, leaving quantum-vulnerable certificates in production long after the organization believes the transition is complete. For organizations subject to NSA’s CNSA 2.0, network equipment such as VPNs and routers must exclusively use quantum-resistant algorithms by 2030, making inventory completeness a hard deadline, not a best practice.

Under CA/Browser Forum Ballot SC-081v3, publicly trusted TLS certificate validity is being reduced in three phases: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. These reductions apply only to certificates issued by publicly trusted CAs within browser and operating system trust stores; certificates issued by private or internal PKI hierarchies are not affected by these baseline requirements.

At each phase, the operational overhead of manual renewal increases sharply. By the 47-day mark, automation is not optional. But automation cannot function without an inventory: a renewal agent needs to know which certificates exist, where they are deployed, and which CA to request the renewal from. An organization that has not built a complete inventory before that pressure arrives will face each phase without the foundation to handle it.

This is where structured assessment and lifecycle platforms become essential, bridging the gap between visibility, governance, and operational control to ensure inventory accuracy translates into sustained cryptographic resilience.

How Encryption Consulting Can Help

Encryption Consulting’s PKI Assessment is a structured engagement that evaluates your entire PKI environment across technical, operational, and governance dimensions. It begins with discovery: mapping your current PKI architecture across on-premises, cloud, and hybrid environments to establish a complete picture of what exists, how it is configured, and where it connects.

This includes CA hierarchy validation, certificate template review, key management practices, and an end-to-end test of your revocation infrastructure, verifying that CDP and AIA extensions resolve to responders that are reachable from the network segments where certificates are validated.

From there, structured stakeholder workshops and architecture mapping sessions capture the operational reality behind the configuration. These sessions surface the gaps that documentation alone does not show: PKI infrastructure policies that exist on paper but are not enforced, OCSP responders that are technically deployed but untested under load, and certificate populations issued under templates that no longer reflect current security standards.

The output is a prioritized risk and gap analysis report. Findings are ranked by severity and mapped to specific remediation actions, delivering a clear roadmap rather than a generic checklist.

CertSecure Manager

CertSecure Manager provides the operational layer that ties expiry tracking and revocation together on an ongoing basis. It maintains a live certificate inventory across public CAs, private CA hierarchies, and Microsoft PKI environments. Some of the key features of CertSecure Manager include:

• Centralized Certificate Inventory: Automatically discovers and inventories certificates across cloud, on-prem, and hybrid environments.
• Automated Lifecycle Management: Handles issuance, renewal, and revocation of certificates with minimal human intervention.
• Policy Enforcement Engine: Ensures compliance with enterprise security policies and industry standards.
• Role-Based Access Control (RBAC): Provides granular access management to ensure only authorized users can manage certificates.
• Integration With Leading CAs and DevOps Tools: Seamlessly integrates with public and private Certificate Authorities, as well as CI/CD pipelines.
• Standards-Based Automation Protocols: Supports ACME (RFC 8555), SCEP, and EST for automated certificate issuance and renewal, the protocols required to operate at 47-day SC-081v3 cadence.
• Real-Time Monitoring and Alerts: Offers dashboards and alerts for expiring or misconfigured certificates.
• Audit and Reporting: Maintains detailed logs and reports for compliance and forensic analysis.

For organizations that need visibility beyond the certificate layer, CBOM Secure continuously discovers and tracks certificates, keys, algorithms, and cryptographic dependencies across enterprise infrastructure, cloud environments, and applications.

Where CertSecure Manager manages the certificate lifecycle, CBOM Secure governs the cryptographic posture beneath it, identifying quantum-vulnerable algorithms and providing the asset-level visibility that post-quantum migration planning requires.

Together, these capabilities give security and PKI teams the visibility and control to manage certificate expiry and revocation not as reactive tasks, but as a continuous, auditable process.

Conclusion

The organizations that manage machine identity well do not think of inventory as an audit exercise. They treat it as live operational infrastructure: continuously updated, tied to ownership records, and feeding directly into automated lifecycle management. Getting to that state requires an initial investment in discovery, a process for resolving ownership gaps, and tooling that keeps the inventory current as new certificates are issued and old ones are retired.

The cost of not doing this is measured in outages, in failed emergency replacements when a CA is compromised, and in quantum-vulnerable certificates that survive longer than they should because no one knew they existed. You cannot revoke what you have not found. You cannot automate the renewal of a certificate that is not in your inventory. You cannot migrate away from an algorithm that your discovery process never surfaced. The inventory is where all of it starts.