Post-Quantum Cryptography: What to Prepare For

By Kokil Thapa | Last reviewed: September 2026

Post-Quantum Cryptography: What to Prepare For is no longer a research-only topic for security teams. RSA and ECDH protect your TLS sessions, API tokens, document uploads, and payment callbacks today. A cryptographically relevant quantum computer could break those schemes at scale. NIST has already standardised replacement algorithms. Your job in 2026 is not to panic. It is to build a crypto inventory, plan hybrid migration, and avoid locking new systems into algorithms that will age badly. This guide maps that work for teams running production web applications, APIs, and client portals.

What is post-quantum cryptography and why should web teams care in 2026?

Post-quantum cryptography (PQC) refers to classical algorithms designed to resist attacks from large-scale quantum computers. Shor's algorithm threatens public-key schemes like RSA and elliptic-curve cryptography. Grover's algorithm weakens symmetric keys, but doubling AES key length largely neutralises that risk.

The practical threat for most businesses is harvest-now, decrypt-later. An attacker copies encrypted TLS traffic or archived ciphertext today. They decrypt it later when quantum hardware matures. Legal documents, KYC files, contract PDFs, and API payloads with ten-year retention are high-value targets. I've seen this concern surface on legal-tech portals where clients upload sensitive paperwork years before any dispute arises.

NIST published the first standardised PQC algorithms in 2024. The NIST Post-Quantum Cryptography project selected ML-KEM (formerly Kyber) for key encapsulation and ML-DSA (formerly Dilithium) for digital signatures. SLH-DSA (SPHINCS+) remains a hash-based backup. These names appear in FIPS documents and vendor roadmaps you will touch during upgrades.

If you maintain payment integrations or client portals, treat PQC as an extension of existing cryptography fundamentals. The difference is timeline and algorithm names, not the core discipline of key management and least privilege.

Which NIST algorithms replace RSA and ECDH in production systems?

NIST standardised three families for general deployment. ML-KEM handles key establishment — the role ECDH plays in TLS 1.3. ML-DSA handles signatures — the role RSA and ECDSA play in certificates and code signing. SLH-DSA offers a conservative hash-based signature when you want algorithm diversity.

Symmetric cryptography mostly stays put. AES-256 and SHA-256/384 remain sound if you avoid deprecated modes. Upgrade paths focus on public-key layers: certificate chains, JWT signing keys, SSH host keys, and application-level encryption that wraps data keys with RSA.

OpenSSL 3.x exposes providers that can load classical and PQC implementations side by side. Cloudflare, Google, and Mozilla have published hybrid TLS experiments using X25519 combined with ML-KEM. The IETF TLS working group continues to define how clients and servers negotiate these combinations without breaking the public web.

What about deprecated candidates?

Do not build on BIKE, Classic McEliece, or other round-four also-rans unless a regulator explicitly requires them. Stick to NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Vendor support concentrates there, and that reduces your long-term maintenance burden.

How do you inventory cryptographic dependencies in a Laravel or PHP stack?

You cannot migrate what you cannot see. Start with an asset list that spans infrastructure, application code, and third-party services. On production Laravel 12 or 13 applications I maintain, the inventory usually spans more layers than developers first expect.

1. Edge TLS. List every hostname, certificate issuer, key type, and expiry. Include CDN, load balancers, and origin servers managed through Linux server administration.
2. Application libraries. Run composer show and grep for openssl, firebase/php-jwt, lcobucci/jwt, encryption packages, and PDF signing tools.
3. Database and cache. Note MySQL 9.7 TLS settings, Redis 8.10 TLS, and any column-level encryption.
4. Integrations. Payment gateways, SMS APIs, and webhooks often pin RSA public keys in config files.
5. Backups and logs. Encrypted S3 buckets, restic repositories, and GPG-encrypted SQL dumps count too.
6. CI/CD secrets. GitLab CI deploy keys, SSH ed25519 keys, and artefact signing in your Deployer pipeline.

