Encrypted today, readable tomorrow?

Every time you open a bank app, log in to a website or send a WhatsApp message, encryption protects what travels across the internet. Much of the "public-key" part of that protection relies on maths problems, such as the ones behind RSA and elliptic curves, that ordinary computers find far too hard to solve.

A big enough quantum computer would solve those problems quickly. NIST, the US standards body, says so plainly: a sufficiently capable quantum computer could defeat the encryption we use now.

Here is the honest part. That computer does not exist yet. Cloudflare's October 2025 review puts it bluntly: today's quantum computers are simply not good enough to crack any real-world cryptographic keys. Nobody can tell you the exact date it will arrive. NIST noted in 2024 that some experts expect such a device within a decade, and that is a prediction, not a promise.

So why talk about it now? Because of what happens to your data in the meantime.

Imagine a diagnostic lab in Pune that sends patient reports to hospitals over the internet. Today those reports are encrypted, and a snooper who copies them sees only scrambled data. But the snooper can keep the copy. If a powerful quantum computer exists in ten years, the old copy could be opened then.

That is the "harvest now, decrypt later" threat. NIST's transition report describes it as adversaries collecting encrypted data now, with the goal of decrypting it once quantum technology matures, and lists it as one of the main reasons the move to post-quantum cryptography is urgent.

NIST also gives a simple way to think about timing. Say your data must stay secret for X years, and moving to new cryptography will take you Y years. If X plus Y is longer than the time until a capable quantum computer arrives, you are already late. NIST adds that, historically, going from a new standard to full use across real systems has taken 10 to 20 years.

If you store personal data about customers, this also touches your privacy duties. Our guide to India's data protection law explains what that data now comes with.

The good news is that the fix exists. In August 2024, after an eight-year effort that began in 2015, NIST published its first three finished post-quantum standards. Each uses a different kind of maths that is believed to resist both ordinary and quantum computers.

• ML-KEM (FIPS 203). Used to set up a shared secret key between two parties over a public network. This is the main standard for general encryption.
• ML-DSA (FIPS 204). Used for digital signatures, which prove who sent something and that it was not altered.
• SLH-DSA (FIPS 205). Also a signature standard, built on a different approach, kept as a backup in case ML-DSA ever proves vulnerable.

NIST's own advice is to start using them now rather than wait for more standards, because full integration takes time.

Here is where things stand, from the primary sources:

1. August 2024NIST finalises FIPS 203, 204 and 205.
2. November 2024NIST publishes a draft transition plan (IR 8547). It proposes that RSA and elliptic-curve algorithms at the 112-bit security level be deprecated after 2030, and that RSA and elliptic-curve signatures and key establishment be disallowed after 2035.
3. July 2025CERT-In publishes version 2.0 of its technical guidelines, including the cryptographic inventory known as a CBOM (see below).
4. October 2025Cloudflare reports that the majority of human-initiated traffic on its network uses post-quantum encryption.

What is already protected

For key exchange, a lot is already switched on. A hybrid method called X25519MLKEM768 combines a classic algorithm (X25519) with ML-KEM, as a hedge in case one of the two is ever weakened. Cloudflare reports that recent versions of all major browsers, plus many libraries and platforms including OpenSSL, Go and recent Apple operating systems, turn it on by default.

Signatures and certificates are the harder half. Cloudflare explains that moving to post-quantum signatures is much more difficult than moving key exchange, and that it will need more time. They also matter less for harvest-now-decrypt-later, because a signature only needs to hold at the moment it is checked.

India's national cyber agency has not ignored this. Version 2.0 of CERT-In's technical guidelines, dated 9 July 2025, includes a chapter on a Cryptographic Bill of Materials, or CBOM. In simple terms, it is a list of every cryptographic asset you rely on: algorithms, keys, protocols, certificates and the software that uses them, with details like how they are used and when they expire.

CERT-In says this inventory helps organisations see which legacy algorithms they depend on and plan a phased move to post-quantum cryptography. Its recommendations include that:

• government, public sector and essential services organisations require a CBOM in related procurements, developments and integrations;
• suppliers of software, systems or devices involving cryptography provide one for what they deliver; and
• organisations keep their own CBOM accurate and up to date.

CERT-In released these guidelines particularly for entities in the public sector, government and essential services, and for organisations in software export and services. If you sell to any of those, expect these questions to reach you through their procurement.

You do not need a big budget to start. These steps are in a sensible order.

• Find where you use cryptographyList your website and app certificates, VPNs, databases, backups, email, payment links, code signing and the third-party services you depend on. This is your own CBOM, and it is the step everything else rests on.
• Rank data by how long it must stay secretHealth records, KYC documents, contracts and intellectual property come first. Short-lived data can wait.
• Ask every important vendor in writingDo they have a post-quantum roadmap? Do they support ML-KEM or a hybrid method today? Can they provide a cryptographic inventory for what they sell you? Put the question into new contracts and renewals.
• Switch on what already existsKeep browsers, operating systems and TLS libraries current, and ask your hosting or CDN provider whether hybrid post-quantum key exchange is enabled. Cloudflare says that for key exchange this is, in the vast majority of cases, an uneventful software update.
• Build crypto-agilityAvoid hard-coding algorithm choices into your software. If you can swap an algorithm through configuration or a library update, the next migration is far easier.
• Plan certificates and signatures for laterThese need more time and ecosystem support. Put them on the roadmap and watch your vendors, but do not rush them ahead of key exchange.
• Write a one-page planName an owner, list your top five long-lived data sets, record vendor answers and review it every year.

• Do not panic-buy "quantum-proof" products. Ask which NIST standard a product implements and ask for it in writing. Vague claims are a warning sign.
• Do not build your own cryptography. Use the published standards through well-reviewed libraries.
• Do not rip out AES. NIST's draft says approved symmetric algorithms at 128 bits or more are significantly less vulnerable to known quantum attacks. The work is in public-key cryptography.
• Do not wait for certainty about the date. The point of starting early is that nobody knows it, and migrations take years.

The summary is simple: find it, rank it, ask about it, and update what is already available. Most companies can make real progress this quarter with an inventory and a few emails to vendors.