A certificate is a public document. It is meant to be handed to anyone who connects, and discovering it carries no risk, because the certificate reveals nothing that was not already published to every client. A key is the opposite. The private half of a key pair is the actual secret, the thing whose disclosure undoes every protection built on top of it, and any inventory process that reads private keys to catalog them has turned the inventory itself into the largest concentration of risk in the estate. This is the first principle of key discovery and the one most often ignored: you inventory keys by describing them, never by exporting them.
That constraint is not a limitation to work around. It is the correct design. A private key should live exactly where it was generated and should leave that place only under the narrowest possible circumstances, if ever. An inventory that respects this does its work entirely through metadata: fingerprints, algorithm and parameters, references from the objects that use the key, and the properties of the store that holds it. The private key material stays put. What the platform collects is everything about the key except the one thing that must never move.
This post explains how key discovery works under that constraint, how keys are classified by origin and custody, how they are correlated to the certificates and operations that depend on them, and why key reuse detection is among the most valuable findings a key inventory produces.
The Certificate Visibility Gap
Typical enterprise: what's tracked vs. what actually exists
Tracking Coverage
Certificates Found by Source
⚠️ In the average mid-market enterprise, less than 15% of certificates have both ownership documentation and expiry monitoring.
Why Keys Are Harder and More Sensitive Than Certificates
Certificate discovery is forgiving. The object you want is served openly, carries structured attributes that describe itself, and can be collected at scale without touching anything secret. Key discovery is forgiving in none of those ways. The object you care about is deliberately hidden, is often protected by hardware that is designed specifically to prevent its extraction, and describes itself only partially if at all. A key sitting in a file does not announce its role, its origin, or whether it is also sitting in nine other files across the estate. The sensitivity is inverted too: finding a certificate is safe, while mishandling a key during discovery can leak the very secret the key exists to protect.
The consequence is that key discovery has to be built around a hard rule that private key material is never exported, never copied, and never centralized. A platform collects the public key, the key’s fingerprint, its algorithm and parameters, and metadata about where and how it is stored. It does not read the private key out of an HSM, it does not pull a private key out of a keystore into a central database, and it does not treat the private half as something to be gathered. The inventory is a map of where keys are and what they are, not a vault that holds them. A platform that cannot inventory keys without exporting them has misunderstood the problem and created a new one larger than the one it set out to solve.
Inventorying Keys as Metadata
What a safe key inventory actually records is a set of properties that identify and describe each key without reproducing it. The public key and the fingerprint together give the key a stable identity that can be matched across the estate without the private half. The algorithm and parameters, the key length, the curve, the padding mode where relevant, describe the key’s cryptographic character and feed quantum-risk and policy evaluation. The references, which certificates present this public key, which configurations point at this key file, which operations invoke this key, describe what the key does. And the custody metadata describes where it lives and under what protection.
| Key Metadata | What It Captures |
|---|---|
| Public key and fingerprint | A stable identity for matching without the private half |
| Algorithm and parameters | Key length, curve, padding, and the key’s cryptographic character |
| Origin | How the key was generated and where it came from |
| Custody location | The store that holds the private material and its protection model |
| References | The certificates, configurations, and operations that depend on the key |
| Observed scope | The services, environments, and tenants where the key appears |
None of these requires reading the private key. All of them are derivable from public material, from the objects that reference the key, and from the properties of the store. This is what makes a key inventory both safe and useful at once: it answers every operational question about a key, which keys are weak, which are quantum-vulnerable, which are shared, which lack an owner, without ever holding the secret that would make the inventory itself a target.
Classifying Key Origin
Where a key came from tells you a great deal about how much you can trust it and how it should be governed. Origin classification sorts keys by how and where they were generated, and the categories differ sharply in their security properties.
A key generated inside a hardware security module and never exported is the strongest case: the private material was created in hardware designed to keep it there, and there is good reason to believe it has never existed anywhere else. A key generated by a cloud key-management service sits in a similar category, with the protection model defined by the provider rather than by on-premises hardware. A software-generated key is weaker by default, because it was created in general-purpose memory where it could have been observed, copied, or persisted insecurely before it reached its resting place. An imported key is weaker still in a specific way: the fact that it could be imported means it existed outside its current store at some point, which raises the question of where else it may still exist. And an unknown-origin key is the one that most deserves investigation, because a key whose provenance cannot be established cannot be trusted and may be the visible end of a process no one controls.
Origin is not always stated, and where it must be inferred the inference should carry a confidence level rather than be asserted as fact. A key found in an HSM with no export capability can be classified high-confidence as HSM-generated. A key found in a file could have come from anywhere, and the honest classification is unknown until a reference or a generation record establishes otherwise.
Classifying Custody Location
Custody is the other half of the picture: not where the key came from, but where it lives now and what is protecting it. Custody location is what determines the real-world difficulty of compromising the key, and it spans a wide range of stores with very different protection models.
| Custody Location | Protection Characteristics |
|---|---|
| HSM | Hardware-enforced, designed to prevent private-key extraction |
| Cloud KMS | Provider-managed, protection defined by the service’s model |
| Java keystore | Software store, protection depends on configuration and access control |
| PKCS#12 | Portable bundle of key and certificate, protected by a passphrase |
| PEM file | Plain file on disk, protection depends entirely on file-system controls |
| Kubernetes secret | Cluster-managed, base64-encoded, protection depends on cluster hardening |
| Database | Stored as data, protection depends on the data store’s access model |
| Configuration repository | Key material in config, often the weakest and most exposed custody |
The range is the point. A key in an HSM and the identical key material sitting in a PEM file in a configuration repository are, cryptographically, the same key, but their custody could not be more different, and the second is an incident waiting to be discovered. Custody classification is what lets a platform rank keys by how exposed they actually are, rather than treating every key as equally protected because they share an algorithm. The weakest-custody rows, keys in config repositories and plain files, are where the most urgent findings tend to concentrate.
Custody coverage is expanding across the category as more stores become discoverable. Keys held in platform TPMs, on smart cards, and inside secure enclaves are where custody mapping is heading: these are hardware-backed stores whose metadata is harder to reach and enumerate consistently, and broad coverage of them is emerging rather than something to claim as finished. The honest position is that mainstream software and hardware stores are well-covered today, and the long tail of embedded and device-bound custody is an area of active expansion.
Correlating Keys to Certificates and Operations
A key on its own is an orphan fact. Its meaning comes from what depends on it, and correlation is the capability of connecting each key to the certificates that present its public half and the operations that invoke it. A key pair whose public key appears in a certificate is tied to that certificate’s role, exposure, and expiry; if the certificate secures an internet-facing service, the key inherits that exposure. A key referenced by a signing operation is tied to whatever that operation protects. These correlations are what turn a key inventory into something that supports blast-radius reasoning, because the impact of a key’s compromise is the sum of everything that depends on it.
Correlation also disciplines the inventory. A key with no discoverable references is either genuinely unused, in which case it is a candidate for decommissioning, or it is used in a way the discovery did not reach, in which case it is a gap to investigate. Either way, surfacing the unreferenced keys is more useful than hiding them, because an unreferenced key is either dead weight or a blind spot, and both are worth knowing about.
Detecting Key Reuse
The single most valuable finding a key inventory produces is key reuse: the same private key material appearing in more than one place it should not. Because the inventory identifies keys by fingerprint without needing the private half, it can detect that the identical key is present across services that should each have their own, across environments that should be isolated, or across tenants that must never share cryptographic material. Each of these is dangerous in its own way.
Reuse across services means a single key compromise takes down every service that shares the key, turning what should be an isolated incident into a sprawling one. Reuse across environments, the same key in development and production, means a leak from the lower-security environment compromises the higher-security one. Reuse across tenants is the most serious of all, because it breaks the cryptographic isolation that multi-tenant systems depend on, and a single shared key can collapse the boundary between customers who were promised separation. These findings are often invisible to the teams involved, because each team sees only its own use of the key and no one sees the overlap. A fingerprint-based inventory sees all of it at once, which is precisely why reuse detection is worth building the rest of the inventory to support.
FAQ
Q: Why should a key inventory never export private keys? Because the private key is the secret itself, and any process that reads and centralizes private keys becomes the largest concentration of risk in the estate. A key should stay where it was generated; the inventory describes it through public material, fingerprints, references, and custody metadata. A platform that must export keys to catalog them has created a bigger problem than the one it set out to solve.
Q: How can you inventory a key without reading its private half? Everything an inventory needs is derivable without the private key: the public key and fingerprint give a stable identity for matching, the algorithm and parameters describe its cryptographic character, the references describe what depends on it, and the store’s properties describe its custody. The private material stays put while the metadata answers every operational question.
Q: What makes key origin classification useful? Origin tells you how much to trust a key. An HSM-generated key that never left hardware is strong; an imported key existed outside its store at some point and may still; an unknown-origin key cannot be trusted until its provenance is established. Where origin is inferred rather than stated, it should carry a confidence level instead of being asserted as fact.
Q: Why is key reuse such a dangerous finding? Because it converts isolated incidents into sprawling ones. The same key across multiple services means one compromise takes them all down; across environments, a leak from development compromises production; across tenants, it breaks the isolation multi-tenant systems depend on. Each team usually sees only its own use, so the overlap is invisible to everyone except an inventory that matches keys by fingerprint across the whole estate.
Q: Does key discovery cover hardware stores like TPMs and smart cards? Mainstream software and hardware stores, HSMs, cloud KMS, keystores, PKCS#12, PEM files, Kubernetes secrets, are well-covered today. Device-bound custody in TPMs, smart cards, and secure enclaves is harder to enumerate consistently, and broad coverage of it is emerging rather than finished. The honest position is that the common stores are mapped now and the embedded long tail is an area of active expansion.
About QCecuring
QCecuring discovers keys as metadata, by fingerprint, algorithm, references, and custody, and never exports private key material. It classifies each key’s origin and custody location, correlates keys to the certificates and operations that depend on them, and detects key reuse across services, environments, and tenants, surfacing the shared and ownerless keys that are invisible to the teams using them.
See what a key inventory reveals without ever touching a private key
Tags: CBOM, Key Management, Key Discovery, Custody Mapping, HSM, Cloud KMS, Key Reuse, Private Key Security, Cryptographic Inventory, PKCS12, Crypto Governance, Enterprise Security