Cryptographic Discovery: A Complete Guide to Finding Hidden Crypto Across Your Enterprise

Quick answer: Cryptographic discovery is the automated process of finding every key, certificate, algorithm, and protocol in an environment, across cloud, hardware, databases, directories, filesystems, and source code. CBOM Secure automates it end-to-end, from PKCS#11 object enumeration on HSMs to deep Active Directory analysis, producing a single deduplicated, risk-scored Cryptography Bill of Materials. 

Key takeaways 

• Discovery succeeds or fails at the edges: the Hardware Security Module (HSM) slot nobody audits, the krbtgt record in AD, the PEM block inside a YAML file. 
• CBOM Secure covers the surfaces that certificate tools never reach: KMIP servers, database TDE views, LDAP attributes, GPG keyrings, and application source code. 
• Standards-based protocol support means one platform covers entire vendor ecosystems: PKCS#11 v2.x for HSMs, KMIP 1.0 through 2.1 for key managers, RFC 4523 for LDAP directories. 
• The same key showing up in a cloud vault, an HSM, and a file share is caught automatically, so key reuse becomes a finding instead of staying invisible. 
• Private key material is never read or moved; the platform records metadata and existence entries only. 
• Discovery output doubles as compliance evidence: PCI DSS 4.0’s cryptographic inventory requirement, NIST algorithm guidance, and CNSA 2.0 quantum-readiness tracking all draw from the same continuously updated CBOM. 

What is cryptographic discovery? 

Cryptographic discovery is the automated identification and cataloging of cryptographic assets across an IT environment. A complete discovery process inventories keys with their algorithms and storage locations, certificates with their chains and expiry, the protocol versions and cipher suites in active negotiation, and the cryptographic calls inside application code. It is the prerequisite for compliance evidence, incident response, and post-quantum migration, because none of those are possible for assets you cannot see.

Discovery has moved up the priority list recently for three reasons. NIST finalized its first post-quantum standards (FIPS 203, 204, and 205) in August 2024, and the NSA’s CNSA 2.0 guidance expects full quantum-safe adoption by 2030, so every organization now needs to know exactly where its quantum-vulnerable cryptography lives. PCI DSS 4.0 made a documented inventory of cryptographic cipher suites and protocols an explicit requirement, enforceable since March 31, 2025. Harvest-now, decrypt-later attacks mean long-lived sensitive data is already at risk today, not at some future quantum date.

The hard part is coverage. An inventory that captures 80 percent of your cryptography is not 80 percent useful, because audits, breaches, and migrations are decided by the assets in the remaining 20 percent. This guide walks through where cryptography actually hides and how CBOM Secure reaches each hiding place.

What should a cryptographic discovery tool cover?

A practical checklist, drawn from where real findings come from. If a tool you are evaluating cannot reach one of these surfaces, that surface is where your audit finding or incident will eventually originate. 

• TLS endpoints, including protocol versions and full cipher-suite enumeration, not just the certificate. 
• Hardware security modules and tokens over PKCS#11, with visibility into every object on every slot. 
• Enterprise key managers over KMIP, where storage products and hypervisors source their keys. 
• Database transparent data encryption, where the master keys protecting regulated data live. 
• Active Directory and LDAP directories, which hold far more key material than user certificates. 
• Filesystems and developer keyrings, where keys accumulate in PEM files, keystores, and GnuPG rings. 
• Cloud KMS across all providers in use, with key specs and protection levels for every key. 
• Application source code, where algorithm choices and hardcoded secrets live outside the reach of every other tool class. 
• Compiled binaries, which embed cryptographic libraries and versions that never appear in source scans or infrastructure inventories. 

Container images are already covered through binary analysis, and coverage keeps expanding: Kubernetes secrets, CI/CD pipeline integration, and cloud secret managers are next on the CBOM Secure roadmap. 

How does TLS endpoint discovery work? 

CBOM Secure performs live TLS analysis rather than certificate collection. Against any host and port, it identifies every protocol version and cipher suite the endpoint actually negotiates, flags deprecated protocols, spots post-quantum hybrid suites where servers already offer them, and records the full certificate chain. Typical findings include TLS 1.0 or 1.1 still enabled, cipher suites without forward secrecy, expired or mismatched intermediate certificates, and self-signed certificates in production. 

