Encryption key management is the practice of creating, storing, using, changing and retiring the keys that lock and unlock encrypted data. A key is a secret value, and anyone who holds it can read the data it protects. This article explains three terms that often appear together: KMS (key management service), HSM (hardware security module) and BYOK (bring your own key), and how they fit together, including the choice of who holds the key.

Why the key matters more than the algorithm

Strong encryption algorithms such as AES are public and have been reviewed by many researchers. What protects the data is therefore not the secrecy of the algorithm but the secrecy of the key. If the key is stolen, or stored next to the data it protects, encryption gives little protection. If the key is lost, the data cannot be recovered. Key management exists to prevent both outcomes.

The key lifecycle

NIST SP 800-57 Part 1 is NIST's general guidance on key management. It covers the security services cryptography can provide, the algorithms and key types to use, how each key type should be protected, and the key-management functions. Revision 5, published in May 2020, is the current final version. A Revision 6 initial public draft was published on 5 December 2025, and its comment period closed on 5 February 2026. As of 27 October 2026, the NIST pages we read show no final Revision 6, so treat it as a draft.

The main stages of a key's life are:

  • Generate: create the key from a strong random source, ideally inside a KMS or HSM
  • Store: keep it in a protected place, never in source code, internal documents or chat messages
  • Use: allow only named people and systems to use it, and log every use
  • Rotate: replace it on a schedule, and at once if exposure is suspected
  • Retire and destroy: stop using it, and delete it only when no data still needs it
INFOGRAPHIC
The key lifecycle
1
Generate
strong randomness, inside a KMS or HSM
2
Store
never in code or chat
3
Use
named users only, and log it
4
Rotate
on schedule, or at once if exposed
5
Retire and destroy
delete when no data needs it

KMS and HSM: how they fit together

A KMS is a system that creates keys, stores them, and controls who may use them. Applications do not hold the key. They ask the KMS to encrypt or decrypt for them. An HSM is a dedicated device built to generate and hold keys and to perform cryptographic operations inside the device, so the key does not leave it in readable form. The two work together, because many cloud KMS services keep their keys in HSMs. For example, AWS states that AWS KMS keys are protected by HSMs validated to FIPS 140-3 Security Level 3 (explained below).

Most systems use envelope encryption, which means two layers of keys. A data key encrypts the data itself. A KMS key encrypts the data key and never leaves the KMS in readable form. The KMS gives the application the data key in two forms, readable and encrypted. The application encrypts the data, discards the readable copy at once, and stores the encrypted copy next to the data. To read the data later, it sends the encrypted data key to the KMS, which decrypts it only for an authorized caller. The main key therefore stays in one well-guarded place.

INFOGRAPHIC
How envelope encryption works
01
App asks for a data key
calls the KMS
02
KMS returns two forms
readable and encrypted
03
App encrypts the data
discards the readable key
04
Later, KMS decrypts it
authorized callers only

Who holds the key: BYOK and HYOK

BYOK means the organization creates the key in its own environment, often in its own HSM, and imports it into the cloud provider's key service. Providers describe it in similar ways. AWS says that when you use imported key material you remain responsible for it while AWS KMS uses a copy. Azure Key Vault describes moving a key from an on-premises HSM so that it never exists outside an HSM in plain form, and is protected by a key held in the Azure Key Vault HSM while in transit. Note that the provider still holds a usable copy. BYOK changes who generated the key, not who can use it.

HYOK (hold your own key) goes further. The key stays outside the cloud, and the cloud service sends each encrypt or decrypt request to a key manager that the organization runs. AWS calls its version an external key store. If access to that key manager is cut off, AWS cannot use the keys, and data encrypted under them cannot be decrypted. If the key is lost for good, the data is unrecoverable. AWS itself warns that this adds operational burden and risks to availability and latency, and that for most workloads these costs exceed the perceived security benefit. It also shifts duties between customer and provider, as described in Cloud shared responsibility model.

The common choices, from least to most control and effort, are:

  • Keys owned by the provider: easiest, but the organization cannot change their policies or audit their use (this is how AWS describes its AWS owned keys, and other providers differ)
  • Customer managed keys in a cloud KMS: the organization sets the access policy, rotation and deletion, and can audit use
  • BYOK: the organization generates the key and imports it, and the provider still holds a usable copy
  • HYOK or an external key store: the key never enters the provider, and the organization runs the key manager and carries the availability risk

FIPS 140-3: what "validated" means

FIPS 140-3 is the US government standard for the security of cryptographic modules, meaning the hardware or software that performs encryption, such as an HSM. NIST lists it as published in March 2019 and effective on 22 September 2019. It refers to ISO/IEC 19790:2012, which defines four security levels, so vendors often quote a level such as Level 3.

A validation applies to one specific module, tested by a laboratory and listed in the database of the CMVP (Cryptographic Module Validation Program). When a vendor says "FIPS validated", ask for the certificate number and check that the listed module and version are the ones you actually use. CMVP says FIPS 140-3 validations stay on its Active list for 5 years. For the older FIPS 140-2, CMVP says agencies can accept validations through 21 September 2026, after which certificates move to a Historical list that allows continued use only in existing systems. That date has now passed, so check whether a product you plan to buy still relies on a FIPS 140-2 certificate.

Key management and post-quantum cryptography

Key management must also prepare for post-quantum cryptography (PQC), which means new algorithms designed to resist future quantum computers. The Revision 6 draft of SP 800-57 Part 1 adds the post-quantum algorithms, and it discusses keys used for key establishment separately from keys used for key storage. Ask your KMS and HSM vendors for a PQC roadmap and for a way to add new algorithms without replacing hardware. See What is PQC? and Crypto-agility and CBOM.

Common mistakes

  • Keeping keys in source code, config files or shared drives: anyone who can read the repository or the drive can read the key
  • Using one key for everything and never changing it: a single leak exposes all the data
  • Treating BYOK as full control: the provider still holds a usable copy of the key
  • Having no tested way to recover keys: if a key is lost or deleted, the data is gone, which matters most for imported keys and HYOK
  • Accepting "FIPS validated" without checking: the certificate must cover the module and version actually in use
  • Letting any service account call the KMS: key use needs least privilege and logging
INFOGRAPHIC
Risky key handling versus safer handling

Risky

  • Keys in code or config filesanyone who reads the code gets the key
  • One key for everythingone leak exposes all data
  • Any service account can callkey use may go unlogged

Safer

  • Keys in a KMS or HSMapps never hold the KMS key
  • Separate keys per purposeand changed on a schedule
  • Named access, every use loggedleast privilege

Start today

  • List your keys: where each key is, what it protects and who owns it
  • Move keys out of code and config files: use a KMS or an HSM-backed service instead
  • Use separate keys for separate purposes: and set a rotation schedule for the most important ones
  • Test recovery: restore from a backup using only the documented procedure
  • Restrict and log key use: named people and service accounts only, as covered in Non-human identities and service accounts
  • Choose BYOK or HYOK by requirement: write down the reason before adopting either

To see how key management fits with the rest of your security controls, try the self-assessment.

Scope and accuracy

The sources were read on 27 October 2026. The AWS and Azure pages describe those two providers only, and other providers differ in names and limits. The status of NIST SP 800-57 Part 1 Revision 6 and of FIPS 140-2 certificates can change, so confirm on csrc.nist.gov before relying on it. This article is general information and not legal or compliance advice.

References and further reading