Key Management – Recommendations and Best Practices

Key management is the set of practices governing how cryptographic keys are generated, stored, rotated, and retired, and it is the single point of failure for every encryption system built on top of it. It matters because a compromised or mismanaged key defeats the encryption protecting it entirely, regardless of algorithm strength. Recommended action: follow NIST SP 800-57 Part 1 Revision 5’s current cryptoperiod and algorithm guidance, assign one key per purpose, and plan now for Revision 6’s forthcoming changes.

Published: September 2020. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Key Management Team.

For a foundational definition of key management, see our Education Center article What is Key Management? How does Key Management work?. For how these practices extend across cloud providers, see What is Multi-Cloud Key Management? and What is Hybrid Key Management System (KMS)?. For cloud-specific implementations, see AWS KMS Vs Azure Key Vault Vs GCP KMS, Google Cloud Platform’s Data Encryption Tools, and Google Cloud Security – Key Management Services.

What Is Key Management and Why Does It Matter?

Key management is the process of putting standards in place to govern the creation, exchange, storage, deletion, and rotation of cryptographic keys within an organization, along with who is permitted to access them. Cryptographic keys do everything from encryption and decryption to user authentication, so a compromised key can let an attacker decrypt sensitive data, authenticate as a privileged user, or reach other classified resources. Proper key management is what keeps that risk contained.

How Do Symmetric and Asymmetric Key Systems Compare?

Symmetric keys generally protect data-at-rest and asymmetric key pairs generally protect data-in-motion, because symmetric encryption is fast enough for repeated access to stored data, while asymmetric encryption supports secure exchange between parties without a pre-shared secret.

System	Typical use	Why
Symmetric keys	Data-at-rest (databases, storage)	Fast and efficient for repeated encrypt/decrypt operations by the same party.
Asymmetric key pairs	Data-in-motion (TLS, digital signatures, key exchange)	Lets two parties communicate securely without having shared a secret in advance.

A typical symmetric-key request flow works as follows:

1. A user contacts the storage system (a database or object store) and requests encrypted data.
2. The storage system requests the data encryption key (DEK) from the key manager API, which verifies the certificates of both the key manager API and the key manager itself.
3. A secure TLS connection is established, and the key manager uses a key encryption key (KEK) to decrypt the DEK, which is returned through the key manager API.
4. The data is decrypted and returned to the user as plaintext.

A typical asymmetric-key exchange works differently, since it relies on key pairs rather than a single shared key:

1. The sender and recipient validate each other’s certificates through a private certificate authority (CA) or an external validation authority (VA).
2. The recipient sends their public key to the sender, who encrypts the data with a one-time symmetric key, itself encrypted with the recipient’s public key, and sends both to the recipient.
3. The recipient decrypts the one-time symmetric key with their own private key, then uses it to decrypt the data.

What Does NIST Currently Recommend for Key Management?

NIST SP 800-57 Part 1 Revision 5, published in 2020, is the current, official key-management standard, written to secure sensitive but unclassified federal information and widely treated as a best-practice baseline for non-government organizations as well. A subsequent Initial Public Draft of Revision 6 was released for public comment, with the comment period closing February 5, 2026; as of this writing, Revision 6 has not been finalized, so Revision 5 remains the standard to cite and follow. Organizations building a key-management program today should track NIST’s Key Management Guidelines project page for when Revision 6 is finalized, rather than adopting draft recommendations as settled guidance.

Which Cryptographic Algorithms Does NIST Approve?

NIST Standards approve a specific, limited set of algorithms rather than every symmetric or asymmetric option in use.

• Block cipher-based symmetric algorithms such as AES, which iterate a series of bits (blocks) through operations like XOR across multiple rounds to produce ciphertext.
• Hash function-based algorithms such as SHA-256, which use one-way functions to generate hash data (SHA-1 is deprecated for most security uses and should not be selected for new systems).
• Asymmetric algorithms generally, with the requirement that the private key stay under the sole control of the entity that owns the key pair.
• Random Bit Generators (RBGs), used for key material generation, and cryptographic hash functions, which do not themselves use cryptographic keys. Full lists of approved algorithms appear in FIPS 180 (hash functions) and SP 800-90 (RBGs).

How Should Cryptoperiods Be Set?