Why the distinction matters: a perfectly valid, freshly rotated certificate sitting on a server that still negotiates TLS 1.0 with weak suites is a compliance finding under PCI DSS 4.0 and NIST SP 800-52 guidance, and it is invisible to tools that only look at the certificate. The same analysis applies to any TLS-wrapped protocol, including HTTPS, LDAPS, SMTPS, IMAPS, POP3S, and FTPS, on any port. 

How does HSM discovery work over PKCS#11? 

CBOM Secure connects to any PKCS#11 v2.x-compliant module and inventories every certificate and key on every slot: what it is, what algorithm and key size it uses, what it is allowed to do, and whether it can be extracted. You get a complete, current picture of what actually lives in your HSM estate, and every finding is checked against the rest of the inventory, so reused keys surface immediately.

Because PKCS#11 is an OASIS standards interface, one platform covers the whole hardware ecosystem rather than needing a connector per vendor. Tested coverage spans three groups:

• Commercial HSMs: Entrust nCipher and nShield, Thales Luna and SafeNet Luna, Utimaco SecurityServer and CryptoServer, IBM 4767, 4768, and 4769 crypto cards, Securosys Primus, Marvell LiquidSecurity, and Atos Trustway Proteccio. 
• Cloud HSMs: AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM. 
• Developer and test HSMs and tokens: Yubico YubiHSM 2 and YubiKey PIV applets, Nitrokey HSM 2, smart cards through OpenSC including PIV and CAC, and SoftHSM2 for development and test. 

Common vendor libraries are detected automatically, so coverage extends across the estate with minimal setup. Operationally, this is what surfaces the findings that matter: orphaned keys that no application references, inactive objects that have never been used, extractable keys that policy says should be hardware-bound, and duplicates reused across partitions.

How does key manager discovery work over KMIP? 

CBOM Secure speaks every shipping version of the OASIS Key Management Interoperability Protocol, 1.0 through 2.1, using standards-compliant messages. The platform therefore inventories Thales CipherTrust Manager, Entrust KeyControl, IBM Security Key Lifecycle Manager, Fortanix Data Security Manager, Utimaco ESKM, Oracle Key Vault, Fornetix VaultCore, HashiCorp Vault in KMIP mode, Cryptomathic CKMS, QuintessenceLabs qCrypt, and any other conforming server, with no vendor-specific configuration. 

Every key, certificate, and secret in those servers lands in the inventory with its full lifecycle state, so a key that has been deactivated or marked compromised shows up that way rather than as a live asset. Weak and quantum-vulnerable algorithms are flagged wherever the server exposes them. 

One architectural point evaluators often miss: the common enterprise encryption use cases, VMware vSphere VM and vSAN encryption, NetApp ONTAP volume encryption, Nutanix, and Dell EMC PowerProtect, are KMIP clients, not servers. Their keys live in the KMIP server, which is exactly where CBOM Secure inventories them. Scanning the authoritative source is both simpler and better than chasing every consumer.

How does database TDE discovery work? 

CBOM Secure reads transparent data encryption metadata directly from each database engine, producing the evidence auditors ask for: key algorithms, protecting certificates, and expiry. It never touches key material or interrupts the database. Where the engine exposes key versioning, as MySQL and MariaDB do for InnoDB tablespace encryption, key version metadata is captured, so stale master keys are visible instead of assumed.

Database	What You Get
SQL Server 2012+	TDE key algorithm and length, encryption state, and the protecting certificate with its thumbprint and expiry.
Oracle 11g+	Master key status, Oracle Wallet status, and per-tablespace and per-column encryption detail.
MySQL 5.7+ / MariaDB 10.1+	Tablespace encryption status, scheme, and key versioning.

What does CBOM Secure find in Active Directory? 

Most tools treat AD as a container for user certificates. CBOM Secure runs a deep, multi-stage analysis across the directory (multi-forest and multi-domain), and the material it surfaces goes far beyond certificates.

