PQC Governance Objections: A Field Guide to the Arguments That Delay Programs

Introduction

Every PQC program I have worked on has faced internal resistance. Not hostility, usually. Reasonable-sounding objections from reasonable people who are either genuinely uncertain about the program’s approach or (less charitably) looking for reasons to defer something that will consume budget, political capital, and organizational attention they would rather spend elsewhere.

These objections are predictable. They cluster around the same themes regardless of industry, geography, or organization size. And they are most dangerous in the first six months of the program, when the governance model is being established, the budget is being negotiated, and the accountable executive’s authority has not yet been tested in practice.

This article catalogs nine objections I encounter repeatedly, explains what is genuine in each, and provides the counter-reasoning that keeps programs moving. It is part of the PQC Governance Deep Dive series. Where an objection is addressed in depth in another article in the series, I point there rather than repeating the full argument.

“Our Vendors Will Handle It”

This is the most common objection and the most dangerous one, because it gives the entire organization permission to do nothing. IBM’s “Secure the Post-Quantum Future” report found that 62% of executives hold this view: they expect cloud providers, network equipment manufacturers, and software vendors to embed PQC so that internal teams can apply updates when available.

The genuine observation: vendors do play a critical role. Your cloud provider will eventually support hybrid TLS. Your HSM vendor will release PQC-capable firmware. Your CA will issue PQC certificates. These vendor deliverables are necessary inputs to your migration.

Why it fails: necessary is not sufficient. Your vendors do not have visibility into your cryptographic estate. They do not know which of their products you use, in which configuration, with which cryptographic dependencies, integrated with which other vendors’ products. They cannot assess whether their PQC update will break your custom integrations, your application-layer certificate handling, or your cross-system digital signature workflows. They will deliver their component. The puzzle assembly across potentially 120,000 tasks is your problem.

I wrote about why PQC readiness is not a vendor problem when the IBM report came out. The vendor governance article in this series covers how to govern vendor dependencies without outsourcing your accountability for the migration. The short version: vendors are partners in your migration, not substitutes for it.

“The Board Doesn’t Need to Be Involved”

The argument: PQC migration is a technical infrastructure project. The CISO and IT team can handle it within their existing remit. The board has enough on its agenda without adding a cryptographic migration that most directors won’t understand.

The genuine observation: boards should not micromanage technical projects. Directors do not need to evaluate lattice-based key exchange mechanisms or debate PQC algorithm selection.

Why it fails: PQC migration is not a technical project that happens to be large. It is a multi-year transformation program that requires dedicated CapEx funding (distinct from normal cybersecurity OpEx), cross-functional authority that the CISO may not have without board backing, and compliance with regulatory deadlines that carry material consequences for non-compliance. The SEC’s cybersecurity disclosure rules require public companies to describe board oversight of material cybersecurity risks. As PQC migration deadlines approach (FIPS 140-2 deprecation in September 2026, CNSA 2.0 procurement gate in January 2027), PQC preparedness becomes a disclosable risk.

The board does not need to understand the technology. It needs to set risk appetite, approve the budget, monitor aggregate KRIs, and hold the accountable executive to delivery. This is the same oversight model boards use for every other material risk they govern without domain expertise, from credit risk to climate risk to AI risk. The board governance article covers the full mechanism: risk appetite statements, three-tier KRI cascade, and the questions directors should ask at each stage of the program.

“It’s Just a Crypto Upgrade”

The argument: PQC migration is an algorithm swap. Update the cryptographic libraries, rotate the certificates, upgrade the HSMs. It is a technical project the security team can handle within their existing budget and authority. No need for a cross-organizational program, a dedicated PMO, or a transformation-scale budget.

The genuine observation: at the atomic level, PQC migration is indeed about replacing algorithms. ML-KEM replaces ECDH for key exchange. ML-DSA replaces ECDSA for digital signatures. If every system in the enterprise used cryptography through a single abstraction layer with a clean API, the migration might be as straightforward as this objection implies.

Why it fails: almost no enterprise works that way. Cryptography is embedded at every layer of the technology stack, in different ways, by different teams, over decades of accumulated decisions. It is in TLS configurations on load balancers, in certificate validation logic in custom applications, in hardcoded algorithm selections in legacy code, in HSM key management workflows, in VPN gateway firmware, in digital signature formats exchanged with business partners, in OT controller authentication protocols, in IoT device firmware that cannot be updated at all. I described in the 120,000 Tasks article why the task count reaches six figures and why the interdependencies between those tasks are what make PQC qualitatively different from a library upgrade.

The most telling test: ask the person making this objection to name every system in the enterprise that uses public-key cryptography. They cannot. Nobody can before discovery. An organization that does not know the scope of the problem is in no position to assert that the problem is small.

“Just Swap the Algorithms, Worry About Crypto-Agility Later”

The argument: the urgent priority is migrating from classical to PQC algorithms before regulatory deadlines hit. Building crypto-agility (the ability to swap algorithms quickly in the future) is a nice-to-have that can wait. Don’t let the perfect be the enemy of the good.

