The Human & Organizational Side MOC

up:: The Transition MOC

The Human & Organizational Side

The human and organizational side of the post-quantum transition is the people-and-process work that decides whether a migration actually happens: seeing where cryptography lives, naming who owns the change, moving the vendors you don’t control, and bringing along the engineers who have to do it. This is where the transition stalls, long before it stalls on math. The algorithm swap is the easy 20% of the work, and the organizational effort is the other 80%, which is why so many programs produce a flawless technical roadmap and no motion. It’s the half of the transition almost no other resource teaches, because most of the field doesn’t have the words for it.

Map of content

A short overview of the human and organizational side of the transition, and the index that routes you to every note in this section. Skim it to get oriented, then follow the links to go deep.

The short version:

• The cryptography is rarely the bottleneck. Visibility, ownership, and change management are, and they hold nearly all of the delay.
• Ownership is the keystone: name one accountable executive owner first, before discovery, before budget, before any code. A migration with no owner doesn’t move.
• Visibility comes second: the vulnerable algorithm hides inside vendor products and firmware nobody mapped, so a cryptographic inventory is the first deliverable.
• People are the quiet blocker: engineers fear the change makes their hard-won skills obsolete, so they resist, and the way through is small, completely reversible first moves framed around what they gain.
• Vendors control most of your cryptographic footprint, so the leverage that moves them lives at procurement and contract renewal, not in day-to-day operations.

Think of the transition like a citywide project to replace aging water mains. The engineering of the new pipe is well understood, and a good crew can lay it quickly. The years go into figuring out which streets carry pipe nobody ever mapped, deciding whether the water utility or the roads department owns the job and the budget, and reassuring the crews who have maintained the old system their whole careers that the new one won’t put them out of work. The people and the coordination are the project. The pipe is the easy part.

Why do post-quantum migrations stall on people instead of math?

Because the cryptographic decisions are bounded and largely solved, and the human system around them is not. A capable engineer can choose the replacement (ML-KEM for key exchange, ML-DSA for signatures), design a hybrid rollout, and put it behind a config in a matter of weeks. Then the program sits, because the roadmap assumed the organization would simply execute it. It won’t, for three reasons that have nothing to do with cryptography, and each one has a remedy that has nothing to do with cryptography either:

The problem	Why it stalls the migration	The move that unblocks it
Visibility	The vulnerable algorithm is buried inside vendor products, firmware, and forgotten systems, so most organizations can’t see their own exposure and can’t prioritize against what they can’t see	Build the cryptographic inventory as the first deliverable, before any decisions rest on it
Ownership	The work spans engineering, procurement, security, and governance, so each function assumes another one owns it and it lands in the gap between them	Name one accountable executive owner and a cross-functional working group, per Cryptographic Ownership
Resistance	The engineers who do the work quietly fear it makes their expertise obsolete, so it shows up as a hundred small delays rather than open refusal	Start with small, completely reversible moves and frame them around what the team gains, per Change Management for Cryptographic Migration

A program that treats the transition as a cryptography project optimizes the one part that was never the constraint. Planning for visibility, ownership, and change management as deliberately as the cryptography is most of the advantage, and naming that out loud is where it starts. Every firm has the technical arm. Almost none treat the human and organizational side as real work with its own method, and that gap is the reason so many migrations stall.

How much of a migration is actually cryptography?

Less than most leaders expect. The through-line worth memorizing, from migration architecture: swapping the algorithm is the easy 20%, and finding every place it hides and rolling the replacement out safely is the other 80%. That 80% is almost entirely organizational, and it breaks into six streams of work:

1. Discovery across a fragmented estate, because you can’t migrate cryptography you can’t find.
2. Ownership and coordination across teams that don’t normally share a mandate.
3. Vendor engagement on timelines you don’t control, covered in Vendor-Controlled Crypto Surfaces.
4. Rollout endpoint by endpoint, with testing, interop, and rollback at each one.
5. Change management to get people to actually do the work.
6. Governance to keep the queue moving across a multi-year program.

Notice that the cryptography touches only the tail of that list. The reason a migration takes years is the six streams around it, and a plan that skips them ships a roadmap that never becomes motion.

Who owns a post-quantum migration?

In most organizations the honest answer is “no one, exactly,” and that vacuum is the single most common reason a migration stalls before it starts. Cryptography worked invisibly for decades, so nobody was ever put in charge of the whole estate, and now the invisible plumbing has a deadline. The work spans functions that each hold one lever and none of the others: engineering owns the implementation but not the vendor contracts or the budget, procurement holds the renewal leverage but doesn’t assess cryptographic risk, the CISO owns the risk but usually not the engineers, governance owns the deadline, and the board owns the money. Because the levers are split, ownership has to be a structure, not a single overloaded team:

