Is Your Business Ready for Post-Quantum Cryptography? A Practical 2026 Checklist

Short answer: most businesses are not ready for post-quantum cryptography yet, and in 2026 that is normal. What is no longer acceptable is not knowing where your cryptography lives. The practical goal for this year is not "be quantum-safe". It is to finish a crypto inventory, switch on hybrid post-quantum key exchange wherever your stack already supports it, and put quantum-safe requirements into every new contract and system you buy.

This guide is written for founders, CTOs and engineering leads at small and mid-sized companies, especially in India, who keep hearing "Q-Day" in vendor pitches and want to know what actually needs doing, in what order, and what it will cost. No physics required.

What is post-quantum cryptography?

Post-quantum cryptography (PQC) is a family of encryption and signature algorithms designed to stay secure against both today's computers and a future, large-scale quantum computer. It runs on ordinary hardware: your servers, laptops and phones. You do not need a quantum computer to use it, and it has nothing to do with "quantum key distribution", which needs specialised optical equipment.

The reason it exists: almost all public-key cryptography on the internet today (RSA, Diffie-Hellman, and elliptic-curve schemes like ECDH and ECDSA) relies on maths problems that Shor's algorithm can solve efficiently on a sufficiently large quantum computer. That covers the handshake that protects every HTTPS connection, your SSH keys, your VPN, your code-signing certificates and the digital signatures on your documents.

Why act in 2026 if quantum computers are years away?

Because the attack does not wait for the computer. An adversary who records your encrypted traffic today can store it cheaply and decrypt it later. This is called harvest now, decrypt later, and it means the deadline for any secret is not Q-Day. It is Q-Day minus how long that secret needs to stay secret.

Cryptographer Michele Mosca put it as a simple inequality. If X is how many years your data must remain confidential, Y is how many years your migration will take, and Z is how many years until a cryptographically relevant quantum computer exists, then you have a problem whenever X + Y > Z.

  today                                        Q-Day (unknown)
    |                                                  |
    |<------------------- Z years -------------------->|
    |                                                  |
    |<--- Y: migration --->|<------ X: secrecy needed ------>|
    |                      |                           |     |
    |                      migration done              |  still secret?
    |                                                  |     |
    |          traffic recorded before migration ------+---> readable
    |
    If X + Y > Z, data you send today is already at risk.

Put real numbers in. A health-records company must keep patient data confidential for decades. A bank's customer KYC data, a law firm's contracts, source code for a product you will sell for ten years, government tenders: all of these have an X of ten years or more. Enterprise crypto migrations routinely take five to ten years (the move off SHA-1 took most of a decade). Estimates for Z keep shrinking. In 2025 a Google Quantum AI paper estimated that RSA-2048 could be factored in under a week with fewer than one million noisy qubits, down from about 20 million in the same author's 2019 estimate.

Aug 2024

NIST publishes FIPS 203, 204 and 205

2030

NIST target to deprecate RSA and ECC (112-bit)

2035

Common deadline to disallow quantum-vulnerable crypto

<1M

Noisy qubits estimated to break RSA-2048 (2025)

What are the NIST post-quantum standards?

After an eight-year public competition, the US National Institute of Standards and Technology (NIST) published its first three post-quantum standards on 13 August 2024. They are the de facto global baseline: other governments, browser vendors, cloud providers and open-source libraries are all implementing these same algorithms.

The catch is size. Post-quantum keys and signatures are much larger than the elliptic-curve ones they replace. That is harmless for a TLS handshake but matters for certificate chains, constrained IoT devices, smart cards, QR codes, and anything that squeezes a signature into a fixed-size field.

What deadlines do regulators set?

There is no single worldwide deadline, but the major guidance lines up remarkably well. If you sell to regulated customers, their deadlines become yours.

