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.

The result is predictable. Organizations accumulate cryptographic debt for years without realizing its full extent. SHA-1 persists in systems no one has touched in years. Triple-DES still runs on payment terminals configured in a different era. Hardcoded keys sit in repositories that developers long since moved on from. Certificates operate on infrastructure that no one formally owns. And somewhere in your cloud environment, a microservice is running with default encryption settings that no one ever deliberately decided on.

This is the cryptographic discovery problem, and it sits underneath every other cryptographic initiative your organization will need to execute. Compliance readiness, post-quantum migration, certificate lifecycle management, and key governance: all of them require knowing what you have before any meaningful work can begin.

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. 

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, 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 & Certificate Scanning	Cipher suite policies on managed infrastructure; shadow certificates via CT logs
Runtime & 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, such as 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.

The Compliance Obligations Are 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 the start of this year.

The business case for building a cryptographic inventory does not require a quantum threat assessment or a formal mandate for a post-quantum migration. The compliance case alone has been more than sufficient justification since January 2025.

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 leaves 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.
• 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. The organizations that build that visibility now are the ones that will be ready when it matters.

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.