You Can’t Secure What You Can’t See: The Foundational Case for Cryptographic Discovery

Every organization running RSA, ECC, TLS, or AES-based encryption has a cryptographic estate. Most organizations have no idea what is in it. That is not a criticism; it is a structural reality. Cryptography was never designed to be managed the way servers or applications are managed. It has no IP address. It generates no alert when it reaches the end of its useful life. It runs silently in the background of almost every system you operate, until something breaks, until a regulator asks for documentation you cannot produce, or until a threat model you dismissed as theoretical becomes real enough that someone with real resources decides to act on it. Cryptographic discovery is the multi-layer process of finding and mapping every algorithm, key, certificate, protocol, and library across your environment. DORA Article 9.2 and PCI DSS Requirement 12.3.3 have made it a legal obligation since early 2025. NIST FIPS 203, 204, and 205, finalized August 2024, make it the technical prerequisite for PQC migration. The recommended action: begin cryptographic discovery now, because every compliance requirement and every migration initiative depends on it. For what to do with what you find, see Why Your Cryptographic Inventory Is Your Master Key and Why a CBOM Is Essential Now More Than Ever.

Quick Answer: What Is Cryptographic Discovery and Why Is It Mandatory?

Cryptographic discovery is the process of identifying every algorithm, key, certificate, protocol, and cryptographic library across an organization’s environment using five complementary discovery layers: passive network traffic analysis, static code analysis, configuration and certificate scanning, runtime and binary analysis, and manual investigation. It is mandatory today because DORA Article 9.2 and PCI DSS Requirement 12.3.3 require documented cryptographic inventories as enforceable obligations since January and March 2025 respectively, and PQC migration under NIST FIPS 203, 204, and 205 cannot be planned or scoped without a baseline inventory.

The Real Scale of the Problem

When organizations first attempt a cryptographic inventory, they are consistently surprised by what they find, not because the findings are unexpected, but because there are so many of them, and so few were captured in any existing system of record.

According to BIS Paper No. 158, between 70 and 90 percent of enterprise software is assembled from third-party components. Every one of those components carries cryptographic choices that the organization deploying them never directly made: library versions pinned to outdated dependencies, cipher suite defaults set at the time the library was written, algorithm choices baked into code that ships inside a product whose vendor has never published a cryptographic disclosure.

The Applied Quantum PQC Migration Framework estimates more than 320 cryptographic function calls in a single mobile banking application. Across an enterprise estate, the total count of cryptographic assets, algorithms, keys, certificates, protocols, and library implementations, runs into the hundreds of thousands. Most organizations have formally documented a small fraction of that.

The gap between what organizations believe is in their cryptographic estate and what is actually running in production is not a minor inventory discrepancy. It is the root cause of every compliance gap, every remediation delay, and every migration project that takes twice as long as planned.

The Compliance Obligations Already Active

For organizations subject to DORA, PCI DSS 4.0, or NIS2, a cryptographic inventory is not a best-practice recommendation. It is a current, enforceable legal obligation.

DORA Article 9.2 requires financial entities to maintain an up-to-date register of all information assets, explicitly including cryptographic assets, for all ICT systems supporting critical or important functions. DORA Article 7.4 further requires that this register include all digital certificates and the devices on which they are stored. Both provisions have been enforceable since January 17, 2025.

PCI DSS Requirement 12.3.3 requires a documented, continuously maintained inventory of all cryptographic cipher suites and protocols in use, with a business justification per entry, active viability monitoring, and a documented response strategy for any identified cryptographic vulnerabilities. This requirement has been enforceable since March 31, 2025.

Neither of these is a future deadline. Both are active obligations today. An organization that cannot produce the required documentation during a supervisory review does not have a gap in a roadmap; it has a gap in an enforceable requirement that has been in effect since early 2025. The business case for building a cryptographic inventory does not require a quantum threat assessment. The compliance case alone has been more than sufficient justification since January 2025.

PQC Standards and Why Discovery Must Come First

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547, published November 2024, designates RSA-2048 and ECC P-256 for deprecation by 2030 and full disallowance by 2035. NSA CNSA 2.0 sets binding deadlines for National Security Systems starting January 2027. These deadlines create urgency. But knowing what algorithms to migrate to is only half the problem. The other half is knowing which systems are running RSA, ECDH, ECDSA, and Diffie-Hellman, in what context, and with what hardware and software dependencies. Without a baseline cryptographic inventory, migration planning is guesswork, and migration projects consistently take twice as long as planned. The SHA-1 to SHA-256 migration was estimated to take five years; it took more than ten. The post-quantum transition is larger in every dimension.

