⚛️ Post-Quantum Cryptography & Password Security 2026

In August 2024, the U.S. National Institute of Standards and Technology (NIST) finalized three post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). For anyone working in password security, these standards matter because they'll eventually replace the RSA and ECC algorithms that underpin TLS certificates, digital signatures, and password hashing verification.

Why Quantum Computing Matters for Password Security

Today's password security relies on the computational difficulty of certain mathematical problems. RSA encryption depends on factoring large primes. ECC relies on the discrete logarithm problem. Shor's algorithm, running on a sufficiently powerful quantum computer, can solve both in polynomial time — rendering RSA and ECC completely insecure.

However, there's a critical distinction often missed: Shor's algorithm threatens asymmetric cryptography (RSA, ECC), not symmetric cryptography (AES) or hash functions (SHA-256, bcrypt, Argon2). Password hashing uses symmetric primitives only marginally affected by quantum computing — Grover's algorithm reduces effective security by half, meaning a 256-bit hash still provides 128-bit quantum security.

This means: your current password hashing infrastructure is largely quantum-safe. The vulnerability is in the TLS handshake that transmits the password, not in the hashing itself.

NIST's Post-Quantum Standards: What Changed

• FIPS 203 (ML-KEM) — Module-Lattice-Based Key-Encapsulation Mechanism. Replaces RSA for key exchange. Cloudflare deployed ML-KEM experimentally in 2023 with only 1-2% latency increase.
• FIPS 204 (ML-DSA) — Module-Lattice-Based Digital Signature Algorithm. Replaces ECDSA and RSA for digital signatures. Used for code signing and WebAuthn/FIDO2.
• FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Algorithm. More conservative but slower with larger signatures.

Major browser vendors (Chrome 132+, Firefox 128+, Safari 18+) now support hybrid TLS handshakes using both ECDHE and ML-KEM.

Impact on Password Managers

Password managers that use asymmetric key pairs for sharing or sync need their RSA/ECC key exchange upgraded to ML-KEM. Vendor roadmaps:

• Bitwarden — ML-KEM for end-to-end encrypted sharing (Q4 2026)
• 1Password — Hybrid ECDHE + ML-KEM for sync (deployed March 2026)
• Dashlane — PQC roadmap mid-2027
• Keeper — PQC enterprise key exchange (beta)

Practical Timeline

Open Source Tools for PQC Migration

Several open-source libraries now support NIST's PQC standards. For development teams evaluating PQC integration:

• liboqs (Open Quantum Safe) — The reference implementation of all NIST PQC candidates. Supports ML-KEM, ML-DSA, and SLH-DSA in C with bindings for C++, Python, Go, Java, and Rust. Actively maintained by the OQS team, with regular security audits.
• OpenSSL 3.5+ — The latest OpenSSL release includes provider modules for ML-KEM and ML-DSA. Enables hybrid TLS 1.3 key exchange with a single configuration change. Most Linux distributions have backported this to their LTS releases.
• BoringSSL — Google's OpenSSL fork, used by Chrome and Android, has included ML-KEM experimental support since 2024. The production-ready integration shipped with Chrome 132.
• NSS (Network Security Services) — Mozilla's TLS library, used by Firefox, added ML-KEM support in NSS 3.101 (April 2025).

For Go developers, the github.com/cloudflare/circl library provides ML-KEM implementations that integrate with Go's standard crypto/tls package. Python developers can use pyoqs (Python bindings for liboqs).

What Password Users Should Do

The post-quantum transition is unprecedented in cryptography history — the first time we've voluntarily upgraded the world's crypto infrastructure before a vulnerability was exploited. For password security, the impact is manageable: the foundations (hashing, symmetric encryption, CSPRNG) are already quantum-resistant.

Harvest Now, Decrypt Later: Why PQC Upgrade Urgency Exists Today

Even though a cryptographically relevant quantum computer (CRQC) is not yet operational, the "harvest now, decrypt later" threat makes early PQC adoption critical. Adversaries can collect encrypted traffic today — including VPN sessions, encrypted emails, and password manager backups — and store it for decryption once a CRQC exists.

For password security, this means any password data transmitted over TLS today could be retroactively decrypted in the future. This includes:

• Login credentials sent over TLS 1.3 during authentication
• Password manager vaults synced across devices using RSA-encrypted transport
• Backup codes and recovery keys transmitted during account setup
• VPN authentication tokens that could expose a user's identity retroactively

Organisations handling sensitive data — financial services, healthcare, legal firms — should prioritise hybrid TLS (ECDHE + ML-KEM) for all customer-facing systems immediately. The latency impact is negligible, and the cost of not upgrading is retroactive exposure of today's encrypted traffic.

How to Check if Your Organisation Is PQC-Ready

Most organisations don't know which of their internal systems use RSA, ECC, or post-quantum algorithms. A practical audit approach:

1. Public-facing TLS — Use tools like SSL Labs (ssllabs.com/ssltest) or Cloudflare's PQC readiness scanner to check which key exchange algorithms your HTTPS endpoints support
2. Password manager inventory — Check your password manager's documentation for PQC support in sync, sharing, and backup features
3. Certificate inventory — List all internal CA-issued certificates; identify which still use RSA-2048 or ECDSA P-256 (both need upgrading)
4. VPN and remote access — Check whether your VPN provider supports hybrid key exchange (most major providers including NordVPN and ExpressVPN have announced PQC roadmaps for 2026-2027)
5. Source code scanning — Search your repositories for hardcoded crypto algorithm constants (RSA, ECDSA, P-256, P-384) and flag them for review

For individual users, the most impactful action is ensuring your password manager uses PQC-ready sync encryption. Bitwarden and 1Password have both completed this migration. If you're using a password manager that hasn't published a PQC roadmap, consider migrating to one that has.