How to Prioritize Cryptography for PQC Migration
Once an organization begins preparing for the Quantum Era, a practical problem appears almost immediately: there is too much to change.
Cryptography is embedded almost everywhere. It sits inside applications and networks, identity systems and certificates, databases, devices and hardware, including systems that may have been operating for years. Discovering where all of that cryptography lives is difficult enough. Deciding what to do with it is another problem entirely.
Few organizations can replace everything at once, nor would it necessarily make sense to try. They must decide where to begin.
That decision is sometimes framed as preparation for a future quantum threat. The assumption is understandable: quantum computers capable of threatening widely used public-key cryptography do not yet exist at the scale required, so migration can appear to be preparation for something that may happen years from now.
For some information, however, the security problem has already started.
The reason is commonly described as ׳Harvest Now, Decrypt Later׳. An adversary does not necessarily need to break protected information today to benefit from obtaining it. Encrypted data or communications can be intercepted and stored now in the hope that future capabilities will make it possible to decrypt them later.
That creates an important distinction. The arrival of a cryptographically relevant quantum computer may be uncertain and still years away, but information created today may need to remain confidential well beyond that point. If it can be harvested today and decrypted later, the date of the future breakthrough is not the date on which the risk begins.
For organizations holding long-lived sensitive information, PQC migration is therefore more than preparation for a distant technological change. Decisions made today can affect whether information captured today remains protected years from now.
This is where prioritization becomes important.
Not everything has the same deadline
In previous articles, I introduced the Three Clocks of Quantum Readiness: the Data Clock, the Migration Clock and the Quantum Clock. Together, they provide a way to understand why two systems inside the same organization can face very different migration deadlines.
Consider a system that protects information whose sensitivity largely disappears within a year. Its cryptography can be upgraded relatively easily, tested quickly and deployed with limited disruption. Now compare that with a system protecting information that must remain confidential for fifteen years, where the cryptography is embedded in legacy infrastructure, specialized hardware and applications that may take years to change safely.
Both may eventually need to be migrated. They do not, however, need to begin at the same time.
The second system may require attention much earlier, even though it is technically harder to address. Its fifteen-year Data Clock means that information protected today may still need to remain confidential during a period in which quantum capabilities could become relevant. ׳Harvest Now, Decrypt Later׳ makes that overlap particularly important because waiting for the quantum threat to materialize before protecting long-lived information may already be too late.
The Migration Clock adds another constraint. If changing the system will take five years rather than five months, that time has to be included in the calculation. A long migration cannot simply be postponed until the threat appears more immediate, because the organization may no longer have enough time to complete it safely.
This is why the three clocks need to be considered together. The Data Clock tells us how long information needs to remain protected. The Migration Clock tells us how long changing the systems protecting it may take. The Quantum Clock represents the uncertain external horizon against which both timelines have to be considered.
A future quantum capability can therefore create a security deadline today.
What is at stake?
Once that is understood, migration priority begins with the information and functions being protected. Cryptography itself does not tell an organization how important a system is. The context around it does.
Some information loses its value quickly. Other information may remain sensitive for a decade or more. Intellectual property, government information, personal records, strategic communications and other long-lived data can continue to matter long after they were originally created.
The consequences also extend beyond confidentiality. Cryptography is used to establish identities, authenticate systems, verify software and protect the integrity of transactions and communications. The importance of a cryptographic dependency therefore depends on the role it plays as well as the data it protects.
The answers will differ across organizations. A pharmaceutical company may be particularly concerned about research and intellectual property that must remain confidential for many years. A government agency may focus on classified or sensitive national-security information. A financial institution may have different concerns around identities, transactions and critical records.
This is why the cryptographic inventory discussed in my previous article is only the beginning. Finding cryptography tells you where it exists. Understanding what it protects tells you why it matters.
That context is what begins to turn an inventory into a migration priority.
How long will change take?
Importance alone does not establish the order of migration. The difficulty of changing the system matters as well.
Some cryptographic changes may be relatively straightforward. A software component might be updated, tested and redeployed without major disruption. Others can involve legacy applications, embedded devices, specialized hardware, operational technology, certification requirements or systems that cannot easily be taken offline.
This produces one of the less intuitive aspects of PQC migration: the system that should be started first may not be the system that will be finished first.
A relatively simple migration may be completed quickly. A critical system with a five-year migration timeline will take much longer. If an organization waits three years before beginning work on that system, however, it may have surrendered much of the time it needed to complete the migration safely.
This matters even more when the system protects information with a long Data Clock. If sensitive information is already being generated, transmitted or stored today, the organization cannot assume that the risk begins only when quantum computers become sufficiently capable. ׳Harvest Now, Decrypt Later׳ means that today’s information may already be part of tomorrow’s security problem.
The question is therefore not simply which cryptography is easiest to replace. It is how long the information must remain protected, how difficult the migration will be, and how much time the organization can afford to lose before beginning.
Where the clocks meet
Looking at any one of the Three Clocks in isolation can produce the wrong priority.
Long-lived information may require early attention, but an organization may retain some flexibility if the cryptography protecting it can be changed quickly. A technically difficult system may take years to migrate, but its urgency may be different if the information it protects has little long-term sensitivity.
The greatest pressure appears where those conditions overlap: important information with a long security lifetime, protected by systems that require substantial time to change, against an uncertain quantum horizon.
׳Harvest Now, Decrypt Later׳ adds another dimension to that overlap. It means that an organization cannot simply work backward from an estimated future “Q-Day.” Some of the information that needs protection at that future point is being created and potentially exposed today.
For an organization trying to decide where to begin, this leads to four practical questions: What is at stake? How long does it need to remain protected? How long is the migration likely to take? And, when those answers are considered against the Quantum Clock, when does the work need to start?
Those questions do not produce a simple list of systems ranked from one to one hundred. They produce something more useful: a sequence.
Building the migration sequence
Some systems may require immediate attention because of the sensitivity and lifespan of the information they protect. Others may need migration work to begin early because the technical change itself will take years. Systems with shorter security requirements or relatively simple migration paths may reasonably come later.
This also changes how progress should be measured. A program that reports twenty completed migrations may appear to be further ahead than one that has completed only five. That comparison means little if the second organization has already begun work on its most difficult, long-lead-time systems while the first has left them untouched.
A migration plan therefore needs to show more than what has been completed. It needs to show whether the work that takes the longest, and protects what matters most, started early enough.
That brings the sequence of quantum readiness into sharper focus. Organizations first need to understand their clocks, discover where cryptography exists and determine what it protects. They need clear ownership of the problem. From there, they can establish priorities and build a migration sequence based on the lifetime of the information, the consequences of compromise and the time required to change the systems protecting it.
No organization needs to replace every cryptographic dependency tomorrow. But neither should it assume that the absence of a cryptographically relevant quantum computer today means there is no reason to act.
For long-lived sensitive information, the relevant question is not only when quantum computers may become capable of breaking today’s cryptography. It is whether information being protected today still needs to be secure when that day arrives.
The Quantum Clock has no snooze button. Some of the data it threatens already exists.
Next: Your Quantum Deadline May Belong to Someone Else — What happens when the systems protecting your information depend on vendors, platforms and technology providers whose migration timelines you do not control?