• User and computer certificates across the forest. Expired or weak-key certificates here break authentication and create impersonation risk. 
• SSH public keys are published in the directory. Unmanaged SSH keys grant standing access that nobody reviews. 
• Windows Hello for Business keys. These are primary sign-in credentials, and orphaned or unmanaged entries weaken passwordless authentication. 
• gMSA root keys. Compromise of these keys lets an attacker derive service account passwords across the domain. 
• krbtgt signing key records and domain trust keys, captured as existence-only entries. Stale krbtgt keys enable golden-ticket attacks, and trust keys are domain-takeover targets. 
• DPAPI backup keys. These keys can decrypt user and service secrets domain-wide. 
• BitLocker recovery information. Anyone who can read recovery keys can decrypt the protected disks. 
• The AD Certificate Services hierarchy, end-to-end. Misconfigured templates and CAs are a well-documented privilege escalation path. 

Findings are enriched with up-to-date revocation status wherever the issuing CA publishes it. The sensitive items are recorded as existence entries, never as key material.

What about non-Microsoft directories? 

CBOM Secure also covers the rest of the directory world: OpenLDAP, 389 Directory Server and Red Hat Directory Server, FreeIPA, Samba4, Oracle Directory Server and Oracle Unified Directory, NetIQ eDirectory, IBM Security Directory Server, Apache Directory Server, OpenDJ and ForgeRock and PingDS, and any RFC 4523-compliant LDAP v3 server.

What you get from each directory: every stored certificate with an accurate revocation status, every published SSH key, S/MIME material, and anything an application team has stashed in a custom attribute, which the platform detects automatically across the common key and certificate formats. One pass covers every vendor, instead of a connector project per directory. The business value: certificate estates inside legacy directories, often the oldest and least-owned cryptography in the company, finally appear in the same inventory and policy checks as everything else.

Where do files and keyrings fit? 

Filesystem discovery walks directories recursively and parses the formats key material actually ships in: PEM and DER certificates and chains, CSRs, PKCS#7 and PKCS#12 containers, PKCS#8 keys, Java keystores in JKS and JCEKS formats, and OpenSSH keys. Critically, it also reads PEM blocks embedded inside YAML, JSON, and application config files, which is where a remarkable amount of production key material quietly lives. 

Keyring discovery enumerates GnuPG 1.x and 2.x keyrings across user directories on Windows, Linux, and macOS, covering RSA at all common sizes, DSA, ElGamal, and modern ECC, including Ed25519 and Curve25519. When the private key actually lives on hardware, a YubiKey 5 OpenPGP applet or a Nitrokey, the keyring stub is recorded as a public key plus a private-key existence record, so the inventory answers where the signing key really is without extracting anything. Typical findings include expired signing keys still trusted by build pipelines, legacy 1024-bit DSA keys, keys with no expiry set, and private keys on disk that policy requires on hardware. 

How deep does cloud and vault coverage go? 

Cloud discovery goes deeper than counting keys: 

• AWS: ACM certificates, KMS asymmetric keys with exact key specs down to secp256k1, and legacy IAM server certificates. 
• Azure: Key Vault keys and certificates, Managed HSM, and the TLS bindings across App Service, Application Gateway, Front Door, and API Management, fetched concurrently for speed. 
• Google Cloud: Cloud KMS key rings with rotation period and protection level, distinguishing HSM-backed from software keys. 
• HashiCorp Vault: the PKI engine including issuer chains, the Transit engine across RSA, ECDSA, Ed25519, AES-GCM, and ChaCha20-Poly1305 keys, and KV v1 and v2 with namespace support. 

Native CertSecure Manager integration pulls the full certificate inventory with lifecycle state. And because every provider feeds the same CBOM, multi-cloud governance becomes one policy applied everywhere: the same algorithm and rotation rules are evaluated across AWS, Azure, and Google Cloud, and cross-cloud key duplication becomes visible instead of staying hidden inside per-provider consoles.

What do source code and binaries add to discovery?