For Indian businesses the direct mandate is still forming, but the pull is already here. India's National Quantum Mission (approved in 2023 with an outlay of about ₹6,000 crore) is funding domestic quantum capability, and a Department of Science and Technology task force has published a roadmap for a quantum-safe ecosystem that prioritises critical sectors such as banking, telecom, power and government. If you serve BFSI, healthcare, or any overseas client subject to the timelines above, plan as if the EU and UK dates apply to you.

The 2026 post-quantum readiness checklist

Twelve items, in the order we would do them. The first four are about knowing what you have. The next four are the quick wins your stack probably already supports. The last four make sure you never have to do this panic-migration again.

Phase 1: Know what you have

1. 1

   Name an owner and set a budget line

   PQC fails in most companies because it belongs to nobody. Give it a named owner (CTO, security lead, or a senior engineer with time carved out) and a small budget for the inventory work. It is a multi-year programme; treat it like one.

2. 2

   Build a cryptographic inventory (a CBOM)

   List every place you use public-key cryptography: public websites and APIs, internal service-to-service TLS, VPNs, SSH, databases with TLS, message queues, code signing, document signing, JWT/OAuth token signing, HSMs and KMS keys, payment integrations, mobile apps, IoT devices. For each, record the algorithm, key size, library and version, and who controls it. A Cryptography Bill of Materials (CycloneDX supports this format) is the structured version of that spreadsheet.

3. 3

   Classify data by how long it must stay secret

   This is the X in Mosca's inequality. Customer identity data, health records, financial records, IP and long contracts are 10+ years. Session data and marketing analytics are days. Systems carrying long-lived secrets go to the top of the list.

4. 4

   Ask every vendor for their PQC roadmap

   Much of your crypto is not yours: your cloud provider, CDN, payment gateway, VPN, identity provider, HSM and SaaS tools. Send each one a short question: which NIST PQC algorithms do you support today, which are on your roadmap, and by when? Their answers tell you what you can switch on and what you are waiting for.

Phase 2: Take the quick wins

1. 1

   Enable hybrid post-quantum TLS on everything you terminate

   Hybrid key exchange combines classical X25519 with ML-KEM-768 (the group is called X25519MLKEM768). An attacker has to break both. Chrome, Edge and Firefox already offer it by default, so once your server supports it, most browser traffic is quantum-protected against harvest-now-decrypt-later. With OpenSSL 3.5 or later this is often on by default; otherwise it is one line of config.

2. 2

   Upgrade SSH to a post-quantum key exchange

   OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 its default, and OpenSSH 9.x already shipped sntrup761x25519. If both ends are current, you are protected; the work is finding the old bastion hosts, network appliances and CI runners that are not.

3. 3

   Standardise on AES-256 for long-lived data

   Grover's algorithm roughly halves the effective strength of symmetric keys. AES-128 is still considered adequate by NIST, but for backups, archives and anything with a long X, AES-256 costs almost nothing and removes the question.

4. 4

   Stop issuing new long-lived RSA/ECC signing keys

   A root CA or code-signing key created today with a 20-year life will outlive the classical algorithms. Shorten lifetimes where you can and record which keys must be re-issued once post-quantum certificates are supported by your platform.

Phase 3: Make it permanent

1. 1

   Build crypto-agility into your code

   The lesson of every migration: algorithms hard-coded across 40 services are what make it take ten years. Route cryptography through one internal library or service, make algorithms configuration rather than code, and version your key formats so you can rotate without a rewrite.

2. 2

   Put PQC into procurement and contracts

   Every new system, device or SaaS contract from 2026 onwards should include a requirement to support NIST PQC algorithms, or publish a dated roadmap for doing so. Hardware bought now with a 10-year life and no firmware upgrade path is the most expensive mistake on this list.

3. 3

   Pilot post-quantum signatures internally

   Public web certificates are not yet post-quantum in browsers, but internal systems can go first: an internal PKI, service-mesh certificates, firmware or artefact signing. Pilots surface the real problems (size limits, HSM support, performance on small devices) while the stakes are low.

