You're gonna need a bigger village

It Takes a Village to Migrate

There is an old saying that it takes a village to raise a child. It takes roughly the same number of people to migrate an enterprise to post-quantum cryptography, with the added complication that half the village thinks someone else is handling it.

PQC migration is not an IT project. It is a cross-functional programme that will, at various points, require your CISO, CIO, CFO, legal team, procurement function, application developers, network engineers, and a rotating cast of suppliers who will each tell you, with complete sincerity, that they are "actively monitoring the situation." Your board will need to understand why this is a governance issue. Your CFO will need to understand why it is not optional. Your network engineers will need to understand why swapping in a new algorithm is not the same as completing a migration. None of these conversations happen automatically.

Here is the village you actually need. A programme owner with cross-functional authority. Workstreams across network, PKI, applications, OT, and procurement. A steering committee that meets and makes binding decisions, not one that meets and produces minutes. Crypto champions embedded in application teams who flag new cryptographic choices before they become problems. And a budget that survives more than one financial year, because this programme will not be done by Christmas.

Now, about those suppliers.

Your TLS configuration can be exemplary. Your certificate management can be immaculate. Your critical SaaS provider's API can still be running a cipher suite last updated in 2019, carrying your data through a cryptographic arrangement that would have raised eyebrows in 2015. Your data is only as secure as the weakest link in the chain of systems it travels through, and most of that chain is outside your direct control.

The instinct, at this point, is to assume the suppliers will sort it out. This is understandable. It is also wrong.

Cloud providers are updating transport security between your environment and their boundary. They are not updating the cryptographic configurations inside your applications, your key management systems, your code signing pipelines, or the fifteen SaaS tools your finance team onboarded without telling anyone. Those remain your responsibility. A vendor who tells you "our cloud provider handles all of that" is a vendor who has not yet run a cryptographic inventory. When they do, they will be surprised.

The village has to be built deliberately, and it has to include supplier governance. Send the questionnaire. Ask what TLS versions they enforce, whether they have a PQC migration roadmap, and when they plan to implement the NIST standards. A supplier who cannot answer these questions is not a blocker on your migration. They are a risk on your risk register, and they need to know it.

The good news is that the first step does not require the whole village to show up at once. Start with the cryptographic inventory. Understand what you are actually running. The village can organise itself around real findings rather than theoretical ones.

The child will not raise itself. Neither will this migration.