Source code is the discovery surface every other tool class skips, and it is where algorithm decisions and hardcoded secrets live. CBOM Secure statically analyzes code in seven languages: C and C++, Python, Java, Go, JavaScript and TypeScript, Rust, and C#, across 70+ cryptographic libraries. The outcomes that matter: hardcoded keys, IVs, and passwords flagged as CRITICAL before they become incidents, the algorithms actually in use resolved rather than guessed, and every quantum-vulnerable call tagged for migration planning. Scans run on local directories, archives, and GitHub repositories, entirely offline, so code never leaves your environment. Typical findings: hardcoded AES keys committed to repositories, deprecated SHA-1 still used for signatures or tokens, and static IV reuse that silently undermines otherwise-strong encryption. 

Binary analysis covers the compiled side: which cryptographic libraries your executables actually embed, which versions correlate with known CVEs, and whether the binaries are signed and verified. Every finding carries a confidence level. Together, source and binary analysis close the gap between what your infrastructure says and what your software actually does. They also pair naturally with an SBOM: the SBOM says which libraries you ship, the cryptographic view says which algorithms and key handling those libraries actually perform, and both can be expressed in CycloneDX.

Agentless or agent-based: which discovery mode when? 

Agentless discovery is platform-initiated and needs no software on targets; it covers cloud APIs, KMIP servers, databases, HSMs, and TLS endpoints. Agent-based discovery uses lightweight host agents with short-lived, narrowly scoped credentials, and covers filesystems, source code, binaries, and OS trust stores. Most production deployments combine both, and discovery tasks can be scheduled and chained so a host-level scan triggers filesystem analysis on what it finds. 

Aspect	Agentless	Agent-based
How it runs	Platform-initiated; no software installed on targets.	Lightweight host agents with short-lived, narrowly scoped credentials.
What it covers	Cloud APIs, KMIP servers, databases, HSMs, and TLS endpoints.	Filesystems, source code, binaries, and OS trust stores.
Setup effort	Credentials per target; nothing to install.	Agent deployment per host.
Best for	Centralized, API-reachable infrastructure.	Host-resident material that APIs cannot see.

How findings become one inventory 

Every discovery surface feeds one pipeline: findings are normalized, deduplicated, correlated certificate-to-key, risk-scored from 0 to 100, and tagged for policy and quantum safety. Deduplication is what catches the same key appearing in a cloud vault, on an HSM partition, and in a PEM file, key reuse no single-source tool can see. The result is one CBOM, queryable by algorithm, issuer, key size, or storage location, and exportable in CycloneDX.

A practical example: the same RSA-2048 key surfaces in a cloud vault, on an HSM partition, and in a PEM file inside a configuration repository. Three sources report it, deduplication collapses it into one asset with three locations, and the key reuse finding is scored against the most exposed copy: the file. 

Run it against one messy subnet 

The fastest evaluation is a scan of the environment you suspect is worst. Pick a subnet, a directory, or a repository, and we will walk through what CBOM Secure returns. Contact info@encryptionconsulting.com. 

What does a first discovery typically reveal? 

Run discovery across a real environment for the first time, and the results follow a pattern. The inventory is larger than anyone predicted, usually by a wide margin, because nobody had counted the keys in pipelines, the certificates issued by internal CAs, or the cryptography shipped inside application dependencies. Across anonymized first-run engagements, the pattern is consistent: inventories typically come back two to four times larger than the pre-scan estimate, well over 90 percent of asymmetric material is quantum-vulnerable, and a low single-digit percentage is already deprecated and needs remediation now. The quantum-vulnerable share is no surprise: RSA and elliptic-curve cryptography are still the default in every mainstream stack. The deprecated slice is the dangerous one: MD5 and SHA-1 still hashing, DES and RC4 still negotiating, deprecated TLS versions still enabled for backward compatibility.

That split matters for planning. The deprecated slice is small but urgent; it is this quarter’s remediation work regardless of quantum timelines. The much larger quantum-vulnerable slice is the migration scope. CBOM Secure reports both continuously, quantum-safe versus non-quantum-safe counts backed by named KPIs, so readiness becomes a number you track rather than a guess.

