As of late, we’ve observed a noticeable shift in how post-quantum cryptography (PQC) is being discussed across the security industry.
The good news: the industry has moved from “we should think about PQC someday” to “we need to plan for this... now.” The shift was palpable – in the sessions, in the hallway conversations, and in the tone shift that happens when a threat becomes a line item.
The bad news: we’re about to make a familiar mistake.
Many organizations are going to treat PQC like an upgrade and then be surprised when they are not actually crypto agile afterward. The security veterans know the saying: trust, but verify...and then verify the verification.
The PQC refrain was consistent: “We need to achieve crypto agility.” That’s the right destination. The market has done a lot of the heavy lifting on the what and why:
- What must change: cryptography in use today won’t withstand cryptographically relevant quantum computing.
- Why it matters: regulations are tightening, “harvest now, decrypt later” is not theoretical. Adversaries are conducting HNDL attacks everyday and will be able to decrypt that data once a CRQC is available and cryptographic vulnerabilities don’t wait for convenient quarters.
What’s missing is the question that determines whether this becomes a one-time scramble or a lasting advantage:
- What does crypto agility look like when you’re done and what has to be true in your architecture for it to exist?
- Not “how do we run a migration” (many teams have scars and spreadsheets for that). The more consequential question is: How do you architect during the PQC migration so agility is the outcome... not just the aspiration?
Here’s the uncomfortable truth: Completing a PQC migration does not automatically produce crypto agility. Those are two different outcomes.
The Upgrade Trap
Traditionally, this has been the plan:
- Inventory everything.
- Call your vendors.
- Swap the algorithms.
- Update the certificates.
- Touch every applications, every endpoint and every database.
- Ship it.
- Put "Crypto Agility" on the slide for the board presentation.
Then, a few years later, when the next cryptographic threat arrives (because there will be a next one), the realization lands: You didn’t build agility. You executed another upgrade. That’s not a strategy. That’s a recurring incident with better formatting.
Here is the proposed plan:
- PQC Vendor Implementation - Discuss with vendors how products may perform within an organizational environment.
- Establish funding for implementation and transition.
- Test and evaluate the products for PQC Compliance.
- Implement discovery and inventory tool within enterprise.
- Establish operational performance metrics.
- Baseline current performance before implementation.
- Conduct discovery and inventory of cryptographic assets.
- Use a suite of tools – one tool may only work well with specific devices.
- Manual inventory might be necessary to establish a baseline.
- Conduct inventory on data.
- Sensitive data protection period.
- Traceability of transactions.
- Understand the impact on previous data lost
- Establish Controls For Crypto agility.
- Establish governance.
- Establish policy.
- Develop templates for transition.
- Develop templates for testing.
- Conduct training and education.
- Account for operational technology devices.
- Develop a procurement and acquisition plan for the organization.
Crypto Agility Doesn’t Just Happen
Crypto agility isn’t a participation trophy. It doesn’t appear at the finish line because everyone worked hard and held hands and updated the runbook. It’s achieved by centralizing cryptographic policy and building an architecture that makes cryptographic change routine, often leveraging network-layer controls so updates become repeatable operations, not bespoke engineering projects.
Here’s the part that’s easy to miss: crypto agility is not a concept. It’s a set of controls you can point to. Things security leaders can actually govern:
- A place where policy lives.
- A way to enforce it consistently.
- An operational mechanism to change it quickly without turning every application team into a cryptography SWAT unit.
If cryptography lives primarily at the application layer, you’re stuck in per-app change cycles: dev work, regression risk, exceptions, and inconsistent enforcement. Even if you “finish PQC,” your next algorithm change is still a multi-quarter engineering program. If policy and enforcement are architected to be centralized and automated, cryptographic changes become controlled and consistent. You still test. You still validate. But you’re no longer rewriting half your estate to respond to a cryptographic event.
The goal is not to make crypto agility “easy.” The goal is to make crypto agility operable so much so that your future self doesn’t send you angry emails from three years ahead.
PQC urgency is here. Discovery tooling is improving. Crypto agility is finally being spoken about like a business requirement instead of a niche preference. Now comes the part that determines whether this moment is transformative or just expensive. PQC migration is about deploying quantum-resistant algorithms. Crypto agility is about ensuring the next cryptographic change is fast, controlled, and consistent.
Practically, that means designing for:
- Centralized cryptographic policy: a clear place to define what’s allowed, what’s deprecated, and what’s mandatory.
- Decoupled enforcement: cryptographic decisions don’t require application rewrites to change.
- Orchestrated management: changes propagate through repeatable mechanisms, not coordinated heroics.
- Protocol-aware reality: negotiation and interoperability aren’t afterthoughts, but rather part of the design.
- Consistency at scale: the organization can respond uniformly without “each app team does its own thing.
It means making these decisions during the migration, not after; because “after” is when budgets are spent, teams are tired, and the organization declares victory and moves on. At QuSecure, this architectural approach is built into QuProtect R3TM with network-layer cryptographic policy management that makes crypto agility concrete.
In practice, crypto agility looks like this: you update policy once, and enforcement updates everywhere it needs to—without reopening every application, without coordinating a dozen bespoke release trains, and without waiting on a quarter’s worth of development work. Crypto agility is being decided right now, by design or by default.
If PQC is treated as “the next upgrade,” the industry will get a completed migration and the same future pain... just postponed. Use this moment to do more than migrate. Use it to build infrastructure and real controls that make crypto agility real.
