Cybersecurity glossary
What is a Key Management Service (KMS)?
Learn what a Key Management Service (KMS) is, how cloud KMS protects encryption keys, how envelope encryption works, how IAM policies authorize key use, and when to choose KMS or HSM.
Definition
A Key Management Service (KMS) is a managed cryptographic key service that creates, stores, protects, rotates, authorizes, and audits keys used for encryption, decryption, signing, verification, and key wrapping, usually through cloud APIs backed by hardened key custody infrastructure.
Why KMS exists
Application teams need encryption keys everywhere: databases, object stores, queues, backups, secrets, logs, tokens, and signing workflows. Keeping those keys in config files or local disks makes them too easy to copy, forget, and misuse.
A Key Management Service (KMS) centralizes key custody behind managed APIs. Applications request cryptographic operations, cloud services integrate with those keys, and security teams get policy, rotation, and audit controls around who used which key and when.
What cloud KMS provides
Cloud KMS turns key management into a service boundary rather than a pile of application secrets. It does not remove the need for good access control, but it gives organizations one place to govern high-impact key actions.
Managed key custody
Keys are generated, stored, versioned, and protected in provider-managed infrastructure, often backed by validated cryptographic modules.
Policy-based use
IAM roles, key policies, grants, conditions, and service identities decide who can encrypt, decrypt, sign, rotate, disable, or administer keys.
Envelope encryption
KMS protects data encryption keys so large files and records can be encrypted efficiently outside the KMS while key use remains controlled.
Audit and lifecycle
Key creation, use, policy edits, rotation, deletion scheduling, and failed authorization attempts can feed logs, alerts, and compliance evidence.
How envelope encryption with KMS works
KMS APIs are not usually used to encrypt large objects directly. Instead, they protect the keys that encrypt the objects.
Create or select a KMS key
Security or platform teams define the key, region, usage type, administrators, allowed services, and rotation policy.
Generate a data key
The application asks KMS for a fresh data encryption key, receiving a plaintext copy for immediate use and an encrypted copy for storage.
Encrypt data locally
The application uses the plaintext data key with a suitable algorithm such as AES-GCM, then erases the plaintext key from memory as soon as practical.
Store ciphertext and wrapped key
The encrypted data and encrypted data key are stored together, while the KMS master or wrapping key stays inside the managed key service.
Authorize decryption
When data is needed, IAM and key policy checks decide whether the caller may unwrap the data key.
Audit every sensitive step
Encrypt, decrypt, unwrap, policy, rotation, disable, and deletion events should be monitored for misuse and operational mistakes.
KMS vs HSM vs software keys
KMS, HSM, and software key stores solve related but different problems. The right choice depends on custody requirements, integration needs, regulatory commitments, and operational maturity.
| Option | Best fit | Tradeoff |
|---|---|---|
| Cloud KMS | Cloud-native encryption at rest, envelope encryption, customer-managed keys, service integrations, and centralized audit. | Less direct control over low-level HSM behavior, key ceremonies, and specialized cryptographic interfaces. |
| Cloud HSM | Dedicated HSM partitions, custom PKI, payment workflows, certificate authority keys, and PKCS #11 or JCE integrations. | More work for clustering, backup, client libraries, availability, quorum, and operational procedures. |
| Self-managed HSM | On-premises roots of trust, offline root keys, strict physical custody, and environments with direct hardware ownership requirements. | Requires hardware lifecycle management, secure facilities, ceremonies, disaster recovery, and trained operators. |
| Software key store | Development, low-risk internal tools, ephemeral test keys, or workloads without strong key custody requirements. | Plaintext key extraction risk is much higher if hosts, images, backups, or administrator accounts are compromised. |
IAM authorization to keys
KMS access control should separate two powers: managing a key and using a key. An administrator may create keys, set policy, enable rotation, and schedule deletion without being allowed to decrypt production data. A workload identity may decrypt for one application path without being allowed to change the key policy.
Useful policies are narrow and context-aware. Bind keys to specific services, projects, accounts, regions, tags, tenants, encryption contexts, or request conditions where the provider supports them. Alert on broad principals, wildcard permissions, cross-account grants, disabled logging, sudden decrypt spikes, and policy changes near sensitive keys.
KMS implementation checklist
- Classify keys by purpose, owner, environment, tenant, region, data sensitivity, and recovery requirements.
- Use separate KMS keys for materially different blast radii instead of sharing one organization-wide key.
- Prefer envelope encryption for large data, high-volume workloads, and application-level encryption.
- Separate key administrators from key users, and review IAM grants as part of normal access reviews.
- Enable automatic rotation where it fits, and document manual rotation for asymmetric, imported, or externally managed keys.
- Monitor decrypt volume, failed authorization, key disablement, deletion scheduling, policy edits, and unusual cross-service use.
- Test backup, restore, region failover, and key deletion recovery windows before a real outage.
- Keep plaintext data keys short-lived in memory and never write them to logs, traces, crash dumps, or queues.
Rotation and lifecycle pitfalls
Key rotation is not just clicking "rotate." Symmetric KMS keys often keep old key versions available for decryption while new encrypt operations use the latest version. That reduces outage risk, but it also means old ciphertext may remain protected by old versions until data is re-encrypted or naturally rewritten.
Asymmetric keys, imported key material, externally held keys, and signing keys often need more explicit migration plans. Consumers may need new public keys, certificates, trust bundles, signatures, or wrapped data keys before the previous key can be disabled. Deletion should always have a waiting period and a tested recovery path.
The practical takeaway
A Key Management Service (KMS) is the practical control plane for cloud encryption keys: it provides managed custody, IAM authorization, envelope encryption, rotation workflows, and audit logs. Use it for most application and storage encryption, choose HSMs when direct custody or specialized crypto control is required, and treat key policy as production security code.
Related security terms
Hardware Security Module (HSM)
A tamper-resistant cryptographic boundary often used beneath or alongside managed KMS offerings.
Encryption at Rest
Stored-data protection that commonly depends on KMS-managed wrapping keys.
Key Rotation
The process of replacing cryptographic keys while keeping protected systems available.
Advanced Encryption Standard (AES)
The symmetric cipher often used for data encryption keys in envelope encryption.
Asymmetric Cryptography
Public-key cryptography that KMS products may support for signing, verification, and encryption.
Frequently asked questions
What is a Key Management Service in simple terms?
A KMS is a managed service that keeps encryption keys in a protected place and lets approved applications use those keys through audited API calls instead of storing raw key material in application code or databases.
How does cloud KMS work?
Cloud KMS products expose APIs for creating keys, setting usage policies, encrypting or decrypting small values, wrapping data keys, rotating keys, and recording audit events. The provider operates the key custody infrastructure while customers control policies and access.
What is envelope encryption in KMS?
Envelope encryption uses a fast data encryption key, often for AES, to encrypt the data itself. That data key is then encrypted, or wrapped, by a KMS key so applications can store the encrypted data key beside the ciphertext without exposing plaintext key material.
How does IAM control access to KMS keys?
IAM policies, key policies, grants, service identities, and conditions decide who or what can create, use, rotate, disable, or administer a key. Strong KMS designs separate key administration from key usage.
Is KMS the same as an HSM?
No. KMS is a higher-level managed key service with simple APIs, policy controls, integrations, and rotation features. An HSM is the hardened cryptographic module or appliance that may provide the lower-level custody boundary for some KMS keys.
Should I use KMS or HSM?
Use KMS for most cloud application encryption, storage encryption, secrets integrations, and audit-friendly key control. Choose cloud HSM or dedicated HSMs when you need direct module control, custom crypto interfaces, strict ceremonies, or stronger separation from provider-managed services.
Does KMS key rotation re-encrypt all data automatically?
Usually no. Rotation often changes the key version used for future encryption while older key versions remain available for decryption. Re-encrypting existing data may require a separate migration, especially for application-level envelope encryption.
References
Explore authoritative guidance and frameworks related to key management service (kms).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.