4. 4

   Review every year, and report it

   Add PQC to your annual security review and to your board or leadership risk report. Standards and library support are moving quickly; a roadmap written in 2026 will need revising in 2027.

How do I check whether my server supports post-quantum TLS?

The quickest test uses OpenSSL 3.5 or newer on your own machine. Ask for only the hybrid group; if the handshake succeeds, your server supports it.

# Requires OpenSSL 3.5+ locally:  openssl version
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768 -brief </dev/null 2>&1 \
  | grep -Ei "negotiated|group|protocol"

# Supported:  "Negotiated TLS1.3 group: X25519MLKEM768"
# Not yet:    handshake failure / no shared group

In a browser you can also open DevTools, go to the Security panel, and look at the key exchange for the connection. If it names X25519MLKEM768, that connection is using hybrid post-quantum key exchange.

For nginx built against OpenSSL 3.5+, preferring the hybrid group looks like this. Keep the classical groups in the list so older clients still connect.

server {
    listen 443 ssl;
    http2 on;
    ssl_protocols TLSv1.3 TLSv1.2;

    # Hybrid post-quantum first, classical fallbacks after.
    ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

    # ...certificates and the rest of your config
}

For SSH, check what your client supports and what a server actually negotiated:

# Which post-quantum key exchanges does this client support?
ssh -Q kex | grep -E "mlkem|sntrup"

# What did a real connection negotiate?
ssh -v user@your-server exit 2>&1 | grep "kex: algorithm"
# Good: mlkem768x25519-sha256 or sntrup761x25519-sha512

Which parts of your stack already support PQC?

More than you would think. Support in mainstream libraries arrived mostly in 2024 and 2025, which is why a lot of the Phase 2 work is simply upgrading.

What will a post-quantum migration cost?

Less than the headlines suggest if you start early, and much more if you start late. The expensive part is almost never the algorithm. It is finding every place crypto is used, and the long tail of systems that cannot be upgraded: old appliances, vendor black boxes, embedded devices, and code that hard-codes RSA in forty places.

• Inventory and roadmap for a small or mid-sized company: typically a few weeks of focused engineering time, more if nobody has documented the infrastructure.
• Hybrid TLS and SSH: mostly upgrades and configuration, folded into normal patch cycles.
• Crypto-agility refactoring: the biggest variable. Codebases that already centralise crypto are cheap; ones with crypto scattered everywhere are not.
• Hardware replacement: the true cost driver. Anything without a firmware path to PQC has to be replaced, which is why procurement rules matter from this year.

The cheapest migration is the one spread over normal refresh cycles. Every system you buy in 2026 with PQC support is one you do not have to rip out in 2031.

Common mistakes to avoid

• Waiting for a quantum "announcement". There will not be a clean day when the risk switches on, and recorded traffic is already exposed.
• Going post-quantum only. Use hybrid schemes for now. If a new algorithm turns out to have a flaw, the classical half still protects you. Several PQC candidates were broken during the NIST process.
• Rolling your own implementation. Use vetted libraries (OpenSSL, BoringSSL, AWS-LC, liboqs, language standard libraries). Side-channel mistakes in PQC code are subtle.
• Buying "quantum-safe" marketing. Ask which NIST algorithm, which FIPS standard, which library version. Anything that cannot answer is not a product, it is a slide.
• Treating it as a one-off project. The real deliverable is crypto-agility. The next algorithm change will come, quantum or not.

Start with the inventory

Post-quantum readiness sounds like a physics problem and turns out to be an engineering-hygiene problem: know where your cryptography is, keep it upgradeable, and stop buying things that are not. Companies that do the boring inventory work in 2026 will make the rest of the migration a series of routine upgrades. Companies that wait will do it under a regulator's deadline or a customer's questionnaire.

If you want a second pair of eyes, CruxBit runs cryptographic inventories, hybrid TLS rollouts and crypto-agility reviews for growing teams. Talk to us and we will tell you honestly how much of this you actually need.