PQC Vendor and Supply Chain Governance: Managing Third-Party Cryptographic Risk at Enterprise Scale

The Vendor Delusion

IBM’s “Secure the Post-Quantum Future” report found that 62% of executives admitted their organization is waiting for vendors to make them quantum-safe. They expect cloud providers, network equipment manufacturers, and software vendors to embed post-quantum cryptography so that internal teams can simply apply updates when available.

I wrote about why this mindset is dangerous when the IBM report came out. The short version: your vendors do not have visibility into your cryptographic estate. They do not control your application architecture. They do not know which of their products you use, in which configuration, with which cryptographic dependencies, integrated with which other vendors’ products. Even vendors with excellent PQC roadmaps can only deliver their piece of the puzzle. The puzzle assembly is your problem.

The vendor delusion persists because it is comforting. If vendors will handle PQC, then the CISO does not need to build a business case, the board does not need to approve a multi-year transformation budget, and nobody needs to confront the 120,000-task reality of what enterprise PQC migration actually involves. The delusion is a governance failure disguised as a procurement strategy.

This article covers how to govern the vendor and supply chain dimension of PQC migration once you have accepted that vendors are partners in your migration, not substitutes for it. It is part of the PQC Governance Deep Dive series. The governance overview describes the overall program structure. The cost estimation article covers vendor-related costs. I have also written a tactical guide on how to engage individual vendors on quantum readiness. This article operates at the level above all of those: how the PQC program governs the entire vendor portfolio.

Why Vendor Governance Requires Its Own Workstream

Internal PQC migration is hard. You control the infrastructure, the applications, the timelines, and the budget. You can (with sufficient authority) compel your own teams to prioritize migration work, allocate change windows, and accept the performance overhead of hybrid cryptographic operations.

Vendor PQC migration is a different category of problem. You do not control the vendor’s development roadmap, their engineering priorities, their algorithm choices, or their migration timeline. You may not even know which cryptographic algorithms they use. Your leverage is limited to the contract you signed (which almost certainly does not address PQC), your commercial importance to the vendor (which varies), and your willingness to switch vendors (which is often low for deeply integrated systems).

Four dimensions make vendor governance distinct from internal migration governance.

Visibility. You cannot migrate what you cannot see. For internal systems, the cryptographic inventory process discovers your own algorithms, keys, and certificates. For vendor-supplied systems, discovery depends on vendor cooperation. If a SaaS vendor does not disclose which algorithms their platform uses internally, you have a visibility gap that no scanning tool can close.

Control. For internal systems, the accountable executive can direct engineering teams to migrate. For vendor systems, the best you can do is ask, incentivize, or threaten. If the vendor declines or delays, your options are to accept the risk, find a workaround, or switch vendors. Each option has cost and timeline implications that compound across dozens of vendor relationships.

Timing. Your migration timeline is set by regulatory deadlines and your own risk appetite. Your vendors’ timelines are set by their own business priorities, engineering capacity, and the demand signals they receive from their entire customer base. These timelines rarely align. The UK’s Cross Market Operational Resilience Group acknowledged this gap explicitly in its April 2025 PQC guidance: vendor migration timelines “might not align with those of the financial sector unless demand is signalled.”

Cascade effects. A single vendor that cannot migrate on your timeline can block the migration of every internal system that depends on that vendor. If your certificate authority does not support PQC certificate issuance, your entire PKI migration stalls. If your HSM vendor cannot deliver PQC-capable hardware, your key management migration waits. If your ERP vendor has not tested PQC compatibility, your most critical business application stays on classical cryptography regardless of what you do internally.

Start with Collaboration, Not Contracts

The instinct when facing a vendor governance challenge is to reach for contracts: amend the terms, add requirements, create penalty clauses. That instinct is correct for the long term, but it is the wrong starting point. Most of your vendors are in the same position you are: early in their own PQC planning, uncertain about timelines, and unsure what their customers will need. Leading with legal demands before the vendor understands the problem creates defensiveness, not partnership.

The organizations I have seen make the most progress with vendor PQC readiness started with education and collaboration before moving to formal requirements. Three approaches have worked well in practice.

