Start with Argon2id for new systems, use scrypt when Argon2 support is limited, and keep bcrypt only where legacy compatibility or environmental constraints require it. The decision should also account for tuning, migration, and operational limits, because a technically sound algorithm can still fail if its parameters are misconfigured or never reviewed.
Why This Matters for Security Teams
Password hashing is one of those controls that usually looks settled until an application has to survive real attacker pressure, scale, and future migrations. The choice is not just about “the strongest algorithm”, but about memory cost, GPU resistance, latency, upgrade paths, and whether the deployment can actually support safe parameters over time. Current guidance aligns with the NIST Cybersecurity Framework 2.0 view that controls must be resilient and maintainable, not merely well intended.
This matters because weak tuning can undo a good algorithm, while rigid legacy dependence can trap teams on older schemes long after better options are available. In parallel, broader identity failures often begin with credential handling issues, not exotic exploits. NHI Mgmt Group research shows that 30.9% of organisations store long-term credentials directly in code, which is a reminder that password protection and secret handling are part of the same operational problem set, as reflected in the Cisco Active Directory credentials breach analysis.
In practice, many security teams discover hashing weaknesses only after a credential dump or recovery exercise has already forced a redesign, rather than through intentional lifecycle planning.
How It Works in Practice
The practical decision usually starts with Argon2id because it gives modern applications a strong balance of memory hardness, tunability, and resistance to offline cracking. When support is limited, scrypt is the next common option because it also forces attackers to spend memory as well as compute. bcrypt remains acceptable for legacy compatibility, but it is increasingly a compatibility choice rather than a preferred design target.
For implementation, security teams should treat the algorithm as only one part of the control. The real work is in parameter selection, storage format, and review cadence. Hash cost should be high enough to slow bulk guessing, yet low enough to preserve sign-in reliability under normal load. Teams should also keep a migration path ready so that old hashes can be upgraded on login or during forced reset events. The NIST Cybersecurity Framework 2.0 is useful here because it frames security as an ongoing operational discipline, not a one-time configuration.
- Use Argon2id for new builds when your libraries and runtime support it.
- Set cost parameters based on measured server capacity, not vendor defaults.
- Store algorithm, salt, and parameters together so old records remain verifiable.
- Upgrade hashes progressively during successful authentications.
- Plan for forced resets when a legacy scheme must be retired quickly.
Where password controls fail in the real world, it is often because organisations rely on defaults, skip re-benchmarking, or leave legacy hashes untouched for years, even after application and hardware changes alter the threat model. NHI Mgmt Group research on long-lived credentials highlights the risk of leaving authentication material in place too long, which is why the Cisco Active Directory credentials breach remains a useful warning example.
These controls tend to break down in high-throughput legacy systems with fixed latency budgets, because secure parameters can exceed acceptable login performance and force a slower migration path.
Common Variations and Edge Cases
Tighter hashing settings often increase CPU and memory cost, requiring organisations to balance brute-force resistance against authentication latency and infrastructure spend. That tradeoff becomes sharper in large consumer platforms, mobile backends, and shared authentication services.
There is no universal standard for choosing exact Argon2id or scrypt parameters, so current guidance suggests benchmarking against your own workloads and revisiting values as hardware changes. If the environment includes FIPS-only constraints, regulated legacy stacks, or third-party identity platforms that cannot support modern algorithms, bcrypt may remain a temporary compromise. That does not make it ideal, only operationally necessary.
Security teams should also avoid treating password hashing as a standalone fix. Hashing protects stored passwords, but it does not compensate for poor rate limiting, weak MFA, leaked reset flows, or unsafe secret storage in adjacent systems. The broader control set should align with identity governance and secure lifecycle management, as reflected in the NIST Cybersecurity Framework 2.0 and the breach patterns documented in the Cisco Active Directory credentials breach.
In short, choose the strongest algorithm the environment can operate safely, then prove it can be tuned, monitored, and migrated without breaking production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secure credential handling and rotation around stored secrets. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control depend on protecting authentication material. |
| NIST AI RMF | Supports governance when password systems are tied to automated or adaptive security controls. |
Use AI RMF governance principles to ensure authentication controls are reviewed and accountable.
Related resources from NHI Mgmt Group
- How should security teams design identity continuity for critical applications?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams prevent code injection in modern applications?
- How should security teams prevent cross-tenant data leaks in multi-tenant apps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
