Stop Buying Cryptographic Debt for PQC
A proposed post-quantum semiconductor and cybersecurity centre in Switzerland offers a useful warning for every organisation purchasing technology today.
Post-quantum cryptography is no longer only an algorithm-selection exercise. It is becoming a question of procurement, product lifecycles, hardware dependency, supplier assurance and digital sovereignty.
The central issue is simple:
Can the systems being purchased today remain secure when their current cryptography is no longer acceptable?
PQC has moved beyond software
Switzerland’s Canton of Jura, WISeKey and SEALSQ have announced an MoU for a proposed post-quantum semiconductor and cybersecurity centre. The initiative is expected to involve CHF 40 million to CHF 60 million in investment and could create more than 250 direct jobs.[es.marketscreener][barchart]
The announcement reflects a wider development in the market. Post-quantum capability is moving into semiconductors, hardware security, secure provisioning and supply-chain strategy.
That matters because many enterprise systems cannot be upgraded as easily as a software library.
Cryptography may be embedded in:
Hardware security modules.
Smart cards and secure elements.
Network appliances.
Industrial control systems.
Vehicle platforms.
Identity systems.
Firmware update mechanisms.
Cloud services.
Application programming interfaces.
Third-party products and managed services.
A system may support a post-quantum algorithm in a laboratory demonstration and still present serious migration problems in production.
Algorithm support is not migration readiness
NIST has finalised three principal post-quantum cryptography standards:
These standards provide important building blocks for the transition. They do not, by themselves, make an organisation quantum resilient.
A supplier may state that its product supports ML-KEM or ML-DSA. That claim still leaves important questions unanswered.
Can the product be upgraded?
A credible migration path should explain how cryptographic components can be replaced without redesigning the entire product.
This includes firmware, libraries, protocols, certificates, key stores and hardware-dependent functions.
Can certificates be managed at scale?
PQC migration may affect certificate sizes, signing algorithms, trust chains, issuance processes and lifecycle operations.
An organisation needs to know whether its identity infrastructure can support new algorithms across users, devices, services and external partners.
Can the supplier support the full product lifecycle?
A system purchased today may remain in operation for many years.
Procurement teams should understand whether the vendor has committed to future upgrades, validated implementation paths and continued support for cryptographic changes.
Can the organisation identify hidden dependencies?
Cryptography is frequently inherited through software libraries, cloud platforms, operating systems, embedded components and supplier products.
Without a reliable cryptographic inventory, an organisation may not know where vulnerable algorithms are being used.
Quantum risk begins with data lifetime
The transition cannot be based only on the date when a cryptographically relevant quantum computer becomes available.
Sensitive information encrypted today may be captured, retained and targeted for future decryption. The risk is higher when data must remain confidential for many years.
This creates a direct connection between data classification and PQC prioritisation.
An organisation should ask:
How long must this data remain confidential?
Which systems protect it?
Which public-key algorithms are in use?
Can the systems be upgraded?
Which suppliers control the relevant components?
What happens if migration requires hardware replacement?
Are long-lived archives protected by vulnerable encryption?
The longer the confidentiality requirement and the longer the system lifecycle, the less credible it is to treat PQC as a distant technical project.
Procurement creates future risk
CISA, NSA and NIST have recommended that organisations establish a quantum-readiness roadmap, create a cryptographic inventory and assess their reliance on suppliers using quantum-vulnerable cryptography.[cisa][cisa]
That guidance has a practical implication for procurement.
Contracts should not simply ask whether a product is “PQC-ready”. They should require evidence.
Questions for technology suppliers
Which cryptographic algorithms are used in the product?
Where are those algorithms implemented?
Does the product support ML-KEM, ML-DSA or SLH-DSA?
Is hybrid cryptography supported during transition?
Can algorithms be replaced without a full hardware redesign?
Can firmware and cryptographic libraries be updated securely?
How will certificates and trust chains be migrated?
What cryptographic inventory information can the supplier provide?
Which third-party dependencies remain outside the supplier’s control?
What are the vendor’s post-quantum support and end-of-life commitments?
A supplier that cannot answer these questions may be transferring migration risk to the customer.
Crypto-agility is the strategic requirement
The objective is not to predict the exact date of Q-Day.
The objective is to ensure that systems can adapt when algorithms, standards, threat assessments or regulatory requirements change.
ENISA defines cryptographic agility as the ability to switch between cryptographic algorithms and protocols without significant changes to the underlying infrastructure.[enisa.europa]
That capability should be treated as an architectural and governance requirement.
A crypto-agile system separates cryptographic functions from business logic, avoids hard-coded algorithms, supports controlled updates and provides visibility into dependencies.
In practical terms, crypto-agility can reduce the cost of responding to:
Newly discovered vulnerabilities.
Changes in approved standards.
Supplier failures.
Certificate migration requirements.
New regulatory obligations.
Future cryptographic advances.
The question for boards and CISOs
The post-quantum question is no longer only:
Which algorithm will we deploy?
It is also:
Which systems should we refuse to buy today?
A product with no credible migration path may appear acceptable during procurement and become a long-term security liability later.
That is cryptographic debt.
The organisation pays for it through emergency upgrades, hardware replacement, supplier dependence, operational disruption and delayed risk reduction.
The stronger procurement question is:
Show us how this product will remain secure when its current cryptography is no longer acceptable.
If the answer is vague, the risk should be reflected in the architecture decision, the contract and the business case.
Conclusion
PQC migration is entering the hardware and supply-chain conversation.
The organisations that prepare well will not simply select new algorithms. They will build visibility into their cryptographic dependencies, demand evidence from suppliers and prioritise systems according to data sensitivity and operational lifespan.
Post-quantum resilience begins with the decisions made before a product enters the environment.
Stop buying cryptographic debt.
Comments