Vendor awareness events

Several of my clients have organized vendor conferences or webinars early in their PQC program (within the first three months) to brief their critical vendors on the organization’s PQC migration plans, the regulatory drivers, and what the organization will eventually need from each vendor. These events are not procurement negotiations. They are awareness sessions: “We are beginning this journey, we think you should be aware, we are in this together, let’s figure it out.”

The cost is modest ($10K-$30K for event logistics and content development). The return is substantial. Vendors who attend leave with an understanding that PQC demand is real and approaching. Many will begin internal conversations about their own PQC roadmap that they would not have had otherwise. Some will proactively share information about their cryptographic implementations and migration plans. A few will ask to collaborate on pilot testing. And you will learn, informally and without the friction of a formal assessment process, which vendors are engaged and which are not, which is an early signal of who will cooperate and who will need contractual pressure later.

Informal roadmap conversations

Before sending formal questionnaires, have informal technical conversations with your Tier 1 vendors’ product management or security teams. The question is simple: “What is your PQC roadmap? When will you support hybrid mode? When will you support PQC-only? What do you need from us to help prioritize this?” These conversations produce better information than questionnaires because they are bidirectional. You learn the vendor’s constraints (their dependency on upstream libraries, their FIPS validation timeline, their engineering capacity). They learn your timeline and requirements. Both sides leave with a more realistic picture of the dependency.

Industry-level coordination

For vendors that serve your entire industry (payment networks, industry messaging platforms, sector-specific data exchanges), individual customer pressure has limited impact. Industry-level coordination is more effective. Financial services organizations can work through groups like the Europol Quantum Safe Financial Forum, FS-ISAC, or CMORG. Telecommunications operators can work through GSMA. Government suppliers coordinate through CISA and the defense acquisition community. When a vendor hears from one customer that PQC matters, they note it. When they hear from an industry consortium, they act.

The collaborative phase does not replace formal contractual requirements. It precedes them. By the time you send the formal questionnaire or propose contract amendments, the vendor already understands the context, has had time to assess their own readiness, and is more likely to engage constructively than if the first communication is a legal demand.

Vendor Tiering and Prioritization

You cannot govern 200 vendor relationships with equal intensity. The PQC program needs a tiering model that concentrates governance attention where the cryptographic risk is highest.

I recommend a three-tier model based on two dimensions: cryptographic exposure (does the vendor process, store, or transit data protected by public-key cryptography on your behalf?) and migration dependency (does your internal migration depend on the vendor migrating first?).

Tier 1: Migration-blocking vendors. These are vendors whose PQC migration must complete before or alongside your own. They include your certificate authorities, HSM vendors, cloud infrastructure providers (AWS, Azure, GCP) where you rely on their TLS and key management, identity platform providers (Okta, Azure AD, Ping), payment network processors, and any SaaS platform that handles key exchange or digital signatures on your behalf. Tier 1 vendors require active governance: regular roadmap reviews, contractual PQC commitments, steering committee visibility, and (as I will cover below) substitution contingency planning from day one.

Tier 2: Cryptographically exposed vendors. These vendors process or store sensitive data using cryptography, but your internal migration does not depend on theirs completing first. They include ERP and CRM platforms, managed security service providers, data analytics vendors, and communication platforms. Tier 2 vendors require monitoring: annual PQC readiness questionnaires, tracking of published migration timelines, and escalation to Tier 1 if their timeline slips past your own.

Tier 3: Minimal cryptographic exposure. Vendors whose services involve minimal public-key cryptographic interaction with your data. Office supplies, facilities management, non-digital professional services. These require only baseline contract language in new agreements and no active PQC governance.

The tiering exercise itself produces useful data. In most organizations I have worked with, the number of Tier 1 vendors is smaller than expected (typically 10-25), the number of Tier 2 vendors is larger than expected (50-100+), and the Tier 3 remainder is where most vendor relationships sit. Concentrating governance on 10-25 Tier 1 relationships is manageable. Trying to govern 200 relationships equally is not.

The Regulatory Inventory Paradox