# Example inventory script — TLS cert key type per hostname
for host in api.example.com app.example.com; do
  echo "=== $host ==="
  echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -text \
    | grep -E "Public Key Algorithm|Signature Algorithm|Not After"
done

# Composer packages touching crypto
composer show -D | grep -iE 'jwt|encrypt|openssl|gpg|sodium'

Store results in a spreadsheet with columns for algorithm, key size, owner, data classification, and retention period. Flag anything protecting data retained beyond five years as priority one. Client document portals — like those described in our Mijar Law Associates portfolio case — often fall into that bucket.

Compare your inventory against PCI DSS and HIPAA cryptography requirements if you process cards or health data. Regulators will eventually reference NIST PQC; early alignment reduces audit surprises.

What is hybrid TLS and how do you pilot it without breaking clients?

Hybrid TLS combines a classical key exchange with a PQC key encapsulation mechanism. Both shared secrets feed a KDF that produces the session key. If either primitive holds, the session stays confidential. That design protects you during the transition when some clients lack PQC support.

Pilot on internal subdomains first. Staging APIs, admin panels, and GitLab runners are good candidates. Monitor handshake failures and cipher negotiation in access logs. Only then expose hybrid ciphers on public marketing sites.

Nginx example with OpenSSL 3.x and oqsprovider

# Install liboqs and oqs-provider (Ubuntu 24.04 example)
sudo apt install liboqs-provider openssl

# openssl.cnf — enable oqsprovider
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect
[default_sect]
activate = 1
[oqsprovider_sect]
activate = 1
module = /usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so

# Generate hybrid cert (process varies by CA; many use ML-DSA leaf + classical chain during transition)
# nginx ssl directive — enable groups your build supports
ssl_ecdh_curve X25519:mlkem768:X25519MLKEM768;

Test with multiple clients: current Chrome, Firefox ESR, curl on your CI runner, and any legacy mobile WebView embedded in a client app. A handshake that works in staging but fails on an old Android WebView is a common gotcha I've hit during TLS upgrades unrelated to PQC.

For API development, document which JWT algorithms your services accept. If you add ML-DSA-signed tokens, publish a versioned endpoint and maintain RS256 parallel validation during overlap. Rate-limit and monitor auth failures the same way you would for any API abuse pattern.

What should application developers change in Laravel, WordPress, and custom code?

PHP 8.5 and Laravel 13 do not yet expose first-class ML-KEM helpers in core. Your near-term work is crypto agility: abstract key operations behind interfaces so algorithm swaps do not require sweeping refactors.

• Stop hard-coding RS256. Read allowed algorithms from config. Reject unexpected alg headers on inbound JWTs.
• Prefer libsodium (sodium_crypto_*) for symmetric work. It is well audited and already bundled in PHP.
• Avoid rolling your own envelope encryption. If you must wrap AES keys with RSA today, document the migration path to ML-KEM in your ADR.
• Rotate keys on schedule. Use shorter lifetimes for signing keys that protect high-value data. Our password generator tool helps staff create strong secrets; pair that habit with automated key rotation in vaults.
• Audit WordPress 7.1 plugins that implement custom login or file encryption. WooCommerce 11.1 stores orders for years — treat order meta encrypted with legacy schemes as migration candidates.

// config/jwt.php — crypto-agile pattern (illustrative)
return [
    'allowed_algorithms' => env('JWT_ALGORITHMS', 'RS256,ML-DSA-65'),
    'public_keys' => [
        'rs256' => storage_path('keys/jwt_rsa.pub'),
        'ml-dsa-65' => storage_path('keys/jwt_mldsa.pub'),
    ],
];

// Validation middleware pseudocode
$alg = $token->headers()->get('alg');
if (! in_array($alg, config('jwt.allowed_algorithms'))) {
    abort(401, 'Unsupported signing algorithm');
}

For secrets management, extend patterns from Ansible Vault for secrets or your cloud KMS. Centralise key material so a future ML-DSA key lives beside today's RSA key without scattered .pem files on application servers.

