up:: The Human & Organizational Side MOC
Why Post-Quantum Migrations Stall
Post-quantum migrations stall organizationally rather than cryptographically. The algorithm swap is a small, well-understood engineering task; the transition stalls because organizations struggle to see where their cryptography actually lives, to agree on who owns the work, and to move people who quietly fear the change. Roughly 80% of the effort and nearly all of the delay live in those three problems, and a cryptographer never touches any of them. This is the half of the transition almost no other resource teaches, because most of the field doesn’t have the words for it.
The short version:
- The cryptography is rarely the bottleneck. Visibility, ownership, and change management are.
- Visibility: the vulnerable algorithm is buried inside vendor products, embedded firmware, and systems nobody mapped, so most organizations can’t see their own exposure.
- Ownership: the work falls between engineering, procurement, security, and governance, and a migration with no single accountable owner doesn’t move.
- People: the engineers who have to do it often fear the change makes their hard-won skills obsolete, so they resist, and resistance shows up as a hundred small delays rather than open refusal.
- The move is to name an owner, build the inventory, and bring people along with small reversible steps, before writing a line of new code.
Think of the algorithm swap as changing the locks on a large building. That part is quick, if you have a map of every door. The reason it takes years is that nobody has the map, the facilities budget and the security team each assume the other one owns it, and the people holding the old keys are quietly worried about what happens to them once the locks change.
How much of a post-quantum migration is actually cryptography?
Less than most leaders expect. The cryptographic decisions are bounded and largely solved: choose the replacement (ML-KEM for key exchange, ML-DSA for signatures), run it in a hybrid pairing during the transition, and put it behind a config so it can change again. A capable engineer can do that part quickly. The through-line worth memorizing, from migration architecture: swapping the algorithm is the easy 20%; finding every place it hides and rolling the replacement out safely is the other 80%.
That 80% is almost entirely organizational:
- Discovery across a fragmented estate (the visibility problem below).
- Ownership and coordination across teams that don’t normally share a mandate (the ownership problem).
- Vendor engagement on timelines you don’t control (see Vendor-Controlled Crypto Surfaces).
- Rollout endpoint by endpoint, with testing, interop, and rollback at each one.
- Change management to get people to actually do the work (the human problem).
- Governance to keep the queue moving over a multi-year program.
A program that treats the transition as a cryptography project optimizes the one part that was never the constraint, which is why so many produce a flawless technical roadmap and no motion.
Why can’t organizations see their own cryptographic exposure?
Because cryptography is invisible to the tools most organizations audit with, and it lives in places no one thinks to look. The visibility gap has specific, recurring sources:
- Vendor products. The single largest source. The vulnerable algorithm sits inside SaaS platforms, cloud services, network appliances, and managed services, on a roadmap the vendor controls. Most of an enterprise’s cryptographic footprint is here, and it’s covered in depth in Vendor-Controlled Crypto Surfaces.
- Embedded and firmware crypto. Switches, routers, HSMs, IoT, and OT devices carry algorithms fixed in firmware that change only through an upgrade or a hardware refresh.
- Hardcoded and library-level crypto. Legacy applications with the algorithm baked into the code, or pinned to a specific library version, so the choice never appears in any config a scanner reads.
- Forgotten and shadow systems. Certificates nobody tracks, internal services stood up years ago, and machine-to-machine trust that no current team owns.
Standard internal audits miss all of this because they inventory assets, not cryptographic behavior. They can tell you a server exists and holds a certificate; they rarely tell you which key-establishment algorithm it actually negotiates, or that a vendor appliance behind it downgrades to a quantum-vulnerable exchange. This is why discovery is real detective work and why the cryptographic inventory is the first deliverable of any serious migration. You cannot prioritize, budget, or defend a program against exposure you can’t see.
Who owns a post-quantum migration?
This is the question that quietly kills programs, because the honest answer in most organizations is “no one, exactly.” The work spans functions that don’t normally share a mandate:
| Function | What it controls | Why it can’t own the whole thing alone |
|---|---|---|
| Engineering / platform | The implementation, the rollout | Doesn’t control vendor contracts or the budget, and can’t compel other teams |
| Procurement / vendor management | The contracts and renewal leverage | Doesn’t assess cryptographic risk or run the technical work |
| Security / the CISO | The risk, the accountability, the mandate | Owns the outcome but usually not the engineers or the purchasing levers |
| Governance / compliance | The regulatory obligation | Sets the deadline but doesn’t do the work |
| The board | The budget and the priority | Funds it, but only once someone frames the ask |
Each function assumes another one owns the migration, so it lands in the gap between them and waits. The fix is structural: name one accountable executive owner (usually under the CISO), stand up a cross-functional working group with explicit responsibilities across those functions, and make the ownership map real before discovery begins, not after. A migration with a name attached to it moves; an orphaned one stalls indefinitely, no matter how good the technical plan is. This is deep enough to be its own discipline; see Cryptographic Ownership.
Why do engineers resist a post-quantum migration?
Not because they disagree that it matters, and rarely out in the open. The resistance is quieter and more human than that. Cryptography is specialized, hard-won expertise, and a migration can feel like it threatens that expertise: it exposes gaps (“I’ve never deployed a KEM”), it can read as an admission that the current design was wrong, and it competes with the delivery work people are actually measured on. So the resistance shows up as friction rather than refusal: requests for more analysis, quiet deprioritization, “let’s wait for the standards to settle,” and a hundred small delays that add up to a program that never quite starts.
The way through is to lower the stakes and reframe the gain:
- Start with the smallest completely reversible moves. Give the team a few low-stakes, easily-undone steps (a hybrid handshake on one internal service, a discovery pass on one system) so they build competence and confidence without the fear of a one-way door. Reversibility is what defuses the resistance, because nothing they try can strand them.
- Frame it around what developers actually want. Lead with crypto-agility as less firefighting later, with the migration as career-relevant skill-building, and with the reduction in future emergency work, rather than with what’s being taken away or what was wrong before.
- Make it normal, not heroic. People adopt a change that’s presented as the new baseline far more readily than one framed as a crisis response.
Change management is the true bottleneck of the quantum transition, and it has its own method; see Change Management for Cryptographic Migration.
Why won’t your vendor tell you about this?
You will not hear this framing from a vendor, and the reason is structural, not conspiratorial. A vendor’s incentive is to sell you something: a “PQC-ready” product, an upgraded tier, a migration service. None of those incentives include volunteering that the quantum-vulnerable algorithm is already sitting inside the product you bought from them, on a timeline they control and haven’t committed to. Disclosing that exposure spooks the customer and pins the vendor to a roadmap they’d rather keep flexible. So the honest map of your own exposure is something you have to build yourself, and the questions a vendor would rather you not ask are precisely the ones worth asking. The organizational work begins with refusing to outsource your own visibility, and Vendor-Controlled Crypto Surfaces covers exactly how to turn that refusal into procurement leverage.
How does a stalled post-quantum migration start moving?
The sequence is deliberate, and it front-loads the organizational work that the technical roadmaps skip:
- Name an owner and the stakeholders first. Before discovery, before purchasing, before any code. A program with an accountable name attached to it moves; an orphaned one waits.
- Build visibility. Stand up the cryptographic inventory, because every later decision, what to prioritize, what to budget, what to defend to a regulator, rests on knowing where your cryptography actually lives.
- Make the first moves small and reversible. Acclimate the team with a few completely reversible steps rather than a mandate to rebuild everything, and frame each one around what your engineers gain.
- Set a cadence and govern it. A migration is a multi-year program with owners and a rhythm, and governance is what keeps the queue moving rather than stalling after the first burst of energy.
Notice that the cryptography enters only after the organizational groundwork is laid. That ordering is the whole difference between a program that ships and one that has a beautiful roadmap and no motion.
Has this happened before?
Yes, and the lesson is old. Germany’s Enigma machine was, for its era, a genuinely strong cipher. It fell anyway, on a combination of brilliant cryptanalysis at Bletchley Park and, crucially, the human layer around the machine: operator shortcuts, predictable message formats, and sloppy key-handling procedure that gave the codebreakers their way in. The mathematics largely held; the operations around it did not. Cryptographic systems have failed at the human seams first for as long as there have been cryptographic systems, and the quantum transition runs true to form. The algorithms are the solved part. The people and processes around them are where it actually breaks.
Source: Simon Singh, The Code Book, on Enigma and Bletchley Park.
Common misconceptions
- “This is a cryptography project.” It’s a program. The cryptography is roughly 20% of the effort and almost none of the delay.
- “Our vendors have it handled.” Mostly not, and you have to verify rather than assume. The vulnerable algorithm hides inside vendor products, and a roadmap statement is not deployed protection.
- “We’ll migrate when quantum computers arrive.” Too late. Migration takes years, harvesting is already live, and the organizational work is the slow part, so the window to start closed a while ago for long-lived data.
- “It’s an IT task.” It’s cross-functional. Engineering can’t compel procurement, and neither owns the regulatory clock. An IT-only mandate is how it lands in the ownership gap.
- “We finished, we migrated our systems.” If “our systems” meant internally-managed ones, the vendor-controlled surfaces, usually the majority of the footprint, are still open.
The advantage is in naming it
Every firm has the technical arm. Almost none treat the human and organizational side as real work with its own method, which is why so many programs have a flawless roadmap and no motion. Planning for visibility, ownership, and change management as deliberately as the cryptography is most of the advantage. The transition is a change-management problem first and a cryptography problem second.
Field note → The Psychology of Post-Quantum Risk, the same stall told from the inside of the mind.
Everything here is the map, given freely. When your team needs the organizational and human side of the transition planned and run as deliberately as the cryptography, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.