Your organization can plan its own move to post-quantum cryptography (PQC). Much of the cryptography it depends on, though, sits inside products it buys: cloud platforms, enterprise applications, VPNs, hardware security modules, network infrastructure. That cryptography changes on the supplier's release schedule rather than yours.
For UAE government entities, planning this move is now a requirement. Under the National Encryption Policy announced in November 2025, government entities must develop officially approved plans for the transition from traditional encryption to post-quantum cryptography, with the UAE Cybersecurity Council overseeing the national migration. A transition plan is only as credible as the supplier dates inside it.
This makes supplier PQC readiness a dependency in your migration plan rather than a procurement detail. Where a supplier cannot deliver a capability on the schedule you need, it could delay your own migration, and you will find out late unless you ask early.
To make that easier, we have published two free resources: a PQC vendor readiness questionnaire you send to a supplier, and a companion assessment guide for the team reading the answers. Both are linked at the end of this post. What follows is the reasoning behind the questions, which is worth understanding before you send them.
What “we support post-quantum cryptography” means: five claims
A vendor can make that statement and mean any of five things. Each can be accurate on its own terms. Only the last means the protection is running in your environment.
1. The algorithm is standardized. Proves a relevant standard exists, such as NIST’s FIPS 203 for ML-KEM. It says nothing about any particular product.
2. The product implements it. Check the product version, the parameter set, and which cryptographic functions the implementation covers.
3. The implementation is validated. Check the certificate number (for example, a FIPS 140-3 module certificate), the module version it names, and what the scope of that validation covers.
4. The capability is commercially available. Customers can deploy a supported version, as opposed to a preview, a beta, or a demonstration build.
5. The capability is enabled in your environment. Configured and tested in your deployment. Only this claim means the protection is running.
These are not five stages in a sequence. A product can be commercially available before a module validation completes, and validation is neither available nor required for every implementation. Treat them as separate claims, each with its own evidence, and record which ones a response actually makes. A response that supports the second claim, read as though it supported the fifth, puts a product into your inventory as protected while the capability is not yet running anywhere.
What to check behind a vendor's PQC claim
Four specifics turn a general statement into something you can verify.
The parameter set, not the algorithm family. ML-KEM-768 and ML-KEM-1024 are different security levels. Two products that both support “ML-KEM” will not interoperate unless they agree on the same parameter set. A response that names the algorithm family without the parameter set has not told you whether the product will work with the rest of your estate.
Which function the algorithm serves. Key establishment and signatures are separate problems solved by separate algorithms, and they carry different deadlines. Key establishment protects data in transit, and traffic recorded today could be decrypted later by a sufficiently capable quantum computer (“harvest now, decrypt later”), so the deadline is set by how long that data has to stay confidential. Signatures are judged by how long they must resist forgery, which is brief for a session signature and years for a firmware signing key or a long-lived certificate. A product that has moved its key exchange may still sign firmware or authenticate internal traffic the old way, so a single answer about “signature support” is rarely enough.
What a validation certificate covers. A validated cryptographic module is validated at a defined version and boundary. The certificate does not extend automatically to every product that embeds the module, every deployment mode, or every function the product performs. Ask which module version the certificate names, and what its scope covers.
Whether the change can be repeated (crypto-agility). Standards, parameter choices, and requirements will keep moving after this migration. A product that can accommodate only one scheduled algorithm change will need the same project again. Ask how algorithms are selected and changed, and whether there is a documented rollback path.
These questions concern public key cryptography, where the quantum risk sits. Symmetric algorithms and hash functions are affected far less, and are addressed through key and output lengths. The guide goes further into each of these.
The customer side of a post-quantum migration
A supplier changes the product. You change certificates, client software, configuration, and test plans. The customer side of a migration is routinely underestimated, and it can affect the timeline.
Two situations are worth asking about directly.
The client estate. A gateway, server, or managed service may support a post-quantum mode while the clients deployed against it do not. The capability genuinely exists, and the rollout stays blocked until those clients are upgraded or replaced. Ask for the supported versions on both ends, not just the newest one.
Components that cannot be upgraded in place. Hardware roots of trust, signed firmware, and embedded devices with long service lives may not be upgradable through a software release. Where that applies, the useful question is not whether the supplier is aware of it, but what it commits to for affected customers: replacement, a migration path, or compensating controls, each with a timeline.
Not every supplier needs all twenty questions
Set the depth of each assessment from your own environment rather than from anything the supplier says: how sensitive the data is, how long it has to stay confidential, how critical the service is, and how hard the supplier would be to replace. Where the supplier manages the keys and the protocol configuration, go deeper.
Assess the product rather than the company. A supplier may be well advanced in one product and have done nothing in another, so name the product, the version, and the deployment you are asking about. If you already run a supplier or third-party risk management program, add these questions to it rather than starting a separate exercise.
Free PQC vendor questionnaire and assessment guide
Send the questionnaire to your vendor. Use the guide to assess what comes back. Both are free to use and adapt with attribution.
Download the PQC vendor readiness questionnaire (fillable PDF, 15 pages)
Twenty questions across cryptographic visibility, risk and governance, standards and technical capability, migration plan and customer impact, and cost and support. Most questions take a status, the evidence behind it, and the specifics: product versions, parameter sets, configurations, limitations, and dates. Others ask for a written response. An appendix adds questions by supplier type, covering cloud services, networks, PKI and hardware security modules, software, operational technology, and managed service providers.
Download the vendor post-quantum readiness assessment guide (PDF, 15 pages)
The guide sets out which suppliers to assess first, what a useful answer to each question contains, and what should send you back to the vendor. It includes a worked example of a mixed response, which is how most real answers arrive, a way to turn twenty individual judgments into one outcome you can compare across suppliers, and a record sheet for capturing the outcome, the evidence still owed, and who is chasing it.
Common questions about PQC vendor readiness
What does it mean when a vendor says it supports post-quantum cryptography?
It can mean any of five things: that a standard exists, that the product implements it, that the implementation has been validated, that the capability is commercially available, or that it is enabled in your environment. Only the last means the protection is actually running. Ask which claim is being made.
What should I ask a vendor about post-quantum readiness?
Ask for the exact parameter set rather than the algorithm family, which cryptographic function each algorithm serves, what a validation certificate covers, and whether the product can accommodate a second algorithm change later. Ask about one named product and version, not the company.
Does a validation certificate mean a product is post-quantum ready?
No. A validated cryptographic module is validated at a defined version and boundary. The certificate does not automatically extend to every product that embeds the module, every deployment mode, or every function the product performs. Ask which module version it names and what its scope covers.
How many of my suppliers should I assess?
Set the depth from your own environment: how sensitive the data is, how long it must stay confidential, how critical the service is, and how hard the supplier would be to replace. Most organizations send the full set to a small number of suppliers and a short subset to the rest.
How long should I give a vendor to respond?
Allow enough time for the supplier to coordinate across product, engineering and legal. Several weeks is realistic for a full response. Shorten it where you are working to a submission deadline, and send to your most critical suppliers first rather than waiting for discovery to finish.
Does the UAE National Encryption Policy apply to my suppliers?
The National Encryption Policy, as announced, sets requirements for UAE government entities, which must develop officially approved transition plans to post-quantum cryptography. An entity’s plan depends on when its suppliers can deliver, so supplier PQC readiness is part of that plan. Check the official policy text and any procurement guidance for requirements that apply to suppliers directly.
Where vendor assessment fits in your PQC migration plan
A questionnaire tells you what a supplier knows about its own cryptography and its own plans. It cannot tell you what is running across your estate. Supplier assessment belongs alongside cryptographic discovery and inventory, risk assessment, and migration planning rather than in place of them.
Start with the suppliers behind your most sensitive data and most critical services. Ask for evidence rather than assurances, record the gaps with an owner against each one, and move supplier dates into your own migration plan wherever they sit on your critical path. For UAE government entities, that is the transition plan the National Encryption Policy requires.