Table of Contents
In the recent IBM’s “Secure the Post-Quantum Future” report 62% of executives admitted that their organization is waiting for vendors to make them quantum‑safe. In other words, they expect cloud providers, network equipment makers and software vendors to embed post‑quantum cryptography (PQC) so that internal teams can simply apply updates.
This mindset is understandable, but it is also dangerous. Waiting for vendors delays critical preparations, increases operational risk and ignores the reality that boards and CISOs are accountable for protecting their data and systems. Vendors play a crucial role, yet quantum readiness is not something that can be outsourced.
Why “the vendor will fix it” is a misconception
Many executives see quantum readiness as a vendor problem because much of the organization’s cryptography lives in third‑party products. I always heard similar comments, but the IBM survey exposed how many organizations plan to rely on vendors to “bake in” quantum‑safe cryptography, hoping to apply a patch when new algorithms become available.
Beyond potential (and likely) vendor delays, the scope of work is much broader than a single patch.
I previously noted that the quantum era demands changes across all enterprise systems – servers, applications, databases, networks, IoT devices, OT infrastructure and cloud services. Very few legacy systems have no cryptographic dependencies; almost everything uses encryption, digital signatures or secure protocols and must be identified and updated. To make matters worse, each of these devices, systems, apps have multiple layers of cryptography.
Keep in mind as well that post‑quantum algorithms are not drop‑in replacements for today’s cryptography; they have larger key sizes, different performance characteristics and incompatibilities that require major software and hardware changes.
Treating the problem as a simple vendor patch not only understates the complexity but also exposes the organization to various risks, from not being ready on time, to “harvest now, decrypt later” and “sign today, forge tomorrow (or trust now, forge later)” risks.
Boards and CISOs are accountable
Regulators increasingly view cyber‑risk, including quantum‑threat mitigation, as a board‑level responsibility. Many jurisdictions now even attach personal liability to board members if they fail to exercise oversight on cyber risk. The quantum threat must therefore be treated as a business and governance issue, not merely a technical problem. Boards should ask management questions such as: What is our exposure to quantum‑enabled decryption? How long must our data remain confidential? What is the plan for engaging suppliers?. Failing to answer these questions invites regulatory scrutiny and shareholder criticism.
The CISO plays a central role in orchestrating the quantum‑readiness program. Detailed migration plans demonstrate that achieving full quantum readiness is a decade‑long journey: cryptography is embedded in every device and system across IT, OT and networks. There is no “one‑click fix,” so the CISO’s office must establish program governance, assign clear responsibilities and coordinate teams across network security, application development, procurement and vendor management.
The Bank for International Settlements (BIS) similarly calls for strong governance structures and an executive sponsor to oversee the transition, emphasising that the migration must begin now because a cryptographic inventory is the critical foundation.
Complexity demands an enterprise‑wide inventory
Becoming quantum‑safe starts with discovering where cryptography is used. I previously compared the effort to fixing Y2K, except that this time every device, application and embedded sensor must be evaluated. Automated tools help identify digital certificates and cryptographic libraries, but manual code reviews and documentation are essential because many cryptographic calls are hidden in applications or third‑party modules. Modern devices often implement layered cryptography; a single IoT sensor might use symmetric encryption for local storage, TLS for network communication and digital signatures for firmware updates. Each layer must be examined, and not all algorithms have PQC equivalents today, which means some devices will need to be replaced or retrofitted.
To understand cryptographic complexity, see some of the use cases I described in more detail: Cryptography in a Modern 5G Call: A Step-by-Step Breakdown or Cryptographic Stack in Modern Interbank Payment Systems.
The National Institute of Standards and Technology (NIST) echoes this approach in its cryptographic discovery guidance. NIST’s methodology asks organizations to catalogue both internally developed cryptographic components and those provided by third‑party vendors, incorporating the risk of continuing to use third‑party software into the organization’s risk calculation. In a sample scenario, a CISO directs the migration team to automate discovery of vulnerable cryptography in third‑party services, network traffic and DevOps code so that a risk‑based prioritization can be developed.
These examples underscore that vendor cryptography is part of the inventory, not an excuse to abdicate responsibility.
Key inventory steps
- Create a cryptographic asset inventory: Identify every certificate, protocol and algorithm in use across applications, databases, networks, endpoints, IoT/OT devices and cloud services. Tag assets as internal or vendor‑supplied to differentiate remediation strategies.
- Assess risk and prioritize: Determine which assets protect long‑lived or sensitive data that must remain confidential for years. Use risk assessments to prioritize PQC migration efforts.
- Plan for hybrid and crypto‑agile solutions: Recognize that PQC standards are still evolving; hybrid solutions combining classical and post‑quantum algorithms and architectures that allow algorithms to be swapped (crypto‑agility) are recommended.
- Establish governance: Appoint an executive sponsor (often the CISO) and form a cross‑departmental taskforce to oversee the program. Develop policies for vendor management and cryptographic updates.
Engaging vendors without outsourcing responsibility
Vendor relationships matter because many products and cloud services embed cryptography that your organisation doesn’t control directly. Quantum readiness extends to third‑party vendors and suppliers; if a vendor is unprepared, the organization inherits that vulnerability. Regulators such as the U.S. National Security Agency and NIST are urging organisations and their suppliers to plan PQC migration now. However, engaging vendors does not mean outsourcing accountability.
Engage vendors early for four reasons: to gauge their awareness, influence their product roadmaps, avoid compatibility surprises and demonstrate proactive risk management. Organisations should ask vendors for PQC transition plans, request timelines for supporting NIST‑endorsed algorithms and evaluate whether vendor certificates and APIs support hybrid modes. A tailored PQC readiness questionnaire can help differentiate high‑risk suppliers (e.g., those handling sensitive data or critical infrastructure) from lower‑risk partners. Contracts and RFPs should incorporate clauses requiring cryptographic agility, compliance with emerging standards and disclosure of PQC roadmaps.
It may be necessary to replace vendors who cannot commit to quantum‑safe upgrades. External dependencies should be tracked as part of the risk register and factored into overall migration timelines.
Building the business case for quantum readiness
Waiting for vendors to solve quantum readiness is not only risky but also short‑sighted from a business perspective. Regulatory pressure is increasing. Emerging regulations are turning quantum compliance into a board‑level priority. Boards tend to fund initiatives driven by compliance requirements, so CISOs can leverage this momentum to secure resources for cryptographic discovery and PQC migration.
A quantum‑readiness program also improves asset visibility: many security leaders have experienced incidents because of unknown assets, and establishing a PQC inventory often uncovers other security gaps. Viewing quantum readiness as a risk‑management and asset‑management initiative thus delivers immediate benefits.
Beyond compliance, quantum readiness can be a trust signal. Boards and executives increasingly expect cybersecurity reports at every meeting. Presenting a clear plan to address the quantum threat demonstrates strategic foresight and reduces reliance on last‑minute vendor fixes. A proactive approach helps negotiate better vendor terms, fosters crypto‑agility and positions the organization as a responsible steward of customer data. Conversely, ignoring the problem invites reputational damage when quantum‑capable adversaries eventually exploit unprepared systems.
Conclusion: a shared journey, not a vendor fix
Quantum‑safe cryptography will redefine the way organisations protect data. While vendors play a crucial role in updating products and services, ultimate accountability remains with the enterprise’s leadership.
The complexity of PQC migration – spanning discovery, risk assessment, code changes, hardware upgrades and vendor engagement – demands a long‑term, well‑governed program. Boards and CISOs must create cryptographic inventories, require crypto‑agility, update procurement and contracts, and monitor vendor roadmaps.
By starting now and treating quantum readiness as a strategic initiative rather than a vendor problem, organisations can turn a looming challenge into an opportunity to strengthen security, demonstrate leadership and protect data.
