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.

Quick Answer: What Is a Machine Identity Inventory?

A machine identity inventory is a continuously maintained, authoritative record of every X.509 certificate, SSH key pair, API token, code-signing certificate, and service account credential in an enterprise environment, each mapped to its deployment location, issuing CA, key algorithm, expiry date, and owning team. It is the prerequisite for certificate lifecycle management, zero trust enforcement, and post-quantum migration. Without it, automated renewal, cryptographic agility, and forced CA replacement all fail.

Key Takeaways

• Machine identities vastly outnumber human identities in modern enterprises. A 2026 Cloud Security Alliance whitepaper found the average enterprise ratio is approximately 45 non-human to 1 human identity, reaching 144 to 1 in cloud-native environments. The population grows continuously through cloud-native CA issuance, service mesh workload identity, CI/CD pipeline signing, and IoT device enrollment, mostly outside the visibility of traditional CLM platforms.
• The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. The root cause in most cases is a certificate that was not in any monitored inventory: issued years earlier, deployed to infrastructure that changed hands, never transferred to central management, and invisible until it expired and took down authentication for a business-critical service.
• No single discovery method sees the full estate. Certificate Transparency logs cover only publicly trusted certificates and miss all private PKI. HSMs protect keys but do not catalog certificates or their deployment endpoints. CA databases show issuance but not where certificates were deployed after issuance. A complete machine identity inventory requires drawing from five discovery methods simultaneously: network scanning, CA log analysis, agent-based host scanning, directory and configuration file scanning, and CT log querying.
• CA/Browser Forum SC-081v3 collapses public TLS certificate validity to 200 days (March 15, 2026), 100 days (March 15, 2027), and 47 days (March 15, 2029). At 47-day validity, automated renewal via ACME (RFC 8555) is not optional. But ACME automation cannot function without a complete inventory: the renewal agent needs to know which certificates exist, where they are deployed, and which CA to request the renewal from. The inventory is the prerequisite for the automation.
• The post-quantum migration required by NIST FIPS 203, 204, and 205 (finalized August 13, 2024) cannot succeed without a complete inventory. Organizations will need to replace RSA and elliptic-curve credentials across the full estate. An incomplete inventory means the migration leaves quantum-vulnerable certificates in production long after the organization believes the transition is complete. For post-quantum migration planning and algorithm classification guidance, track current requirements through the PQC Center of Excellence.

Who Should Care About Machine Identity Inventory

Machine identity inventory is not a PKI team problem alone. Every team that deploys, governs, or audits machine credentials has a role in building and maintaining the inventory. The teams below own distinct parts of the problem, and gaps in any one area create blind spots in the overall estate.

