Post-quantum cryptography (PQC) is moving from research and standardization into implementation. For organizations beginning to assess their post-quantum readiness, that creates a new question: how do you choose the right technology and the best provider to support the transition?
The timelines are becoming clearer. In August 2024, the US National Institute of Standards and Technology (NIST) published its first three finalized post-quantum cryptography standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). NIST now advises organizations to begin applying these standards as they migrate towards quantum-resistant cryptography.
In the UK, the National Cyber Security Centre (NCSC) has set out an indicative migration timeline. It recommends organizations complete cryptographic discovery and initial migration planning by 2028, undertake their highest-priority migrations by 2031, and complete migration across systems, services, and products by 2035. For large organizations, the NCSC estimates that discovery, assessment, strategy, and initial migration planning alone could take two to three years.
This means that choosing a PQC provider is much more than checking whether it supports the latest algorithms. Organizations need technology that can be implemented securely, integrated into existing environments, and adapted as standards and requirements continue to evolve.
Here are 10 questions to ask while evaluating a post-quantum cryptography provider.
1. Does the provider support standardized post-quantum algorithms?
A sensible starting point is standards.
NIST’s first three PQC standards cover ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. The standards are designed to protect information against attacks involving future large-scale quantum computers.
NIST selected HQC for future standardization in March 2025, and work on additional digital signature schemes also continues.
A prospective provider should therefore be able to explain which standards it supports, where those algorithms are appropriate, and how its products will be updated as the standards landscape develops.
Simply advertising “quantum-safe encryption” is not enough. Ask which exact algorithms and standards are implemented, whether those implementations have been independently tested or validated where appropriate, and how the provider keeps them aligned with changing guidance.
Standards compliance should be the foundation, rather than the end of the conversation.
2. How involved is the provider in the development of PQC standards?
PQC is a specialized and fast-developing field. That makes the expertise behind a product particularly important.
Look at whether the provider is actively involved in cryptographic research, standardization or implementation work. Does its team contribute to standards bodies and technical discussions? Can it demonstrate expertise in both the underlying mathematics and the practical problems involved in implementing cryptography?
This matters because organizations are not adopting a static technology. The PQC ecosystem will continue to develop as algorithms are studied, standards are refined, and implementations are tested in increasingly diverse environments.
A provider with close involvement in this work is better placed to understand why standards have been designed in a particular way, identify implementation challenges, and respond as guidance evolves.
The important question is not simply, “Do you offer PQC?” It is also, “What expertise sits behind your implementation?”
3. Can the technology work with your existing systems?
Few organizations can replace their entire cryptographic infrastructure overnight.
PQC needs to coexist with established applications, protocols, operating systems, hardware, and security architectures. That makes integration one of the most important factors in provider selection.
Ask how a solution fits into your current environment. Does it provide suitable APIs, libraries, or SDKs? Can it integrate with widely-used cryptographic frameworks? What changes will developers need to make? And can the technology operate across the platforms you expect to maintain throughout the migration?
For example, PQShield’s PQCryptoLib-SDK provides an OpenSSL 3.x provider intended to allow organizations to experiment with and integrate PQC within OpenSSL-based applications. It supports post-quantum algorithms as well as hybrid schemes for TLS.
The specifics will vary between organizations. What matters is establishing the practical integration path before making a technology decision.
4. Does the provider support hybrid cryptography?
Migration from traditional public-key cryptography to PQC will not necessarily happen in a single step.
Hybrid approaches combine post-quantum and traditional cryptographic mechanisms. Depending on the environment and applicable guidance, they can provide a way to introduce PQC while existing cryptography remains part of the system.
That can be useful during a period in which organizations, suppliers, and protocols are migrating at different speeds. However, hybrid approaches also add complexity, so they need to be implemented carefully, and used where appropriate.
Ask prospective providers about which hybrid approaches they support, which standards or protocols those approaches follow, and how the provider expects customers to transition from hybrid deployments towards their intended long-term architecture.
This is also an area where regional requirements matter. PQShield’s review of international cryptographic guidance shows that approaches to hybrid PQC vary between jurisdictions, reinforcing the need to consider the requirements that apply to a particular deployment rather than assuming there is one universal migration model.
5. How crypto-agile is the solution?
PQC migration is an opportunity to address a wider problem: how difficult it can be to change cryptography once it has been embedded into products and infrastructure.
Crypto-agility is the ability to replace or update cryptographic algorithms and implementations without having to redesign an entire system.
That matters because the transition to PQC will continue for years. NIST’s work has not stopped with its first three standards. Further algorithms are being evaluated and standardized, and different use cases may ultimately require different cryptographic choices.
When evaluating a provider, ask how easily algorithms can be changed. Is the architecture tightly tied to one implementation, or can cryptographic components be updated? How are updates distributed? What happens if standards or regulatory requirements change?
For hardware with a long operational life, this question becomes particularly important. A device designed today may still be operating well into the 2030s. The ability to adapt its cryptography can therefore be as important as the choice of algorithms initially installed.
6. How does the solution perform in real-world environments?
A cryptographic algorithm can be secure on paper but unsuitable for a particular system.
PQC algorithms have different requirements from the classical public-key cryptography organizations use today. Depending on the algorithm and implementation, considerations could include larger keys and signatures, memory consumption, processing requirements, bandwidth, latency, and power.
Those constraints become especially significant in embedded systems, IoT devices, automotive systems, and other environments where computing resources may be limited.
There is no single performance number that demonstrates whether a PQC implementation is “fast enough.” Providers should instead be able to supply benchmarks relevant to your architecture and workload.
For example, PQShield’s embedded PQMicroLib-Core implementation is designed to run in environments with as little as 5 KB of RAM. Its hardware portfolio includes solutions designed for high-throughput applications. This illustrates how different the optimization problem can be between a constrained microcontroller and network infrastructure that processes large numbers of transactions.
Ask providers for evidence based on the environments you actually intend to protect.
7. What security protections exist beyond the algorithm itself?
Selecting a standardized algorithm does not automatically guarantee a secure implementation.
Real systems can be attacked through the way cryptography is implemented. Side-channel attacks, for example, attempt to learn secrets from characteristics such as execution timing, power consumption or electromagnetic emissions rather than breaking the underlying mathematical problem.
This is particularly relevant to devices where an attacker may have physical access.
The protections you need depend on your threat model, but providers should be able to explain how they approach implementation security. Questions might cover constant-time implementations, side-channel countermeasures, fault-injection resistance, secure random number generation, code safety and testing.
The distinction is important: evaluating the mathematical strength of an algorithm and evaluating the security of its implementation are not the same task.
Where relevant, ask for evidence of testing, validation and independent assurance rather than relying solely on claims that an algorithm itself is standardized.
8. Can the provider cover your software and hardware requirements?
Cryptography exists throughout modern technology stacks.
An organization may need PQC in enterprise software and cloud services, while the devices connecting to those services need implementations suitable for microcontrollers or embedded systems. Semiconductor and infrastructure providers may need cryptographic hardware IP or dedicated acceleration.
A provider’s ability to work across those layers can therefore become important, particularly for organizations responsible for complex products or long supply chains.
Assess what your migration could ultimately encompass. Do you need software libraries? Embedded implementations? Hardware acceleration? Root-of-trust capabilities? Integration with existing security protocols?
PQShield, for example, develops both software and hardware PQC technology, ranging from libraries for general-purpose and embedded environments to cryptographic coprocessors and high-throughput hardware acceleration.
Even if you only need one of those capabilities today, understanding the wider roadmap can help avoid a fragmented approach later.
9. What does integration and migration support look like?
Good technology is only useful if your teams can deploy it successfully.
Before choosing a provider, look beyond the product specification and understand what implementation support is available.
Is the API documented clearly? Are evaluation versions, development tools, or example implementations available? Can the provider help your engineers benchmark the technology in your environment? What support is available during integration, testing, and deployment?
Also ask how the provider approaches interoperability. Your organization does not operate in isolation, so systems may need to communicate with customers, suppliers, partners, and infrastructure using technology from different vendors.
This connects directly to the NCSC’s migration guidance, which emphasizes understanding dependencies on suppliers and physical infrastructure as part of initial migration planning. It also recommends communicating PQC requirements to suppliers rather than treating migration as a purely internal project.
A provider should therefore be evaluated as part of your wider technology ecosystem, not simply as a source of cryptographic code.
10. Can the provider support your long-term post quantum readiness?
Finally, think beyond immediate implementation.
PQC migration is a multi-year change program. The NCSC’s 2035 target demonstrates the timescale involved, particularly for organizations with large estates, critical infrastructure, or products that remain deployed for many years.
The provider you select should be able to explain how its technology will remain maintainable throughout that transition. Suitable questions include:
- What is its roadmap for new standards?
- How will deployed implementations be updated?
- How does it approach crypto-agility?
- Can its technology scale from early proof-of-concept work to production deployments?
- Can it support systems whose operational life extends well beyond the initial migration?
These questions are ultimately about avoiding another difficult cryptographic migration in the future.
Post quantum readiness should not mean replacing one fixed set of algorithms with another and considering the job finished. It should mean building systems that are better prepared for cryptographic change.
From provider selection to post quantum readiness
The publication of NIST’s first PQC standards was a major milestone, but standards alone do not solve the migration challenge.
Organizations now need to work out where vulnerable cryptography exists, what needs to change first, and how new cryptography can be deployed securely without unnecessarily disrupting existing systems.
That makes the selection of a PQC provider an architectural and strategic decision as much as a cryptographic one.
Look for support for recognized standards, but go further. Examine the security of the implementation, integration options, real-world performance, crypto-agility, and the provider’s ability to support your technology over the long term.
Most importantly, start asking these questions early. The NCSC expects large organizations to spend two to three years on discovery, assessment, strategy, and initial planning alone, with 2028 set as its target for completing that first phase.
PQShield develops post-quantum cryptography for software, embedded systems and hardware, helping organizations take standardized PQC from planning and evaluation through to real-world implementation.
Ready to assess your post quantum readiness? Talk to PQShield about building a practical path to quantum-safe security.