Last week I talked about cryptoagility and why it starts with visibility. But visibility naturally raises the next question: once you know what cryptography is running across your organization, where do you actually begin?
Large enterprises can easily have tens of thousands of certificates, keys, applications, APIs, workloads, and cryptographic dependencies. Nobody migrates all of that at once. So how do you decide what comes first?
This is where a lot of PQC programs get stuck.
The instinct most teams follow. And why it falls short
The natural instinct is to prioritize by technology. Start with TLS. Or code signing. Or SSH. Pick the cryptography that's easiest to replace and work your way through it.
I understand the appeal. It feels systematic. You're making progress. But I don't think it's the right approach, because it treats all assets as roughly equivalent when they aren't. Replacing a low-risk certificate before a mission-critical application doesn't meaningfully reduce your organization's exposure. You're just checking boxes.
The right starting point is business exposure
The questions that should drive prioritization aren't cryptographic. They're operational.
Which assets support your most critical business services? Which are internet-facing? Which process sensitive or regulated data? Which would have the greatest operational impact if compromised? And just as importantly. Who owns them?
Those answers matter far more than the algorithm. A quantum-vulnerable certificate protecting an internal test environment is a different problem than a quantum-vulnerable key protecting your payment processing infrastructure. Treating them the same way wastes time and misallocates effort.
Business impact first, cryptography second
Successful PQC programs build their migration roadmap around business risk, not technical categories. That means mapping cryptographic assets to the business functions they support, assessing the blast radius if each asset were compromised, and sequencing migration based on that risk picture rather than what's technically easiest.
It also means involving the business in the prioritization conversation, not just the security team. The people who know which applications are mission-critical, which data is most sensitive, and which systems have the least tolerance for downtime are often outside the security organization. That context is exactly what you need to build a migration plan that holds up under pressure.
This is how you turn a list of fifty thousand assets into a practical, defensible migration roadmap. Not by starting with the algorithm, but by starting with what the business can't afford to lose.
If you're working through what this looks like in practice, our PQC Readiness page covers how Axiad approaches prioritization across enterprise and federal environments.
Next time, we'll get into something that trips up nearly every migration effort: the hidden dependency graph. Before you can replace cryptography, you need to understand everything that depends on it. And that's harder to map than most teams expect.