Role	Why It Matters	Action Item
PKI and Certificate Teams	Own the core inventory: establishing and maintaining the authoritative record of all certificate-based machine identities, their issuing CAs, and their deployment locations; responsible for integrating all CA sources (internal ADCS, public CAs, cloud CAs) into the CLM platform; the 47-day SC-081v3 validity reduction makes the inventory the operational foundation for automated renewal via ACME (RFC 8555), and a certificate not in the inventory cannot be renewed automatically	Run discovery across all five methods (network scanning, CA log analysis, agent-based host scanning, directory/config scanning, CT log querying); reconcile scan results against CA issuance records to identify certificates issued but not found during discovery; add all inventoried certificates to CertSecure Manager with renewal alerts and ownership metadata; integrate CBOM Secure for cross-environment discovery including cloud-native and private PKI populations
Security Architects	Own the inventory architecture: defining what the inventory must contain per NIST SP 800-130 CKMS requirements, designing the discovery methodology across all identity types (certificates, SSH keys, API tokens, service account credentials), and mapping the inventory to zero trust enforcement controls per NIST SP 800-207; the inventory is the foundation for cryptographic agility and the post-quantum migration roadmap required by NIST FIPS 203/204/205 (August 13, 2024)	Define the inventory data model including all required fields (issuing CA, SANs, key algorithm and size, validity, deployment location, protocol context, owning team); design the algorithm classification scheme mapping each discovered identity to its NIST post-quantum deprecation status; conduct a PQC readiness assessment through PQC Readiness services to classify all inventoried identities by quantum-vulnerability exposure; track algorithm deprecation milestones through the PQC Center of Excellence
Platform and DevOps Teams	Own cloud and container identity coverage: certificates issued by cloud-native CAs (AWS ACM, GCP CA Service, Azure Key Vault) and workload identity systems (SPIFFE/SPIRE, Istio) often never appear in the enterprise CA database; a Kubernetes cluster can generate and rotate hundreds of short-lived workload certificates per day, each completing its lifecycle before a quarterly audit detects it; DevOps pipelines issue code-signing certificates for every build that may bypass all central inventory systems	Confirm that all cloud-native CA certificate populations are routed through or at minimum discovered by the central CLM platform; add certificate expiry monitoring to platform observability alerting; integrate CI/CD pipeline certificate issuance into the inventory; ensure that workload identity certificates from service mesh deployments appear in CBOM discovery; add certificate rotation testing to pre-production validation before each new deployment pattern
Compliance Teams	Must demonstrate that the machine identity inventory meets NIST SP 800-130 CKMS requirements (all keying material inventoried with state, purpose, and assigned roles), NIST SP 800-207 NPE identity governance requirements, and regulatory requirements specific to the sector (PCI DSS 4.0 Requirement 4 for TLS, HIPAA for PHI systems, NERC CIP for operational technology); for organizations subject to NSA CNSA 2.0, inventory completeness is a hard deadline requirement for post-quantum migration by 2030	Include machine identity inventory completeness in the quarterly compliance evidence package; confirm that all discovered identities have documented owners; verify that algorithm classification against NIST post-quantum standards is current; map CA/B Forum SC-081v3 phase dates (200-day March 2026, 100-day March 2027, 47-day March 2029) to internal compliance milestones; document the post-quantum migration roadmap with named owners and dated milestones for each asset class
CISOs	Machine identities outnumber human identities by 45 to 1 on average and by 144 to 1 in cloud-native environments (CSA, 2026), yet most enterprises have no governed program for discovering, inventorying, and managing them; a certificate that expires on a load balancer at 2 AM and takes down a business-critical service is a board-level incident that a complete inventory and automated renewal would have prevented; post-quantum migration and the CA/B Forum 47-day mandate both require the inventory to already exist before their deadlines arrive	Fund machine identity inventory as a continuously maintained program with C-level accountability, not a one-time audit exercise; require that all new system deployments include machine identity governance as a prerequisite before go-live; evaluate PKI as a Service for organizations that need a governed, multi-CA issuance capability without building and operating the infrastructure internally; mandate quarterly inventory reconciliation as a board-level KPI alongside vulnerability count and patch coverage

Machine Identity Inventory Checklist: Issue, Business Impact, Recommended Action, and Owner

Use this checklist to identify which inventory gaps apply to your environment, understand the business impact of each gap, and assign remediation ownership before an undetected expiry or forced migration event exposes the gap under pressure.

