PQC readiness in 2026: the questions we're asking enterprise clients

There is a lot of noise about quantum computing right now, and most of it is trying to sell you a dashboard. I have been doing enterprise security long enough to recognize the shape of it. A real risk arrives, the market gets loud, and the loudness starts to work against the people who have to do the job.

So when we sit down with an enterprise security team, we don't open with the threat. Everyone in the room already knows the threat. We open with questions. The answers tell us more about a company's post-quantum readiness than any maturity score.

Start with what's settled. NIST finished the algorithm argument in 2024. The standards exist, cryptographers have picked at them for years, and they hold. If your team is still debating which algorithm to back, you are spending energy on the one part of this that is no longer in question. The hard part was never the math. It is everywhere the math is hiding.

That is the first question we ask: where does your cryptography actually live? Almost no one can answer on the first pass. I have sat in rooms where a team produced their inventory with some confidence, and then someone from the network side mentioned the load balancers, and then someone remembered the VPN concentrators, and then the firmware on a device from a vendor who stopped returning calls in 2019, and the room got quiet. That quiet is the real starting position. You cannot migrate what you cannot find, and finding it is most of the work.

The second question: how fast could you change an algorithm if you had to? Not for quantum. For any reason. A library goes bad, an authority is compromised, a standard moves. If the honest answer is "we would have to rewrite code," you do not have a quantum problem. You have an agility problem, and quantum is just the deadline that made it visible. The teams that come through this cleanly are the ones who can swap an algorithm by changing a configuration, not a codebase.

The third question is the one people expect to be frightening, and I try to make it boring instead. What of yours has to stay secret for ten years? This is where "harvest now, decrypt later" belongs. Not as a headline. As a filter. Most data does not need protecting on that horizon. Some does: long-lived secrets, health records, anything with a regulatory tail, the design for a product you will still be selling in 2036. Sort your data by how long it has to survive, and the urgency sorts itself.

None of these questions are about quantum computers. They are about knowing your own systems and being able to change them. The migration deadlines are real. The 2030 and 2035 dates in the federal guidance are planning horizons, not a clock counting down to one event. Run this as a change program and it is manageable. Run it as an emergency and you get the rushed, half-inventoried migration that causes the outage people were afraid of in the first place.

There is a trade-off, because there is always one. Working through these questions is slower and less satisfying than buying a platform that promises to handle it for you. It will not give you a number to show the board next quarter. What it gives you is a migration you can run, on infrastructure you understand. That is a worse slide and a better outcome.