Talking to customers about post quantum readiness without overpromising

[QuantumLeap]

TL;DR

• Customers are asking about post quantum readiness more often, driven by EO 14412, the EU roadmap, NCSC guidance and supplier questionnaires
• The best answers are specific, honest and dated: name the standards, state what is done, what is in progress and what is planned
• Avoid absolute claims such as quantum proof or unbreakable, and never imply that a product is finished if only key exchange has moved
• Separate key establishment from signatures, because most organisations will migrate them on different timelines
• Publish a short readiness statement, keep it updated, and give sales and support teams a consistent script

Why this conversation is happening now

For years, post quantum questions from customers were rare and usually came from specialist government buyers. That has changed quickly. Supplier security questionnaires now often include a section on quantum readiness, and procurement teams increasingly ask vendors to describe their migration plans. In the US, Executive Order 14412 requires federal contractors to meet post quantum FIPS requirements by the end of 2030, and that requirement is already rippling through supply chains

In Europe, the coordinated roadmap asks for high risk use cases to be protected by the end of 2030, and national regulators are beginning to ask how organisations will get there. In the UK, NCSC guidance encourages organisations to communicate their requirements to suppliers by 2028. Each of those documents ultimately turns into a question that lands in a sales inbox or a support ticket. Organisations that prepare a clear answer now will look credible and organised

This thread is about how to answer well. It is written for product managers, security teams, sales engineers, support staff and communications people who need to talk about post quantum readiness without misleading anyone. The core idea is simple. Honest, specific and modest answers build far more trust than impressive sounding promises

What customers really want to know

Behind most questions sit three concerns. First, customers want to know whether their data is exposed to harvest now, decrypt later attacks through your product today. Second, they want to know whether your product will meet the deadlines they face from regulators and their own customers. Third, they want confidence that you understand the topic and have a plan, rather than hoping the problem disappears

A good answer addresses all three. It explains current protections, the roadmap with dates, and the standards you follow. It also signals how customers will receive upgrades and what, if anything, they need to do themselves. Answers that skip one of these concerns usually trigger follow up questions

It also helps to know who is asking. A procurement officer filling in a questionnaire needs short, verifiable statements, while a customer's security architect may want technical detail about algorithms and protocols. Executives usually want reassurance about risk and deadlines. Tailoring the same core facts to each audience avoids both oversimplifying and overwhelming

Lead with standards, not slogans

The strongest single move is naming the standards. Say that your product supports ML-KEM as defined in NIST FIPS 203 for key establishment, or that ML-DSA from FIPS 204 is planned for signatures in a given release. Mention which parameter sets you support, such as ML-KEM-768 or ML-KEM-1024. Specific names show competence and allow the customer's experts to verify your claims

Explain whether you use hybrid modes. Many products now offer hybrid key exchange such as X25519MLKEM768, which combines a classical and a post quantum algorithm. Some European customers expect hybrid deployment, while some US federal customers following CNSA 2.0 may ask for ML-KEM-1024 on its own. Saying clearly which modes you support saves a lot of back and forth

If you rely on third party libraries or cloud services for cryptography, say so. Many products inherit post quantum support from OpenSSL 3.5 or later, operating system TLS stacks, cloud load balancers or managed key services. That is perfectly reasonable, and customers appreciate knowing where the protection comes from. It also helps them understand which updates matter

Separate what is done, in progress and planned

Readiness is rarely all or nothing. Most products move in stages, with key exchange first and signatures, certificates and stored data protection later. A clear statement divides capabilities into three groups: available now, in progress with a target date, and planned with a rough timeframe. That structure is honest, easy to read and easy to update

Be especially careful with signatures. The web PKI is still settling how post quantum certificates will work, with Chrome favouring Merkle Tree Certificates and Let's Encrypt targeting production readiness in 2027. If your product uses public certificates, your signature timeline may depend on that ecosystem. Saying so openly is far better than promising a date you do not control

Distinguish between data in transit and data at rest. A product may protect network sessions with hybrid key exchange while still wrapping stored keys with RSA. Customers worried about long lived data will ask about both. A short sentence on each removes ambiguity

