SHA-1 should not be used for anything where an attacker can choose inputs. NIST deprecated it in 2011, disallowed it for digital signatures at the end of 2013, and published a plan in December 2022 to move away from it entirely. SHA-2 and SHA-3 are the approved families.
The official timeline
The NIST hash functions project page states three facts. NIST deprecated the use of SHA-1 in 2011. It disallowed SHA-1 for digital signatures at the end of 2013. In December 2022 it published a plan to transition away from SHA-1 entirely, and the page we fetched gave no target year for finishing.
The same page lists SHA-2, from SHA-224 through SHA-512/256 in FIPS 180-4, and SHA3-224 through SHA3-512 in FIPS 202, as approved, with no expiry dates.
Where SHA-1 still hides
You rarely write SHA-1 on purpose. It shows up through defaults and old integrations.
- Legacy signature schemes in old TLS configurations. RFC 8446 keeps SHA-1 signature schemes only in a legacy list and deprecates them.
- Old certificates, internal CAs and code signing setups created years ago.
- Password storage using a plain SHA-1 hash, which is wrong for a second reason: it is a fast hash, not a password hash.
- Cache keys and deduplication that quietly became security decisions.
- HMAC-SHA-1 in older protocols. OWASP lists HMAC-SHA-1 with PBKDF2 at 1,400,000 iterations as legacy only.
- Build and package integrity checks that still publish SHA-1 sums.
Uses that need care, not panic
Not every use is equally dangerous. Using SHA-1 as a non-security fingerprint, say as a hash table key, is different from using it to prove a file is authentic. The risk grows when an attacker can influence the data being hashed and when the hash is trusted for integrity or identity.
Do not assume a use is harmless without checking who controls the input. If the answer is unclear, replace it.
How to replace it
- Search code, configuration and dependencies for SHA-1 names and identifiers, including hex strings of the SHA-1 length used as checks.
- For integrity and signatures, move to SHA-256 or stronger.
- For passwords, move to a password hashing algorithm such as Argon2id and rehash at next login.
- For protocols, check library and server configuration for allowed signature algorithms and remove SHA-1 ones.
- For stored digests you cannot recompute, keep both values during transition and verify the new one.
What can go wrong
Replacing a hash changes lengths and formats. Database columns, file names, API contracts and cache keys may all assume a 40 character digest. Test with real data and plan a migration window.
Quick check
Is SHA-1 broken for every use?
NIST disallowed it for digital signatures and plans to move away from it entirely, so treat it as unsuitable for security purposes. Non-security fingerprinting is lower risk, but still worth replacing when practical.
Should I use SHA-256 for password storage instead?
No. Fast hashes are poor password hashes. Use a purpose-built password hashing function.
Safeguard's dependency scanning lists the libraries and versions in your projects, which gives you a starting point for that search, and the free scan at gold.safeguard.sh/scan is a quick first look.
Sources
Last reviewed: 19 October 2026.
