Key Management: Operating the Secrets That Cryptography Depends On

A strong encryption algorithm cannot protect data if its key is exposed. It can also make data permanently unavailable if the only key is lost.

Key management is the lifecycle of generating, storing, authorizing, using, rotating, backing up, revoking, and destroying cryptographic keys.

The difficult part of encryption is often operational: deciding which authority can use which key, under what conditions, with what recovery and audit evidence.

A concrete example: envelope encryption

A service needs to encrypt customer records.

It:

1. requests a fresh data-encryption key,
2. encrypts the record locally with that symmetric key,
3. sends the data key to a managed key service for wrapping,
4. stores the ciphertext and wrapped key,
5. and discards the plaintext data key from memory.

The master wrapping key stays inside the managed system rather than source code or the application database.

Inventory keys and purposes

Maintain an inventory including:

• key identifier,
• owner,
• algorithm and size,
• purpose,
• protected data or operation,
• environment,
• creation and expiry,
• storage location,
• access policy,
• rotation state,
• and recovery requirements.

Unknown keys become impossible to rotate safely or include in incident response.

Generate keys securely

Use cryptographically secure random generation from reviewed libraries, operating systems, hardware modules, or managed key services.

Do not derive keys from usernames, timestamps, ordinary random functions, or human-chosen passwords without an approved password-based key derivation function and suitable parameters.

Generation should occur inside the intended protection boundary when possible.

Store keys separately from data

If ciphertext and plaintext key sit together under the same permissions, encryption adds little protection against that compromise.

Use:

• hardware security modules,
• cloud key-management services,
• secure enclaves,
• protected operating-system stores,
• or offline custody

according to threat and availability needs.

Key hierarchy

Key hierarchies limit exposure.

A master or key-encryption key protects narrower data keys. Data keys can be unique per object, tenant, period, or dataset. Rotating a wrapping key may require rewrapping small data keys rather than decrypting every large object.

Define hierarchy depth and dependencies clearly to avoid an unmanageable chain.

Access control

Grant permission by operation, not broad possession.

One service may encrypt but not decrypt. A release pipeline may request signatures but never export the signing key. Administrators may manage policy without reading protected data.

Bind access to workload identity, environment, purpose, and tenant where possible.

Keep keys out of application code

Do not place keys in:

• source repositories,
• container images,
• configuration committed with code,
• logs,
• tickets,
• or chat messages.

Secret scanning can catch some leaks, but prevention and rapid revocation remain necessary. Environment variables are not automatically safe if processes, crash reports, or deployment tools expose them.

Rotation

Rotation limits exposure and replaces keys after policy changes or suspected compromise.

Plan:

• how new writes use the new key,
• how old data remains readable,
• whether old data is re-encrypted or its key rewrapped,
• how caches update,
• when the old key is disabled,
• and how rollback works.

Test rotation before an emergency.

Revocation and compromise

When a key may be compromised:

1. stop or restrict its use,
2. identify affected systems and data,
3. issue replacement keys,
4. rotate dependent credentials or certificates,
5. re-encrypt or re-sign where required,
6. investigate access logs,
7. and communicate impact.

Deletion alone does not undo copies or previous unauthorized use.

Backup and recovery

Some keys require protected backup because losing them destroys access to data. Other keys, such as ephemeral session keys, should not persist.

Backup keys under separate credentials and locations, encrypt them, test restoration, and require stronger approval for recovery. A backup that has never been restored is an assumption.

Availability

Central key systems can become critical dependencies.

Design for service outages, region failure, quotas, latency, and disaster recovery without copying master keys into uncontrolled fallbacks. Cache short-lived derived material only where policy and threat modeling permit.

Audit

Log:

• key creation,
• policy changes,
• encrypt and decrypt operations where feasible,
• signing requests,
• denied access,
• export attempts,
• rotation,
• disablement,
• and destruction.

Protect logs from tampering and alert on unusual identities, volumes, times, or regions.

Separation of duties

High-value keys may require multiple roles:

• one person requests,
• another approves,
• an automated service executes,
• and an independent team reviews logs.

Hardware-backed quorum or multi-party controls can prevent one administrator from exercising complete authority.

Tenant and environment separation

Do not casually reuse keys across development, test, and production. Separate tenants or sensitivity levels when compromise impact warrants it.

Narrow scope improves revocation and reduces blast radius, though too many unmanaged keys create operational risk. Automation and inventory make granularity sustainable.

Destruction and crypto-shredding

When data retention ends, destroy all copies of the required decryption keys after confirming no legitimate dependency remains. This can make ciphertext computationally unrecoverable, sometimes called crypto-shredding.

Account for replicas, backups, wrapped copies, exports, and disaster-recovery systems. Record destruction evidence.

Algorithm agility

Systems should be able to migrate algorithms, parameters, providers, and key formats.

Store key and algorithm identifiers with ciphertext or signatures, avoid hard-coded assumptions, and test migration. Long-lived data may outlast today's cryptographic guidance.

Knowledge check

1. Why should keys be stored separately from encrypted data?
2. How does envelope encryption work?
3. What decisions belong in a rotation plan?
4. Why must backup restoration be tested?
5. What does separation of duties protect against?

The one idea to remember

Cryptography depends on operational control of keys. Secure key management gives every key a purpose, owner, protection boundary, least-privilege policy, rotation and recovery path, audit trail, compromise response, and verified end of life.