Questions to ask vendors about post-quantum readiness

Begin with your service, not the supplier’s headline

Preparation depends in part on understanding technology suppliers and their migration plans. The joint CISA, NSA, and NIST readiness resource makes vendor engagement a core activity. [1] Our suggested questionnaire begins with a precise identifier: the service, product edition, version, hosting model, and business activity you use.

Ask the supplier to distinguish capabilities available now from announced work and ideas under evaluation. A concise written answer is easier to revisit than an informal sales call. Invite the provider to say that a detail is unknown or outside the scope of the response; those limits are necessary inputs to your planning.

Ask what the claim actually covers

Encryption, key establishment, and digital signatures serve different purposes. NIST’s first three finalized PQC standards include ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures. [2] Use these distinctions to ask whether a product statement concerns confidentiality, authentication, software signing, or another function.

• Which exact feature uses post-quantum cryptography, and is it enabled for our account?
• Which algorithm, standard, and implementation version are used?
• Does protection apply throughout the relevant connection, or only one part of the path?
• Which integrations or older clients continue to depend on traditional public-key mechanisms?

Ask how the provider demonstrates the result

Request the evidence appropriate to the claim. That might include product documentation, a configuration guide, a test report, or a relevant validation reference. If the response mentions validation or certification, ask for its exact scope and identifier. NIST maintains separate programs for algorithm testing and cryptographic module validation; broad marketing wording can hide that distinction. [3][4]

Our suggested follow-up is simple: what would your engineer inspect to confirm that our actual system is using the intended protection? Ask whether a connection can negotiate a different option and how that would be detected. The answer should describe a verifiable result rather than only a purchase or installation milestone.

Clarify the work you must do

A supplier may provide a feature while the customer remains responsible for configuration, compatible clients, or an application change. Ask the provider to identify each customer action, required maintenance window, possible service disruption, and support arrangement. Have your own technical team review the response before committing to a deployment.

• Will our current subscription and hardware support the change?
• Which connected systems must be updated first?
• What are the test and rollback procedures?
• What happens to support for the old configuration?
• Who tells us when a roadmap date, standard, or recommended setting changes?

Use answers to make decisions

Build a small comparison register for your important providers. Record the scope, evidence date, customer actions, open dependencies, and next decision. A provider with a candid plan and well-defined limitations may offer more useful information than one with a sweeping assurance and no detail.

Do not convert the questionnaire into a public security rating without a defensible method. Its immediate purpose is to decide what your organization needs to investigate, test, budget, or renegotiate. Review material statements before including them in insurance applications or customer assurances. An answer about one service should never silently become a claim about your whole business.