You’ve probably seen the headlines about quantum computers breaking encryption. Most of it is either panic or hype. The real picture is calmer, but there are a few things worth doing now, especially if you run client sites for a living.
What’s actually at risk
In 2024, NIST published its first post-quantum standards: FIPS 203 (ML-KEM, for key exchange), FIPS 204 (ML-DSA, for signatures) and FIPS 205 (SLH-DSA, a backup signature scheme).
A large enough quantum computer would break RSA and elliptic-curve cryptography. That covers the key exchange and signatures behind HTTPS, SSH, code signing and most API authentication.
What it does not break:
- AES-256. Quantum attacks only weaken it slightly. It stays safe.
- SHA-256 and other modern hashes. Same story.
- Your passwords, as long as they’re hashed properly. WordPress core has moved to modern hashing (bcrypt in recent versions).
So if someone tells you they need to “replace AES with quantum-safe encryption,” they’ve misunderstood the problem.
The real risk: “harvest now, decrypt later”
No one can break your TLS traffic today. But an attacker can record encrypted traffic now and decrypt it in a few years if quantum computers catch up.
For most brochure sites, this doesn’t matter. Nobody cares about the traffic of a local dentist’s website. It matters for sites that handle data that must stay confidential for 10 years or more: medical or legal portals, financial data, internal business apps, customer databases.
If you build web apps for clients like that, this is worth a conversation. If you build brochure sites, it’s mostly a “know what’s coming” topic.
What you control, and what you don’t
Most of the migration will happen below WordPress:
- TLS and key exchange are handled by your host, CDN or server. Cloudflare and current versions of Chrome already support hybrid post-quantum key exchange, so many sites are partly covered without doing anything.
- Certificates will change last. Post-quantum certificates aren’t mainstream yet.
- WordPress core handles a lot of crypto internally (it ships with libsodium support), and it will be updated by the core team.
Your own responsibility is the custom code: plugins, themes, integrations and API connections you write.
Where custom WordPress code gets stuck
This is where “crypto agility” comes in. It’s a fancy term for a simple idea: don’t hardcode your crypto choices, so you can change them later without rewriting everything.
The things we’d check in any custom project:
- Hardcoded algorithms. Calls like
openssl_encrypt()with a fixed cipher scattered across the codebase. Wrap them in one helper class so there’s a single place to change. - Webhook and API signatures. If a custom REST endpoint signs payloads with one fixed algorithm and no way to version it, you’ll have a painful migration later. Include an algorithm identifier in the signature format.
- Bundled libraries. Old Composer packages inside not updated plugins that use outdated crypto. Nobody reviews them until something breaks.
- Encrypted data at rest. If you store encrypted fields in the database, store which method encrypted them, so you can re-encrypt gradually.
We had a project where our developers found an old plugin that broke on a PHP upgrade. So this security plugin was a source of the problem. Outdated crypto just conflicted with new code, so we had to update PHP functions to make it work again
A practical checklist
You don’t need a big project. Start here:
- List the plugins, custom code and third-party APIs on each important site that handle encryption or signatures.
- Check which of your clients hold long-lived sensitive data.
- Move crypto calls in custom code behind a single helper.
- Ask your host whether they support hybrid post-quantum TLS, and whether they’re on a modern PHP and OpenSSL version.
- Add dependency scanning (Composer audit, Dependabot or similar) to your deployment pipeline.
The bottom line
Don’t panic, and don’t ignore it either. If you maintain your website yourself as we recommended, but using this technology, better to ask the professional to do it. For most sites, the migration will happen quietly at the hosting and browser level. For custom web apps, the difference between a painless update and an emergency rewrite is whether the crypto was written in one place or forty.
That’s how we build custom projects at WebGarage. If you’d like us to review an existing site or app, contact us.
