FIPS 140-3 approved algorithms, and the ones on their way out

NIST lists the algorithms a FIPS 140-3 module may use in its approved mode on two web pages. What they approve, what is now limited to legacy use, and what NIST plans to retire by 2030.

Christopher Rule, Chief Operating Officer. Published .

NIST approves the algorithms a FIPS 140-3 module may use through two lists. Since 2023 the Cryptographic Module Validation Program (CMVP) has kept them on web pages rather than in SP 800-140C and SP 800-140D themselves, so it can change them as standards are published or withdrawn. Both were last updated on August 21, 2026.

An algorithm on the lists is not enough on its own. A module must be running in its approved mode, as its security policy describes, to count as FIPS validated, as our introduction to FIPS 140 explains.

What the lists approve

The algorithms on NIST’s two lists, as updated August 21, 2026
Use Approved Standard
Encryption AES with 128, 192 or 256-bit keys, in the modes of the SP 800-38 series, GCM among them FIPS 197, SP 800-38A to SP 800-38G
Hashing SHA-2 and SHA-3, and SHA-1 within the limits below FIPS 180-4, FIPS 202
Message authentication HMAC, CMAC, GMAC and KMAC FIPS 198-1, SP 800-38B, SP 800-38D, SP 800-185
Digital signatures RSA, ECDSA and EdDSA; the post-quantum ML-DSA and SLH-DSA; the stateful hash-based LMS and XMSS FIPS 186-5, FIPS 204, FIPS 205, SP 800-208
Key establishment Finite-field and elliptic-curve Diffie-Hellman, RSA key agreement and key transport, and the post-quantum ML-KEM SP 800-56A Rev. 3, SP 800-56B Rev. 2, FIPS 203
Key derivation The KDFs of SP 800-108 and SP 800-56C, HKDF, password-based derivation for storage, and the key schedules of TLS 1.3 and the protocols in SP 800-135 SP 800-108 Rev. 1, SP 800-56C Rev. 2, RFC 5869, SP 800-132, RFC 8446, SP 800-135 Rev. 1
Random numbers The DRBGs of SP 800-90A, entropy sources tested to SP 800-90B, and the constructions of SP 800-90C, added on June 22, 2026 SP 800-90A Rev. 1, SP 800-90B, SP 800-90C
Lightweight cryptography Ascon-AEAD128, Ascon-Hash256 and Ascon-XOF128, added in 2025 SP 800-232

MD5 and ChaCha20-Poly1305 appear on neither list.

What is now limited to legacy use

Some approved algorithms may now only process what already exists. NIST’s transition rules, SP 800-131A Rev. 2, and the lists set these limits:

  • Triple-DES: “As of January 1, 2024, three-key Triple-DES is only approved for decryption, unwrapping or CMAC verification for legacy use.” Two-key Triple-DES may not encrypt at all.
  • SHA-1: disallowed for generating digital signatures, except where NIST’s protocol-specific guidance allows it. It may still verify existing signatures, and it remains acceptable for uses other than signatures.
  • DSA: FIPS 186-5 says “DSA is no longer approved for digital signature generation.” It may still verify signatures made before that standard.
  • Short keys: keys with less than 112 bits of security strength, such as RSA under 2048 bits or ECDSA under 224 bits, may not sign, only verify existing signatures.
  • RSA key transport with PKCS #1 v1.5 padding: disallowed after December 31, 2023.

What NIST plans next

NIST announced on December 15, 2022 that “SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithms.” Its hash policy adds: “After 12/31/2030, any FIPS 140 validated cryptographic module that has SHA-1 as an approved algorithm will be moved to the historical list.” Such a module will then be where FIPS 140-2 modules are now.

A draft revision of SP 800-131A, Rev. 3, published for comment on October 21, 2024, proposes retiring ECB as a mode for confidentiality and DSA for signature generation, with a schedule for retiring SHA-1 and the 224-bit hash functions, and discusses the move from 112-bit to 128-bit security strength. It is still a draft, and Rev. 2 still applies.

The post-quantum algorithms are already on the lists: ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures. The federal deadlines for moving to them are on our post-quantum cryptography page.

What to do now

  1. For each module in your boundary, list the algorithms it uses in its approved mode, from its CMVP certificate and security policy, and check them against both lists.
  2. Replace Triple-DES encryption, SHA-1 signatures, DSA signing and RSA key transport with PKCS #1 v1.5 padding wherever they still run.
  3. Check key sizes: at least 2048-bit RSA and 224-bit elliptic curves. For new keys, plan for 128-bit strength, the next step the draft revision discusses.
  4. Find every use of SHA-1, in certificates, code signing and integrity checks as well as signatures, and plan its removal before December 31, 2030.
  5. Record anything that cannot change yet as an open risk, with the date it will.

Requirement 3.13.11 of NIST SP 800-171 asks for FIPS-validated cryptography when it protects the confidentiality of CUI, and FedRAMP’s 2026 rules call for modules with active validations, so the same checks serve defense contractors and cloud providers.

How we can help

Our cryptographic inventory finds where your systems encrypt, establish keys and sign, and the libraries underneath them, and our AFIPS model maps each one to the validated module doing the work. For how algorithms and modules relate, read Cryptographic modules vs cryptographic algorithms.

Sources

Choosing algorithms for a FIPS 140-3 system

Where does NIST list the algorithms FIPS 140-3 approves?
On two CMVP web pages that took over the lists in SP 800-140C and SP 800-140D in 2023: one for approved security functions such as ciphers, hashes and signatures, and one for approved ways to generate and establish keys. Both were last updated on August 21, 2026.
Is SHA-1 still approved?
Only in part. SP 800-131A Rev. 2 disallows it for generating digital signatures, except where NIST’s protocol-specific guidance allows it, but it may still verify existing signatures and remains acceptable for other uses. After December 31, 2030, NIST moves any validated module that has SHA-1 as an approved algorithm to the historical list.
Is an approved algorithm enough on its own?
No. A module must be running in its approved mode, as its security policy describes, to count as FIPS validated. Check each module’s CMVP certificate and security policy, not only the algorithm’s name.

Check the algorithms in your boundary