NIST SP 800-57 and 800-131A Cryptographic Key Management and Algorithm Transition Guide: key lengths, statuses and the 2030 and 2035 deadlines

Most organisations cannot say which of their keys and algorithms will stop being acceptable to NIST in 2030, or which will be disallowed in 2035. Two NIST documents answer that question together: SP 800-57 sets out how keys should be managed across their life, and SP 800-131A says which algorithms and key lengths are acceptable, deprecated, disallowed or allowed only for legacy use, and until when. This guide explains how the two fit, what the current final texts say, what the October 2024 draft of SP 800-131A Rev. 3 and the companion draft NIST IR 8547 propose, and how to turn them into a key length policy you can enforce. It is written for cryptography and PKI owners, security architects, and the people who write the organisation's encryption standard. Status was checked on csrc.nist.gov on 27 October 2026.

Key takeaways

• Two documents, one policy: SP 800-57 tells you how to manage keys (types, states, cryptoperiods, protection, policy); SP 800-131A tells you which algorithms and key lengths you may still use, with dates.
• Rev. 2 is still the final 800-131A (March 2019); Rev. 3 has been an initial public draft since 21 October 2024, so treat its dates as proposed, not settled.
• 112-bit security is on a clock: the Rev. 3 draft keeps 112-bit RSA and ECDSA signature generation acceptable through 2030 and deprecated after it, and moves block ciphers and hash collision resistance to 128-bit from 1 January 2031.
• 2035 comes from NIST IR 8547, not from 800-131A: the draft report proposes disallowing quantum-vulnerable RSA, ECDSA, EdDSA and Diffie-Hellman schemes after 2035, at every security strength.
• Most of the keys at risk belong to machines: TLS server keys, workload certificates, SSH host and user keys, token signing keys and code signing keys are where 2048-bit RSA and P-256 live, and where the inventory work starts.

What it is and who it applies to

SP 800-57 "Recommendation for Key Management" is a three-part series. SP 800-131A "Transitioning the Use of Cryptographic Algorithms and Key Lengths" builds on Part 1 and gives more specific guidance on moving to stronger keys and more robust algorithms. Both are written for US federal agencies and the systems they buy, but they are the reference most private sector cryptography standards, FIPS 140-3 validated products and many sector rules point to. If you sell to the US government, operate a FedRAMP system or follow NIST SP 800-53, they apply to you directly through SC-12 and SC-13. Everyone else uses them as the most widely cited public answer to "how long is long enough".

Because Rev. 3 and IR 8547 are drafts, write your policy so that the dates sit in one place (a table in your cryptographic standard) and can be changed when NIST finalises them, rather than scattering them across system designs.

Structure and key requirements

SP 800-57 Part 1: managing keys over their life

• Key types: Part 1 lists 19 key types, from private and public signature keys and authentication keys to symmetric data encryption keys, key wrapping keys, random number generation keys, master keys and key agreement keys. Each has its own protection needs and cryptoperiod.
• One purpose per key: Part 1 states that a single key shall be used for only one purpose, for example not using the same key for encryption and signing. This rule is broken surprisingly often in token signing and service-to-service designs.
• Key states: pre-activation, active, suspended, deactivated, compromised and destroyed. Your key inventory should record the state, not just whether a key exists.
• Key management phases: Section 8 groups functions into pre-operational, operational, post-operational and destroyed phases, covering generation, registration, distribution, use, archive, recovery, revocation and destruction.
• Cryptoperiods: Part 1 recommends a cryptoperiod per key type, split into an originator usage period (when the key may apply protection) and a recipient usage period (when it may still process protected data). Set yours from the Part 1 table and your own risk, and record the reason for any longer period.
• Security strength: Part 1 expresses every algorithm's strength in bits so you can compare a symmetric key with an RSA modulus or an elliptic curve.

The practical point: a 2048-bit RSA key, still the default in many certificate requests and SSH key generators, is a 112-bit key. A P-256 key is a 128-bit key. That difference decides which side of the 2030 line a system falls on.

SP 800-131A: the four statuses

• Acceptable: no security risk currently known when used as guided.
• Deprecated: may be used, but the user must accept some security risk.
• Legacy use: may be used only to process already protected information, such as decrypting old ciphertext or verifying an old signature.
• Disallowed: no longer allowed for applying cryptographic protection.

Rev. 2 already requires at least 112 bits of security for applying protection, disallows two-key TDEA, disallowed three-key TDEA encryption after 31 December 2023, disallows SHA-1 for digital signature generation (except where NIST protocol guidance allows it), and disallowed PKCS #1 v1.5 padding for RSA key transport after 31 December 2023.

What the Rev. 3 draft and IR 8547 propose

Two details matter for planning. First, the Rev. 3 draft keeps the 128-bit move for block ciphers and hash collision resistance on 1 January 2031, but for signatures and key establishment it proposes going straight to quantum-resistant algorithms rather than to 3072-bit RSA. Second, the 2035 dates appear only in IR 8547; the Rev. 3 draft says NIST is developing that schedule. Quote the right document for each date in your policy. IR 8547 also notes that application-specific guidance may require earlier migration of key establishment. See the Post-Quantum Cryptography Migration Guide and the ML-KEM Guide.

Identity and NHI requirements

The keys these documents govern are overwhelmingly held by machines. Treat each one as a non-human identity credential with an owner, a purpose, a strength, a cryptoperiod and a replacement plan.

• Ownership: every key needs a named human owner and the identity of the workload that uses it. Part 2 calls for this in the key management policy and practice statement.
• Separation of duties: keep key administrators apart from key users, and require dual control for export and destruction of high-value keys. See the Cryptographic Key Management Guide.
• Cryptographic module authentication: SP 800-53 IA-7 requires authentication to cryptographic modules; service accounts that call an HSM or KMS are in scope. See the Post-Quantum Migration for NHIs Guide.