DORA’s ICT risk management regulatory technical standards (Commission Delegated Regulation EU 2024/1774) require financial entities to maintain a cryptographic inventory as a compliance output. Tim Williams identified a structural paradox in his PQC cost estimation paper: the same regulatory package (DORA) that requires you to inventory your cryptographic implementations does not, through its contractual arrangements RTS (EU 2024/1773), require vendors to disclose which algorithms they use.

The result: you have a regulatory obligation to produce an inventory you cannot complete without information your vendors are not contractually obligated to provide. The gap is real, the workaround is manual, and it costs money and time. Organizations with significant third-party dependencies should expect to add 10-20% to their discovery phase costs for contractual renegotiation and vendor assessment work that would be unnecessary if the regulatory framework were internally consistent.

The Canadian Centre for Cyber Security’s guidance ITSM.00.501 is the only government publication I am aware of that provides specific recommended contract clauses for cryptographic specifications. Every organization running a PQC program should have a copy of it, regardless of jurisdiction.

Contract Requirements

The collaborative engagement described above builds the foundation. Contract requirements provide the enforcement mechanism. Both are needed.

New contracts

Every new technology vendor contract should include PQC-relevant clauses. These do not require the vendor to be PQC-ready today. They require transparency and a commitment to a migration path.

Five clauses cover the minimum. A cryptographic disclosure clause requires the vendor to identify the public-key algorithms used in the service and notify the customer within 30 days of any algorithm changes. A PQC migration commitment clause requires the vendor to provide a written PQC migration roadmap upon request, including target dates for supporting NIST-approved PQC algorithms and hybrid deployment modes. An audit and assessment right permits the customer (or an appointed third party) to assess the vendor’s cryptographic implementation at a frequency appropriate to the vendor tier. A subcontractor flow-down clause requires the vendor to flow PQC disclosure and migration requirements to any subcontractors handling customer data. A termination trigger adds quantum-related cryptographic non-compliance as a named termination event if the vendor materially fails to meet its PQC migration commitments within an agreed timeline.

Existing contracts

Amending existing contracts is slower, more expensive, and depends on vendor willingness. Williams estimates contract amendment costs at £5,000-£50,000 per major vendor. For an organization with 20 major vendor relationships, the aggregate legal cost runs £75,000-£300,000, and this should be budgeted as a discrete line item in the PQC program (see the cost estimation article for the full budget structure).

Where contract amendment is not immediately feasible, a standalone PQC readiness questionnaire administered through the existing vendor management framework produces the visibility data even without contractual enforcement. Your vendor PQC readiness assessment process should include a standard questionnaire covering algorithm usage, migration roadmap, hybrid mode support, and subcontractor exposure.

Vendor Readiness Tracking and the KRI Cascade

Vendor PQC readiness feeds directly into the board-level KRI framework described in the board governance article. The specific KRI:

Vendor PQC readiness coverage. Percentage of Tier 1 and Tier 2 vendors who have provided a documented PQC migration roadmap or demonstrated PQC capability.

This KRI decomposes at the management level into: Tier 1 vendor-by-vendor readiness status (red/amber/green), Tier 2 aggregate readiness score, specific dependency blockers (which Tier 1 vendors are behind schedule and which internal migrations are affected), and contract amendment completion rate.

The steering committee should review Tier 1 vendor readiness quarterly. When a Tier 1 vendor’s status shifts from green to amber (roadmap exists but is slipping) or amber to red (no roadmap, no engagement, or roadmap materially behind your timeline), the accountable executive needs decision options: escalate commercially, accept the risk temporarily, or initiate the substitution process.

The vendor readiness KRI doubles as an early warning system for the cost estimation traps I described in the cost estimation article. If vendor readiness is lagging across the board, the program’s budget and timeline estimates need upward revision, and the steering committee needs that information before the board’s next quarterly review.

Substitution Planning: Start on Day One

This is the section most PQC programs defer and most regret deferring.

For every Tier 1 vendor, the program should maintain a substitution contingency from the start of the program, not from the moment the vendor disappoints. Substitution for critical systems is hard and lengthy. If you begin evaluating alternatives only after a Tier 1 vendor misses its roadmap commitments, you have added 12-18 months to your migration timeline (vendor evaluation, procurement, integration, testing, cutover), and you will be doing that evaluation under time pressure and with reduced negotiating leverage because the vendor knows you have no alternative ready.