Why Your Current Tooling Has Structural Blind Spots

The natural instinct when starting a cryptographic inventory is to reach for existing tools: run the vulnerability scanner, export the certificate management system, query the CMDB. Those tools each capture something useful, but each has a structural limitation that no amount of configuration can overcome.

Certificate management platforms manage the certificates you registered with them. They have no mechanism for discovering certificates provisioned outside your managed workflow, such as the certificate a developer requested directly from a public CA, the one a cloud platform generated automatically, or the one still running on a staging environment that was never decommissioned.

Vulnerability scanners report on what is reachable and what services are running. They do not reveal which cipher suites are actively being negotiated on east-west traffic between your application tiers, the internal service-to-service connections that are invisible at the perimeter and are almost never governed by the same TLS policies as inbound external traffic.

CMDBs capture officially provisioned infrastructure. They miss cloud resources deployed outside standard workflows, OT devices that facilities management provisioned independently, systems from acquired companies that were integrated into operations but never into the asset register, and any system whose owner left the organization without documenting it.

These are not tool failures. They are design limitations. Each tool was built for a specific purpose, and that purpose was not cryptographic discovery. Closing the gaps requires treating discovery as a multi-layer discipline, not a single scan you run once and move on from.

The Five Discovery Layers, and What Each One Finds

A complete cryptographic inventory requires five distinct discovery layers. They are not interchangeable and not redundant. Each one surfaces what the others structurally cannot.

Layer Method	What It Uniquely Finds
Passive Network Traffic Analysis	Live protocol negotiation in production: what is actually being used, not just what is configured
Static Code Analysis	Hardcoded keys, deprecated library imports, and algorithm choices fixed in application logic
Configuration and Certificate Scanning	Cipher suite policies on managed infrastructure; shadow certificates via CT logs
Runtime and Binary Analysis	Cryptographic posture of vendor appliances, OT systems, and firmware that you cannot read directly
Manual Investigation	Custom protocols, proprietary schemes, undocumented integrations, and organizational context

Layer 1: Passive Network Traffic Analysis

Passive network analysis is the only discovery method that reveals what cryptographic protocols are actually being negotiated in production, as opposed to what configurations say should be negotiable. That distinction matters more than most teams expect.

A server configured to support TLS 1.3 may still negotiate TLS 1.1 with legacy endpoints that cannot do better. A load balancer enforcing modern cipher suites at the perimeter has no control over backend connections between application servers and databases, which run whatever the application was originally coded to use. Deployed on network taps or SPAN ports at key aggregation points, passive analysis captures live TLS handshake metadata from those connections without decrypting traffic or placing any load on production systems.

Santander’s cryptographic inventory program, presented at the PKI Consortium PQC Conference 2025 by Jaime Gómez García, achieved visibility across 9,000 Apache instances globally using adapted existing tooling rather than purpose-built discovery platforms. Layer 1 is consistently where the most operationally significant surprises surface.

Layer 2: Static Code Analysis

Static analysis scans source code repositories for cryptographic material embedded directly in application logic: hardcoded key values, deprecated library imports, and explicit key size parameters in key generation calls. These represent cryptographic choices that are fixed at the code level and cannot be changed without a full redeployment.

A call to hashlib.sha1() in a production application is not just a deprecated-algorithm warning. It is a remediation task that requires a code change, a build cycle, a test cycle, and a deployment. Across an enterprise codebase containing hundreds of thousands of cryptographic function calls, Layer 2 is where the true scope of the application-level migration effort becomes visible for the first time.

Layer 3: Configuration and Certificate Scanning

This layer covers the cipher suite policies configured on load balancers, firewalls, and VPN concentrators, as well as the certificate inventory across your PKI environment and cloud infrastructure.

Certificate Transparency (CT) logs are the most consistently underused source in this layer. Every publicly trusted Certificate Authority (CA) is required to submit every certificate it issues to CT logs, which are publicly queryable. A CT log query against your domains returns every certificate ever issued for them, including those that were never registered in your certificate management system. Those are your shadow certificates, and they are in regulatory scope whether or not they appear in your managed inventory.

Layer 4: Runtime and Binary Analysis

For vendor appliances, embedded firmware, and OT systems where no source code is available, runtime and binary analysis is the only viable method for assessing actual cryptographic posture. This applies to ATM and POS terminals, network appliances, industrial control systems, and any device whose cryptographic implementation lives in firmware that your organization did not write and cannot inspect directly.

