NIST SP 800-57 Part 1 Rev. 5 (key management recommendation), explained

NIST SP 800-57 Part 1 Revision 5, "Recommendation for Key Management: Part 1 – General," provides cryptographic key-management guidance covering the security services cryptography can provide, the types of keys and other cryptographic information involved, the protection each requires, the functions involved in managing keys through their lifecycle, and issues such as cryptoperiod length and algorithm/key-size selection. Per its own executive summary, "the proper management of cryptographic keys is essential to the effective use of cryptography for security. Poor key management may easily compromise strong algorithms." Authored by Elaine Barker, Revision 5 was published in May 2020, superseding Revision 4 of January 2016.

Three parts, one recommendation

The publication's abstract splits SP 800-57 into three parts: Part 1 (this document) "provides general guidance and best practices for the management of cryptographic keying material," including definitions of the security services cryptography provides and the algorithms and key types that may be employed; Part 2, "Best Practices for Key Management Organizations," addresses policy and security-planning requirements primarily for U.S. government agencies; and Part 3, "Application-Specific Key Management Guidance," addresses the key-management issues associated with currently available cryptographic implementations. Section 3 lists the security services keys support — confidentiality, data integrity, authentication, authorization, non-repudiation, and various support services — and Section 4 covers the three basic classes of approved cryptographic algorithms that use these keys: hash functions, symmetric-key algorithms, and asymmetric (public-key) algorithms.

19 cryptographic key types

Section 5.1.1 classifies cryptographic keys into 19 distinct types, distinguished by whether they're public, private, or symmetric (secret), with key-agreement keys further split into static (long-term) or ephemeral (single-transaction) variants:

1. Private signature key
2. Public signature-verification key
3. Symmetric authentication key
4. Private authentication key
5. Public authentication key
6. Symmetric data-encryption key
7. Symmetric key-wrapping key
8. Symmetric random-number-generation key
9. Symmetric master key/key-derivation key
10. Private key-transport key
11. Public key-transport key
12. Symmetric key-agreement key
13. Private static key-agreement key
14. Public static key-agreement key
15. Private ephemeral key-agreement key
16. Public ephemeral key-agreement key
17. Symmetric authorization key
18. Private authorization key
19. Public authorization key

Each type is defined by what it's used for — a key-wrapping key (sometimes called a key-encrypting key) "encrypts other keys," while a private key-transport key "decrypt[s] keys that have been encrypted with the corresponding public key." Section 6.1.1's Table 5 ties each of the 19 types to the specific protection requirements it needs (e.g., confidentiality, integrity, source/destination association), which is the practical reference point for deciding how a given key must be stored, transmitted, and sanitized at end of life — see our SP 800-88 media sanitization guide for how cryptographic erase of several of these key types (master/key-derivation keys, key-wrapping keys, data-encryption keys, key-transport keys) is used as a purge technique.

Cryptoperiods: how long should a key live?

Section 5.3 defines a cryptoperiod as "the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect." A suitably defined cryptoperiod serves several purposes at once: it limits the amount of plaintext/ciphertext available for cryptanalysis, limits the exposure from a single key's compromise, limits use of an algorithm to its estimated effective lifetime, limits the window available to penetrate the mechanisms protecting a key, and limits the time available for computationally intensive cryptanalysis attacks.

The publication lists over a dozen factors that should inform cryptoperiod selection, including: the embodiment of the cryptographic mechanism (e.g., a FIPS 140 hardware module vs. software on a PC), the operating environment, personnel turnover, data volume and transaction count, the security life of the protected data, the re-keying method and process used, the number of nodes sharing a key, and "the threat to the information from new and disruptive technologies (e.g., quantum computers)." For asymmetric key pairs, each key of the pair gets its own cryptoperiod: the key that applies protection (e.g., generates a signature) has an originator-usage period, while the key that processes protected information (e.g., verifies that signature) has a recipient-usage period — the recipient-usage period can extend beyond the originator-usage period, since verifying old signatures or decrypting old data can remain valid long after the originating key stopped being used to create new protections.