What substitution planning looks like

Substitution planning does not mean switching vendors preemptively. It means maintaining the option to switch, so that the decision, if needed, can be made quickly and from a position of strength.

For each Tier 1 vendor, the program should answer three questions at the start and update the answers annually.

Who are the alternative vendors? For your CA, your HSM provider, your cloud KMS, your identity platform: who are the credible alternatives that offer PQC capability (or have a more aggressive PQC roadmap than your current vendor)? This is a desktop exercise that your procurement team and vendor liaison can complete in weeks, not months.

What would switching cost? An order-of-magnitude estimate of the migration cost (data migration, integration rework, retraining, parallel operations during cutover) and timeline for each Tier 1 vendor. You do not need a detailed project plan. You need a rough number and a rough timeline so that when the steering committee asks “what happens if we switch?”, the answer is a range, not “we have no idea.”

What is the trigger? Define the conditions under which the steering committee will initiate a formal substitution evaluation. A vendor that misses two consecutive roadmap milestones. A vendor that refuses to engage on PQC readiness. A vendor whose PQC timeline is more than 18 months behind your migration schedule. These triggers should be documented and agreed in the steering committee charter, not decided in the heat of a crisis.

Why this changes the vendor dynamic

Substitution planning has a secondary benefit beyond contingency: it changes the conversation with the incumbent vendor. A Tier 1 vendor who knows you have no alternative has little incentive to prioritize your PQC requirements. A Tier 1 vendor who knows you have assessed alternatives, estimated switching costs, and defined substitution triggers treats your PQC requirements differently. You do not need to threaten. The fact that you have done the homework is the leverage.

Several of my clients have found that the vendor’s PQC engagement improved after the vendor learned (through informal channels or commercial conversations) that alternatives had been evaluated. The evaluation itself sent a demand signal stronger than any formal questionnaire.

When Vendors Genuinely Cannot Cooperate

Some vendors will engage constructively. Major cloud platforms have published PQC roadmaps and already support hybrid key exchange in some services. Major HSM vendors have PQC-capable firmware in various stages of deployment and FIPS 140-3 validation. Major certificate authorities are piloting PQC certificate issuance.

Some vendors will not engage. Before concluding that a vendor is being uncooperative, consider that some genuinely cannot migrate on your timeline even with the best intentions. Their product may depend on a third-party cryptographic library that has not been updated. Their FIPS 140-3 validation may be in progress but 18 months from completion. Their engineering team may be fully committed to a major platform rewrite that must complete before PQC changes can be integrated. Understanding whether a vendor’s delay is strategic indifference or genuine constraint changes the governance response.

For genuinely constrained vendors, the response is collaborative: help them understand your timeline, provide testing environments or feedback loops that accelerate their development, participate in their beta programs, and build the interim compensating controls (network segmentation, data classification restrictions, additional monitoring) that reduce your exposure during the gap.

For strategically indifferent vendors, the response is commercial: the renewal conversation (conducted jointly by procurement and the accountable executive), the escalation to industry coordination bodies, and the formal initiation of substitution evaluation. If the vendor serves your entire industry and remains indifferent, the substitution trigger should activate, because a vendor that does not respond to industry-wide demand signals is unlikely to respond to any future pressure.

For Tier 1 vendors in either category, the situation is a program-level risk that the steering committee must address. Risk acceptance for a Tier 1 vendor means a critical dependency in your migration will remain on classical cryptography beyond your target date. That is a board-level decision because it affects the organization’s regulatory compliance posture and HNDL exposure.

For Tier 2 vendors, the response is proportionate: document the risk, apply compensating controls, and include the vendor in the next contract renewal cycle with PQC requirements baked in.

The Procurement Function’s Role

In most PQC programs, procurement is an afterthought. It should not be. The procurement function controls the contractual relationship with every vendor. If procurement is not part of the PQC program from the start, every contract amendment, every vendor assessment, and every new-vendor evaluation requires a separate engagement with a team that has not been briefed on PQC requirements and treats each request as ad hoc.