NIST CSWP 39 documents that the average OT system refresh cycle is 20 years. In practice, this means deprecated cryptographic algorithms can remain entrenched in operational technology environments for a decade or more, with no update mechanism, and no governance process that has ever touched them.

Layer 5: Manual Investigation

Architecture documentation reviews, HSM and KMS audit log examination, vendor security documentation analysis, and structured interviews with platform and system owners round out the discovery picture. Manual investigation surfaces the custom protocols, proprietary encryption schemes, and undocumented integrations that every automated layer will miss, and it provides the organizational context that transforms raw technical findings into genuinely actionable intelligence.

Every layer finds what the others cannot. Skipping any one of them means permanently inheriting that layer’s blind spots.

What Discovery Must Surface: Algorithm and Interoperability Caveats

A cryptographic discovery program that stops at identifying which algorithms are present is not sufficient for PQC migration planning. Discovery must also surface the hardware and software constraints that determine how quickly each system can be migrated:

• HSM firmware support gaps: Many FIPS 140-3 validated HSMs do not yet support ML-KEM or ML-DSA. Discovery must capture the HSM model and firmware version for each cryptographic asset using an HSM, and document the vendor’s roadmap for PQC algorithm support and FIPS 140-3 re-validation timeline.
• TLS library versions: TLS 1.3 implementations must be updated or patched to support PQC key exchange groups. Discovery must capture TLS library versions across all endpoints and services, flagging those that cannot support PQC without a library update.
• Hardcoded algorithm choices: Layer 2 discovery surfaces algorithm choices baked into application code. These cannot be changed by configuration; they require code changes, build cycles, and deployments. Discovery must flag them as requiring a different remediation track from configuration changes.
• Counterparty dependencies: Systems that must maintain interoperability with counterparties that have not yet migrated will require hybrid mode deployment during the transition period. Discovery must identify counterparty dependencies that constrain the migration timeline.
• HNDL exposure: Discovery must map algorithm use to data confidentiality lifetime so that systems transmitting data with long-term confidentiality requirements encrypted under quantum-vulnerable algorithms can be flagged for earliest migration.

Cryptographic Discovery Implementation Checklist

• Deploy passive network sensors at key aggregation points to capture live TLS handshake metadata from production traffic
• Run static code analysis across all first-party source code repositories and scan third-party dependency trees
• Query Certificate Transparency logs against all your domains to surface shadow certificates not in your managed inventory
• Scan cipher suite configurations on all load balancers, firewalls, and VPN concentrators
• Execute runtime or binary analysis on all vendor appliances, OT systems, and firmware in scope
• Conduct structured interviews with platform and system owners to surface custom protocols and undocumented integrations
• Capture HSM model and firmware version for all assets using an HSM; document vendor PQC support roadmap
• Capture TLS library versions across all endpoints and services; flag those requiring updates for PQC key exchange
• Map algorithm use to data confidentiality lifetime to identify HNDL-exposed systems for priority migration
• Assign ownership to every discovered asset; route remediation to the responsible team
• Tag every discovered asset against DORA Article 9, PCI DSS 12.3.3, CNSA 2.0, and NIST IR 8547 as applicable
• Integrate discovery tooling with DevSecOps pipeline so new deployments update the inventory before reaching production
• Establish continuous Certificate Transparency log monitoring to surface newly issued or expiring certificates

How Encryption Consulting Can Help You Build Your Cryptographic Inventory

Understanding the discovery problem is the first step. Having the right platform to execute on it is the second, and that is where CBOM Secure comes in.

CBOM Secure is Encryption Consulting’s Automated Cryptography Discovery and Inventory (ACDI) platform, purpose-built to execute all five discovery layers as a single integrated capability. Passive network sensors capture live protocol negotiation on production traffic. Static analysis integrates directly with version control systems to scan first-party code and third-party dependency trees. Certificate enumeration runs continuously against CT logs and certificate management systems. Cloud API queries cover encryption-at-rest and key management configurations across connected cloud accounts. Manual investigation workflows feed directly into the living CBOM, ensuring that nothing discovered outside automated tooling falls through the cracks.

Every CBOM entry is automatically enriched with quantum vulnerability status, ownership routing, and regulatory compliance gap tagging against DORA, PCI DSS 4.0, and NIS2, so your team is always working from a prioritized, contextualized picture of the estate, not a raw findings collection.

CBOM Secure does not produce a list of findings and leave your team to determine how to address them. It produces a governed, continuously maintained system of record that converts discovery into action, from the first scan through every subsequent change in your environment.

Where to Start

The full scope of a cryptographic inventory can feel overwhelming. It does not need to be approached all at once.

