What Is Cryptographic Discovery?
Cryptographic discovery is the systematic process of identifying every cryptographic algorithm in use across an organization's technology estate: network protocols, application source code, binary dependencies, X.509 certificates, key management systems, firmware, hardware security modules, APIs, and supply chain software components. The output of discovery is a Cryptographic Bill of Materials (CBOM) a structured inventory that maps each cryptographic asset to its location, algorithm type, data sensitivity context, and migration urgency.
Discovery is the non-negotiable prerequisite for post-quantum cryptographic migration. Organizations that attempt to plan or execute a PQC migration without a complete inventory inevitably miss critical components, misallocate resources, and discover gaps in production that could have been caught in planning. NIST SP 1800-38, OMB M-23-02, and the joint CISA/NSA/NIST guidance on quantum-readiness all identify cryptographic inventory as the first required step in a PQC migration program.
“Agencies shall maintain a current inventory of their information systems that use cryptographic systems or software and prioritize the transition of those systems to post-quantum cryptographic standards.”
Why Discovery Is the Non-Negotiable First Step
Without a complete cryptographic inventory, migration planning cannot be risk-based. Migration decisions are guesses rather than informed prioritization. Resources are allocated to visible, well-understood systems while critical but less visible components embedded libraries in third-party dependencies, legacy APIs still serving production traffic, firmware-based cryptography in operational technology remain unaddressed. Discovery converts migration from a hope into a program.
OMB M-23-02 explicitly requires federal agencies to develop and maintain a cryptographic inventory as a compliance obligation. NSA CNSA 2.0 provides algorithm and timeline requirements for National Security Systems, but those requirements cannot be met without knowing which systems use which algorithms. The CISA joint guidance on quantum-readiness identifies inventory as the essential foundation for the risk-based prioritization that follows. Even organizations without federal obligations benefit from discovery's ability to reveal cryptographic assumptions that have drifted from policy, supply chain dependencies that have introduced unauthorized algorithms, and certificate inventories that reveal imminent expiration risks alongside algorithm migration needs.
The Scope of a Discovery Engagement
A comprehensive cryptographic discovery engagement covers six primary categories. Network protocols: TLS cipher suites and key exchange algorithms observed in active connections; SSH host key algorithms and key exchange methods; IKEv2 proposals and transforms in VPN configurations; DTLS in real-time communication systems. Application code and binaries: cryptographic API calls in source code, binary analysis of compiled applications, dependency trees of software libraries, and configuration files specifying algorithm preferences.
Certificate and PKI infrastructure: inventory of all X.509 certificates by algorithm (RSA, ECDSA, EdDSA), key size, issuing CA, validity period, and deployment location. Key management systems: HSM key types and algorithm identifiers in use; key management software and its supported algorithms. Firmware and operational technology: cryptographic operations in embedded firmware, secure boot implementations, and industrial control systems. Supply chain: third-party software and SaaS service dependencies that perform cryptographic operations on behalf of the organization.
Network Protocol Scanning
Network protocol scanning uses active probing to identify TLS cipher suites, key exchange algorithms, and server certificate algorithms in use across an organization's network infrastructure. Tools such as testssl.sh, SSLyze, and custom probes can enumerate the cipher suites accepted by TLS endpoints, identify the server certificate algorithm, and detect whether elliptic-curve or classical Diffie-Hellman key exchange is in use. Scanning should cover all network-accessible services, not only web servers: SMTP with STARTTLS, IMAP and POP3 over TLS, database connections using TLS, API gateways, load balancers, and internal microservices.
Passive network monitoring using traffic analysis can complement active scanning by revealing protocols and connections that are not reachable by external scanners internal microservice-to-microservice communication, database client connections, and encrypted communication with third-party services. Packet capture analysis of representative traffic samples can identify the TLS versions, cipher suites, and key exchange algorithms in active use across a broader range of connections than active scanning alone can reach.
Source Code and Binary Analysis
Source code analysis identifies cryptographic API usage in application code. Static analysis tools scan codebases for calls to cryptographic library functions, configuration of algorithm identifiers, and hardcoded algorithm constants. Findings include direct calls to ECDSA signing functions, RSA encryption operations, specific hash function calls, and configurations that select cipher suites or key types. Source code analysis is most effective when applied to code that is actively maintained and available for review.
Binary analysis extends discovery to compiled applications and third-party components where source code is not available. Binary analysis tools identify imported cryptographic library symbols, embedded algorithm constants, and cryptographic constant patterns in compiled code. Dependency analysis of software package manifests npm package-lock.json, Python requirements.txt, Java pom.xml, Go go.mod identifies third-party library dependencies that may include their own cryptographic implementations, which are common in language-native TLS libraries, JWT processing packages, and cryptographic utility libraries.
Certificate and PKI Inventory
Certificate inventory is often the most immediately actionable discovery output because certificate data is structured and machine-readable. A complete certificate inventory covers all X.509 certificates in the organization's infrastructure: TLS server certificates, client authentication certificates, code signing certificates, S/MIME certificates, root and intermediate CA certificates, and OCSP responder certificates. For each certificate, the inventory records the signature algorithm (RSA-SHA256, ECDSA-SHA384, etc.), key type and size, validity period, issuing CA, and deployment locations.
Certificate inventory reveals several actionable findings beyond algorithm identification: certificates using weak algorithm parameters (e.g., RSA with 1024-bit keys, SHA-1 signature hashing), certificates approaching expiration that must be replaced in the near term in any case (creating a natural opportunity for algorithm migration), root CA certificate lifetimes that will extend into the post-quantum risk window, and certificates issued by third-party CAs where migration depends on CA support for post-quantum algorithms rather than on internal infrastructure changes.
Library and Dependency Scanning
Modern software depends on extensive third-party library ecosystems. Cryptographic operations are frequently performed by library code rather than application code written by the organization TLS by OpenSSL or a platform-provided TLS stack, JWT signing by a language-specific JWT library, SSH by libssh or OpenSSH, HTTPS by an HTTP client library. Each of these dependencies has its own algorithm support and configuration defaults that may not align with the organization's cryptographic policy.
Dependency scanning tools analyze software package manifests and lock files to identify all transitive dependencies, including indirect dependencies of dependencies. For each dependency that performs cryptographic operations, the discovery process should determine which algorithms the library uses by default, which algorithms are configurable, whether the library version in use has been updated to support FIPS 203, 204, and 205 algorithms, and what the library vendor's roadmap for post-quantum support is. Dependencies with no post-quantum roadmap may require replacement rather than configuration.
Firmware and Operational Technology Analysis
Firmware analysis is technically challenging because firmware is often delivered as binary images without source code. Reverse engineering tools, cryptographic constant detection, and TLS library symbol identification in firmware binaries are used to identify cryptographic operations in embedded systems. For operational technology (OT) environments industrial control systems, SCADA systems, building management systems the cryptographic analysis must account for both network protocol-level cryptography and application-level command authentication.
Operational technology systems present additional migration complexity because they often run on specialized hardware with long replacement cycles, may not have network-accessible update mechanisms, and may use proprietary or legacy protocols with limited cryptographic flexibility. Discovery of cryptographic usage in OT environments informs risk assessment: systems that cannot be migrated before their hardware reaches end of life require compensating controls (network isolation, one-way data diodes) or hardware refresh planning as part of the migration program.
Supply Chain Cryptographic Assessment
Software supply chain cryptographic exposure is increasingly recognized as a significant migration risk. Third-party software components SaaS platforms, cloud services, vendor-supplied applications perform cryptographic operations on the organization's behalf or in the organization's data flows. If a SaaS platform uses ECDH for its API connections and does not have a PQC migration timeline, data flowing through that platform may be subject to HNDL collection even after the organization's own infrastructure has migrated.
Supply chain assessment involves querying software and service vendors about their PQC migration roadmaps, reviewing vendor security documentation for cryptographic algorithm specifications, and including PQC readiness requirements in vendor selection and contract renewal processes. OMB M-23-02 requires federal agencies to assess their supply chain cryptographic dependencies as part of their inventory obligations. NIST SP 1800-38 includes supply chain assessment as part of the comprehensive discovery process.
Building the CBOM from Discovery
The CBOM (Cryptographic Bill of Materials) is the structured output of the discovery process. A CBOM entry records: the cryptographic asset identifier (certificate serial number, library name and version, service endpoint, firmware component identifier); the algorithm type (key exchange, digital signature, symmetric encryption, hash function); the specific algorithm and parameters (e.g., ECDSA with P-256); the data sensitivity context (what data does this algorithm protect); the system criticality (what is the operational impact of cryptographic failure); and the migration status.
CBOM data should be stored in a format that supports both human review and automated processing. Proposed standards for CBOM data schemas are being developed by the IETF and within the CycloneDX and SPDX software bill of materials ecosystems. Organizations do not need to wait for a finalized CBOM standard to begin their inventory a structured spreadsheet or database with consistent field definitions provides the functional equivalent for migration planning purposes.
Prioritizing Discovery Findings
Not all discovery findings carry equal migration urgency. Findings are prioritized by the combination of data sensitivity, confidentiality lifetime, system criticality, and regulatory context. A TLS endpoint serving long-retention healthcare data should receive higher migration priority than a TLS endpoint serving anonymized public web content. A root CA certificate with a 25-year validity period and an ECDSA key receives higher priority than an end-entity certificate expiring in six months.
CNSA 2.0 requirements drive prioritization for National Security Systems: systems within CNSA 2.0 scope are subject to specific timelines regardless of the organization's general risk prioritization. OMB M-23-02 compliance drives prioritization for federal agencies. For commercial organizations, HNDL exposure specifically, which systems protect data whose required confidentiality lifetime extends into the quantum risk window provides the primary prioritization signal. The output of prioritization is a risk-scored migration backlog that sequences findings from highest-urgency to lowest.
Common Discovery Gaps to Avoid
Several categories of cryptographic exposure are systematically underrepresented in discovery programs that rely primarily on network scanning. Internal service-to-service communication microservices communicating over internal networks is often missed by external-facing scans. Cryptography embedded in data at rest encrypted database fields, encrypted backup files, encrypted archive storage is not visible to network protocol scanners. Client-side cryptography in mobile applications and desktop clients may use different algorithm configurations than server-side infrastructure.
Hardware-rooted cryptography in secure enclaves, Trusted Platform Modules (TPMs), and Hardware Security Modules (HSMs) requires direct inventory of the HSM's supported algorithm list and key inventory, which is not visible to network or code scanners. Legacy cryptography in batch processing systems, data pipelines, and ETL (Extract-Transform-Load) workflows may perform encryption or signing operations outside the paths covered by web and API scanning. A complete discovery program must explicitly scope these areas and use appropriate discovery methods for each.
Integrating Discovery into the Development Lifecycle
Ongoing cryptographic inventory accuracy requires integrating discovery into the software development lifecycle. New code should be checked for non-compliant cryptographic API usage during code review and CI/CD pipelines using static analysis tools configured with the organization's cryptographic standards. Certificate lifecycle management should automatically alert on certificates using deprecated algorithms. Dependency updates should trigger algorithm compliance checks on any dependency that performs cryptographic operations.
Treating cryptographic compliance as a continuous property that is monitored and maintained rather than a one-time state achieved at migration completion provides the ongoing visibility needed for crypto-agility. An organization that completed a thorough discovery in 2024 but has not maintained its CBOM through subsequent system changes by 2026 may have accumulated new cryptographic exposure without realizing it. Integrating discovery tooling into standard DevSecOps processes prevents inventory drift.
From Discovery to Migration Roadmap
A complete, prioritized CBOM is the direct input to migration roadmap development. Each CBOM entry becomes a migration work item with an associated priority score, migration approach, algorithm target, and timeline estimate. High-priority items high HNDL exposure, regulatory deadline pressure, critical system criticality form the first migration phase. Lower-priority items are sequenced into subsequent phases based on available engineering capacity and dependency ordering.
The migration roadmap should account for dependencies between CBOM entries: TLS server certificate migration depends on intermediate CA migration, which depends on root CA migration. Firmware signature verification key changes depend on device firmware update delivery infrastructure migration. Mapping these dependencies ensures the roadmap sequences work in the correct order and avoids creating situations where migrated components cannot be verified because their upstream infrastructure has not yet migrated. NIST SP 1800-38 provides a structured migration planning framework that organizes work around these dependencies.
References
- [1]
- [2]
- [3]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [4]OMBOMB M-23-02(2022)Memorandum on Migrating to Post-Quantum Cryptography
- [5]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [6]ETSIETSI TR 103 619(2022)Quantum-Safe Cryptography; Migration and Co-existence
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.