Six key states, four management phases

Section 7 defines six states a key can occupy over its life: pre-activation (generated but not yet authorized for use, except for proof-of-possession), active (authorized to apply and/or process cryptographic protection), suspended (temporarily not to be used, e.g., pending investigation of a suspected compromise), deactivated (no longer used to apply new protection, though it may still process previously protected information), compromised (integrity or confidentiality is suspect — triggers revocation), and destroyed. Section 8 groups the functions that move a key between these states into four key-management phases: pre-operational (registration, initialization, and key establishment — generating or distributing the key), operational (normal storage, continuity-of-operations/backup, and key-change functions during active use), post-operational (archive, de-registration, destruction and revocation functions once a key leaves active service), and destroyed.

Algorithm and key-size strength: what's still adequate

Section 5.6.1 gives estimated maximum security strengths, in bits, for the commonly used strength levels of 80, 112, 128, 192, and 256 bits — and states plainly that "a security strength of 80 bits is no longer considered adequate." Table 2 maps each strength level to comparable symmetric and asymmetric algorithms/key sizes:

Security strength	Symmetric algorithm	FFC (DSA/DH/MQV)	IFC / RSA (k)	ECC (f)
≤ 80 bits	2TDEA	L=1024, N=160	k=1024	f=160–223
112 bits	3TDEA (deprecated through 2023)	L=2048, N=224	k=2048	f=224–255
128 bits	AES-128	L=3072, N=256	k=3072	f=256–383
192 bits	AES-192	L=7680, N=384	k=7680	f=384–511
256 bits	AES-256	L=15360, N=512	k=15360	f=512+

The publication flags 3TDEA's 112-bit strength as deprecated through 2023 per SP 800-131A, after which it is "disallowed for applying cryptographic protection" on new data (decrypting/verifying already-protected data with it remains a risk-acceptance decision, not a prohibition). Separately, the publication carries an explicit quantum-computing caveat: once large-scale quantum computers exist, they will threaten the security of the approved public-key (asymmetric) algorithms specifically — digital-signature schemes and Diffie-Hellman/MQV/RSA key-establishment schemes among them — and states that, as of this revision, "NIST was undergoing a process to select post-quantum cryptographic algorithms for standardization," directing readers to NIST's post-quantum cryptography project page for status.

A workable starting point

1. Name the key type before choosing its protection. The 19 key types aren't an academic taxonomy — Table 5's protection requirements (and therefore storage, access-control and sanitization decisions) differ by type, so misidentifying a key-wrapping key as a data-encryption key, for instance, can lead to the wrong safeguard.
2. Set the cryptoperiod from risk, not convention. The publication explicitly rejects "an arbitrary time period" as the basis for a cryptoperiod — weigh the consequence-of-exposure factors (sensitivity, criticality, cost of recovery) alongside the operational factors (re-keying cost, personnel turnover, threat landscape).
3. Track asymmetric key pairs' two cryptoperiods separately. A signature-verification key's recipient-usage period legitimately outlives its signing key's originator-usage period — conflating the two risks destroying a verification key while old signatures still need checking.
4. Retire 80-bit and (by 2023) 3TDEA-112-bit combinations. If a legacy system still negotiates 2TDEA or similar ≤80-bit strength, treat it as a finding, not a baseline — the publication is explicit that this strength "is no longer considered adequate."
5. Record every state transition. Sections 7 and 8 both tie state changes (active → compromised, active → destroyed, etc.) to a documentation requirement — the six-state model is only useful as an audit trail if transitions are actually logged when they happen.

SoftWSP's firmware and device security assessments document the cryptographic key inventory, key-type classification, and state/lifecycle evidence that an SP 800-57-aligned key management program — and the cryptographic-erase sanitization it enables — depends on: see Device & Firmware Security.

This guide summarises NIST SP 800-57 Part 1 Revision 5 (May 2020) and its publication page; it is not a substitute for the full text and does not constitute compliance or legal advice.