Post-quantum password security: What changes and what to do

Post-quantum password security: What CISOs must do now

Quantum computers will not brute-force a properly hashed 16-character password anytime soon. Grover's algorithm only halves the exponent of a hash search, not the whole problem. What a large enough quantum computer does break is the RSA and elliptic-curve key exchange that carries that password to your server, and NIST has already put a 2030 deadline on replacing it.

Two separate problems get collapsed into one headline: "quantum computers will break your passwords." This guide keeps them apart, then hands IT and security teams a workflow for checking which one actually applies to their own password estate, and which parts of that estate can wait.

Key takeaways

Shor's algorithm breaks RSA and elliptic-curve key exchange. Grover's algorithm only halves the effective strength of a password hash, from roughly 128-bit to 64-bit.
NIST finalized FIPS 203, 204, and 205 in August 2024 and set a 2030 deprecation, 2035 disallowance timeline for RSA, ECDSA, and EdDSA in NIST IR 8547.
Harvest-now-decrypt-later is already active. 61% of security professionals name it their top quantum concern, according to Thales's 2026 report.
The 3-Layer Quantum Exposure Audit sorts a password estate into hashes, key exchange, and long-lived encrypted data. Each layer gets its own verdict.
AES-256 stays quantum-resistant at current key sizes. RSA-2048 is the component every vendor, including password managers, needs a migration plan for.

The two quantum algorithms that matter (Shor vs Grover)

Two quantum algorithms matter for password security, and they do different jobs. Shor's algorithm delivers an exponential speedup against the math behind RSA and elliptic-curve cryptography, which breaks key exchange once a large enough quantum computer exists. Grover's algorithm delivers only a quadratic speedup against symmetric search, cutting effective strength in half rather than to zero.

Algorithm	Speedup	Target	Practical effect
Shor's algorithm	Exponential	RSA, elliptic-curve cryptography (ECC), Diffie-Hellman	Breaks key exchange and digital signatures once a large error-corrected quantum computer exists
Grover's algorithm	Quadratic (square root)	Symmetric search: password hashes, AES keys	Halves effective bit strength (128-bit becomes roughly 64-bit); the algorithm itself stays intact

The gap between exponential and quadratic is the whole story. A quadratic speedup against a 128-bit hash still leaves roughly 2⁶⁴ operations to try, which is computationally enormous today, and a memory-hard function like Argon2id multiplies that cost further. An exponential speedup against RSA-2048 doesn't leave a comparable margin.

For the deeper mechanics of lattice-based and other post-quantum schemes, see our explainer on what is quantum cryptography; this guide stays focused on what changes for password infrastructure specifically.

What is Shor's Algorithm?

Shor's Algorithm — a quantum algorithm developed by Peter Shor in 1994 that efficiently factors large integers into their prime factors in polynomial time. On a quantum computer, it can factor an n-bit number in approximately O(n³) operations, compared to the best known classical algorithms which require exponential time. This algorithm is significant because it can break RSA encryption, which relies on the difficulty of factoring large numbers. For example, while a classical computer might take thousands of years to factor a 2048-bit number, Shor's algorithm on a sufficiently powerful quantum computer could do it in hours.

What is Grover's Algorithm?

Grover's Algorithm — a quantum algorithm developed by Lov Grover in 1996 that searches an unsorted database of N items in O(√N) time, providing a quadratic speedup over classical search which requires O(N) time. The algorithm uses quantum superposition and amplitude amplification to identify a marked element among many unmarked ones. For example, to find a specific item among 1 million items, Grover's algorithm would need approximately 1,000 queries instead of 500,000 on average. While less dramatic than Shor's algorithm, Grover's speedup applies to a broader range of problems including database searching, optimization, and cryptanalysis.

Why your password hash is not the real target

A properly hashed password stays expensive to crack even under Grover's algorithm, because the hashing function's cost applies to every single guess a quantum computer makes. Argon2id and bcrypt are memory-hard by design, so halving the exponent still leaves an attacker paying a steep price per attempt.

Take a 16-character random password drawn from the full 95-character printable set: roughly 105 bits of entropy before hashing touches it. Grover's quadratic speedup roughly halves that exponent, landing an attacker around 2⁵² effective operations. That number stays out of reach for any quantum computer under serious discussion today, and Argon2id's memory-hard cost multiplies the price of each guess on top of it.

Not every hashing function offers that protection equally. PBKDF2 is CPU-bound and cheaper to parallelize on custom hardware. Argon2id and bcrypt force an attacker to pay in memory as well as time, which matters more as GPU and ASIC cracking improves, quantum or not. Salting stays mandatory regardless of algorithm: it stops precomputed rainbow-table attacks and forces every guess to run individually against a single hash.

