Last year, cybersecurity and IT leaders were curious to learn about quantum readiness, yet they weren’t ready to start preparations. They were in listen mode. 

As we start the New Year, enterprises are taking action or planning to do so soon. Those that have started pilots are discovering that key parts of their technology stacks do not yet support post-quantum cryptography (PQC). 

To the skeptics, this might feel like confirmation that preparing for PQC is a low-priority task. If we know pilots fail, then why run them? 

The goal of a PQC pilot isn’t to prove it will work. The goal is to deliberately and proactively surface obstacles that would otherwise remain hidden. It’s important to reframe a PQC pilot from the onset as an effort to uncover interoperability issues and knowledge gaps rather than to produce a fully functional and quantum-resistant system. 

The Real Reason to Start Now 

“If you haven’t started to prepare for PQC you’re already late.”
— every vendor. 

Some IT and cybersecurity leaders and practitioners believe that the right time to act is when the ecosystem is ready. In other words, it is time to begin when standards have settled, vendors have executed their roadmaps and implementations are codified. 

That’s not going to cut it. Perhaps, the nuance between the tongue-in-cheek quote above and the fence-sitters is that starting doesn’t have to be an enterprise-wide project. 

PQC will not arrive as a clean upgrade. It will unfold unevenly across operating systems, applications, network devices, embedded systems, cloud services and third-party dependencies. Much of the cryptography involved is invisible even after it breaks — and by the time it breaks, organizations will have to move according to a regulatory or key customer’s timeline rather than on their own terms. 

Redefining Success 

With most technology pilots, the goal is to prove readiness. If the pilot works, the organization proceeds. If it fails, people are grumpy. 

PQC pilots invert that logic.  

The goal for a PQC pilot is not to prove that your tech stack is ready. The goal is to find the areas that aren’t ready so you can manage the implementation risks. In fact, a PQC pilot where everything works smoothly should prompt skepticism. It likely means the scope was too narrow to be relevant. 

Running pilots allow organizations to identify the knowledge and skills they’ll need for the transition. It helps them catalog the technologies they need to re-evaluate, and the vendors they need to engage. It begins the process of building a cryptographic inventory. Lastly, it allows them to identify the processes they will need to automate before, during and after the transition to PQC. 

This context is important. Organizations that experiment with PQC should not expect success. They should expect to learn. 

Each issue uncovered during a PQC pilot maps directly to implementation risks. 

Skill and Knowledge Gaps 

Pilots quickly show whether teams understand the implications of a PQC migration. They need to know how to make software source code cryptographically agile. They need to be aware of the prevailing PQC algorithms and their appropriate uses. This is not a one-for-one swap; we may have over a dozen replacements for the two algorithms we use today. Identifying gaps early creates time for training, hiring or partnering. 

Cryptographic Inventory 

Many enterprises lack a complete cryptographic inventory. Certificates may be tracked, but often, primitives, keys and protocols are not. PQC pilots force that visibility. You cannot assess readiness or risk without first discovering what exists. This does not mean you should pause preparations until the inventory is complete. Build your inventory as you pilot various application environments. 

Vendor Readiness and Leverage 

When systems fail, organizations gain clarity on whether the blocker is internal or external. PQC pilots replace vague roadmap conversations with concrete discussions about capability gaps and timelines. That insight is critical for procurement, planning and third-party risk management. 

Process Fragility and Automation Needs 

Manual cryptographic processes may be tolerable today, but they will not survive the scope and reliability required for the PQC transition. Pilots highlight where automation is no longer a future improvement but a prerequisite for scale. Note that PQC may not be a forcing function for automation today — shortening certificate life cycles should be. 

PQC pilots are not rehearsals for success; they are more akin to reconnaissance missions. Their value lies in what they expose, not in how cleanly they run. Every incompatibility, skills gap, and brittle process uncovered today is one less surprise when timelines compress. 

Waiting for the ecosystem to be ready doesn’t reduce risk; it transfers control to regulators, customers and attackers. Organizations that pilot now earn something far more valuable than early adoption — clarity. They understand where they are vulnerable, which levers they can pull and how fast they can move. 

A failed PQC pilot isn’t a setback. It’s proof that you asked the right questions early, while you still had the freedom to learn instead of the pressure to react.