The genuine observation: organizations facing near-term deadlines (CNSA 2.0 in January 2027, FIPS 140-2 deprecation in September 2026) should not delay migration to build a perfect crypto-agility framework first. Getting started matters more than getting everything right in one pass.

Why it is partly wrong: crypto-agility is not a separate project bolted on after migration. It is a design principle applied during migration. The way you migrate determines whether the next algorithm transition (and there will be one, because algorithm standards evolve) costs another $50M or can be handled through configuration changes in weeks.

NIST’s crypto-agility guidance (CSWP 39, finalized December 2025) describes a maturity model where most organizations operate at Level 0-1 (each transition requires a full project). Investing an additional 3-5% during migration to reach Level 2 (documented processes and standards, 3-6 month transitions) is the kind of investment that CFOs should want to make, because it reduces the present value of all future cryptographic transitions.

DORA’s ICT risk management RTS (Article 6(4)) requires “provisions for updating or changing the cryptographic technology on the basis of developments in cryptanalysis,” which many legal interpretations read as a crypto-agility mandate. Organizations that migrate to PQC without building agility may find themselves non-compliant with the very regulation they were trying to satisfy.

The pragmatic answer: do not delay migration to build crypto-agility. But do build crypto-agility into the migration as you go. Use abstraction layers in new code. Document the cryptographic decisions. Automate certificate lifecycle management. Maintain the cryptographic inventory as a living system, not a one-time exercise. These choices add minimal cost during migration and dramatically reduce the cost of future transitions.

“We Can’t Start Migration Until We’ve Inventoried Everything”

The argument: you cannot migrate what you cannot see. The organization must complete a comprehensive cryptographic inventory across every system, application, vendor, and device before any migration work begins. Starting migration without complete visibility risks missing critical systems.

The genuine observation: discovery is essential. Migration without a cryptographic inventory is guesswork. I have written extensively about why discovery is the foundational phase of any PQC program.

Why it stalls programs: “complete” discovery in a large enterprise is a moving target. New systems are deployed. Vendor relationships change. Shadow IT appears. IoT devices are added to networks. OT environments that were air-gapped become connected. Waiting for 100% inventory completeness before starting any migration means waiting indefinitely, because the estate is not static.

The pragmatic approach is concurrent, not sequential. Begin discovery broadly (covering all execution domains). Simultaneously, begin migration on the systems discovery has already identified as highest priority. The HNDL threat makes waiting costly: every month you delay migrating an external-facing TLS endpoint while waiting for the last 10% of discovery to complete is a month that data transiting that endpoint can be harvested for future decryption.

In the programs I have worked on, the pattern that works is: run discovery continuously (it is never truly “done”), and start migration waves as soon as each wave’s systems have been discovered and assessed. Wave 2 migration can begin while the discovery team is still mapping OT systems that will not migrate until Wave 4 or 5. The wave plan described in the execution model article explicitly builds this concurrency into the timeline.

“Quantum Risk Is Too Exceptional for Existing Governance”

The argument: quantum risk is unlike anything the organization has faced. Its scope spans every system. Its depth reaches the cryptographic foundations of digital trust. Its time dynamics are unusual (HNDL means data harvested today is decrypted years later). Its impact is existential. Therefore, quantum risk requires governance fundamentally different from how the organization handles cyber risk.

The genuine observation: quantum risk does have unusual properties. I have called PQC migration the largest IT/OT transformation in enterprise history. The scope, depth, and time dynamics are real.

Why the proposed remedy fails: every one of the properties attributed to quantum risk has appeared in other risks that organizations governed through existing frameworks with expanded mandates. AI risk affects every function and system. GDPR affected every process touching personal data and extended to every supplier. Climate risk in financial services affects every loan, investment, and counterparty, over decades. The pandemic was literally existential for many businesses. Basel II/III was a multi-year transformation requiring entirely new data infrastructure and trillions in capital reallocation. Y2K had universal scope, deep technical reach, a hard deadline, and potentially catastrophic systemic impact.

In every case, organizations expanded existing governance to meet the challenge. Nobody created a Chief Privacy Transformation VP for GDPR. Nobody appointed a Chief Pandemic Officer. Nobody invented a new role for Basel III. They expanded the DPO’s mandate, the CRO’s mandate, the crisis governance structure’s mandate. The pattern over 20 years is consistent: organizations that expand existing governance deliver; organizations that try to build new governance structures from scratch lose 12-18 months on design before execution begins.

Quantum risk is serious. It is not so exceptional that it requires abandoning governance models that have worked for every other serious risk of the past two decades.

“The CISO Can’t Lead This. We Need a New Executive Role.”

The argument takes two forms. First: the CISO is consumed by daily operations, has influence but not power, is a lower-level executive, and will burn out. Second: the organization needs a dedicated transformation leader, perhaps a Chief Quantum Officer, a Chief Cryptographic Officer, or a senior business VP who commands the political weight to force enterprise-wide change.

The genuine observation: some CISOs do lack the organizational authority for an enterprise-wide transformation. And PQC migration does require extraordinary resources, dedicated staff, and cross-functional authority that the CISO may not currently possess.