Our guide to password hashing and salting covers the mechanics of each function in more depth, including why a 16-character minimum has become the practical floor.

What is Argon2id?

Argon2id — a modern password hashing algorithm that won the Password Hashing Competition in 2015. It is designed to be resistant to both GPU and ASIC attacks by requiring significant amounts of memory and computational time. Argon2id combines two variants: Argon2i (resistant to side-channel attacks) and Argon2d (faster but potentially vulnerable to side-channels). It uses configurable parameters for time cost, memory cost, and parallelism, making it highly resistant to brute-force attacks. For example, with recommended settings, hashing a password might take 1-2 seconds and require 64MB of memory, making it impractical for attackers to crack passwords at scale.

What is PBKDF2?

PBKDF2 (Password-Based Key Derivation Function 2) — a key derivation function standardized by NIST that applies a pseudorandom function (like HMAC-SHA256) repeatedly to a password and salt to produce a derived key. It is designed to slow down password hashing by using a configurable iteration count, making brute-force attacks more computationally expensive. PBKDF2 has been widely adopted for password hashing and key derivation in various applications. However, it has limitations compared to modern algorithms like Argon2id because it does not require significant memory, making it vulnerable to GPU and ASIC-based attacks. For example, PBKDF2 with 100,000 iterations is still considered acceptable but less secure than memory-hard alternatives.

What is bcrypt?

bcrypt — a password hashing algorithm based on the Blowfish cipher, designed by Niels Provos and David Mazières in 1999. It incorporates a salt and a configurable cost factor (work factor) to slow down the hashing process, making it resistant to brute-force attacks. The cost factor can be increased over time as computing power grows, allowing bcrypt to remain secure for years. bcrypt automatically generates and stores the salt within the hash output, simplifying implementation. For example, bcrypt with a cost factor of 12 takes approximately 250 milliseconds to hash a password on modern hardware. While bcrypt is still widely used and considered secure, it does not require memory like Argon2id, making it somewhat vulnerable to specialized hardware attacks.

The layer that actually breaks: Key exchange

RSA-2048 and ECDH key exchange are the actual target here. Shor's algorithm makes factoring the math behind RSA and computing the discrete logs behind ECC tractable, which breaks TLS handshakes, SSH sessions, VPN tunnels, and any private-key wrap built on the same primitives.

Public-key cryptography carries that risk into everyday infrastructure in more places than most teams track:

TLS 1.3 handshakes: RSA or ECDHE key exchange, ECDSA certificates
SSH host and user key exchange
VPN tunnel negotiation
Private-key wrapping inside a password manager's key hierarchy
Code-signing and document-signing certificates

The math behind that risk isn't hypothetical. Google Quantum AI published a May 2025 preprint showing that 2048-bit RSA could theoretically be factored by a sufficiently large error-corrected quantum computer. The machine doesn't exist yet. The mathematics that would break it does.

A password manager sits inside this same list. Sharing a vault with a new team member, syncing a record between devices, or unwrapping a private key at login all depend on an asymmetric operation somewhere in the chain. Auditing your password manager's crypto stack belongs in the same inventory as your TLS endpoints and VPN concentrators.

Harvest now, decrypt later: The threat that exists today

Harvest now, decrypt later describes an attacker recording encrypted traffic today and decrypting it once a capable quantum computer exists. It reframes "quantum is ten years away" into "the collection already started," which matters for any data whose confidentiality needs to survive a decade or more.

Thales's 2026 Quantum & AI Threat Report surveyed 3,120 security and IT professionals across 20 countries and found harvest-now-decrypt-later is their top quantum concern, cited by 61% of respondents, ahead of algorithm deprecation or compliance deadlines. Adversaries with the patience to wait years for a payoff, typically nation-state actors, are the ones running this collection today.

The exposure concentrates in data that needs to stay confidential for years: medical records, legal filings, intellectual property, government communications. A TLS session key discarded the moment a connection closes is a poor target. An RSA-wrapped archive from 2024 still sitting on a backup tape in 2034 is exactly what this threat targets, and so is an encrypted vault export sitting in a decommissioned backup that nobody remembered to purge.

What NIST actually decided, and the deadlines that bind you

NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST IR 8547 then set the compliance clock, deprecating RSA, ECDSA, and EdDSA after 2030 and disallowing them after 2035.