Issue	Business Impact	Recommended Action	Owner
No machine identity discovery program across all five discovery methods	The certificate estate is partially visible at best; certificates from self-signed, cloud-native, and developer-provisioned sources are invisible; expired certificates from undiscovered sources produce service outages with no advance warning	Run discovery across all five methods: network scanning (active listeners), CA log analysis (managed issuers), agent-based host scanning (file systems and key stores), directory and configuration file scanning (Group Policy, LDAP, infrastructure-as-code), and CT log querying (publicly trusted TLS); reconcile results against CA issuance records to identify certificates issued but not found during scanning	PKI Team
No ownership metadata for discovered machine identities	A certificate without a documented owner is an unmanaged certificate; unmanaged certificates expire unexpectedly, are overlooked during forced replacement events (CA distrust, post-quantum migration), and have no renewal escalation path when automated renewal fails	Require ownership assignment for every machine identity entered into the inventory; establish an ownership resolution process for discovered certificates with no documented owner; include ownership completeness as a quarterly compliance metric	PKI Team + Compliance Team
Cloud-native CA and workload identity certificates not in the central inventory	Cloud workload certificates completing their full lifecycle outside the CLM platform are invisible to renewal monitoring, revocation workflows, and post-quantum algorithm classification; a service mesh rotating mTLS certificates hourly outside CLM visibility creates a governance blind spot for every mTLS-authenticated service	Integrate cloud-native CA sources (AWS ACM, GCP CA Service, Azure Key Vault) into the CLM discovery pipeline; configure CBOM Secure to discover workload identity certificates from SPIFFE/SPIRE and service mesh environments; add cloud certificate expiry monitoring to platform observability dashboards	Platform Team + PKI Team
Certificate Transparency logs treated as the complete inventory for public TLS	CT logs reflect issuance, not deployment; a CT log entry confirms a certificate was issued but does not show where it was deployed, on how many systems, or whether it is still in active use; CT logs also miss private PKI entirely	Use CT log querying as one of five discovery methods, not as a standalone inventory; reconcile CT log findings against network scan results to identify deployment locations for each publicly issued certificate; use CA APIs for issued-but-unscanned reconciliation	PKI Team
SSH key pairs and API tokens not included in the machine identity inventory	SSH key pairs granting privileged access that were generated years ago, never rotated, and stored on developer laptops represent persistent access for credentials that should have been retired; API tokens for automated cloud service access are machine identities with no expiry visibility in certificate-only inventory tools	Extend the machine identity inventory beyond X.509 certificates to include SSH key pairs (with age, rotation status, and authorized users) and API tokens (with last-rotation date, usage logs, and owning service); include rotation policy enforcement for both types in the quarterly compliance review	Security Architect + PKI Team
No algorithm classification against post-quantum deprecation milestones	NIST FIPS 203/204/205 (August 13, 2024) require replacing RSA and elliptic-curve credentials; CNSA 2.0 requires NSS-adjacent systems to use quantum-resistant algorithms by 2030; an inventory without algorithm classification cannot prioritize the post-quantum migration or identify which credentials are most urgently exposed	Add algorithm classification to every inventoried machine identity (RSA-2048, ECDSA P-256, etc.) and map each to its NIST post-quantum deprecation status; prioritize long-lived credentials and those protecting data with long confidentiality horizons; conduct a structured PQC readiness assessment through PQC Readiness services	Security Architect + Compliance Team
Inventory not reconciled against CA issuance records	Certificates that appear in CA issuance records but are not found during discovery may be deployed to unmanaged or out-of-scope infrastructure; this is the highest-risk category because it represents active credentials that cannot be monitored, renewed, or revoked through any central process	Compare scan results against CA issuance logs after each discovery cycle; escalate all certificates found in CA issuance records but not confirmed as deployed to a known system to the owning team for investigation; treat unresolved issued-but-unscanned certificates as unmanaged credentials	PKI Team
No quarterly renewal and ownership review cadence	The machine identity estate changes continuously as new certificates are issued and deployed; a discovery scan from six months ago does not reflect the current estate; without a quarterly review, the inventory drifts from reality and the benefits of the initial discovery investment decay	Schedule quarterly discovery runs across all five methods; reconcile results against the prior quarter’s inventory to identify new, changed, and expired identities; confirm ownership assignments are current; review algorithm classification for newly discovered identities; include quarterly inventory completeness metrics in the CLM platform dashboard	PKI Team + Compliance Team

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. The table below maps each discovery method to what it surfaces, what it misses, and the best scenario for applying it.

