Last week I talked about the hidden dependency graph and why you need to understand what depends on your cryptographic assets before you touch them. But once you have that picture, another question comes up immediately: who actually makes the change?
This is where a lot of PQC programs quietly stall. Not because the technical work is impossible, but because nobody has a clear answer to that question.
Cryptography doesn't belong to one team
In most organizations, cryptography is everybody's problem and nobody's job. Security defines the standards. PKI teams manage the certificates. Infrastructure teams manage the platforms those certificates run on. Application owners manage the software that depends on them. And the business ultimately owns the risk if something goes wrong.
That's four or five different teams, each with partial ownership over the same asset. When a migration needs to happen, it's easy for each group to assume someone else is driving it. Security assumes PKI is handling the execution. PKI assumes Infrastructure has already prepared the platform. Application owners are waiting to hear from someone. And nothing moves.
It's not negligence. It's a natural consequence of how cryptography is spread across an organization. The structure creates ambiguity, and ambiguity creates delay.
Why governance gaps are so costly
The frustrating thing is that ownership gaps don't show up in a risk assessment or a technical audit. You can have a detailed inventory, a prioritized asset list, and a fully mapped dependency graph, and still have your migration stall the moment you try to act on it.
That's because execution requires someone to make decisions under pressure. Who approves a change that affects a production system? Who's responsible when a migration causes an unexpected outage? Who signs off that the new cryptography is correctly implemented? If those questions don't have clear answers before migration begins, teams will hesitate at exactly the moments when momentum matters most.
I've seen technically sound PQC programs sit on the shelf for months because nobody had resolved these questions. The plan was good. The ownership wasn't.
What clear ownership actually looks like
Successful organizations answer four questions before migration begins, not during it.
Who approves changes? Someone needs final authority to greenlight a migration, especially when it touches production systems or regulated environments. Without a named approver, changes wait in a review queue indefinitely.
Who performs the work? This sounds obvious, but in a multi-team environment it often isn't. The team that owns the certificate may not be the team that can modify the application depending on it.
Who validates the outcome? After a migration, someone needs to confirm that the new cryptography is functioning correctly and that nothing downstream broke. That's usually a different team than the one that did the work.
Who accepts the remaining risk? Post-quantum migration doesn't eliminate risk. It reduces it. Someone in the business needs to acknowledge the residual risk and formally accept it. Without that, migrations stay in a perpetual "not quite done" state.
Getting those four questions answered before you start is what separates programs that make steady progress from programs that generate good documentation but don't change much.
Governance comes before execution
PQC isn't just a technology problem. It's also an organizational one. The cryptography you need to replace is governed by people and processes that weren't designed with migration in mind. Before you can move efficiently, you need to redesign the governance around it.
That's not a reason to slow down. It's a reason to get the governance work done early, so it doesn't slow you down later when you're trying to execute at scale.
If you're working through how to structure ownership for PQC migration across a complex environment, our PQC Readiness page covers how Axiad approaches this with enterprise and federal customers.
Next up: once you know what you have, what matters most, how it's connected, and who owns it, how do you turn that into a practical migration backlog? That's Episode 6.
The PQC Playbook Series
Previous: Episode 4: The Hidden Dependency Graph: Why PQC Migration Is Harder Than It Looks