Encryption key management: a practical guide
Keys, not ciphers, are where encryption usually fails. The key lifecycle, KMS, HSMs and vaults compared, keeping keys out of code, and what to ask a vendor.
On this page 9 sections
Encryption key management is everything that keeps encryption keys secret, available and under control for their whole life: how they are generated, where they are stored, who and what can use them, how they are rotated and retired, and how every use is recorded. It matters more than the choice of cipher, because attackers rarely break AES; they find the key in a code repository, a configuration file or an app package. Most teams handle it with a managed key service or a hardware security module rather than building their own.
Why key management matters more than the cipher
The algorithms that protect data today are public and heavily studied. The secret is the key, which means the key is also the target. Our guide to how encrypted data really gets hacked shows that attackers go around encryption far more often than through it. The recurring failures are ordinary:
- a key committed to a code repository, sometimes a public one;
- a key bundled inside a mobile app or website, where anyone who unpacks it can find it;
- a key stored on the same server, or in the same database, as the data it protects;
- one key used for everything, so a single leak exposes everything;
- keys nobody owns, with no record of who can use them and no plan for a leak.
Good key management turns "we encrypt student data" from a claim into something that holds up when a laptop is stolen, a server is breached or an employee leaves. If the basics of encryption are new to you, start with what encryption is.
The key lifecycle
NIST's key management recommendation, SP 800-57 Part 1, describes the states a key can pass through. They map neatly onto everyday decisions:
| State | What it means | The decision it forces |
|---|---|---|
| Pre-activation | Generated, not yet in use | Was it created with a strong random source, inside a trusted system? |
| Active | Encrypting and decrypting data | Which systems and people genuinely need to use it? |
| Suspended | Temporarily unusable | Can we freeze a key during an investigation without losing data? |
| Deactivated | No longer protects new data, but can still decrypt old data | How long must old data stay readable? |
| Compromised | Known or suspected to have leaked | How fast can we replace it, and what did it protect? |
| Destroyed | Key material erased | Is it really gone, everywhere, including backups? |
The same document suggests cryptoperiods, the length of time a key should be used. For symmetric keys that encrypt data or wrap other keys, it suggests using them to protect new data for up to about two years. Our guide to key rotation covers how often to rotate in practice.
The last state has a useful side effect. Destroying a key, provided no copy of the key survives anywhere, makes everything encrypted with it unreadable, including copies of the data sitting in old backups you can't easily find. This is sometimes called crypto-shredding, and it is one of the few practical ways to make data disappear from systems with many copies.
KMS, HSM and secret vaults
There are a handful of places keys can live, each with its own trade-offs:
| Option | What it is | Why teams choose it | Trade-offs |
|---|---|---|---|
| Cloud key management service (KMS) | A managed service where master keys stay inside the provider's hardware and applications ask it to encrypt or decrypt | No hardware to run; access policies, logging and rotation built in | Per-request costs and rate limits, network latency, and dependence on one provider |
| Hardware security module (HSM) | Dedicated tamper-resistant hardware, on premises or single-tenant in the cloud | Maximum control; required for some regulated uses, such as the signing keys behind India's eSign service | Cost, specialist skills, and planning for failover |
| Secrets manager or vault | A central store for API keys, database passwords and certificates, sometimes offering encryption as a service | One place to control, rotate and audit credentials | Becomes a high-value target and a dependency for every service |
| Device key stores | Hardware-backed key storage built into phones and laptops | Keys are hard to extract from the device | Protects only keys on that device, within platform limits |
| Environment variables and config files | Keys stored alongside the application | Simple | Readable by anyone with server access, and prone to ending up in logs, crash reports and backups |
Most platforms combine these. A common pattern is to keep a small number of master keys in a KMS or HSM and use them to protect many working keys stored next to the data, which is the idea behind envelope encryption and KMS.
Keeping keys out of code
Keys end up in code because it's convenient: a developer pastes one into a config file to get a feature working, or a build pipeline needs credentials to deploy. The principle is that code should refer to keys, not contain them, and that anything which runs automatically should get short-lived access rather than a permanent secret.
- Repositories. Code hosts now scan for secrets. GitHub, for example, turns push protection on by default for users pushing to public repositories. A secret that has been pushed should be treated as leaked, even if the commit is later removed.
- Build pipelines. Instead of storing long-lived cloud credentials, pipelines can exchange an identity token for credentials that last only for one job. GitHub describes this approach in its OpenID Connect documentation.
- Apps and websites. Anything shipped to a phone or browser can be extracted by a determined user. Master keys never belong there.
- Logs and error reports. Keys and tokens often leak through debug output, error reports and support tickets. Make sure they are never logged.
Access control and audit
Holding keys in a proper service only helps if access to them is tight and visible.
- Separate duties. The people who administer keys shouldn't be the ones who use them to read data, and applications should get only the operations they need, for example encrypt but not decrypt.
- Bind keys to a purpose. Many key services let you attach context, such as which institute or which kind of record, so data encrypted for one purpose can't be decrypted under another.
- Log every use, and look at the logs. A spike in decryption requests at 2 a.m. is exactly the signal you want to catch. India's DPDP Rules, 2025 also expect access logs and monitoring as part of reasonable security safeguards; our DPDP compliance checklist has the details.
- Plan for a leak before it happens: who decides a key is compromised, how it is replaced, how you find out what it protected, and who assesses whether it is a reportable breach.
The trade-offs
- Security vs availability. A key nobody can reach is secure, and so is the data it locks, permanently. Losing a key is as bad as leaking one for data you still need, so recovery has to be planned.
- Control vs convenience. Your own HSM gives the most control and the most work; a cloud KMS gives the least work and ties you to a provider.
- Centralisation vs blast radius. One central service is easier to audit but becomes a single target; many separate keys limit damage but need more management.
- Rotation vs risk of breakage. Frequent rotation limits exposure, and every rotation is a change that can go wrong if it isn't automated.
- Cost and speed. Every call to a key service costs time and, often, money, which is why large systems use master keys sparingly and protect working keys with them.
What to ask a vendor about key management
If a platform stores your institute's student data or content, you don't need its internal design, but you should expect clear answers to these questions:
- Where are the keys that protect our data kept, and who at your company can use them?
- Is key storage hardware-backed, and has it been independently validated?
- Is every use of those keys logged, and can we get a record if we need one?
- How often are keys rotated, and what happens to data encrypted under old keys?
- Are any keys embedded in apps, websites or shared configuration?
- If a key leaked, how would you find out, and what would you do in the first 24 hours?
- When we leave, can you destroy the keys for our data and confirm it in writing?
Vague answers such as "everything is encrypted with military-grade encryption" say nothing about keys, and keys are the part that matters.
Key takeaways
- Key management covers a key's whole life: creation, storage, use, rotation, compromise and destruction.
- Real-world encryption usually fails through its keys, not its cipher.
- Managed key services and HSMs keep master keys out of reach of application servers and people.
- Keep keys out of code, apps, logs and pipelines; prefer short-lived access.
- Limit who can use each key, log every use, and plan for a leak before one happens.
Frequently asked questions
What is key management in cryptography?
Key management is the set of processes and tools for handling cryptographic keys safely throughout their life: generating them securely, storing and distributing them, controlling who can use them, rotating them, responding to compromise and destroying them. Strong encryption depends on it, because a leaked or lost key undoes the protection. NIST's SP 800-57 is the standard reference for key management practice.
What is key management system?
A key management system, or KMS, is software or hardware that stores encryption keys and performs operations with them on behalf of applications, so the most important keys never leave it. It typically enforces access policies, logs every use and automates rotation. Cloud providers offer managed versions backed by hardware security modules; organisations with stricter needs run their own HSMs.
What is key management in network security?
In network security, key management covers the keys that protect communication: TLS certificates and their private keys, session keys agreed automatically during handshakes, VPN and Wi-Fi credentials, and SSH keys. It includes issuing and renewing certificates, keeping private keys off shared machines, revoking access when devices or staff leave, and rotating credentials before they become a liability.