Ask most engineering organisations how they plan to deal with the cryptographic threat from future quantum computers, and the answer tends to sound like this: “When it becomes urgent, we’ll run a big migration project.” That plan has a serious flaw, and it is the same flaw that has hurt software security for decades. This article diagnoses why treating post-quantum cryptography migration as a single end-stage project is likely to fail, and proposes a more resilient alternative: building small cryptographic checks into every step of how software is designed, built and released, so that quantum-vulnerable choices are caught where they are made.

Background: why quantum computing worries cryptographers

Much of today’s public-key cryptography, including RSA and elliptic-curve schemes used to secure web traffic, software updates and digital signatures, relies on mathematical problems that are hard for classical computers. In 1994, Peter Shor described a quantum algorithm that could solve integer factoring and discrete logarithms efficiently on a sufficiently large, error-corrected quantum computer. Our introduction to Shor’s algorithm explains the mechanics in more depth.

No machine capable of breaking real-world key sizes exists today, and credible estimates of when one might appear vary widely. But two facts make the issue pressing anyway. First, adversaries can record encrypted traffic now and decrypt it later once capable hardware exists, a pattern often called “harvest now, decrypt later”. Second, migrating cryptography across large software estates takes years. In August 2024, the US National Institute of Standards and Technology published its first finalised post-quantum cryptography standards, FIPS 203, 204 and 205, giving organisations concrete algorithms to move towards.

The problem: migration planned as a one-time event

The common plan treats post-quantum migration like a single, large project scheduled for some future date. Inventory every use of cryptography, replace vulnerable algorithms, test, and declare victory. On paper this is tidy. In practice it runs into four predictable problems.

Symptom 1: the inventory starts ageing the moment it is complete

Software changes constantly. New services are added, libraries are upgraded, contractors contribute code. A cryptographic inventory compiled in one big push captures a single moment. By the time remediation starts, new uses of vulnerable algorithms have already crept in.

Symptom 2: cryptography hides in unexpected places

Algorithms are not only chosen in application code. They are embedded in third-party libraries, container base images, hardware security modules, network appliances, certificate configurations and infrastructure templates. A one-off search through first-party source code misses much of this.

Symptom 3: fixes collide with everything else

When migration is a single project, it competes with feature work for the same engineers and release windows. Large cross-cutting changes to cryptography are risky, so they get delayed, scaled back or split into phases that never quite finish.

Symptom 4: nobody owns the ongoing state

Once the project closes, responsibility evaporates. There is no mechanism to stop a developer next month from introducing a new dependency that relies on a quantum-vulnerable signature scheme.

Diagnosis: a final-inspection model applied to cryptography

All four symptoms share a root cause. The plan relies on inspecting the system once, at a late point, rather than controlling cryptographic choices at the moment they enter the system. It is the classic weakness of end-of-line inspection: it finds defects only after they have accumulated, and it does nothing to stop new ones forming.

Application security learned this lesson the hard way. Teams that relied on one penetration test before each release consistently found more issues, later, at higher cost, than teams that placed small security controls inside each stage of delivery. Cryptographic agility is simply another security property, and the same logic applies.

The solution: post-quantum cryptography migration built into each step

The alternative treats post-quantum readiness as a continuous property of the delivery process. Rather than one large inventory, each stage carries a narrow check relevant to the cryptographic decisions made there.

While designing: record cryptographic intent

When a new service or feature is planned, the design notes state which cryptographic functions it needs, such as key exchange, signatures or symmetric encryption, and through which library or service. Threat modeling sessions include one extra question: how long must this data stay confidential? Data that must remain secret for a decade or more is the most exposed to harvest-now attacks and deserves priority.

While code is written and built: flag hard-coded choices and inventory dependencies

Static analysis rules can detect direct calls to specific algorithms or fixed key sizes. Flagging these during code review nudges developers to route cryptography through an abstraction layer that can be switched later, which is the essence of crypto-agility; the cost is a comment on a pull request, not a rewrite years later. In the same spirit, each build can emit a software bill of materials naming every component, cryptographic libraries and their versions included. The organisation’s inventory of where vulnerable algorithms live then refreshes itself as a by-product of ordinary work. When a library ships support for the newly standardised algorithms, teams can see at once which services are ready to switch.

Before release: enforce a written cryptographic policy

A release gate can check builds against a short policy: for example, disallowing deprecated algorithms outright and warning on quantum-vulnerable ones in systems marked as handling long-lived sensitive data. Writing the rules in a policy language, Open Policy Agent being one common choice, keeps every release judged by an identical standard. As the organisation’s migration progresses, warnings can tighten into blocks.

Our article on wiring automated security checks through a cloud delivery pipeline covers the broader mechanics of placing controls like these.

Why this approach holds up better

Compared with a single end-stage project, the embedded approach addresses each of the four symptoms directly:

• The inventory stays current, because it is regenerated with every build.
• Hidden cryptography surfaces, because dependency and image analysis covers third-party code, not just first-party source.
• Fixes are small and continuous, because new vulnerable choices are blocked as they appear and old ones are replaced service by service.
• Ownership is clear, because each stage owner is responsible for the check in their stage.

A large coordinated effort will still be needed for some legacy systems, hardware and protocols. But its scope shrinks considerably when new problems stop accumulating in the meantime.

Anticipating the objections

“We cannot switch algorithms until our vendors support them.” True for many components. That is precisely why the build-time inventory matters: it tells you which dependencies are waiting on vendors and which are already movable, so effort goes where progress is possible.

“Post-quantum algorithms have larger keys and signatures; performance may suffer.” Also true in some contexts. Embedding checks early means performance testing happens service by service, with real workloads, rather than being discovered across the whole estate during a rushed final migration.

“The threat is years away.” Perhaps. But the data being harvested is today’s, and the codebase being written is today’s. Every vulnerable choice made now is one more item for some future team to unpick.

A note on the physics side

Interestingly, quantum computing itself embodies a version of this principle. Physical qubits are fragile, and errors accumulate quickly during computation. Quantum error correction does not wait until the end of a calculation to check the answer; it measures error syndromes repeatedly throughout, correcting faults as they arise. The field has concluded, in its own domain, that checking only the final output is not enough. Readers new to that topic may enjoy our primer on the fundamentals of quantum-secure communication.

Building the skills to do this

Placing controls at each stage of delivery is a core DevSecOps discipline, and post-quantum readiness is a natural extension of it. Engineers and architects who want structured grounding in that discipline can look at DevSecOpsSchool’s programmes on securing software delivery. Its architect-level certification addresses enterprise blueprints, multi-cloud design and policy-as-code, which maps closely onto the release-gate and policy work described above, while its engineer-level certification covers building secure pipelines with static analysis and infrastructure-as-code checks. For organisations that prefer outside help, it also takes on consulting engagements around threat modeling and automating compliance.

Conclusion

The quantum threat to today’s public-key cryptography is uncertain in timing but serious in consequence, and the standards needed to respond now exist. Treating migration as one future project repeats the oldest mistake in security: inspecting at the end instead of controlling at each step. Organisations that embed small cryptographic checks into design, code review, build and release will find that, when the time comes for the hard final push, most of the work has already been done quietly along the way.