The common mistake is treating bcrypt as if age alone makes it sufficient. In practice, weak cost settings, the 72-byte input cap, and unsafe pre-hashing patterns create avoidable exposure. Legacy compatibility may justify bcrypt, but only with explicit controls and a plan to revisit the configuration over time.
Why This Matters for Security Teams
Bcrypt is still useful in legacy estates, but the mistake is assuming “still common” means “still safe by default.” Weak work factors, inconsistent implementation, and old application constraints can turn a respectable algorithm into a brittle control. The practical risk is not just password cracking speed, but the way legacy code often stores passwords, hashes, and salts in patterns that make migration harder and incident response slower.
Teams also overestimate how much security they get from “just hashing it.” If the password policy allows long passphrases, bcrypt’s 72-byte input limit can silently truncate material, and if developers pre-hash incorrectly, they can lose the benefits of bcrypt’s adaptive cost model. Current guidance on identity hygiene and secret handling still points back to lifecycle discipline, not algorithm nostalgia, as reflected in the Ultimate Guide to NHIs and the broader control emphasis in the NIST Cybersecurity Framework 2.0.
In practice, many security teams discover bcrypt weaknesses only after a migration, outage, or cracking exercise exposes how much technical debt has been hiding in plain sight.
How It Works in Practice
The right way to think about bcrypt in a legacy system is as a bounded compromise, not a permanent answer. Security teams should first identify where bcrypt is used, which cost factor is deployed, whether salts are unique, and whether the implementation handles input length safely. If passwords are pre-hashed before bcrypt, the design should be reviewed carefully, because pre-hashing can be legitimate only when it is done consistently and with full awareness of what is being preserved or lost. The Ultimate Guide to NHIs is a useful reminder that identity controls age poorly when they are not actively managed, rotated, and validated.
For operational review, align the migration plan with established identity and resilience practices from the NIST Cybersecurity Framework 2.0 and treat password storage as part of the larger protect-and-recover cycle. In practical terms, that means:
- confirming the current bcrypt cost factor is still computationally meaningful for your threat model;
- testing whether any user input exceeds the 72-byte limit and is being truncated;
- checking for unsafe pre-hashing, especially when the pre-hash is deterministic and unsalted;
- ensuring salts are unique per password and stored correctly;
- planning a staged move to stronger settings or a different password-hashing scheme where the platform allows it.
For stronger policy alignment, use NIST Cybersecurity Framework 2.0 to justify owner assignment, change control, and verification after any configuration change. These controls tend to break down when the application stack cannot be redeployed safely because the password store, authentication logic, and user directory are tightly coupled.
Common Variations and Edge Cases
Tighter password-handling controls often increase migration effort, so organisations have to balance risk reduction against downtime, user lockout risk, and development capacity. That tradeoff is real, especially in older applications where a hashing change touches schema, login flow, password reset logic, and integrations at once.
One common edge case is a legacy system that cannot switch hash algorithms immediately. In that environment, the best practice is evolving rather than fixed: keep bcrypt temporarily, raise the cost factor where performance permits, and create a rehash-on-login path so active accounts gradually move to better settings. Another edge case is mixed credential stores, where some accounts were created with one pre-hash pattern and others with another. That makes security reviews harder because the visible hash may not reflect the actual input handling history. The operational lesson is to inventory the full chain, not just the final stored hash.
Guidance on password hashing is also clearer than consensus on migration timing. There is no universal standard for when every bcrypt deployment must be replaced, but there is strong agreement that legacy convenience should not excuse weak cost settings, silent truncation, or undocumented preprocessing. The Ultimate Guide to NHIs reinforces the broader point: identity controls must be observable and revocable, not simply inherited from the past.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Password hashing is a data security control and needs lifecycle review. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy credential handling often overlaps with poor secret governance. |
| NIST AI RMF | Governance discipline applies when legacy auth changes affect risk and accountability. |
Inventory stored secrets and password hashes, then remove weak or undocumented handling paths.
Related resources from NHI Mgmt Group
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