Remember that customers may share your answers. A readiness statement often ends up in a customer's own audit file or board paper. Write as if a regulator might read it, because sometimes one will. That mindset naturally encourages accuracy

Words and phrases to avoid

Avoid absolute claims. Phrases such as quantum proof, quantum safe forever, unbreakable or fully protected against all quantum attacks cannot be justified. Cryptographers do not make such promises about any algorithm, and NIST selected backup algorithms precisely in case a weakness appears. Absolute language also creates legal and reputational risk if circumstances change

Avoid implying completion when only part of the work is done. Saying a product is quantum safe when only its TLS key exchange has moved invites misunderstanding. Customers may assume signatures, certificates and stored data are covered too. Precise wording protects both parties

Be cautious with vague words such as quantum ready. On their own they say very little. If you use them, define them immediately, for example by stating that quantum ready means the product supports ML-KEM hybrid key exchange today and has a documented plan for ML-DSA signatures. A defined term becomes useful rather than decorative

Do not exaggerate the threat to sell urgency. Claims that Q-Day is imminent or that RSA has already been broken are not supported by public evidence. Experienced buyers will notice and trust you less. A calm, factual tone is far more persuasive

A simple readiness statement template

• Our approach: we follow NIST FIPS 203, 204 and 205 and align our roadmap to NCSC, EU and US federal timelines
• Available now: hybrid key exchange (X25519MLKEM768) for all TLS connections to our service
• In progress: ML-DSA support for code signing, target release in a stated quarter
• Planned: post quantum certificates once ecosystem standards settle, expected 2027 to 2028
• Customer action: none required for TLS; update clients to version X or later for full support
• Last reviewed: a stated date, with a link to our changelog

A statement like this fits on one web page and answers most questions before they are asked. It can be linked from security documentation, trust centres and questionnaires. Updating it quarterly keeps it accurate as products evolve. Including a review date tells readers how fresh the information is

Equip your sales and support teams

Inconsistent answers do more damage than imperfect ones. If one salesperson promises full quantum safety and another says nothing is planned, customers lose confidence quickly. Give customer facing teams a short script based on the readiness statement, plus a route to escalate detailed questions to security experts. A brief internal training session goes a long way

Prepare answers to the most common follow up questions. Customers often ask whether harvest now, decrypt later affects them, whether you support customer managed keys with post quantum algorithms, how you handle hybrid versus pure modes, and whether your implementation has been validated under FIPS 140-3. Having agreed answers ready keeps conversations smooth. It also stops engineers being pulled into every sales call

Encourage teams to say I do not know, I will find out, when they are unsure. That answer is perfectly acceptable in a technical field that is still evolving. Guessing is what causes trouble. Customers remember who gave them reliable information

Track the questions you receive. A simple log of customer post quantum questions reveals which topics worry the market most. Product teams can use that insight to prioritise roadmap items, and communications teams can update the readiness statement to answer common questions directly. Over time, the log becomes a valuable source of market intelligence

Handling difficult questions

Sometimes customers ask for commitments you cannot give, such as a guarantee that a product will never be vulnerable to quantum attacks. The honest answer explains that no responsible vendor can guarantee that, then describes your crypto agility. If a weakness were found in an algorithm, how quickly could you switch? A credible answer to that question reassures more than any guarantee

Customers may also ask about dates that depend on others, such as when post quantum certificates will be issued by public certificate authorities. Explain the dependency and share the public timelines you are tracking. Offer to notify them when the situation changes. That turns a potentially awkward conversation into a demonstration of partnership

Closing thoughts

Talking about post quantum readiness is becoming part of normal business, much like discussing data protection or uptime. Organisations that communicate clearly will stand out in a market full of vague marketing. The approach is not complicated. Name the standards, show your stages, give dates where you can, and never claim more than you have done

If you have drafted a readiness statement or faced tricky customer questions, please share your experience below. Real examples would help many members here. Together we can make honest communication the norm


Key references for citation

• NIST FIPS 203, 204 and 205, August 2024
• Executive Order 14412, June 2026
• UK NCSC, Timelines for migration to post-quantum cryptography, March 2025
• Let's Encrypt, post-quantum certificates announcement, 3 June 2026

Not a valid attachment ID.