• Start with Layers 1 and 3: Your load balancers, VPN concentrators, and reverse proxies are already in your CMDB, have identifiable owners, and their cryptographic configurations are discoverable with tooling most organizations already have. Certificate Transparency log queries require no additional infrastructure.
• Build the inventory incrementally, not all at once: The Applied Quantum PQC Migration Framework recommends achieving comprehensive Layer 1 and Layer 2 coverage first, a timeline of weeks to months depending on estate size, and beginning risk assessment on those entries immediately rather than waiting for a complete inventory before starting any remediation. You can start sequencing fixes on what you already know while continuing to build visibility into the rest.
• Engage your strategic vendors now: If any vendor-supplied component in your environment depends on a cryptographic library or HSM whose post-quantum upgrade path has not been communicated, that conversation needs to start today. Vendor timelines are entirely outside your control. The only variable you can influence is when you begin the engagement.

Conclusion

The cryptographic discovery problem is not a future challenge; it is an active one. Most organizations are operating with significant gaps between what they believe their cryptographic estate contains and what is actually running in production. Those gaps are not benign. They are the reason migration projects stall, compliance audits surface findings nobody anticipated, and remediation timelines stretch far beyond original estimates.

The SHA-1-to-SHA-256 migration was estimated to take five years. It took more than ten. The post-quantum transition is larger in every dimension, and the compliance obligations under DORA and PCI DSS 4.0 are already in effect. Every month without a complete, governed inventory is a month of compounding risk. Knowing what you have is not the finish line. It is the starting line. But it is the one that every other initiative, compliance, migration, and governance, depends on crossing first. For what to do with what you find, see Why Your Cryptographic Inventory Is Your Master Key and Why a CBOM Is Essential Now More Than Ever. For PQC migration planning, see Unlocking the Quantum Era: Essential Steps for Post-Quantum Cryptography Readiness.

Part 2 of this series covers what to do with what you find: how a Cryptographic Bill of Materials transforms discovery data into a governed system of record, and how to use it to drive compliance evidence, risk prioritization, and PQC migration planning.

Frequently Asked Questions

What is cryptographic discovery and why is it different from a certificate inventory?

Cryptographic discovery is the multi-layer process of identifying every algorithm, key, certificate, protocol, and cryptographic library in use across an organization’s environment. It is different from a certificate inventory because certificate management platforms only manage certificates registered with them; they miss shadow certificates, east-west traffic cipher suites, hardcoded keys in source code, and cryptographic choices in vendor appliances and OT systems.

What compliance requirements make cryptographic discovery mandatory today?

DORA Article 9.2 has required financial entities to maintain a documented cryptographic asset register since January 17, 2025. PCI DSS Requirement 12.3.3 has required a continuously maintained cipher suite inventory since March 31, 2025. Both are active enforcement obligations. An organization that cannot produce the required documentation during a supervisory review has a gap in an enforceable requirement in effect since early 2025.

What are the five cryptographic discovery layers and what does each one uniquely find?

Layer 1 (passive network analysis) reveals what protocols are actually negotiated in production traffic. Layer 2 (static code analysis) finds hardcoded keys and deprecated library imports fixed in application logic. Layer 3 (configuration and certificate scanning) covers cipher suite policies and shadow certificates via CT logs. Layer 4 (runtime and binary analysis) is the only viable method for vendor appliances and OT systems without source code access. Layer 5 (manual investigation) surfaces custom protocols and undocumented integrations that automated layers miss.

Why do existing tools like vulnerability scanners and CMDBs have structural blind spots?

Certificate management platforms manage only registered certificates. Vulnerability scanners report on reachable services but not east-west traffic cipher suites. CMDBs capture officially provisioned infrastructure but miss cloud resources deployed outside standard workflows, OT devices from facilities management, and systems from acquisitions never integrated into the asset register. These are design limitations, not tool failures; each tool was built for a purpose that was not cryptographic discovery.

How does cryptographic discovery support PQC migration under NIST FIPS 203, 204, and 205?

Cryptographic discovery provides the baseline inventory required before PQC migration can be planned or scoped. NIST finalized FIPS 203, 204, and 205 in August 2024. Knowing which algorithms to migrate to is only half the problem. The other half is knowing which systems run RSA, ECDH, ECDSA, and Diffie-Hellman, in what context, and with what hardware and software dependencies that constrain the migration timeline. Discovery identifies HSM firmware support gaps, TLS library version constraints, hardcoded algorithm choices requiring code changes, and HNDL-exposed systems requiring earliest migration.