United States (federal) · federal standard
SHA-256 / FIPS 180-4: what it requires, and the records to keep
FIPS 180-4 specifies the approved secure hash algorithms, including SHA-256, which turns any input into a fixed 256-bit digest so that any change to the input produces a different value. It underpins digital signatures, file integrity checks, content addressing and Merkle trees used in software and AI provenance.
01 / What it requires
What SHA-256 / FIPS 180-4 requires
Federal agencies and vendors implementing approved hash functions; used worldwide in signatures, integrity checks and provenance records.
- 01Use a FIPS-approved hash algorithm (SHA-2 family; SHA-3 is in FIPS 202) where federal rules require one.
- 02Compute digests exactly as specified, including message padding and parsing into 512-bit blocks for SHA-256.
- 03Do not use SHA-1 for new applications; NIST plans to remove it by December 31, 2030.
- 04Use CAVP-validated implementations inside validated cryptographic modules for federal systems.
02 / AI work
Where it touches AI work
Hashing model weights, datasets, prompts and outputs with SHA-256 lets a third party check that an AI artifact is the one that was tested. The standard says nothing about AI specifically.
03 / Dates
The dates that matter
Previous FIPS 180-4 version published
Current FIPS 180-4 published
NIST announces SHA-1 phase-out by end of 2030
NIST decides to revise FIPS 180-4 and remove SHA-1
04 / Enforcement
Who enforces it
None directly; enforced through federal procurement, CMVP/CAVP validation and system authorization.
05 / Records
Records an organisation keeps
What an auditor or an inquiry usually asks to see. Your obligations depend on your role and your facts.
- 01Recorded SHA-256 digests of released artifacts
- 02CAVP algorithm validation certificate for the implementation
- 03Signed manifests or Merkle roots binding digests together
Optional evidence · where Planisphere fits
Keep a record anyone can check
When your team meets a duty, Planisphere can seal the event it reports as a receipt.
A disclosure shown, a review signed, a model change approved: the event your system reports.
The event becomes a sealed receipt, dated and attributed to whoever is signed in.
Paste the receipt into Verify. No account or key.
A record supports your compliance evidence process. It is not a legal finding or a certification. Systems that call Planisphere's gate API can also hold or refuse an action before it runs.
QUESTIONS
The questions that come next
How does SHA-256 pinning make an AI audit record tamper-evident?+
SHA-256, specified in FIPS 180-4, turns any input into a fixed 256-bit digest, and changing even one bit of the input produces a different digest. Recording the digest of each artifact, such as model weights, the test set and the results, lets anyone recompute the hashes later and see whether a file changed. Combining the digests into a signed manifest or Merkle root extends the check to the whole record. Because finding two inputs with the same SHA-256 digest is computationally infeasible, a match shows the files are the ones originally recorded. Read the full answer
SOURCES
Go back to the source
NIST CSRC
CHANGE LOG
What changed, and when
Rebuilt from primary sources; facts checked on this date.
Related: SHA-256 / FIPS 180-4 vs FIPS 140-3 · SHA-256 / FIPS 180-4 for defense AI workflows · NIST AI RMF · OMB M-25-21/22 · DoW RAI S&IP · EO 14179 · FIPS 140-3 · NIST SP 800-53 Rev. 5