Before you switch to a new cipher, you need to know what you're already running — and where
Why PQC Migration Conversations Always Start With "What Do We Switch To?"
Ask anyone about PQC (Post-Quantum Cryptography) migration, and the first question that comes up is almost always "which algorithm should we use?" In our earlier piece, we looked at why that question doesn't stop at algorithm selection — it extends into how the keys that algorithm depends on get generated and protected, which is where Key Management and HSMs (Hardware Security Modules) enter the picture.
But there's a question that has to come before all of that. Before deciding which algorithm to adopt or how to manage its keys, an organization has to know what cryptography it's already running, and where. In the industry, this step usually goes by the name Crypto Discovery.
You Can't Prescribe Treatment Without a Diagnosis First
No doctor writes a prescription before finding out what's wrong. History-taking and testing come first; the treatment plan follows only once the actual problem is clear. Skip the diagnosis and jump straight to treatment, and you risk treating the wrong thing entirely — or missing the problem that actually needed urgent attention.
PQC migration isn't so different. Cryptography is scattered throughout an organization — not just in servers and network gear, but in applications, databases, certificates, firmware, aging legacy systems, and even the components and modules a vendor ships as part of a supply chain. Announcing "we're migrating to PQC" without knowing which algorithms and key lengths are running where is a lot like drawing up a treatment plan before running the diagnostic.
What Crypto Discovery Actually Means
Crypto Discovery is the work of finding and cataloging which cryptographic algorithms, key lengths, certificates, and protocols are actually in use across an organization's systems, software, and hardware. The joint quantum-readiness guidance from CISA, the NSA, and NIST makes the same point: the first thing an organization should do is build a cryptographic inventory. That inventory is meant to identify where and how quantum-vulnerable cryptography is protecting an organization's most sensitive data, and how long that data actually needs to stay protected.
In other words, Crypto Discovery isn't just about pulling together a list of ciphers. It's closer to drawing the map that every downstream migration decision — which algorithm, in what order, under what key management model — will be drawn on top of.
There's one common misconception worth clearing up here: building a cryptographic inventory doesn't mean scooping up actual secret key values. NIST NCCoE's PQC migration FAQ is explicit about this — what belongs in the inventory is metadata like key type, owner, associated algorithm, and expiration date, not the key material itself. Crypto Discovery answers "what are we using, where, and why" — it isn't an exercise in centralizing secrets.
The questions an organization needs to ask at this stage are, in fact, fairly simple:
- Which systems and services are actually using cryptography?
- Which algorithms and certificates are in place?
- What data and workflows does that cryptography protect?
- Who actually owns and manages the systems and components involved?
There's nothing exotic about this list. Its value is that it gives security teams and system owners a shared document to start the conversation from.
Why This Step Gets Skipped So Often
A step that sounds obvious in theory gets skipped or shortchanged surprisingly often in practice. The reason is simple: cryptography tends to hide in places that aren't easy to see.
Keys hardcoded into application code, certificates issued years ago and long forgotten, undocumented legacy systems still quietly running, cryptographic functions embedded differently across components and modules from a dozen different vendors — the places where cryptography actually lives in a real environment are usually far more extensive than what a security team has mapped out. Cryptography embedded at the chip or firmware level, in particular, often can't be found through a software scan alone, since it's built into the physical device itself.
That's exactly why the CISA/NSA/NIST guidance frames building a cryptographic inventory as more than an IT task — it's an organization-wide effort that has to reach into supply-chain dependence on quantum-vulnerable cryptography as well.
From Discovery to Build — An Industry Trend Taking Shape
Against this backdrop, a pattern has started to emerge: partnerships that bundle cryptographic asset identification (Crypto Discovery) with PQC- and PUF-based trust infrastructure into a single, continuous migration model.
One example: on September 18, 2026, ICTK signed a memorandum of understanding with information security firm Jiran Security under a project named "Q-BRIDGE," laying out a single business model that runs from cryptographic asset identification and quantum-vulnerability analysis through PQC/PUF-based security infrastructure and on to field validation (PoC). Under the agreement, Jiran Security uses its own Crypto Discovery solution to assess an organization's cryptographic assets and risk exposure, and provides migration recommendations and implementation consulting. ICTK is responsible for the design and supply of CA (certificate authority), KMS (key management system), HSM, and VPN products that combine a PUF-based hardware root of trust with PQC, along with interoperability and security validation and post-deployment technical support. The two companies also plan to jointly develop a migration roadmap and run field PoCs together. (ICTK's press release, Newspim coverage — Korean-language source)
What this example illustrates isn't a particular product bundle so much as a broader shift in thinking: discovery and build are no longer treated as separate tasks owned by separate teams, but as a single flow that has to be designed together. You can't know what to build if you don't first know what you have.
Conclusion — The First Sentence of Any PQC Migration Is "What Are We Running?"
The question that comes up first in most PQC migration conversations is usually algorithm choice — but answering that question well requires knowing, first, what cryptography an organization is running, where, and how. Shortchange this discovery step, and even the most carefully designed algorithm and key-management architecture can miss the point that actually mattered most.
At bottom, PQC migration is less a project to adopt a new cipher than a question about how precisely an organization understands its own cryptographic infrastructure. Only once that question is answered does algorithm selection, key-management design, and hardware-root-of-trust deployment fall into place.
Coming Up Next
This piece focused on why cryptographic assets need to be identified first. The next one picks up from there — turning that diagnostic work into an actual migration roadmap (what changes, on what timeline, which systems need to be validated together) and carrying it through to field validation (PoC).
See For Yourself
☑️ Curious where your organization's PQC migration should start? Visit the ICTK PQC Services page.
☑️ Need guidance on turning cryptographic asset discovery into a PQC infrastructure build? Get in touch with our team.
References
Before you switch to a new cipher, you need to know what you're already running — and where
Why PQC Migration Conversations Always Start With "What Do We Switch To?"
Ask anyone about PQC (Post-Quantum Cryptography) migration, and the first question that comes up is almost always "which algorithm should we use?" In our earlier piece, we looked at why that question doesn't stop at algorithm selection — it extends into how the keys that algorithm depends on get generated and protected, which is where Key Management and HSMs (Hardware Security Modules) enter the picture.
But there's a question that has to come before all of that. Before deciding which algorithm to adopt or how to manage its keys, an organization has to know what cryptography it's already running, and where. In the industry, this step usually goes by the name Crypto Discovery.
You Can't Prescribe Treatment Without a Diagnosis First
No doctor writes a prescription before finding out what's wrong. History-taking and testing come first; the treatment plan follows only once the actual problem is clear. Skip the diagnosis and jump straight to treatment, and you risk treating the wrong thing entirely — or missing the problem that actually needed urgent attention.
PQC migration isn't so different. Cryptography is scattered throughout an organization — not just in servers and network gear, but in applications, databases, certificates, firmware, aging legacy systems, and even the components and modules a vendor ships as part of a supply chain. Announcing "we're migrating to PQC" without knowing which algorithms and key lengths are running where is a lot like drawing up a treatment plan before running the diagnostic.
What Crypto Discovery Actually Means
Crypto Discovery is the work of finding and cataloging which cryptographic algorithms, key lengths, certificates, and protocols are actually in use across an organization's systems, software, and hardware. The joint quantum-readiness guidance from CISA, the NSA, and NIST makes the same point: the first thing an organization should do is build a cryptographic inventory. That inventory is meant to identify where and how quantum-vulnerable cryptography is protecting an organization's most sensitive data, and how long that data actually needs to stay protected.
In other words, Crypto Discovery isn't just about pulling together a list of ciphers. It's closer to drawing the map that every downstream migration decision — which algorithm, in what order, under what key management model — will be drawn on top of.
There's one common misconception worth clearing up here: building a cryptographic inventory doesn't mean scooping up actual secret key values. NIST NCCoE's PQC migration FAQ is explicit about this — what belongs in the inventory is metadata like key type, owner, associated algorithm, and expiration date, not the key material itself. Crypto Discovery answers "what are we using, where, and why" — it isn't an exercise in centralizing secrets.
The questions an organization needs to ask at this stage are, in fact, fairly simple:
There's nothing exotic about this list. Its value is that it gives security teams and system owners a shared document to start the conversation from.
Why This Step Gets Skipped So Often
A step that sounds obvious in theory gets skipped or shortchanged surprisingly often in practice. The reason is simple: cryptography tends to hide in places that aren't easy to see.
Keys hardcoded into application code, certificates issued years ago and long forgotten, undocumented legacy systems still quietly running, cryptographic functions embedded differently across components and modules from a dozen different vendors — the places where cryptography actually lives in a real environment are usually far more extensive than what a security team has mapped out. Cryptography embedded at the chip or firmware level, in particular, often can't be found through a software scan alone, since it's built into the physical device itself.
That's exactly why the CISA/NSA/NIST guidance frames building a cryptographic inventory as more than an IT task — it's an organization-wide effort that has to reach into supply-chain dependence on quantum-vulnerable cryptography as well.
From Discovery to Build — An Industry Trend Taking Shape
Against this backdrop, a pattern has started to emerge: partnerships that bundle cryptographic asset identification (Crypto Discovery) with PQC- and PUF-based trust infrastructure into a single, continuous migration model.
One example: on September 18, 2026, ICTK signed a memorandum of understanding with information security firm Jiran Security under a project named "Q-BRIDGE," laying out a single business model that runs from cryptographic asset identification and quantum-vulnerability analysis through PQC/PUF-based security infrastructure and on to field validation (PoC). Under the agreement, Jiran Security uses its own Crypto Discovery solution to assess an organization's cryptographic assets and risk exposure, and provides migration recommendations and implementation consulting. ICTK is responsible for the design and supply of CA (certificate authority), KMS (key management system), HSM, and VPN products that combine a PUF-based hardware root of trust with PQC, along with interoperability and security validation and post-deployment technical support. The two companies also plan to jointly develop a migration roadmap and run field PoCs together. (ICTK's press release, Newspim coverage — Korean-language source)
What this example illustrates isn't a particular product bundle so much as a broader shift in thinking: discovery and build are no longer treated as separate tasks owned by separate teams, but as a single flow that has to be designed together. You can't know what to build if you don't first know what you have.
Conclusion — The First Sentence of Any PQC Migration Is "What Are We Running?"
The question that comes up first in most PQC migration conversations is usually algorithm choice — but answering that question well requires knowing, first, what cryptography an organization is running, where, and how. Shortchange this discovery step, and even the most carefully designed algorithm and key-management architecture can miss the point that actually mattered most.
At bottom, PQC migration is less a project to adopt a new cipher than a question about how precisely an organization understands its own cryptographic infrastructure. Only once that question is answered does algorithm selection, key-management design, and hardware-root-of-trust deployment fall into place.
Coming Up Next
This piece focused on why cryptographic assets need to be identified first. The next one picks up from there — turning that diagnostic work into an actual migration roadmap (what changes, on what timeline, which systems need to be validated together) and carrying it through to field validation (PoC).
See For Yourself
☑️ Curious where your organization's PQC migration should start? Visit the ICTK PQC Services page.
☑️ Need guidance on turning cryptographic asset discovery into a PQC infrastructure build? Get in touch with our team.
References