Before the Algorithm: Where a Post-Quantum Plan Really Starts

The deadline is on the calendar and nobody's name is next to it yet. That may be exactly where you are right now. The mandate landed, or a prime wrote the requirement into your next contract, and the work is real, but it hasn't been handed to anyone. The instinct at this point is to jump straight to the algorithm question: which one, and how fast can we move.

Hold that thought. A post-quantum plan runs through a few phases before the algorithm ever matters, and skipping them is how a good migration turns into one you have to do twice. Here is what those phases are.

Phase one: who owns it

The first phase is a name. These programs rarely stall on the cryptography. They stall because no single person owns the outcome. The work touches infrastructure, applications, procurement, and whoever talks to your providers, so it needs one person with the reach to move across all of them.

The natural home for this is the CISO, or someone the CISO hands real authority to. The pieces it depends on already live there: key and certificate management, cryptographic policy, vendor security requirements, and the compliance reporting a mandate demands. Give it to someone without that authority and the work stalls at the first team that pushes back. In a larger shop the owner chairs a small standing group and carries the accountability, so the decision always has somewhere to land.

Until that person exists, everything after this stays a conversation. If you are reading this and the name still isn't decided, that is the first move, and it costs nothing but a decision.

Then that owner pins the deadline that actually binds you. That means the specific regulation or contract clause that names your sector and your systems, the one that actually applies, rather than the headline year everyone quotes. That single date sizes everything downstream: what you fix first, how fast, and what leadership needs to hear. A plan without it has no scale.

Phase two: find out what you have

You can't plan for cryptography you can't see. You probably don't have the full picture yet: where cryptography lives, what it protects, how long that data has to stay secret, and the part that quietly sets your timeline, which of it you can actually change. This is the inventory, and it is why the first artifact is a bill of materials.

The cryptography you can't easily change is what you plan around first. Some of it is welded in:

Phase three: the hard calls

Once you can see what you have, you prioritize. That means choosing between good options under a real constraint, and it is rarely the clean swap people picture.

I have sat in this phase myself. At FEDLIN I own our own post-quantum posture, and a while back I had to make exactly this kind of call on our own cluster. We were running post-quantum key exchange across it, ahead of any requirement telling us to. Then we moved the cluster onto a FIPS-validated operating system, and that validated baseline would not run the particular post-quantum hybrids we had deployed. So inside the cluster, I gave them up.

On paper that reads like a step backward. It wasn't. The same move meant the cluster stopped negotiating deprecated cipher suites. At the platform layer, the baseline now runs on validated, approved algorithms, with the weak and legacy options gone. I traded the newest post-quantum key exchange for a hardened, validated floor, on purpose, because of where we are headed and what will be required of us there. The public edge never stopped speaking post-quantum. And because we keep the inventory and the roadmap current, the in-cluster post-quantum comes back the day the validated toolchain supports it.

The call was a deliberate tradeoff, written down and reversible. That is the payoff of treating it as a capability instead of a one-time swap: you can change it again.

Your version of that call comes down to two forces. The first is Harvest Now, Decrypt Later: an adversary does not need a quantum computer today to put you at risk today, because they can capture your encrypted traffic now and hold it until the means to read it arrives. So the data with the longest secrecy lifetime, and the key establishment that guards it, goes to the front of the line. The second is feasibility: what you can actually change once you account for the dependency chains and the change management that real systems carry. You act where those two meet, the high harvest exposure you can also move, and you stage the rest.

Phase four: a roadmap you can act on

What comes out the other side is a sequence you can act on. Ranked by how long the data has to stay secret and how far a failure would spread, key establishment first. That is the roadmap: the thing you take to leadership, and the thing you re-run when the next standard lands instead of starting over.

The first move on that roadmap is a small, reversible pilot: a hybrid handshake on a single service that runs the old and new key exchange together, so you prove it against your own stack before you bet the estate on it.

We hold our own infrastructure to this same crypto-agility program: a written post-quantum standard, an inventory of the cryptography we actually run, and a roadmap we revisit as the standards and our own requirements move. The FIPS call above was one entry in it, logged and reversible, made the way I would want a client's made. The instinct for this comes from somewhere: a decade in enterprise security operations and vulnerability management, at healthcare, financial services, telecom, and retail scale, where you learn how change like this holds together or falls apart. See it, rank it, sequence it, and make the tradeoff calls with your eyes open.

The wall is smaller than it looks

It is easy to read all of this as a wall. So the migration goes untouched until a deadline forces it. Up close, though, the wall is smaller than it looks. The algorithms are standardized, the sequencing is a known problem, and more of the estate is movable than the dread suggests. What is usually missing is someone beside you who has spent years in security operations and vulnerability management in environments like yours, and can tell you which of your fears are real and which are not.

That is the specialized expertise worth having next to you: for someone who has spent a career prioritizing and remediating risk under deadline, the harvest-versus-feasibility calls are familiar ground, so you are not learning the terrain on the clock. It turns an overwhelming project into an ordered one.

The deadline stays on the calendar. Meet it with a plan you can reuse, and start earlier than the algorithm: a name and an inventory.

Common questions

Sources: OMB M-26-15 (federal PQC migration); NIST FIPS 203 / 204 / 205; CNSA 2.0; Keyfactor and The Quantum Insider on crypto-agility.