1. One accountable executive owner, most often the CISO or a direct delegate, answerable for the outcome and empowered to convene the rest.
2. A cross-functional working group chartered to make decisions, with real representation from every function that holds a lever.
3. An explicit responsibility map for discovery, algorithm decisions, rollout, vendor engagement, and governance, so the overlaps get resolved deliberately.
4. Board-level sponsorship with committed budget and priority, so the program survives competing demands.

The test is simple: ask five people who owns the post-quantum migration, and a healthy organization gives you one name while a stalling one gives you five shrugs. Assign it first, and everything downstream has somewhere to live. This is deep enough to be its own discipline; see Cryptographic Ownership.

Why do engineers resist a cryptographic migration?

Rarely in the open, and rarely because they think it doesn’t matter. 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 a verdict on the design someone built before, and it competes with the delivery work people are actually measured on. So the resistance surfaces as friction rather than refusal, through requests for more analysis, quiet deprioritization, and “let’s wait for the standards to settle.” A hundred small delays are what a stalled migration is actually made of. The way through is to lower the stakes and reframe the gain, which is a real method with its own moves in Change Management for Cryptographic Migration.

What are the smallest reversible first moves?

The most effective opening to a migration is a handful of moves small enough and reversible enough that the team can try them with no fear of a one-way door. Reversibility is the active ingredient, because when a first step can be undone with a config change, the anxiety that drives the resistance has nothing to grip. Three that qualify:

1. Turn on a hybrid handshake for one internal service. Enable hybrid key exchange between two internal systems where the classical path stays negotiable, so it falls back cleanly and flips off in one line.
2. Run a discovery pass on a single system. Inventory the cryptography of one bounded application, producing a first slice of the CBOM and a real taste of what discovery involves.
3. Enable a post-quantum-capable library without switching it on. Upgrade to a library or provider that already speaks the new algorithms and leave the classical path active, so the capability arrives quietly with nothing changing in production.

Once the first reversible move lands without incident, the second is far easier, and the program has motion it didn’t have before. Frame each one around what developers gain, less firefighting later through crypto-agility and a scarce, rising skill, and present it as the new baseline rather than a crisis.

How do you move a vendor you can’t change yourself?

Most of an enterprise’s cryptography lives in systems a vendor owns, and you cannot change those algorithms unilaterally. SaaS platforms, cloud services, CDNs, managed security services, and hardware with vendor firmware all decide their own cryptography and migrate on a schedule you don’t set. Your real leverage lives at procurement and contract renewal, and it starts with asking the questions a vendor would rather you skip:

1. In new procurement, write post-quantum readiness into the RFP and require a documented roadmap with dated support commitments before you sign.
2. At contract renewal, negotiate explicit support obligations and timelines into the deal, because renewal dates are forcing functions.
3. Through enterprise relationships, route the roadmap question up to the vendor’s product strategy team rather than the support desk.
4. With regulatory leverage, point to the mandate that binds you, since a vendor that serves regulated customers moves faster when compliance risk is on the table.

A vendor’s verbal “we’re working on it” is a comfort, and only the contractual answer is real. An opaque vendor surface with no roadmap and a long timeline is one of the highest-priority findings in any migration, precisely because it’s the part you can’t fix alone. The full playbook is in Vendor-Controlled Crypto Surfaces.

What separates a healthy migration from a stalling one?

The difference shows up in the organizational signs long before it shows up in the cryptography. A migration that’s actually moving looks different from one that’s frozen behind a beautiful plan:

Sign	A healthy migration	A stalling one
Ownership	One name answers “who owns this”	Five shrugs, or five different answers
Visibility	A living CBOM exists and grows	Nobody can say where the cryptography lives
First moves	Small, reversible pilots landing without drama	A big-bang plan that never quite starts
Vendors	Roadmap questions written into contracts	”Our vendors have it handled”
Framing	Presented as the new engineering baseline	Framed as a crisis, then quietly deprioritized
Cadence	A governed, sustained, multi-year rhythm	One burst of energy, then silence

Read down the “stalling” column and you’re reading the anatomy of a program that has a flawless roadmap and no motion. Every entry is organizational, and every fix is too.

How does a stalled migration start moving?

The sequence is deliberate, and it front-loads the organizational work the technical roadmaps skip. From the anatomy of a stall:

1. 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.
2. Build visibility by standing up the cryptographic inventory, because every later decision about what to prioritize, budget, and defend rests on knowing where your cryptography actually lives.
3. Make the first moves small and reversible, acclimating the team with steps it can undo rather than a mandate to rebuild everything, and framing each one around what your engineers gain.
4. Set a cadence and govern it, because a migration is a multi-year program and governance is what keeps the queue moving after the first burst of energy fades.