Why the proposed remedy fails: I address this in full in the CISO organizational models article. The short version: this argument solves for the weakest version of the CISO role and concludes the role itself is insufficient. In practice, CISO roles range from 15-person oversight functions to 2,000-person organizations with nine-figure budgets and direct board access. The argument also founders on four practical problems with the proposed new role: the 12-18 month relationship delay (the new leader must build every relationship the CISO already has), the unicorn hire (the profile combining domain expertise, business credibility, and multi-year commitment to cryptographic migration does not exist in most organizations), the succession fragility (hero-dependent programs collapse when the hero leaves), and the career incentive mismatch (nobody gets promoted for preventing an invisible disaster; the people willing to commit years to this work are the people who built their careers in security).

When a challenge outgrows an existing role, the right response is to expand the role. Every major security transformation of the past decade (cloud security, OT security, DevSecOps, GDPR technical compliance) followed this pattern. I have also previously examined the Chief Quantum Officer proposal in detail.

“Engineering and OT Can’t Report to the CISO. Lead It by Committee.”

The argument: OT engineers, plant managers, facilities teams, and LOB heads are not going to take direction from the CISO. These domains have their own governance structures, their own reporting lines, and their own operational cultures. The only workable approach is a committee where all affected parties have equal voice and decisions are made by consensus.

The genuine observation: the execution model article describes at least a dozen execution domains, many of which operate outside the CISO’s reporting line. Plant managers do have final authority over their plant environments. Facilities directors do manage building systems independently. Regional IT directors do operate with significant autonomy. The program cannot pretend these authority structures do not exist.

Why governance by committee fails: committees advise. They do not deliver. A multi-year transformation program with 120,000 tasks, thousands of interdependencies, and regulatory deadlines requires a single accountable executive who can make decisions, allocate resources, and force trade-offs when competing priorities conflict. Committee governance produces consensus at the speed of the most reluctant participant, which in practice means the program advances only when every domain owner simultaneously has capacity and willingness to participate. I have never seen a committee-led transformation program succeed at enterprise scale, in PQC or in any other domain.

The distinction is between leadership and directive authority. The accountable executive leads the program. That does not mean the CISO directs plant operations or tells the facilities team how to run their building systems. It means the CISO (through the steering committee, which includes OT and facilities representation) sets the program standards, timelines, and risk acceptance criteria. The domain owners execute within their own environments according to those standards, using execution models appropriate to their domain. The accountable executive holds them accountable for delivery through the governance structure, not through a reporting line. That is how the governance overview and the execution model are designed to interact: central governance with distributed execution.

“This Is So Important the CFO Should Lead It”

The argument: PQC migration is a multi-year, multi-million-dollar transformation. It should be run by someone who understands capital allocation, can secure sustained funding, and has the organizational weight to command respect across business units. The CFO is the right person.

The genuine observation: sustained funding and board-level organizational weight are critical. The cost estimation article in this series covers the budget structure in detail, and the CapEx/OpEx split, the stage-gate reviews, and the multi-year phasing are exactly the kind of financial planning the CFO’s office manages well.

Why it fails: the CFO has no relationship with the cryptographic technology providers, security vendors, regulatory bodies, or the internal teams who operate the cryptographic estate. The CFO does not understand the difference between ML-KEM and ML-DSA, cannot evaluate whether a vendor’s PQC roadmap is credible, and has no basis for making technical trade-off decisions about hybrid deployment strategies or algorithm selection. A CFO-led PQC program would need to hire the entire technical leadership layer that the CISO already has, then spend 12-18 months building the institutional relationships that the security function has cultivated over years.

The CFO has a critical role in PQC governance. It sits on the steering committee, where it approves the budget, validates the CapEx/OpEx structure, and ensures that the program’s financial reporting meets the organization’s capital planning standards. The CFO may co-sponsor the initial board mandate alongside the CISO. But the CFO leads the financial governance, not the program execution. Those are different things.

How to Use This Article

These objections will surface in your program, probably in the first six months. Some will come from well-meaning colleagues with genuine concerns. Some will come from executives who would prefer a different governance structure or a different leader. Some will come from consultants positioning their own services.

When they surface, resist the urge to dismiss them. Each objection contains a genuine observation that deserves acknowledgment. Then address the logical gap between the observation and the proposed remedy. The vendor does play a role, but the vendor cannot do your migration. The board should not micromanage, but the board must govern. The CISO may need expanded authority, but expanding authority is faster than inventing a new role. The observation is usually right. The conclusion is usually wrong.

Forward this article to the colleague making the objection. Not as a rebuttal, but as a discussion document. The strongest programs I have seen are the ones where objections were engaged openly, answered with evidence, and resolved through structured governance rather than suppressed through authority. An objection that is answered stays answered. An objection that is silenced returns, usually at the worst possible moment.

The governance overview provides the model these objections challenge. The board governance article explains the oversight mechanism. The CISO role article maps organizational models. The cost estimation article covers funding. The vendor governance article covers the supply chain. The execution model covers delivery across every domain. Together, they provide the evidence base for answering any objection a PQC program will face.

The PQC Migration Framework provides the migration methodology. Quantum Ready covers the full readiness strategy.