Marin Ivezic
NIST published its first post-quantum standards in August 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. Two years on, the algorithm question is settled for most enterprises. Almost none of the arguments that stall a post-quantum cryptography (PQC) migration program are arguments about algorithms.
They are arguments about money, sequencing, and reporting lines. They arrive early, usually inside the first two quarters, while the funding case is still open and the accountable executive’s authority has not yet been tested against a domain owner who says no. They are rarely hostile. They come from capable colleagues who have a real point buried inside a conclusion that does not follow from it, which is what makes them so hard to answer in a live meeting.
We group the recurring ones into three shapes: objections that move the work somewhere else, objections that shrink it, and objections that rewrite the org chart. Learn the shape and you can answer a version you have never heard before.
Split the objection in two
Every durable objection has two halves. There is an observation, which is usually correct, and there is a remedy, which usually does not follow from it. Programs get into trouble when the program lead disputes the observation. The room can see the observation is true, so the room concludes the program lead isn’t listening, and the remedy survives untouched.
Take the most common one: our vendors will handle it.
The observation is sound. Your cloud provider will ship hybrid TLS. Your hardware security module (HSM) vendor, the appliance that generates and guards your private keys, will release PQC-capable firmware. Your certificate authority (CA) will issue PQC certificates. None of this is optional, and none of it is inside your control.
The remedy doesn’t follow. Vendors deliver components. Nobody outside your organization knows which of those components you run, in which configuration, wired to what. A vendor cannot tell you that your claims-processing application pins a certificate chain in code written in 2011, or that two of your reinsurance partners accept signatures only in a format your new library doesn’t emit. Both of those are integration failures that appear on cutover weekend, and both are yours.
Concede the first half completely. Then name the gap in one line: necessary is not sufficient. That sentence is the whole technique, and it works on all nine of the objections below.
Shape one: move the work somewhere else
These objections accept that the migration is real. They relocate it, either to another party or to a later date.
Our vendors will handle it. Answered above. The follow-up that closes it is a question rather than a rebuttal: which of our systems does that vendor see, and who owns the ones it doesn’t?
We can’t start until we’ve inventoried everything. The observation is correct and important. Migrating without a cryptographic inventory is guesswork, and discovery is the foundation of every credible program.
The remedy fails on arithmetic. Complete discovery in a large estate is a moving target. New services deploy weekly, acquisitions arrive with their own certificate authorities, and previously isolated operational technology gets a network route so a vendor can do remote diagnostics. A program that waits for the last five percent waits forever, and waiting has a price. Harvest-now-decrypt-later (HNDL) is the reason: an adversary records your encrypted traffic today and decrypts it years later, once a cryptographically relevant quantum computer exists. Every month an external-facing TLS endpoint stays on classical key exchange is a month of traffic banked against your future.
The workable answer is concurrency. Run discovery continuously and start migration waves as each wave’s systems are discovered and assessed. Your second wave can be in flight while the discovery team is still mapping plant floor controllers that won’t move until wave five.
Crypto-agility can wait. Crypto-agility is the ability to change a cryptographic algorithm through configuration and process rather than through a new capital project. The observation here is fair: don’t delay the migration to build a perfect agility framework first.
But agility isn’t a phase that follows migration. It is a property of how you migrate. Every system you touch is either left with its algorithm choice hardcoded, or left with that choice behind an abstraction layer and a documented owner. The first option means the next transition is another full program. The second means it is a change request. NIST’s crypto-agility white paper (CSWP 39) sets out a maturity model along exactly these lines, and the EU’s Digital Operational Resilience Act (DORA) technical standards on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, require firms to provide for updating cryptographic technology in light of developments in cryptanalysis. Migrating without agility can leave you compliant with the algorithm requirement and exposed on the update requirement.
Shape two: shrink the problem
These objections don’t relocate the work. They argue there is less of it than you claim.
It’s just a crypto upgrade. At the atomic level, this is true. ML-KEM replaces ECDH, ML-DSA replaces ECDSA, and if every system reached cryptography through one clean interface, the objection would be right.
Very few estates work that way. Cryptography sits in load balancer configurations, in certificate validation logic inside custom applications, in HSM key ceremonies, in VPN gateway firmware, in signature formats agreed with trading partners a decade ago, and in device firmware that cannot be patched at all. The most efficient answer in the room isn’t a counter-assertion. Ask the person to name every system in the enterprise that uses public-key cryptography. They can’t, and neither can anyone else before discovery runs. An organization that doesn’t yet know the scope isn’t positioned to declare it small.
The board doesn’t need to be involved. The observation is right that directors shouldn’t be evaluating lattice-based key exchange. The remedy fails because the program needs three things the board alone can supply: capital expenditure funding that sits outside the normal security operating budget, cross-functional authority the CISO may not otherwise hold, and a documented position on regulatory deadlines. FIPS 140-2 module validations move to the Cryptographic Module Validation Program (CMVP) historical list in September 2026, and the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets its own requirements for national security systems and their suppliers. SEC disclosure rules already require public companies to describe board oversight of material cybersecurity risks. Directors don’t need the mathematics. They need to set risk appetite, approve the funding profile, watch a small set of indicators, and hold one named executive to delivery. That is the same oversight model they apply to credit risk and climate risk without domain expertise in either.
Shape three: rewrite the org chart
These are the most expensive objections, because acting on them costs a year before any migration work begins.
Quantum risk is too exceptional for existing governance. Every property attributed to quantum risk has appeared before. The General Data Protection Regulation (GDPR) touched every process handling personal data and extended to every supplier. Basel III demanded new data infrastructure and years of capital reallocation. Y2K had universal scope, deep technical reach, and a fixed date. In each case the organizations that delivered expanded an existing mandate. Nobody appointed a Chief Privacy Transformation Officer.
The CISO can’t lead this, so create a new executive role. The observation is sometimes true: some CISOs genuinely lack the authority for an enterprise transformation. The remedy solves for the weakest version of the role and then discards the role. It also imports three new problems. The incoming leader spends a year building relationships the CISO already has. The profile you are hiring for, combining cryptographic depth, business credibility, and a multi-year commitment, is thin in most markets. And a program built around one exceptional individual fails when that individual leaves. When a challenge outgrows a role, expanding the role is faster than inventing one.
Engineering and OT won’t take direction from security, so lead it by committee. The observation is accurate. Plant managers hold final authority over their environments, and facilities and regional IT operate with real autonomy. The remedy fails because committees advise and do not deliver. Consensus governance moves at the pace of the most reluctant participant, which in practice means the program advances only when every domain has capacity and appetite at the same moment.
The distinction to draw is between program authority and directive authority. The accountable executive doesn’t run the plant. Through a steering committee that includes OT and facilities representation, the executive sets standards, sequence, and risk acceptance criteria. Domain owners execute inside their own environments and are held to delivery through the governance structure rather than through a reporting line.
The CFO should lead it. Sustained multi-year funding does need financial ownership, and the CFO’s office should own the capital expenditure and operating expenditure split, the stage gates, and the reporting. But the CFO has no relationship with the cryptographic vendors, no basis for judging whether a supplier’s PQC roadmap is credible, and no view of the estate. The CFO governs the money and co-sponsors the mandate. Those are not the same job as running the program.
Rehearse before the meeting, not after it
The technique is simple and almost nobody prepares it. For each objection you expect, write three lines: the observation you will concede out loud, the gap between that observation and the proposed remedy, and the one piece of evidence you will bring. A regulatory date, a discovery finding from your own estate, a named integration that a vendor patch would break. One page per objection.
Then answer in writing afterwards and circulate it. An objection that is answered on the record stays answered. An objection that is overridden by seniority comes back, usually at the stage gate where you can least afford to reopen it.
Where to build this
Answering these objections well depends on knowing the underlying material well enough to concede the accurate half without hesitating. Someone who cannot explain why a full inventory is never finished will either dismiss the concern or surrender to it.
That is what our post-quantum governance and migration training is built for: the funding case, the discovery sequence, the wave plan, the board reporting cascade, and the vendor accountability model, taught as the working artifacts a program lead has to defend. You can review the current programs and enrollment options at quantumacademy.com/.
For the migration methodology these objections are usually aimed at, see the PQC Migration Framework. For the longer governance treatment this article draws on, see the original analysis on PostQuantum.com.