Harvest Now, Decrypt Later: The Question Enterprise Buyers Started Asking in 2026

A question that did not appear in vendor security questionnaires two years ago now shows up regularly, usually in one of these forms:

• “Describe your post-quantum cryptography migration plan.”
• “Do your public endpoints support hybrid key agreement?”
• “What is your crypto-agility posture?”

Most vendors answer badly, in one of two ways. They either say “we use TLS 1.3 and AES-256”, which does not address the question, or they describe a multi-year roadmap with no deployed component, which reads as evasion.

What the buyer is actually worried about

The concern is specific and it is not science fiction. An adversary records encrypted traffic today and stores it. The session keys were agreed with elliptic-curve Diffie-Hellman. When a cryptographically relevant quantum computer exists, those recordings are decrypted retroactively.

This makes the risk a function of one variable the buyer already knows: how long their data stays sensitive.

A retailer’s session tokens are worthless in a week. A bank’s customer records, a hospital’s patient data, a law firm’s case files and an insurer’s underwriting positions are sensitive for decades. That is why the question arrives disproportionately from regulated buyers, and why it arrives attached to DORA and NIS2 assessments rather than to general procurement.

The buyer is not asking whether you have solved post-quantum cryptography. They are asking whether the data they are about to send you is being recorded today in a form that will be readable later.

The answer that works

There is a deployable component, and it takes one configuration line.

Enable the X25519MLKEM768 hybrid group on your TLS terminator. Browsers have negotiated it by default since Chrome, Firefox and Edge 131. Clients that do not support it fall back to classical key exchange with no compatibility break.

ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;

Once it is on, your answer stops being a roadmap and becomes an observation the buyer can verify themselves:

openssl s_client -connect yourdomain.com:443 -groups X25519MLKEM768

That shift matters more than it looks. A security team reading fifty vendor responses can check this one in ten seconds, without trusting you. Claims that are externally verifiable get a different weight than claims that are not, which is the same reason an external scan report carries weight a self-assessment does not.

Structuring the full response

A complete answer has four parts, and only the first needs to be finished today.

1. What is deployed. Hybrid key agreement on all public endpoints, with the group named and the date it was enabled.

2. What is not, and why. Authentication is still classical: your certificate is signed with RSA or ECDSA. Say so. The honest justification is that signature forgery has to happen during a live connection, so there is no harvest-now equivalent for authentication, and post-quantum certificate chains are not yet issuable by public CAs. A buyer’s cryptographer will accept this. They will not accept a claim that you are “fully post-quantum”.

3. Crypto-agility. How long would it take you to change algorithm? The concrete evidence here is certificate automation: teams running ACME with short-lifetime certificates can turn over their entire certificate population in weeks. Teams renewing by hand cannot, and that is the real measure of agility.

4. Inventory. Which endpoints terminate TLS, and who controls them. A CDN in front of your origin means the hybrid group has to be enabled in two places, and vendors routinely enable it on the edge while the origin connection stays classical.

The regional nuance

ETSI and the EUCC framework endorse hybrid deployment through at least 2028 and treat pure post-quantum deployments as premature. If a buyer asks why you are not using ML-KEM alone, that is the answer, and it is the recommended posture rather than a compromise.

If the buyer operates under FIPS constraints, note that ML-KEM is FIPS-approved but X25519 is not, so the strictly compliant hybrid is SecP256r1MLKEM768, which browsers do not offer by default. This is a genuine tension, not something you caused, and naming it demonstrates you understand the material.

What not to say

Avoid “quantum-safe” and “quantum-proof”. Both are marketing terms, neither is true of a hybrid deployment, and a technical reviewer will mark the response down for it.

Avoid committing to a migration date for signatures. It depends on CA issuance, which is outside your control.

Where it maps

• NIS2 Article 21(2)(h), cryptography and encryption.
• ISO/IEC 27001:2022 A.8.24, use of cryptography.
• DORA Article 9, protection, for financial entities and their ICT providers.

The short version

The question is about data lifetime, not about quantum computers.

One configuration line gives you a deployed, externally verifiable answer today. Pair it with an honest statement of what is not yet covered, and the response is stronger than a roadmap twice its length.