On eCommerce builds — see our Quick And Easy Nepalese Grocery project — payment callbacks and webhook signature verification depend on gateway-published RSA keys. You cannot unilaterally switch algorithms until the gateway ships PQC. Track their roadmap and test in sandbox environments.

What migration timeline fits a small team with limited budget?

You do not need a Big Four consulting engagement to start. A phased plan fits Nepal-scale teams and solo maintainers who already wear dev, ops, and SEO hats.

Budget for testing and optimization during pilot phases. Handshake latency for ML-KEM is usually acceptable, but measure on your actual hardware. A shared EC2 instance serving both PHP-FPM and TLS termination may behave differently from a managed CDN edge.

Enterprise clients with compliance obligations should loop in legal and DPO stakeholders early. Document decisions in the same way you would for GDPR or local IRD record-keeping — algorithm choice becomes part of the control narrative.

Common mistakes to avoid

Teams often chase PQC while leaving TLS 1.0 enabled or using self-signed certs in production. Fix classical hygiene first. Another mistake is storing private keys in Git — PQC keys are larger; leaking them hurts more. Use proper vaults and the patterns from WireGuard cryptography practices as a mindset model: small surface, explicit keys, regular rotation.

Do not assume your hosting provider handles everything. Ask whether domain and hosting includes PQC-ready certificate issuance and whether shared hosting limits custom cipher suites. Managed WordPress hosts may lag behind VPS setups you control.

Key Takeaways

• Build a crypto inventory now — TLS, JWT, backups, webhooks, and document storage — before regulators and clients ask for it.
• Standardise on NIST ML-KEM, ML-DSA, and SLH-DSA; avoid non-standard PQC candidates without a compliance reason.
• Deploy hybrid TLS on staging first; combine classical and PQC key exchange until client support is broad.
• Make application code crypto-agile: configurable algorithms, centralised keys, no hard-coded RS256 assumptions.
• Prioritise systems with long data retention — legal portals, eCommerce order history, and KYC archives migrate first.
• Budget incremental testing and library upgrades; full migration is a multi-year programme, not a single sprint.

People Also Ask

Will AES-256 still be safe after quantum computers arrive?

Yes, with proper key sizes. Grover's algorithm effectively halves symmetric security margins. AES-256 retains roughly 128-bit post-quantum strength, which remains adequate for foreseeable threats. Focus PQC effort on public-key components — RSA, ECDH, and ECDSA — not on replacing AES-GCM for bulk encryption.

When will browsers require post-quantum TLS by default?

Major browsers are experimenting with hybrid ciphers in 2025–2026 releases. Mandatory PQC-only TLS is unlikely before client ecosystems catch up. Expect a long hybrid period where servers offer both classical and PQC key exchanges and negotiate the best mutual option.

Does post-quantum cryptography affect password hashing?

Not directly. Argon2id, bcrypt, and scrypt target different threat models than Shor's algorithm. Keep using modern password hashes from your encoding and secrets tooling workflows. PQC matters for key exchange and digital signatures, not for replacing password KDFs.

Can small businesses in Nepal defer PQC until 2030?

You can defer full migration, but you should not defer inventory and hybrid planning. Harvest-now-decrypt-later applies to any site served over TLS today. Start with a spreadsheet, patch OpenSSL, and ask vendors about ML-KEM roadmaps. That costs little and preserves optionality.

Start your Post-Quantum Cryptography preparation checklist

Post-Quantum Cryptography: What to Prepare For is ultimately a maintenance discipline, not a one-off upgrade. Inventory your algorithms this quarter. Patch OpenSSL on origin servers. Refactor JWT validation for agility. Pilot hybrid TLS where failure is safe. If you want help mapping crypto dependencies across a Laravel app, WordPress estate, or multi-site deploy pipeline, contact us for a scoped review. For larger programmes, see enterprise application development and custom software development services. Read more on the blog, review Notary Nepal and other portfolio work, or learn about our approach on the about page and homepage.