A cryptoperiod is the span of time a key may be used for its intended purpose before it must be renewed or, preferably, replaced with a new key. NIST’s core recommendation is that a unique key be created for every distinct purpose; a key used for authentication should never also be used for decryption. For asymmetric key pairs, each key in the pair has its own cryptoperiod: the originator-usage period governs the key used to create a digital signature, and the recipient-usage period governs the corresponding verification key. NIST recommends both periods start at the same time, but the recipient-usage period may extend beyond the originator-usage period, never the reverse, since a signature must remain verifiable after the signing key retires.

How Does Key Management Change in Multi-Cloud and Hybrid Environments?

NIST’s guidance is deliberately vendor-neutral, but multi-cloud and hybrid deployments add practical questions NIST does not answer directly: which cloud’s native KMS holds the authoritative key, how key hierarchies map across providers that do not share a root of trust, and how access policies stay consistent when the same data moves between environments. See What is Multi-Cloud Key Management? and What is Hybrid Key Management System (KMS)? for how those questions get answered in practice, and our AWS KMS Vs Azure Key Vault Vs GCP KMS comparison for how the three major clouds differ on rotation, IAM, and cost specifically.

What Are the Limitations of Following NIST Guidance Alone?

• NIST SP 800-57 sets cryptoperiod and algorithm recommendations, but it does not prescribe the specific IAM, logging, or cost tradeoffs of any particular cloud KMS implementation.
• Revision 6 is still in draft; organizations that adopt draft-stage recommendations as final risk having to revise their key-management program again once Revision 6 is published.
• NIST guidance does not address multi-cloud key hierarchy or cross-provider access-policy consistency, which have to be designed separately.
• Following NIST Standards addresses algorithm and cryptoperiod selection; it does not by itself cover operational practices like rotation automation or incident response for a compromised key.

Decision Checklist: Applying NIST Key Management Recommendations

1. Match each key to one purpose only; never reuse a key across authentication and decryption.
2. Select only NIST-approved algorithms (AES for symmetric, SHA-256 or stronger for hashing) for any new system.
3. Set a documented cryptoperiod per key, with separate originator- and recipient-usage periods for asymmetric pairs.
4. Cite Revision 5 as the current standard today, and assign someone to monitor Revision 6’s finalization rather than ignoring it.
5. Extend NIST’s baseline with cloud-specific IAM, logging, and rotation practices for any multi-cloud or hybrid deployment.

What Would Encryption Consulting Recommend?

Most organizations we assess have a key-management policy on paper that does not match what is actually deployed, often because it still references a superseded NIST revision or was never updated for a multi-cloud footprint. Encryption Consulting’s Cloud Key Management services benchmark your current key-management practices against NIST SP 800-57 Part 1 Revision 5, design cryptoperiods and access separation for your actual environment, and our HSM-as-a-Service offering gives you hardware-backed key custody without operating HSMs directly.

Frequently Asked Questions

Is NIST SP 800-57 Part 1 Revision 6 the current standard now?

No. Revision 6 is still an initial public draft; its comment period closed February 5, 2026, but it has not been finalized. Revision 5, published in 2020, remains the current official standard.

What is a cryptoperiod?

A cryptoperiod is the length of time a specific key may be used for its intended purpose before it should be renewed or, preferably, replaced with a new key.

Should the same key ever be used for both authentication and decryption?

No. NIST recommends a unique key for every distinct purpose; using one key for multiple purposes increases the impact if that single key is compromised.

Why do asymmetric key pairs have two different cryptoperiods?

The originator-usage period covers the signing key, while the recipient-usage period covers the verification side; the recipient-usage period can extend beyond the originator-usage period so a signature can still be verified after the signing key itself has retired.

Does NIST guidance cover multi-cloud key management specifically?

Not directly. NIST SP 800-57 sets vendor-neutral algorithm and cryptoperiod guidance; the specific questions of cross-cloud key hierarchy and access-policy consistency have to be addressed through hybrid and multi-cloud key management design on top of that baseline.

Need help benchmarking your key-management program against current NIST guidance? Talk to Encryption Consulting’s Cloud Key Management team.

References

NIST Key Management Guidelines project page – csrc.nist.gov

NIST SP 800-57 Part 1 Revision 5 (final publication) – csrc.nist.gov