Discovery Method	What It Surfaces	What It Misses	Best Applied To
Network scanning	Certificates presented on active TLS listeners: IP address, port, certificate details, and full chain	mTLS client certificates (not presented to an initiating scanner); certificates on firewalled or out-of-scope segments; embedded certificates in application code or config files not negotiated over the network; dormant certificates installed but not currently listening	External-facing TLS surface and internal network segments with full scanner access; best first pass for finding the visible TLS estate
CA log analysis	Every certificate issued through a CA that is in scope for the query: issuer, subject, SANs, validity, serial number	Self-signed certificates (never issued by a managed CA); certificates from CA sources not included in the query scope; deployment location after issuance (CA log shows issuance, not where the certificate was deployed)	Reconciling what was issued against what was found in scans; identifying certificates issued but not found during network scanning (possible deployment to unmanaged infrastructure)
Agent-based host scanning	Certificates installed on the local file system, Windows certificate stores, Java keystores (JKS and PKCS12), and application-specific directories, including dormant certificates not in active network use	Certificates on hosts where the agent is not deployed; certificates in cloud-native workloads and containers with ephemeral storage; certificates that exist only at runtime and are never written to disk	Comprehensive discovery of dormant and installed-but-not-listening certificates; Windows environments with local certificate stores; Java application servers with JKS/PKCS12 keystores
Directory and configuration file scanning	Certificates distributed through Active Directory, LDAP, Group Policy, or infrastructure-as-code systems; certificates for endpoint authentication and smart card logon deployed through configuration management tools	Certificates distributed through channels not included in the directory query scope; certificates in non-standard configuration locations outside the scanner’s path definitions	Domain-joined Windows environments where Group Policy distributes certificates; infrastructure-as-code pipelines where certificates are embedded in Terraform or Ansible configurations
Certificate Transparency log querying	Every publicly trusted TLS certificate logged since Chrome’s CT enforcement (April 30, 2018) for domains and subdomains in scope; covers certificates from any public CA, including developer-provisioned and cloud-provider-issued certificates	All private PKI certificates (never logged to CT); deployment location (CT log shows issuance, not where the certificate is deployed or whether it is still active); certificates issued before April 30, 2018	Discovering shadow IT and developer-provisioned public TLS certificates that were never registered with the enterprise inventory; passive external surface coverage at no cost with no internal infrastructure dependency

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. Assess the current quantum-vulnerability exposure of the machine identity estate through PQC Readiness services.

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.

Frequently Asked Questions

What is the main takeaway from You Cannot Secure What You Cannot See: The Case for a Machine Identity Inventory?

A machine identity inventory is the operational prerequisite for everything that follows: certificate lifecycle management, automated renewal, cryptographic agility, zero trust enforcement, and post-quantum migration. Without a continuously maintained, authoritative record of every X.509 certificate, SSH key pair, API token, and code-signing credential, mapped to its deployment location, issuing CA, key algorithm, expiry date, and owning team, none of the downstream capabilities can function reliably. The inventory is where all of it starts.

Why does machine identity inventory matter for enterprise PKI teams?

Enterprise PKI teams are responsible for the certificate estate, but machine identities now vastly outnumber human identities and originate from sources PKI teams often do not control: cloud-native CAs, developer-provisioned endpoints, service mesh workload identity systems, and self-signed certificates. A 2026 CSA whitepaper found the average enterprise ratio is approximately 45 non-human to 1 human identity. The DigiCert Trust Pulse Survey (July 2025) found 45 percent of enterprises experienced certificate-related downtime in the prior year. Under CA/B Forum SC-081v3, public TLS validity collapses to 47 days by March 15, 2029, making automated renewal mandatory; automation cannot function without a complete inventory.

What risks increase if machine identity inventory is handled manually?

Four risk categories increase: undetected expiry (certificates not in any monitored inventory expire without renewal alerts, causing authentication failures with no advance warning); incomplete migration during CA distrust or algorithm deprecation events (an organization without a complete inventory cannot find and replace every affected certificate before a deadline); unmanaged key sprawl (SSH key pairs and API tokens accumulate without rotation or revocation); and failed post-quantum migration (NIST FIPS 203/204/205 require replacing RSA and elliptic-curve credentials; an incomplete inventory means the migration leaves quantum-vulnerable certificates in production long after the organization believes the transition is complete).

Which teams should own machine identity inventory governance?