The cryptography enters only after the organizational groundwork is laid, and that ordering is the whole difference between a program that ships and one that stalls.

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.
• “It’s an IT task.” It’s cross-functional. Engineering can’t compel procurement, and neither owns the regulatory clock, so an IT-only mandate is how the work lands in the ownership gap.
• “Our vendors have it handled.” Mostly they don’t, and a roadmap statement is not deployed protection. The vulnerable algorithm hides inside vendor products on a timeline you have to verify.
• “If we mandate it, engineers will do it.” A mandate produces compliance-shaped delay, not adoption, because the resistance is emotional and an order doesn’t address the fear underneath it.
• “Start with the most important system to show we’re serious.” Backwards. Start with the least important, most reversible system, so the first attempt is cheap, private, and safe.
• “We finished, we migrated our systems.” If “our systems” meant the internally-managed ones, the vendor-controlled surfaces, usually the majority of the footprint, are still open.

Questions people ask

Why is the human and organizational side the hard part? Because the cryptography is bounded and largely solved, while the visibility, ownership, coordination, and adoption around it are open-ended and involve people. The algorithm swap is the easy 20%; the organizational work is the other 80%, and it holds nearly all of the delay.

Who should own a post-quantum migration? One accountable executive, most often the CISO or a direct delegate, supported by a cross-functional working group and board-level sponsorship. No single function can own it alone because the levers are split across engineering, procurement, security, and governance. See Cryptographic Ownership.

What’s the very first step? Name the accountable owner, before discovery, before budget, before any code. A migration with a name attached to it moves, and an orphaned one waits indefinitely no matter how good the technical plan is.

Why do engineers resist if they agree quantum is a real threat? The resistance is about expertise, exposure, and competing priorities, not disagreement. A migration can feel like it makes hard-won skills obsolete and it competes with the delivery work people are measured on, so it surfaces as quiet delay rather than open objection.

What’s a completely reversible first move? A hybrid handshake on one internal service, a discovery pass on a single system, or enabling a post-quantum-capable library while leaving the classical path active. Each can be undone with a config change, which is what lowers the stakes enough for the team to act.

Can we just wait for our vendors to migrate? You have to engage them, not wait. Vendors set their own timelines and won’t volunteer their exposure, so the move is to write post-quantum commitments into procurement and renewals and to record each surface in your inventory. See Vendor-Controlled Crypto Surfaces.

How long does the organizational side take? Longer than the cryptography, which is the point. Discovery, ownership, vendor engagement, and adoption run over a multi-year program, so starting now matters even though a quantum computer doesn’t exist yet.

Isn’t change management soft compared to the real technical work? It’s the primary bottleneck. The technical work is the part that was always going to get done once people actually started, and getting them to start is the discipline that decides whether a roadmap becomes motion.

Go deeper

The four notes in this hub:

• Why Post-Quantum Migrations Stall: the anatomy of a stall, why migrations stall organizationally rather than cryptographically, and the 80/20 that explains it.
• Cryptographic Ownership: who actually owns the migration, why the seat is usually empty, and how to structure accountability so the program has somewhere to live.
• Change Management for Cryptographic Migration: the discipline of getting people to adopt the change, and the reversible-moves approach that defuses resistance.
• Vendor-Controlled Crypto Surfaces: the majority of your footprint that a third party controls, and how to turn procurement and renewals into leverage.

The operating model and its levers:

• The Crypto Center of Excellence: the central-team operating model that gives cryptographic migration a permanent home.
• The Cryptographic Risk Register: putting quantum risk into enterprise risk management so it competes for budget and attention on the same terms as every other risk.
• PQC Procurement and RFP Language: writing PQC readiness into purchasing, so vendor-controlled surfaces move on your schedule.
• Cryptographic Supply-Chain Risk: the nth-party layer beneath the direct vendor, where most cryptography is inherited transitively through open-source libraries and your vendors’ vendors, traced with an SBOM linked to a CBOM and made checkable through attestation.
• Funding a PQC Program (The Business Case): turning a threat with no breach date into a budget line, the memo that moves money, and the loss-avoidance case a finance committee approves.
• Cryptographic Incident Response and Emergency Rotation: the break-glass runbook for the week an algorithm, parameter set, or library is broken, the emergency-rotation steps, the named owner, and the tabletop rehearsal that turn crypto-agility into a capability people can actually execute.

Field notes (essays):

• The Psychology of Post-Quantum Risk: why the mind waves off a slow, invisible threat and why the people who must do the work quietly defend against it, the psychology beneath every stalled migration.
• When Crypto Fails, Who Actually Pays: the human and societal cost of cryptographic failure, why the fine lands on a balance sheet while the patient and the citizen carry the loss that never expires.

Where this connects:

• The inventory this whole side depends on: Cryptographic Bill of Materials (CBOM).
• The architecture that makes the next change a config swap: Crypto-Agility and Hybrid Cryptography.
• The clock and the exposure that set the urgency: Mosca’s Theorem, Blast Radius, and Harvest Now, Decrypt Later (HNDL).
• The deadlines that make it mandatory: the mandates. How to actually roll it out: migration architecture.

---

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, so a roadmap actually turns into motion, 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.