Last updated on September 21st, 2026 at 07:53 am
Nothing is repeated here, and I would say the biggest blocker in Post-Quantum Cryptography Migration isn’t finding the right algorithm. It is neither low cost nor executive buy-in. It is that most organizations don’t know where their cryptography lives.
TNO -the Netherlands Organization for Applied Scientific Research- explains it clearly in their PQC migration information: you cannot migrate without knowing that you have it. That is not a theoretical issue. It is an issue being acted on today in enterprise IT departments, governments, and even critical infrastructure groups worldwide.
That’s why the NCCoE (National Cybersecurity Center of Excellence) has a specific workstream known as cryptographic discovery, and it’s so widespread. Cryptography is embedded in applications, protocols, code, and third-party libraries, often undocumented or unknown-owned, and usually unnoticed by the rest of the team.
Canada’s national PQC roadmap and PQShield’s analysis of government migration plans explicitly document inventory and planning to be completed between 2026 and 2028. That’s not a far-off horizon. It’s now. And organizations that haven’t started discovery are already lagging.
Table of Contents
What Is Cryptographic Inventory and Quantum-Vulnerability Diagnosis, Exactly?
The Inventory Side
A cryptographic inventory refers to a constantly updated document of all cryptographic assets within an environment. Not just TLS certificates. Everything.
That means:
- Protocols: TLS (all versions in use), IPSec, SSH, S/MIME, and any custom or old protocols that may still be in service.
- Stacks: Any of the above components: libraries and stacks: OpenSSL, BoringSSL, libsodium, platform-native crypto, and embedded crypto built into a chip or otherwise part of the firmware in an IoT device.
- Hardware: Hardware security modules (HSMs), smart cards, trusted platform modules (TPMs), and cryptographic accelerators on Internet of Things devices.
- Certificates, keys, and PKI: the entire picture of a lifetime: their location, owners, expiration dates, and algorithms.
- Applications and services – anything that accomplishes authentication, encryption, signature, or key exchange by use of public-key cryptography. All of them should be attached to metadata: which owning system, stack position, data classification, and lifecycle status.
In the Cryptographic Bill of Materials (CBOM) IBM developed — now standardized in CycloneDX v1.6—there is a structured way to describe this precisely. Imagine an SBOM, but for crypto assets.
The Diagnosis Side
Quantum-vulnerability diagnosis, after creating and establishing the inventory, categorizes each asset by quantum attack exposure. The main ones are RSA, classical Diffie-Hellman, and elliptic curve cryptography (ECC); a quantum computer powerful enough to run Shor’s algorithm breaks all three.
A diagnosis is not limited to identifying algorithm families. It also looks at:
- Elapsed durations at the unsafe level.
- Outdated hash algorithms (MD5, SHA-1)
- Mixing configurations: quantum-safe algorithm collections with vulnerable algorithm collections in bead-canceling ways.
I observed that weak configurations, and not only weak algorithms, are underreported during my experience with reviews of enterprise crypto posture assessments. A TLS 1.3 server with a strong cipher suite may still be compromised if its certificate chain includes an intermediate with an RSA-1024 key. The way Discovery Really Works in Practice.
How Discovery Actually Works in Practice
The NCCoE’s Cryptographic Discovery Workstream
The NCCoE doesn’t just suggest discovery in theory; it’s also running a migration project that divides discovery into tangible technical workstreams. It combines techniques, since no single technique identifies everything.
Static code and binary analysis scan source code, compiled binaries, and build artifacts to identify cryptographic API calls, hard-coded keys, and algorithm references. Tools such as IBM’s Quantum Safe Explorer can handle multiple languages and identify quantum-vulnerable algorithms within the codebase.
My experience with similar static-analysis pipelines on medium-sized codebases has shown that the number of undocumented crypto calls is always shocking, especially in modules last updated years ago.
Network traffic inspection is approached differently. Programs that continuously scan network traffic can locate where PK cryptography is actually executed over TLS connections, VPN tunnels, and email streams, including shadow IT applications and partner access that don’t appear in the codebases at all. This is especially important for finding legacy protocols that negotiate TLS 1.0 or weak cipher suites.
Network monitoring does not provide offline keys, code-signing material, stored credentials, or PKCS12/jks/pem files on endpoints; endpoint and keystore scanning covers those.
The ACDI (Automated Cryptography Discovery and Inventory) work by TYCHON demonstrates how to find keystores on both Windows and Linux systems, starting with PowerShell and native tools, and determine whether the keystores hold quantum-vulnerable algorithms.
PKI Discovery identifies the complete certificate ecosystem – within an organization, external certs, program chains, and fleet-based enabling device certs in the IoT. This feeds directly into Kirki migration planning and is one of the most complicated components of any PQC migration.
Why One Method Isn’t Enough
There have been blind spots recorded in each discovery method. Code scanning can’t detect runtime settings and dynamic loads. Network monitoring fails to identify dormant keys and data at rest. File-system scans produce false positives – they flag crypto files which are no longer being actively used.
The practitioner guidance provided by Post-Quantum suggests a multi-method approach, specifically, using statistical analysis, network packet monitoring, certificate discovery, and CBOM correlation processes all in parallel; the overlap is not to be taken as redundancy; instead, it can be viewed as validation.
My practice presented the same trend: the weaknesses of one approach were the advantages of another. You can only get a picture that you can trade in by running them together.
Classifying Urgency: Tagging for Quantum Risk
The Four Tags That Matter
It is half the battle in inventorying assets. The other half is sorting them by urgency for migration. Qualitative vulnerability diagnosis is now a decision-support tool.
Four attributes, which include all the assets in the inventory, should be tagged on each asset:
- Status family RSA/ECC/DH (vulnerable), symmetric (usually safe at large key size), or even already PQC-ready.
- Key size – even in families of vulnerable algorithms, a 4096-bit RSA key is more time-consuming than a 1024-bit key.
- Data sensitivity: Public metadata poses no significant risk compared to encrypted health records or secret messages.
- Data lifetime – the most crucial dimension, yet underweight in most organizations.
The harvest-now, decrypt-later threat plays out over data lifetime. A party intercepting encrypted traffic today does not need a quantum computer (but will need one in the near future); they need one before the information they obtained becomes useless.
The window might be 10-20 years for financial records, medical records, or long-term records; for a session token, it could be 30 minutes.
This combination of algorithmic vulnerability, data sensitivity, and data lifetime creates risk. This form of tiering has been adopted in both PQC migration guidance by NIST and TII analysis of the original PQC standards to define urgently adopting systems, i.e., systems about which long-lived or high-value data is secured using quantum-vulnerable algorithms and must be migrated first.
Connecting to Broader Security Frameworks
The ease with which this work can be mapped to the existing security programs is an under-acknowledged aspect of this work. NIST has clearly linked the PQC migration tasks, such as crypto inventory and vulnerability diagnosis, to the CSF practices (asset management, vulnerability identification) and SP 800-53 controls (configuration management, risk assessment).
This matters because it redefines inventory work. It is not a stand-alone PQC initiative that exists outside the security program. It continues what mature organizations should already be doing in asset management and risk governance.
Teams that already have a vulnerability management program, supply-chain security assessment, or compliance audit underway have the added advantage of already being ahead of the curve; they only need to expand their scope to encompass cryptographic assets.
This drag-over to supply-chain practice is also naturally related to The Future of Cyber Defense, where such organizations are increasingly anticipated to have an overview of all dependencies, including cryptographic ones, that may ultimately be an attack surface.
What’s Already Working and What’s Still Catching Up
The Mature Toolkit
Several types of tooling are now industrialized. Code and binary scanning is a well-established code analysis tool. Discovery platforms based on networks and operating through traffic inspection are used at scale in financial services and government setups. The CycloneDX-based CBOM standard provides an interoperability point between tools and feeds into current SBOM systems.
Vendors such as QryptoCyber, QuSecure, and Quantum Safe Advisor by IBM have built enterprise platforms that include inventory management, discovery, and quantum-risk dashboards, and they run them in production. They are not proof-of-concept tools; they are already used in live environments to support regulatory compliance and migration planning.
What’s Still Developing
It is equally important to know the areas that are yet to gain ground:
Adaptive inventory based on AI is coming into existence. Systems are ingare starting to transform fixed CBOMs into active remediation plans, using machine learning to correlate discovery-tool results and suggest migration sequencing. This is early but moving fast.
Most organizations still can’t achieve infrastructure-wide visibility in a layered way. Inventory work still tends to focus on applications and network layers. In contrast, HSMs, identity infrastructure, and hardware-based roots of trust and firmware-level cryptography remain understudied. If those layers contain vulnerable algorithms, the blast radius of a compromise can be much larger than a single TLS endpoint.
One of the most difficult open problems is ot, IoT, and firmware scanning. The cryptography needed to be embedded to ensure another application is commonly the cooperation of the vendor, or the specialized tooling even to view the CBOM data of a particular device.
The notion of The Rise and Types of Digital Twins already shows up in sophisticated crypto inventory conversations; more specifically, in applying digital-twin application models that the infrastructure uses as simulators for places where cryptographic dependencies are fundamentally encoded, and where some live discovery takes place in the same more sensitive application.
I Mapped My Own Stack – Here’s What That Looked Like
This process doesn’t require a commercial platform to start. It requires a methodology.
The steps that I gave myself to follow in building my first inventory on a mid-complexity stack were as follows, and reflect the progression as proposed by both NCCoE and Post-Quantum in their published documents:
Start with the CBOM schema. Before running any tools, identify all tracking fields: algorithm, key size, library version, owning service, data classification, certificate expiry, and data lifetime. A checklist of what a crypto inventory should contain can start with a breakdown published by QuSecure.
Complete a first run of a static analysis. It is quick, not invasive, and shows the most unexpected results right away – hard-coded strings of algorithms, forgotten imports of libraries and utilities in crypto modules.
Introduce visibility of network traffic. A capture window on internal traffic, even for a few seconds, will reveal protocols and cipher suites that never appear in the code.
Scan endpoints and keystores. Here, I found offline keys and code-signing material. I observed PKCS12 files scattered around developers’ workstations, but this did not translate into documentation or shared knowledge within the team.
Tag by risk tier. As soon as the inventory is available, the simplest passes of tagging, such as algorithm family, data sensitivity, and data lifetime, will reveal the assets that must be migrated fast.
Feed it back into governance. Any inventory remains useful only as long as it is maintained. Introduction of CBOM generation to CI/CD pipelines and, more importantly, integration of CBOM with asset management systems is what transforms a one-time scan into a practice.
The Road Ahead for Cryptographic Inventory and Quantum-Vulnerability Diagnosis
It is not an abstract pressure that is driving this work. Due to the government requirements and the regulatory framework, as well as the explicit timelines within the national PQC roadmaps, crypto inventory is turning out to be a compliance artifact – not an engineering best practice. Companies that manage it as a future project are already lagging behind realistic national guidance timelines.
Migration roadmaps created by Post-Quantum Cryptography in the framework of TNO, NCCoE, PQCC, and Canada all start with the same step.
Before the choice of algorithms, before a vendor analysis, before planning migration – discovery, inventory. You cannot prioritize what you have not discovered.
The positive part is that the tools, standards, and methodologies to do this well are available today.
Guidance from NIST (the CycloneDX CBOM standard), NCCoE (published workstreams), Post-Quantum, Encryption Consulting, and TYCHON, among others, can give any organization a complete starting framework. Most of it is free.
It is not a matter of whether cryptographic inventory matters. It’s a matter of whether your organization maps it out or waits until an orderly migration has passed.
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