PKI and certificate teams own the core inventory: establishing the authoritative record of all certificate-based machine identities, running discovery across all five methods, and integrating all CA sources into the CLM platform. Security architects own the inventory architecture: defining data model requirements per NIST SP 800-130 CKMS, designing the discovery methodology across all identity types, and mapping the inventory to the post-quantum migration roadmap. Platform and DevOps teams own cloud and container identity coverage. Compliance teams own regulatory evidence. CISOs own the governance mandate that machine identity inventory is a funded, continuously maintained program.

How does machine identity inventory connect to certificate lifecycle management?

The machine identity inventory is the input to every CLM operation. Automated renewal via ACME (RFC 8555) requires knowing which certificates exist, where they are deployed, and which CA to request the renewal from; a certificate not in the inventory cannot be renewed automatically. Revocation in response to CA compromise requires knowing every deployment location. CertSecure Manager provides the CLM layer that operates on the inventory: discovery, monitoring, automated renewal via ACME, SCEP, and EST, policy enforcement, and audit reporting, sized for the 47-day SC-081v3 cadence.

How should organizations measure success in machine identity inventory management?

Key metrics: inventory coverage (100 percent of production systems covered by at least one discovery method with results reconciled against CA issuance records); ownership assignment rate (all discovered machine identities have a documented owner); zero unmonitored expiry events (no certificate expiry produces a service outage without a prior renewal alert); discovery reconciliation completeness (CA issuance records compared against scan results to identify certificates issued but not found during discovery); and post-quantum readiness coverage (all machine identities classified by algorithm exposure against NIST IR 8547 deprecation milestones).

What should be audited or monitored regularly for machine identity inventory?

Monitor continuously: certificate expiry across all inventoried identities with renewal alerts at 30 percent of remaining validity; SSH key pair age and rotation status; API token usage and last-rotation date; and new certificate issuance events from CA APIs and CT log feeds. Audit quarterly: run discovery across all five methods and reconcile against the current inventory and CA issuance records; review ownership assignments; verify cloud-native CA and workload identity certificates appear in the central inventory; and confirm algorithm classification is current for all newly discovered identities.

How does machine identity inventory affect cloud, hybrid, or multi-CA PKI environments?

Cloud and hybrid environments are where the inventory problem is structurally hardest. Cloud-native CAs issue certificates automatically with lifetimes measured in hours or days, completing their entire lifecycle before a quarterly audit detects them. Service mesh environments rotate mTLS certificates outside CLM platform visibility. In multi-CA environments, each CA source must be independently discovered and reconciled. CBOM Secure provides the cross-environment machine identity discovery that integrates CT log feeds, network scanning, CA APIs, and agent-based discovery into a single continuously updated inventory across cloud, on-premises, and hybrid infrastructure.

What common mistakes should teams avoid when building a machine identity inventory?

The most frequent mistakes: treating the CA database as the complete inventory (self-signed, cloud-native, and developer-provisioned certificates never appear in enterprise CA issuance records); treating CT logs as a master inventory (CT covers only publicly trusted certificates and reflects issuance not deployment; private PKI is invisible); treating the inventory as a one-time project rather than continuously maintained operational infrastructure; not capturing ownership metadata for each machine identity; and discovering certificates without reconciling against CA issuance records (certificates issued but not found during scanning may be deployed to unmanaged infrastructure, which is the highest-risk category).

What should be refreshed quarterly for machine identity inventory governance?

Quarterly: run discovery across all five methods and reconcile against the prior quarter’s inventory; review and update ownership assignments; audit SSH key pair age and confirm rotation; review API token usage and revoke tokens not used within the policy period; confirm cloud-native CA and service mesh certificate populations are in the central inventory; classify newly discovered identities by algorithm exposure against NIST post-quantum deprecation milestones (FIPS 203/204/205, finalized August 13, 2024, with RSA and ECC deprecated for federal systems after 2030 per NIST IR 8547); and update the post-quantum migration roadmap to reflect newly discovered quantum-vulnerable credentials. For post-quantum migration planning guidance, check the PQC Center of Excellence.