Discovery also surfaces the cryptography nobody is using, but everyone is shipping: multiple versions of the same TLS library on one server image, keystores left behind by retired applications, leftover keys that no service references. Dormant material is an untracked attack surface and silent migration debt, and because CBOM Secure separates dormant cryptography from material in active production use, it stops inflating your migration scope. The same pass catches key reuse, the one key quietly shared across a cloud vault, an HSM, and a build server.

The last consistent finding is organizational rather than technical. Certificates get created by developers, pipelines, and third-party integrations without lifecycle tracking, and no single team owns the estate, so expiry surprises and policy violations get discovered by outage or by auditor. This is why the durable outcome of discovery is not the first report but the operating model it enables: continuous inventory, clear ownership, and policy evaluated on every asset.

The stakes are asymmetric. Data with a long confidentiality lifetime, such as health records, financial records, and intellectual property, can be harvested now and decrypted later, once a sufficiently capable quantum computer exists. Signatures trusted today can be forged later if the underlying algorithm falls. Those two risks, plus PCI DSS 4.0’s inventory requirement and the CNSA 2.0 adoption horizon, are why a first discovery run is usually followed by a standing program.

Frequently asked questions 

What is cryptographic discovery?

The automated identification and cataloging of all cryptographic assets, keys, certificates, algorithms, and protocols across an environment, including infrastructure and application code. It is the foundation for cryptographic compliance, incident response, and post-quantum migration.

How is it different from certificate discovery?

Certificate discovery finds X.509 certificates, usually at network endpoints. Cryptographic discovery also inventories keys in HSMs and key managers; database TDE material; directory-resident keys; files and keyrings; and algorithm usage inside source code.

Does discovery require installing agents everywhere?

No. Cloud APIs, KMIP servers, databases, HSMs, and TLS endpoints are scanned agentlessly. Lightweight agents cover filesystems, source code, and OS trust stores.

Can it find SSH keys?

Yes, in several places: OpenSSH files on disk, SSH public keys published in AD and LDAP directories, and hardware-resident keys via their keyring stubs.

Can it find keys inside config files?

Yes. Filesystem discovery parses PEM blocks embedded in YAML, JSON, and application configuration files during recursive walks.

Is private key material ever exposed?

No. Across HSMs, databases, directories, and hardware tokens, private keys are recorded as metadata and existence entries only.

How often does discovery run? 

On whatever schedule you configure. Discovery tasks are orchestrated, schedulable, and chainable, so the inventory stays continuously current rather than audit-driven.

What happens to the findings?

They are normalized, deduplicated, correlated, risk-scored from 0 to 100, evaluated against policy, and exported on demand in CycloneDX.

What do organizations typically find in a first discovery?

More cryptography than expected, most of it quantum-vulnerable, a small slice already deprecated (MD5, SHA-1, DES) that needs immediate remediation, dormant libraries and leftover keys inflating the attack surface, and certificates without clear ownership. The durable value is turning that picture into tracked, continuous governance.

Can cryptographic discovery support post-quantum migration?

Yes. Quantum-vulnerable algorithms are tagged automatically across keys, certificates, protocols, and source code, and quantum-safe versus non-quantum-safe KPIs turn migration progress into a number you can track against CNSA 2.0 timelines.

How long does an initial discovery scan take?

It depends on the scope. Discovery runs are scoped per target and scheduled, so a first pass is usually phased surface by surface; in M&A scenarios, the platform has produced a complete inventory of an acquired environment, with prioritized risk findings, within hours. After the first pass, discovery runs continuously on whatever schedule you configure. 

Does discovery impact production systems?

No. Discovery is read-only: it queries metadata, never key material, and never modifies a target, so databases, HSMs, and endpoints keep serving production traffic while being scanned.

Can discovery identify deprecated algorithms?

Yes. DES, RC4, MD5, SHA-1, RSA-1024, and deprecated TLS versions are flagged on sight, each with a severity rating, so the remediation queue builds itself.

Can discovery detect cryptographic policy violations?

Yes. Every discovered asset is evaluated continuously against the selected compliance policy, and violations surface as findings with pass-fail trends over time.

Get started

Every capability described in this guide ships in production today. To see what CBOM Secure finds in your environment, contact Encryption Consulting at info@encryptionconsulting.com or visit www.encryptionconsulting.com.