Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
Key takeaways
Ask a security team where its quantum-vulnerable cryptography lives in the software being run, and the answer usually arrives in pieces. The code scanner reports on first-party repositories, the dependency inventory lists declared packages, the certificate platform tracks the certificates it manages, and vendor questionnaires fill in the rest.
Each tool reports accurately on what it was built to see. The trouble is the layer none of them inspects: the cryptography compiled into the commercial and third-party software the organization runs every day.
The gap is rarely obvious from inside a mature security program, because every tool in the stack produces clean, confident output. The National Cybersecurity Center of Excellence (NCCoE) at NIST put the underlying problem plainly in its post-quantum migration project materials: "Organizations are often unaware of the breadth and scope of application and function dependencies on public-key cryptography."
That lack of awareness matters more now that the post-quantum algorithms are finalized and migration deadlines are being set. A post-quantum cryptography (PQC) program can't sequence a migration around algorithms it hasn't found, and the ones most likely to be missed are the ones buried in software nobody on the security team wrote, noted Prathibha Rama, computer engineering and security researcher at the Johns Hopkins University Applied Physics Laboratory.
None of the tools below is broken. Each was designed to answer a specific question, and each answers it well. The blind spot appears only when a team asks them to answer a question none of them was designed for: what cryptography is inside the software we run?
Static application security testing (SAST) and code scanners see the cryptographic API calls in code the organization writes. That makes them useful for catching a developer who reaches for MD5 in a new service. They can't analyze what they can't read, however, and most of the software in a typical enterprise arrives without source: commercial applications, prebuilt libraries, SDKs, drivers, and appliance firmware. Even for first-party code, a source scan describes intent, not the final build, which can link in a different library version or pull in cryptography through the build toolchain.
Software composition analysis (SCA) tools and the software bills of materials (SBOMs) typically generate a list the packages an application declares in its manifest and lock files. They answer "which components are supposed to go into this build?" and they answer it well. Similarly, SBOMs generated from the final build is a more comprehensive list of components in the software as distributed. Without additional analysis, they can't report is which algorithms those components run, what key sizes they use, or whether a vendor statically linked or copied a cryptographic library into its own code, where no manifest records it, noted vice John Gallagher, vice president at Viako, in a report on RL Blog.
"Generating an SBOM based on binary code analysis can catch transitive dependencies that can lead to security and privacy issues compared to generating an SBOM through source code analysis."
—John Gallagher
Certificate lifecycle and key management platforms track the certificates and keys they issue or discover in keystores, directories, and endpoints. They are essential for renewals and revocation, but their view stops at the credentials they know about. Certificates and keys bundled inside application packages or hard-coded into binaries often never reach a managed store. Many quantum-relevant algorithms also never appear in a certificate at all, including the key-exchange mechanisms, symmetric ciphers, and hash functions that applications call directly.
Network analysis tools observe the algorithms negotiated in live handshakes, and runtime tools see the code paths that execute while they are watching. Both report what happens in traffic and memory during an observation window. Neither sees cryptography that protects data at rest, signs code or firmware, runs in batch jobs outside the window, or sits on fallback paths that execute only when something fails. Encrypted handshakes also limit what passive observers can see; TLS 1.3, for example, encrypts the server's certificate in transit.
For commercial software, many organizations fall back on asking the vendor. A questionnaire reflects what the vendor knows and chooses to disclose, and vendors often have incomplete visibility into the third-party components inside their own products. Federal guidance anticipates this: the 2023 quantum-readiness factsheet from CISA, the NSA, and NIST warns that "discovery tools may not be able to identify embedded cryptography used internally within products, hindering discoverability or documentation," and directs organizations to their vendors instead. An attestation can help, but it rests on trust rather than evidence.
Similarly, Gartner’s guidance for cybersecurity leaders is to select cryptographic discovery tools and processes that support an ongoing crypto-agility program, not just a one-time inventory. That is a different job from the one vendor questionnaires are designed to do.
Put the five views side by side and the uncovered layer comes into focus. It is the final software artifact: the compiled binaries, packages, containers, and installers that run in production, including every commercial off-the-shelf (COTS) product the organization has bought. Coverage of that layer depends on source code the organization doesn't have, manifests vendors don't publish, traffic that may never be observed, or disclosures that may never come.
Independent research points to the same fragmentation. In a benchmark of cryptographic asset discovery tools presented at the ARES 2026 conference, researchers described "a fragmented open-source landscape, with significant gaps observed in some categories and strengths in others," and found "deficits in detection completeness and accuracy." Their recommendation was to orchestrate several tools rather than rely on any one.
The missing view is filled by analyzing the software artifact itself. Binary analysis inspects the compiled package directly, so it can identify the algorithms, certificates, keys, and protocols inside whether or not source code, a manifest, or a vendor disclosure exists. The results can be recorded as a cryptography bill of materials (CBOM) in CycloneDX format, which ties each cryptographic asset to the component that contains it.
Supply chain guidance has been moving in this direction for broader reasons. The Enduring Security Framework (ESF), a public-private working group led by the NSA and CISA, recommended in December 2023 guidance that "before shipping the software package to customers, the developer or supplier should perform binary composition analysis to verify the contents of the package." The same logic applies to cryptography. Reading source code is not the same as knowing what shipped, noted Matt Rose, former field CISO at ReversingLabs.
"It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business."
—Matt Rose
Artifact-level analysis doesn't replace the rest of the stack. Network tools still show what production traffic negotiates, and certificate platforms still manage renewals. What artifact analysis adds is the baseline inventory the other tools assume someone already has.
A team can find out in an afternoon whether its current tools share this blind spot. Pick three business-critical commercial applications the organization runs and try to answer these questions from tool output alone, without asking the vendor:
If any answer depends on a vendor's word or on source code the team doesn't have, the stack has a visibility gap. The good news is that closing it doesn't require you to already support for post-quantum algorithms, especially since new cryptography is not a simple drop-in replacement. The first job of a cryptographic inventory is to find the quantum-vulnerable cryptography already in production, such as RSA and elliptic-curve cryptography (ECC), and that work can start now. For a primer on what that inventory should contain, see, What a CBOM Is, and Why an SBOM Won't Answer the Quantum Question.
-1400x732.jpg&w=3840&q=75)
Post-quantum readiness depends on knowing where cryptography lives in the software you run, and a list of components can't tell you that.
Here’s a look at the Ethereum Foundation’s new PQC security effort — and why you need to modernize your SecOps.
Learn how RL Spectra Assure’s Cryptography Bills of Materials can help you achieve crypto-agility — and secure your software supply chain.