You send a confidential file. The connection is encrypted, the transfer finishes, and you get back to work. But suppose someone keeps a copy of that encrypted traffic for ten years. Would the file still be private when they come back to it with better equipment?
That question is why I think quantum-safe cybersecurity deserves attention now. It’s easy to treat quantum computing as something for a research lab to worry about. The awkward part is that a file sent in October 2026 might still contain information you want private in October 2036. Your security decision has a longer life than the software version you made it with.
NIST calls this risk “harvest now, decrypt later”: an attacker collects encrypted data now and hopes to read it once the necessary technology exists. We don’t have a reliable date for that technology. We do have standards meant to help us prepare, and the work of putting them into real systems has started.
Access without medium partner: Quantum-Safe Cybersecurity
Why some of today’s cryptography needs replacing
The threat is specific. A quantum computer large enough to attack cryptography could break widely used public-key methods such as RSA and elliptic-curve cryptography. Those methods support secure connections and the checks that help computers trust one another. NIST’s migration FAQ identifies both as part of the problem.
Actually, the word “encryption” can make the discussion confusing. A secure connection has several jobs to do. It needs a way to establish secret keys, a way to protect the data itself, and a way to check who is on the other end. Changing one part doesn’t tell you whether the whole connection has been updated.
AES, the symmetric encryption used to protect data with a shared secret, faces a different kind of quantum threat. In its cryptography FAQ, NIST says current applications can continue using AES with 128-, 192-, or 256-bit keys under its existing guidance. It also explains why the theoretical speedup from a quantum search algorithm doesn’t translate neatly into a practical attack. So a headline saying quantum computers will break “all encryption” skips a lot.
I don’t know when a machine capable of breaking widely used public-key cryptography will arrive. NIST doesn’t give a certain date either. That’s an uncomfortable answer if you’re trying to put an upgrade into next year’s budget, but inventing a countdown wouldn’t make the decision any better. The useful questions are how long your data must stay private and how long your systems take to change.
And no, deploying post-quantum cryptography doesn’t mean buying a quantum computer. The algorithms work on ordinary computing systems. NIST’s migration project is about bringing them into the products and protocols we already depend on. The server room can stay fairly ordinary. The difficult bit is often the software sitting inside it.
What NIST’s three standards do
On 13 August 2024, NIST published its first three finalized post-quantum standards. The names aren’t friendly: ML-KEM, ML-DSA, and SLH-DSA. I wouldn’t expect a business owner to memorize them. I would expect a supplier claiming to offer quantum-resistant protection to explain which one it uses and what that protection covers.
Start with ML-KEM, defined in FIPS 203. KEM stands for key-encapsulation mechanism. Its job is to help two parties establish a shared secret over a public channel. That secret can then be used with symmetric cryptography to protect their communication. It helps set up the protection; the file itself is encrypted using the appropriate data-encryption algorithm.
Here’s a simplified walk-through. One party creates a public key and keeps its corresponding private key secret. The other party uses the public key to produce a shared secret and an encapsulated message. It sends that message back. The private key lets the first party recover the same secret. An observer can see the public exchange. The design aims to prevent that observer from recovering the secret. The applications then use the established secret within a secure protocol. This explanation leaves out protocol details, but it shows why calling ML-KEM a replacement for every encryption step is a bit wonky.
NIST published separate recommendations for using KEMs in September 2025. That document covers their properties and applications, along with recommendations for secure use. There’s a reason for a separate document: an algorithm name alone doesn’t describe a complete system. My advice would be to use maintained software that implements a suitable protocol, and ask how it has been tested, before treating the presence of ML-KEM as a finished security job.
ML-DSA handles a different problem. Under FIPS 204, it creates and verifies digital signatures. A signature helps a recipient detect unauthorized changes and authenticate the signer. For a software update, that distinction matters: you want to know whether the update came from the expected publisher and whether its contents changed. Signing a file doesn’t hide its contents from someone who can read it.
SLH-DSA, defined in FIPS 205, is another digital signature algorithm. It uses hash-based methods and comes from SPHINCS+. ML-DSA uses lattice-based mathematics. You don’t need to learn those mathematics to see the benefit of having options built on different approaches. NIST’s public evaluation process can keep examining them as research develops.
Those labels can still be a pain to read. The distinction I’d keep on a sticky note is this: ML-KEM helps establish a secret; ML-DSA and SLH-DSA help verify signed information. When a product page says “quantum-safe,” ask which of those jobs it means.
Chrome’s upgrade shows why the details matter
Google’s Chrome team described a snag in its September 2024 account of the move from Kyber to ML-KEM. Chrome’s experimental hybrid key exchange paired X25519 with Kyber. Small changes in the finalized ML-KEM made it incompatible with that earlier version.
Small changes. An incompatible result.
Google scheduled the switch for Chrome 131 so servers had time to update. The size of the two post-quantum versions made offering both key-share predictions impractical. Servers could support both during the change to accommodate different clients. There was a specific compatibility problem to deal with before the rollout.
But the lesson I take from it is broader than Chrome. A supplier can be working on the correct cryptography and still need a coordinated rollout. Clients update on different schedules. Servers have their own release cycles. Someone has to check what happens where those schedules don’t match. The version number belongs in the plan.
Hybrid here meant combining conventional and post-quantum methods for establishing keys. A statement about protecting captured traffic should leave you asking a separate question about authentication and certificates.
I think that separation gets lost because “we support post-quantum cryptography” fits so neatly into a sales slide. “Here are the connections we protect, the clients we tested, and the parts still waiting for updates” would be much more useful to the person responsible for the system.
The work is still unfinished in October 2026
Cloudflare’s 29 September 2026 account of its migration work makes the problem less abstract. The company described CryptoLabe, an internal AI tool it is developing to find cryptography in its code and investigate how that cryptography is used. The tool is specific to Cloudflare’s own systems and wasn’t being offered to customers.
One detail caught my attention: a certificate carried inside an HTTP header. Cloudflare identified it as a case needing more investigation because a larger post-quantum certificate could run into size limits. At publication, the team still needed to decide whether the code would stay in use and, if so, measure the relevant limits. The algorithm could be fine and the surrounding application could still need changes.
Cloudflare also said it wasn’t convinced its scans had found every use of cryptography. I find that admission more useful than a tidy claim of complete coverage. It gives another engineering team something concrete to check: hidden assumptions about size, and gaps in discovery.
A header limit sounds like a boring detail until it’s your connection that stops working.
There is ongoing work at the standards level too. NIST’s current project overview lists Falcon and HQC as selected algorithms whose standardization is still underway. Their selection doesn’t make them additional finalized standards. The status matters when you read an old announcement or compare two suppliers’ claims about what they support.
A useful first step is smaller than a company-wide replacement
NIST advises organizations to identify vulnerable cryptography and plan updates. Its PQC guidance also explains that products, services, and protocols need changes. That’s a fair amount of coordination, especially when part of a system belongs to another company.
My preference would be to start with one service that handles information you need to keep private for years. Give that service an owner. Write down where its data goes and who supplies the software along the way. You can expand from there, but a first pass should lead to something you can check or change.
So for a file-transfer service, I’d want a record of its cryptographic algorithms and library versions. I’d also want the certificate details and the people responsible for upgrading each end. NIST’s inventory guidance covers these kinds of records. It makes a useful distinction: record information about keys, such as their type and owner, without putting the secret key material into the inventory.
Basically, give the spreadsheet enough detail to answer an engineering question. A row that says “encrypted” won’t help much when you need to know whether an older client can use the planned replacement. Nor will a vendor name with no product version attached. This is where an otherwise sensible project can turn into paperwork, and I’d push back on that early.
Then ask the supplier for evidence you can use. Which release supports the required algorithm? Is the protection active by default? Which part of the connection does it cover? What happens if the other side doesn’t support it? These are my suggested procurement questions, not a quoted NIST checklist. A clear answer to each would help me judge how much work remains.
The pilot needs a definition of success. “The page loaded” is too thin. I’d want to confirm which cryptographic method the connection used, check performance under the conditions the service will face, and record any fallback to older methods. NIST’s NCCoE migration work includes interoperability and performance for good reason. A feature being available and a connection using it are different facts.
Ordinary security work still belongs in that plan. A post-quantum connection won’t stop someone who steals a user’s session or gets access to the unencrypted file after it arrives. I wouldn’t let a cryptographic upgrade become an excuse to neglect access control or software updates. The file needs protection at the points where people use it too.
Leave room for the next change
NIST calls the ability to replace cryptographic methods while keeping systems secure and operational crypto agility. Its guidance updated in June 2026 covers that ability across software and hardware. The phrase sounds like management jargon; the practical test is whether you can change a cryptographic dependency without rebuilding everything around it.
That’s the part I’d want an upgrade to improve. Or, more precisely, I’d want it written into the acceptance criteria: someone owns the dependency, updates can be tested, and the team knows how to respond when requirements change. Nobody enjoys discovering that a security setting is buried in a product that stopped receiving support two years ago.
Go back to the file you sent at the start. If its contents need to stay private until 2036, find out how that transfer is protected today and who can update it. Start with that one connection. Put a name and a product version beside it, then ask for a migration date you can follow up on.