Is PBKDF2 Deprecated? What Developers Should Use in 2026

Short answer: no, PBKDF2 is not deprecated. But it is no longer the algorithm you should reach for by default in a new system, and understanding why is more useful than a yes-or-no.

This question comes up constantly because guidance has shifted. For years, PBKDF2 was a standard, respectable choice for password hashing. It is still standardized, still supported everywhere, still approved for compliance regimes that require validated cryptography, and still meaningfully secure when configured correctly. What changed is that better options matured, and the threat landscape that PBKDF2 was designed for evolved in ways that expose its main weakness.

Let me give you the practical developer answer: where PBKDF2 still makes sense, where it falls short, and what to use instead. This builds on my fuller comparison of password hashing algorithms, which covers Argon2, bcrypt, scrypt, and PBKDF2 in depth.

What PBKDF2 Actually Is and Why It Was Good

PBKDF2 (Password-Based Key Derivation Function 2) takes a password and runs it through a hash function many times, a process called key stretching. The point of all that repetition is to make each password guess computationally expensive, so an attacker trying to crack a stolen database has to spend significant time on every single guess.

For its era, this was exactly the right idea. By tuning the iteration count upward over time, defenders could keep pace with faster hardware. PBKDF2 is well-understood, has decades of analysis behind it, is built into virtually every cryptographic library, and is FIPS-validated, which matters enormously for government and regulated industries that require approved algorithms. None of those strengths have disappeared.

This is why PBKDF2 is not deprecated. It does its job, it is trusted, and in compliance contexts it is sometimes the only approved option. Deprecation would imply it is broken or unsafe, and it is neither.

The Weakness: PBKDF2 Is Cheap to Attack in Parallel

Here is the actual problem, and it is the reason guidance moved on.

PBKDF2 is computationally expensive but not memory-expensive. It needs very little memory to run. This matters because modern password cracking does not happen on regular CPUs. It happens on GPUs and specialized hardware that can run thousands of computations in parallel.

Because PBKDF2 uses almost no memory, an attacker can run an enormous number of PBKDF2 guesses simultaneously on a GPU at relatively low cost. The algorithm's defense, raising the iteration count, helps, but it does not change the fundamental fact that the work parallelizes cheaply. An attacker with modern hardware gets a large advantage against a defense that was designed before that hardware was common.

This is the specific weakness that newer algorithms were designed to fix. They make cracking expensive not just in computation but in memory, which is much harder and more costly to parallelize at scale.

What to Use Instead: Argon2id

For new systems in 2026, the recommended default is Argon2id.

Argon2 was the winner of the Password Hashing Competition, and the Argon2id variant is specifically designed to be both computationally and memory-hard. That memory-hardness is the key. By requiring a meaningful amount of memory per hash, Argon2id makes large-scale parallel cracking on GPUs and specialized hardware far more expensive than it is against PBKDF2. It is the current consensus best practice for password storage where you have the freedom to choose.

The practical guidance for new systems:

Use Argon2id by default if your platform and libraries support it and you are not bound by a compliance regime that forbids it. It is the strongest mainstream option and is widely available.

bcrypt remains a solid, battle-tested choice if Argon2id is not available in your stack. It has been trusted for a long time, has a built-in cost factor, and resists GPU attacks better than PBKDF2, though not as well as Argon2id.

scrypt is also memory-hard and a reasonable option, though Argon2id is generally preferred for new work.

I go through the tradeoffs among all of these in detail in the full hashing comparison.

When PBKDF2 Is Still the Right Call

PBKDF2 is not the default anymore, but there are legitimate situations where it is still the correct choice. Do not rip it out reflexively.

Compliance requires FIPS-validated cryptography. This is the big one. Many government systems and regulated industries require algorithms validated under FIPS, and Argon2 is not FIPS-validated in the way PBKDF2 is. In these environments, PBKDF2 with a strong configuration is often the approved, correct choice. Following the rules that apply to you matters more than using the theoretically strongest algorithm.

You are working in a constrained environment where Argon2's memory requirements are genuinely problematic, such as some embedded or highly resource-limited contexts. PBKDF2's low memory footprint, which is its weakness against attackers, can be a practical necessity here.

You have an existing PBKDF2 system that is correctly configured with a strong iteration count and proper salting. In this case, there is no emergency. You can migrate to Argon2id over time as part of normal maintenance rather than treating it as an urgent security fix. A well-configured PBKDF2 deployment is not a vulnerability that demands immediate action.

If you do stay on PBKDF2, make sure the iteration count is set high, following current OWASP guidance, and that every password is hashed with a unique salt. A poorly configured PBKDF2 implementation with a low iteration count is genuinely weak. A well-configured one is acceptable.

How to Migrate Without Breaking Everything

If you decide to move from PBKDF2 to Argon2id, you cannot re-hash existing passwords directly, because you do not store the original passwords (and should not). The standard approach is to migrate on login.

When a user successfully authenticates with their existing PBKDF2-hashed password, you take the plaintext password they just provided, re-hash it with Argon2id, and store the new hash. Over time, as users log in, your database gradually transitions from PBKDF2 to Argon2id with no disruption. For accounts that never log in, you can age them out or force a password reset after a long period.

This on-login migration pattern lets you upgrade your hashing without forcing every user to reset their password at once, which is the practical way most teams handle the transition.

The Bottom Line

PBKDF2 is not deprecated. It is a still-standardized, still-secure-when-configured-correctly algorithm that remains the right choice in FIPS-constrained and certain resource-limited environments.

But for new systems where you have a free choice, Argon2id is the recommended default in 2026 because its memory-hardness defends against the parallel GPU cracking that PBKDF2 is structurally vulnerable to. bcrypt is a solid fallback. And if you have a well-configured PBKDF2 system today, there is no fire to put out: migrate to Argon2id as normal maintenance, using the on-login pattern, rather than treating it as an emergency.

The headline that "PBKDF2 is dead" overstates it. The accurate version is quieter and more useful: PBKDF2 is fine where it is required and acceptable where it is well-configured, but it is no longer what you should choose first when you get to choose.

For the complete technical breakdown of all four major algorithms, see the full password hashing comparison.