The governance overview describes a “vendor and supplier liaison function, embedded in procurement.” In practice, this means a named individual (or small team, in large organizations) within procurement who holds the PQC vendor governance brief. They attend the steering committee. They own the vendor tiering model. They manage the contract amendment pipeline. They coordinate vendor readiness questionnaires and the collaborative engagement events described above. They maintain the substitution contingency files for each Tier 1 vendor.

This person does not need to be a cryptographic engineer. They need to understand PQC contract requirements, the vendor tiering model, the regulatory drivers (DORA Article 30 contractual obligations, CNSA 2.0 procurement gates, NIST FIPS 140-2 deprecation), and the internal migration dependencies that each Tier 1 vendor relationship creates. The cryptographic engineering team provides technical specifications. Procurement translates those specifications into contractual language and manages the vendor relationship.

Supply Chain Cascades

The vendor governance challenge extends beyond direct vendor relationships. Your vendors have their own vendors. Your certificate authority depends on its root key infrastructure. Your cloud provider depends on its network equipment vendors. Your SaaS platform depends on its hosting provider’s TLS implementation.

Governing this cascade end-to-end is not realistic for most organizations. What is realistic is requiring Tier 1 vendors to address their own supply chain PQC risk through the subcontractor flow-down clause in your contract, and then monitoring their progress. If your Tier 1 vendor’s PQC migration is blocked by one of their own suppliers, that becomes visible through the vendor readiness tracking process, and you can factor it into your substitution planning.

The Harvest Now, Decrypt Later threat adds urgency to supply chain governance. Data transiting a vendor’s infrastructure today, encrypted with classical algorithms, may be harvested for future quantum decryption. Even if the vendor eventually migrates to PQC, the data that transited during the gap period cannot be retroactively protected. For organizations with long-sensitivity data (financial services, healthcare, defense, government), the vendor migration timeline directly affects HNDL exposure, and the governance model must account for that.

Practical Starting Points

For PQC programs that have not yet addressed vendor governance, the sequence matters. Start with collaboration, layer in structure, add contractual requirements as the program matures.

Organize a vendor awareness event. Brief your critical vendors on your PQC plans, the regulatory drivers, and what you will eventually need. This can happen within the first month of the program.

Complete the tiering exercise. It takes a week with the procurement team and the cryptographic engineering lead. Classify every technology vendor into Tier 1, 2, or 3. The output is a list of 10-25 Tier 1 vendors that need active governance.

Have informal roadmap conversations with Tier 1 vendors. Before the formal questionnaire, have a technical conversation. Learn their constraints. Share yours. Identify collaborative opportunities (joint testing, beta programs, feedback loops).

Build substitution contingency files for each Tier 1 vendor. Identify alternatives, estimate switching costs and timelines, define triggers. This is a desktop exercise that takes days per vendor, not months.

Send formal readiness questionnaires to Tier 1 and Tier 2 vendors. By this point, the context has been set through the awareness event and informal conversations. The questionnaire lands as a structured follow-up, not a cold demand.

Brief procurement and update contract templates. Get the five PQC contract clauses into procurement’s standard templates for new contracts. This is a one-time effort with permanent returns.

Build the vendor readiness KRI. Integrate Tier 1 and Tier 2 vendor readiness data into the board-level KRI cascade.

Plan the contract amendment pipeline. Prioritize Tier 1 contract amendments by expiry date and renewal opportunity. Amending at renewal is cheaper and faster than reopening mid-term. Build a 12-18 month pipeline that matches contract renewal cycles to PQC amendment readiness.

The vendor dimension of PQC migration is large, slow, and mostly outside your direct control. The governance response is to build relationships first, create visibility, create leverage (contractual requirements, commercial conversations, substitution options), and integrate the data into the program governance framework so that vendor risk is visible to the steering committee and the board alongside every other dimension of the migration.

The PQC Migration Framework covers vendor assessment within its 8-phase lifecycle. For the complete readiness strategy, Quantum Ready covers vendor governance as part of the full picture from board mandate through operational crypto-agility.