Implementation steps

1. Write the policy table first. One table in your cryptographic standard: algorithm, minimum key size, status now, status after 31 December 2030, status after 2035, and the NIST source for each date (Rev. 2 final, Rev. 3 draft, IR 8547 draft). Mark draft dates as provisional.
2. Build the inventory. Discover keys and certificates from certificate transparency logs, internal CAs, KMS and HSM audit logs, TLS scans, SSH key scans, code repositories and secret stores. Record algorithm, key size, owner, cryptoperiod and dependent systems. See the Cryptographic Inventory and CBOM Guide.
3. Stop issuing what is already disallowed. Block TDEA encryption, SHA-1 signatures, DSA signature generation and RSA keys under 2048 bits at the CA and in key generation templates. Check PKCS #1 v1.5 RSA key transport in older protocols.
4. Change the defaults. Set new certificate and SSH key templates to P-256 or higher (or RSA-3072 where ECC is not supported), and HMAC to SHA-256 or higher. Changing defaults costs little and removes most future 2030 work.
5. Test in a pilot ring. Roll the new defaults to one environment, watch handshake failures and client compatibility (older appliances, embedded clients, partner integrations), then widen. Keep the previous templates available for rollback, with an expiry date.
6. Plan the post-quantum step. For key establishment, follow the hybrid route where your protocols support it; for signatures, track ML-DSA and SLH-DSA support in your CA, HSM and libraries. See the Crypto-Agility Guide.
7. Set exception rules. A deprecated algorithm may be used only with a recorded risk acceptance, an owner, a compensating control and an end date before the disallowance date.
8. Revisit when NIST finalises. Put a review in the calendar for when SP 800-131A Rev. 3 and IR 8547 are finalised, and update the policy table rather than individual designs.

Evidence and assessment

Assessors testing SC-12 and SC-13 will look for a documented policy, evidence that it is applied and evidence that exceptions are controlled. Useful evidence:

• Key management policy and practice statement: the documents Part 2 describes, with roles, approved algorithms, cryptoperiods and procedures.
• Inventory export: keys and certificates with algorithm, size, state and owner, showing coverage of all environments.
• CA and KMS configuration: templates and policies that enforce minimum key sizes and block disallowed algorithms.
• Scan results: TLS and SSH scans showing negotiated algorithms, before and after changes.
• Exception register: each deprecated algorithm still in use, with risk acceptance and end date.
• FIPS 140-3 certificates: for the cryptographic modules in use, where your rules require validated modules. See the Linux System-Wide Crypto Policies and FIPS Mode Guide.

Metrics

• Percentage of keys and certificates in the inventory with a named owner and recorded cryptoperiod.
• Number of keys using disallowed algorithms (target zero) and deprecated algorithms (trending down).
• Percentage of newly issued certificates and SSH keys at 128-bit strength or higher.
• Number of open exceptions and how many pass their end date.
• Percentage of critical systems with a tested algorithm change (crypto-agility) procedure.

Mapping to other frameworks

For the wider control set, see the NIST SP 800-53 Guide.

Common pitfalls

• Quoting a draft date as a rule: policies that say "NIST disallows RSA in 2035" without saying the source is a draft report invite challenge and need rewriting when the final text changes.
• Treating RSA-2048 as safe until 2035: under the Rev. 3 draft, 112-bit signatures and key establishment are deprecated from 2031, five years earlier.
• Forgetting verification lifetimes: signatures on firmware, documents and logs must verify long after they are made. Legacy use allows verification, but only if your tools still support the old algorithm.
• Inventory limited to certificates: SSH keys, HMAC secrets, token signing keys and keys embedded in applications are left out, and they are where SHA-1 and 2048-bit RSA linger. Breaches such as the Microsoft Storm-0558 key breach show what happens when a signing key outlives its cryptoperiod: a 2016 consumer token signing key, due for retirement in 2021, was still trusted in 2023.
• No owner, no rotation: keys without owners exceed their cryptoperiod and are never re-keyed when algorithms change.
• One key, many purposes: the same key used for TLS and signing, or for several tenants, breaks the single purpose rule and makes rotation an outage.

Practitioner checklist

• Record in your cryptographic standard which NIST document and version each algorithm date comes from, and whether it is final or draft.
• Block TDEA encryption, SHA-1 signatures, DSA signature generation and keys under 112-bit strength now.
• Set certificate, SSH and token signing defaults to 128-bit strength or higher.
• Inventory every key and certificate with owner, algorithm, size, state and cryptoperiod, including machine credentials.
• Find SHA-1 and SHA-224 in HMAC, DRBG and non-signature uses before the proposed 2030 cut-off.
• Run a pilot ring for new defaults, with rollback templates that expire.
• Keep an exception register with end dates before the disallowance dates.
• Plan post-quantum key establishment and signatures for systems whose keys or data must remain protected past 2035.
• Review the policy when SP 800-131A Rev. 3 and NIST IR 8547 are finalised.

Standards and references

• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1, General
• NIST: SP 800-57 Part 2 Rev. 1, Best Practices for Key Management Organizations
• NIST: SP 800-57 Part 3 Rev. 1, Application-Specific Key Management Guidance
• NIST: SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST: SP 800-131A Rev. 3 Initial Public Draft
• NIST: IR 8547 Initial Public Draft, Transition to Post-Quantum Cryptography Standards
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Post-Quantum Cryptography Migration Guide · Cryptographic Inventory and CBOM Guide · Crypto-Agility Guide · Machine Identity, PKI and Certificate Lifecycle Guide