PQC migration looks daunting. It isn’t if you narrow the problem.

Joel MosesVP, Strategic Engineering | F5

Spend enough time looking at the scope of post-quantum cryptography (PQC) migration, and it's easy to come away with one conclusion: This is going to be difficult.

Cryptography is embedded across decades of enterprise technology. It protects web transactions, network connections, VPN tunnels, certificates, applications, infrastructure, and data. Some systems will eventually need more than a software upgrade. They may need to be replaced. Across a large enterprise, that makes PQC migration a significant, multi-year undertaking.

As an engineer, however, my next question isn't whether the problem is difficult. It's whether we're defining the problem correctly.

Not everything needs to be done at once

One of the biggest mistakes organizations can make with PQC readiness is looking across their entire technology estate and concluding that everything needs to change at once. It doesn't.

The quantum threat affects different forms of cryptography differently. That distinction matters because it allows organizations to narrow their immediate exposure rather than approaching PQC as an indiscriminate rip-and-replace exercise.

However, narrowing the problem doesn't make existing technical debt disappear. In fact, PQC can expose just how consequential that debt has become, something I discuss in more detail in my session, “PQC readiness starts now,” at the on-demand F5 Post Mythos Security Summit.

Consider TLS 1.3. F5 Labs’ 2026 research found that 10% of top websites still don't support it. That's more than a modernization issue. PQC ciphers can't negotiate over TLS 1.2, making TLS 1.3 a foundational requirement for PQC readiness. Organizations still dependent on legacy TLS therefore have work to do before they can even make the next cryptographic transition.

Today's modernization backlog can become tomorrow's security constraint.

Migration time is part of the risk

There's another reason to narrow the problem now rather than wait for greater certainty about when Q-Day will arrive: The date itself isn't the only clock that matters.

Mosca's theorem offers a useful way to think about timing: It weighs how long information must remain secure and how long it will take to migrate to quantum-safe cryptography against the time remaining before sufficiently powerful quantum computers could threaten today's public-key cryptography. If the first two periods combined exceed the third, the organization has a problem.

That changes the way we should think about PQC readiness. Migration time isn't merely a project-planning consideration; it’s part of the risk.

And enterprise architecture can have an enormous effect on that time.

The more tightly cryptography is coupled to individual applications and systems, the more places an organization may eventually have to modify, test, validate, and maintain. Add legacy infrastructure and third-party dependencies, and what appears to be a cryptographic upgrade can quickly become a sprawling enterprise transformation.

That's why organizations shouldn't wait for certainty about Q-Day's timing before addressing the architecture. You don't need to know exactly when quantum computing will cross the threshold to know that reducing the time required to respond is valuable.

Design for cryptographic change

Ultimately, the objective isn't simply to deploy today's approved PQC algorithms, but also to build the ability to adapt as cryptographic requirements continue to evolve.

That's what crypto-agility means to me: the capacity to replace and adapt cryptographic algorithms without interrupting the flow of running systems.

Here's a useful question for technology leaders to ask: If a cryptographic algorithm had to change tomorrow, how many applications would we have to touch?

If the answer is hundreds or thousands, PQC isn't just a cryptography problem. It's an architecture problem.

And trying to solve that problem by manually rewriting application after application isn't an attractive answer. Across a large enterprise, that approach can become slow, expensive, operationally disruptive, and demanding on infrastructure.

Fortunately, it isn't the only answer.

The challenge ahead is substantial, but organizations can make it more manageable by identifying where their real exposure lies, understanding which dependencies they control, and designing infrastructure so cryptographic change doesn't have to become every application team's problem.

Summit session: PQC readiness starts now

At the on-demand F5 Post-Mythos Security Summit, I dig into exactly that challenge in my session, “PQC readiness starts now.” Join me as I walk through a practical three-step approach to scope immediate exposure, govern the transition, and protect infrastructure while avoiding unnecessary disruption to current operations.

About the Author

Joel MosesVP, Strategic Engineering | F5

More blogs by Joel Moses