Date	Milestone
2016	NIST opens its post-quantum cryptography standardization process
August 2024	FIPS 203, 204, and 205 finalized: ML-KEM, ML-DSA, SLH-DSA
November 2024	NIST IR 8547 published, setting the deprecation and disallowance timeline
After 2030	RSA, ECDSA, and EdDSA deprecated
After 2035	RSA, ECDSA, and EdDSA disallowed

Symmetric cryptography at 128-bit security or higher is unaffected by any of this. AES-256 needs no algorithm change. The deadlines target the asymmetric layer specifically: RSA, ECDSA, and EdDSA, replaced by ML-KEM and ML-DSA. The Commercial National Security Algorithm Suite 2.0 mirrors this timeline for U.S. national security systems, one signal of how seriously procurement teams are meant to take it.

NIST IR 8547 frames post-quantum migration as a multi-year engineering effort, on the order of a decade to integrate across products and infrastructure, which is the real argument for starting an inventory now rather than waiting until 2029. IBM's public quantum roadmap targets a system of 100,000-plus qubits by 2033. That's the vendor's own stated goal, not an independent projection, but it puts a rough date on when "large enough" stops being theoretical.

Building crypto agility into procurement now, meaning the ability to swap an algorithm without rearchitecting a product, is what turns this from a scramble into a scheduled migration.

The 3-Layer Quantum Exposure Audit

Running this audit takes an afternoon, not a consulting engagement. Sort your password estate into three layers, and each one gets its own verdict: safe, watch, or act now.

Layer	What it is	Quantum status	Verdict
1. Password hashes	Argon2id, bcrypt, or PBKDF2 protecting stored credentials	Grover halves effective strength; memory-hard functions stay expensive per guess	Safe. Recheck the algorithm and iteration count, but this isn't urgent
2. Key exchange and transport	RSA, ECDH, ECDSA in TLS, SSH, VPN, and private-key wraps	Shor breaks the underlying math once a capable quantum computer exists	Act now. Inventory it and plan a migration to ML-KEM and ML-DSA
3. Long-lived encrypted data at rest	Archives, backups, and records whose confidentiality must outlast a decade	Exposed today via harvest-now-decrypt-later if protected only by an asymmetric key exchange	Watch. Prioritize by data sensitivity and retention period

Layer 1 is the one teams worry about most and need to worry about least. If your login and password-manager master-password hashes already use Argon2id, PBKDF2 or bcrypt with a reasonable work factor, Grover's algorithm doesn't change your risk calculus. The one real gap worth chasing: a legacy system still running MD5 or unsalted SHA-1 was already broken before quantum entered the conversation.

Layer 2 is where an admin usually finds the actual gap: a VPN concentrator still pinned to RSA-2048, an internal PKI issuing ECDSA certificates with no renewal plan, a legacy API that never moved past TLS 1.2. Inventory every place RSA, ECDH, or ECDSA performs a key exchange, and start with whatever protects your longest-lived traffic.

Layer 3 is about what's already been collected, not what gets encrypted tomorrow. Ask what data your organization protects today that still needs confidentiality in 2035: legal holds, cap tables, source code, anything under a multi-year NDA. Then check whether that confidentiality depends on an asymmetric key exchange performed years ago.

Run the audit once, then fold it into whatever cadence your team already uses for a crypto inventory. Annually is reasonable. Faster if you're issuing new PKI or renegotiating a VPN contract this year.

How to read a password manager's crypto documentation

A password manager's crypto documentation should name exactly what protects your vault at each layer. A vague "military-grade encryption" claim doesn't count. Look for named algorithms, stated key sizes, a named key-derivation function, and a public position on post-quantum migration.

What a quantum-aware vendor publishes:

The exact symmetric cipher and key size protecting vault data (AES-128 and AES-256 are not the same margin, so "AES" alone isn't enough)
The exact asymmetric algorithm used for key exchange and private-key wrapping
The key derivation function and iteration count turning a master password into an encryption key
Whether encryption happens client-side, the zero-knowledge model, or only at rest on the server

Passwork's own documentation is a reasonable example of what that transparency looks like in practice. Its client-side encryption applies AES-256 to vault and record data, with a separate AES-256 layer protecting the database at rest. A master password derives a 512-bit master key through PBKDF2 (HMAC-SHA-256), which unwraps an RSA-2048 private key that in turn unwraps per-vault and per-record keys, a hierarchy documented in the cryptography overview.

Run that stack through the 3-Layer Audit and the honest answer is straightforward. The AES-256 data layer stays quantum-resistant at current key sizes; the RSA-2048 key-exchange layer is the component to watch as post-quantum standards mature across the industry. That's the same answer any vendor wrapping keys with RSA should be giving you today: a documented AES-256 layer that doesn't need to change, and an asymmetric layer with an acknowledged migration path, not a claim that everything is already quantum-proof. Our AES-256 explainer covers why the key size margin matters on its own.

If your team is starting its own crypto inventory, Passwork publishes exactly this kind of documented AES-256/RSA-2048 stack, with exportable audit logs to feed straight into your Layer 2 review. Start a free trial

What to do today (and what can wait)

Start with what protects TLS, SSH, and VPN key exchange today, since that's the layer with an actual 2030 deadline. Passkey rollout, hybrid key exchange testing, and a documented crypto inventory can run in parallel. Re-keying AES-256 deployments or worrying about password hash strength can wait.

Do now:

Inventory every place RSA, ECDH, or ECDSA performs key exchange: TLS endpoints, SSH hosts, VPN concentrators, internal PKI.
Confirm your password manager and identity provider publish their actual crypto stack instead of a vague "bank-level encryption" claim. If a vendor won't name its algorithms and key sizes on request, treat that as the answer.
Turn on MFA everywhere it isn't already mandatory. It doesn't touch the quantum question directly, but it closes exposure while migration runs.

Plan this year:

Get hybrid key exchange (classical plus ML-KEM) onto your vendor roadmap conversations, especially for anything facing a 2030 deadline.
Prioritize passkey rollout for user-facing authentication. FIDO2's algorithm agility means the migration path already exists, even though today's passkeys still use ECDSA, and rollout itself reduces how much of your estate still depends on a password hash at all.
Close out any lingering TLS 1.2 endpoints. Update TLS 1.3 is a prerequisite for post-quantum key exchange, not a separate project.

Watch:

IBM's and Google's quantum hardware roadmaps. A jump past the milestones in the NIST timeline above would move deadlines up rather than simply confirm them.
NIST guidance on hybrid and pure post-quantum modes as FIPS 203, 204, and 205 implementations mature in mainstream TLS and SSH libraries.

None of this requires replacing an existing password manager. If it already publishes an AES-256/RSA-2048 stack like the one above, the platform is doing its part; the inventory work above is yours.

Conclusion

Quantum computers are not coming for your password hash. They're coming for the RSA and ECC key exchange that carries it, and NIST has already put dates on the calendar: 2030 to deprecate, 2035 to disallow. The 3-Layer Quantum Exposure Audit turns that abstract risk into three concrete checks a team can run this quarter, one of which is probably closeable this afternoon.

Start with Layer 2. Pull the list of everywhere RSA, ECDH, or ECDSA handles a handshake in your environment, and you'll know within a day which vendors need a migration conversation and which ones already have one started.

If your team is building that inventory, Passwork gives you a documented AES-256/RSA-2048 vault with exportable audit logs to feed straight into it. Start a free trial

Frequently asked questions

Will quantum computers break all current passwords?

No. Shor's algorithm breaks the RSA and ECC key exchange around a password, not the password hash itself. A 16-character random password stays computationally expensive to crack even with Grover's quadratic speedup, especially under a memory-hard function like Argon2id.

Are password hashes quantum-safe?

Largely, yes. Argon2id, PBKDF2, and bcrypt stay costly under Grover's algorithm because their memory-hard work applies to every guess, quantum or not. Sufficient length (16 characters or more) and a modern hashing algorithm are the two controls that actually matter here.

What's the difference between Shor's and Grover's algorithms for passwords?

Shor's algorithm delivers an exponential speedup against factoring and discrete logarithms, which is what breaks RSA and ECC key exchange. Grover's algorithm delivers only a quadratic speedup against hash search, cutting 128-bit strength to roughly 64-bit rather than breaking it outright.

What is harvest now, decrypt later?

It's the practice of recording today's encrypted traffic and decrypting it once a capable quantum computer exists. Data with a long confidentiality requirement, such as legal, medical, or intellectual property records, is the target, which is why the collection risk exists now, not in 2030.

What does NIST's 2030/2035 deadline mean for my organization?

NIST IR 8547 deprecates RSA, ECDSA, and EdDSA after 2030 and disallows them after 2035. Teams should inventory where those algorithms handle key exchange now and build a migration plan toward ML-KEM and ML-DSA before the deadline arrives.

Are passkeys quantum-safe?

Not yet, but they're positioned well. Current passkeys use ECDSA, which Shor's algorithm would eventually break, but the FIDO2 protocol supports algorithm replacement by design. That should make the passkey transition smoother than migrating legacy password infrastructure.