Key Management 101 — Practical control for cryptographic keys

01 / INVENTORY

Start with a complete record.

A useful inventory connects every key, certificate, and related secret to an accountable owner, a narrow purpose, its dependencies, status, and planned end.

OWNERPURPOSEENVIRONMENTLOCATIONDEPENDENCIESSTATUSEXPIRATION

LOCAL TOOL / INVENTORY BUILDER

Record a fictional key

Entries stay in this page and disappear when it closes.

Label	Type	Owner	Environment	Location	Status	Review

SYM

Symmetric keys

One secret enables both encryption and decryption. Distribution and copying create the central risk.

PRV

Private keys

The non-public half of a keypair. Signing and decryption keys have different recovery and escrow needs.

KEK

Key-encryption keys

Protect other keys. Their smaller population and larger blast radius justify tighter controls.

DEK

Data-encryption keys

Protect data directly. They are often numerous, short-lived, and wrapped by a KEK.

CER

Certificates

Bind identity information to public keys for a stated purpose and validity period.

SSH

SSH keys

Grant access through public-key authentication. Inventory both authorized public keys and private-key custody.

02 / LIFECYCLE

Assign an owner to every stage.

Each stage needs an owner, an allowed action, evidence, and an exit path. Select a stage to inspect the operational question it must answer.

CREATE TRUSTWORTHY MATERIAL

Generate with an approved cryptographic source.

Choose the algorithm, size, parameters, and entropy source for the key’s exact purpose. Generate inside the intended protection boundary when non-exportability matters.

CONTROL

Approved generator, documented purpose, and restricted creation rights.

EVIDENCE

Creation event, owner, algorithm, source, date, and policy reference.

Could anyone predict or silently replace this key?

OWNERSHIP MAP

Separate accountability from access.

Role	Owns	Should not do alone
Business owner	Purpose and risk acceptance	Export production key material
Platform team	Service and protection boundary	Approve its own exception
Application team	Dependencies and integration	Bypass the approved key service
Security / audit	Policy, review, and evidence	Operate every production key

03 / STORAGE + CONTROL

Choose the protection boundary before the product.

Start with exposure, extractability, latency, availability, audit, recovery, and operator needs. A stronger device does not fix excessive permissions or unsafe application behavior.

DEVICE

OS keystore

Good for device-bound application keys and user credentials. Protection follows the operating system and account boundary.

Examples: Keychain, TPM-backed keystore

SERVICE

Managed KMS

Central policy, logging, rotation support, and API-based operations. IAM design becomes part of key security.

Useful for cloud workloads and envelope encryption

HARDWARE

HSM

Dedicated hardware can enforce non-exportability, tamper resistance, dual control, and high-assurance operations.

High-impact signing roots and KEKs

SECRET STORE

Vault

Centralizes access to keys and general secrets. Confirm whether keys are merely stored or used inside the service.

Application secrets and controlled distribution

ENDPOINT

Secure element

Isolates device keys and performs limited operations without exposing private material to the main processor.

Passkeys, mobile identity, embedded devices

LOCAL TOOL / PLACEMENT DECISION

Where should this key live?

Use the result as a conversation starter, not a product prescription.

SERVICE BOUNDARY

Start with a managed KMS or equivalent key service.

Keep the key non-exportable where practical, grant workloads permission to request only the required operation, and log use.

04 / ENVELOPE ENCRYPTION

Separate data keys from key-encryption keys.

Envelope encryption separates high-volume data protection from the smaller set of centrally controlled key-encryption keys.

DATACustomer record

DEKFresh data key

OUTPUTEncrypted data

KEK in key servicewraps DEKWrapped DEK stored beside ciphertext

STEP 01 / 04

Generate a fresh data-encryption key.

The DEK is created from a cryptographically secure source for a defined scope such as one object, tenant, or data partition.

Data and wrapped key may travel together

The wrapped DEK is not plaintext key material. Its security depends on the KEK boundary and wrapping construction.

KEKs stay centralized

Applications request wrap or unwrap operations through narrowly scoped permissions and auditable APIs.

Rotation can happen in layers

A KEK change may allow DEKs to be rewrapped without decrypting and re-encrypting every data object, depending on the architecture.

05 / ROTATION

Plan the replacement path.

There is no universal rotation interval. Cryptoperiods depend on purpose, algorithm, exposure, policy, threat, data lifetime, and operational constraints.

READINESS CHECK

Can this key be replaced today?

0 / 7 ready

Every dependency is inventoried. A replacement can be generated in the approved boundary. Old and new identifiers can overlap safely. Rollout order and owners are documented. Failure signals and rollback conditions are defined. Revocation or distrust can be propagated. The process has been tested outside production.

PLANNED ROTATION

Introduce, overlap, migrate, verify, retire.

OLD KEYCONTROLLED OVERLAPNEW KEY

Overlap is intentional compatibility, not indefinite dual trust. Define who can still use the old key and when that permission ends.

SUSPECTED COMPROMISE

Contain, revoke, and replace now.

Do not wait for the next scheduled interval when compromise is known or reasonably suspected. Investigate what the key could authorize, decrypt, or impersonate.

06 / COMPROMISE RESPONSE

First actions after a key is exposed.

Copying a key may leave no visible trace. Response scope comes from what the key could do, where it was trusted, and what evidence exists.

LIMIT FURTHER USE

Disable, restrict, or isolate the exposed key.

Stop new use without destroying evidence. Preserve logs, identify active sessions and automation, and assign an incident owner.

Disable or narrow the principal that can invoke the key.
Block affected deployments or integrations.
Preserve key-service, IAM, application, and host logs.

REVOCATION

Tell relying parties to stop trusting it.

Certificates, SSH access, signing trust, tokens, and application allowlists propagate distrust differently. Confirm the revocation reached every dependency.

RECOVERY

Loss and theft require different plans.

Decryption keys may need tightly controlled backup or escrow. Signing keys should not be escrowed casually because extra copies increase impersonation risk.

DUAL CONTROL

High-impact actions should need two people.

Separate authorization and execution for root keys, exports, destructive operations, and emergency recovery. Split knowledge prevents any one person from holding the whole secret.

AUDIT

Record operations, not key material.

Log who requested which operation, against which key, from where, when, and with what result. Never place plaintext keys in logs.

07 / FAILURE PATTERNS

Common failure patterns.

Most incidents are not broken mathematics. They are misplaced files, permissions that grew, ownership that vanished, or replacement paths that were never tested.

01
Hardcoded or committed keys
Assume repository history, forks, caches, and build artifacts may retain the value after deletion.
02
Data and key stored together
A single compromise reaches both. Separate protection boundaries where practical.
03
Exportable by default
Copies escape central controls and become difficult to inventory, revoke, or prove destroyed.
04
Broad IAM and shared identities
Too many principals can use keys, while logs cannot establish accountable ownership.
05
Stale keys and certificates
Expired owners and forgotten systems preserve access paths long after their purpose ends.
06
Untested rotation
Hidden dependencies turn routine replacement into an outage, so risky keys remain active.

08 / PRACTICAL PLAYBOOKS

Controls by key use.

Select a common system to see what to inventory, protect, rotate, and monitor.

TLS / SERVICE IDENTITY

Keep private keys controlled and renew before trust expires.

Inventory the certificate, private-key location, hostnames, issuer, renewal owner, deployment targets, and every load balancer or service that terminates TLS.

Protect: Generate or import into an approved keystore; restrict export; separate test and production.
Replace: Automate renewal, support overlap, deploy the chain correctly, then remove the previous key.
Watch: Expiration, unexpected issuance, handshake failures, export events, and private-key access.

09 / SOURCE DESK

Standards and source material.

Educational analogies support understanding; production decisions need current specifications, threat models, maintained libraries, and organizational policy.

NIST GUIDANCESP 800-57 Part 1 Rev. 5

General key-management guidance, lifecycle protection, and cryptoperiod factors.

OWASP CHECKLISTKey Management Cheat Sheet

Application-focused generation, storage, compromise, recovery, and accountability practices.

NIST STANDARDFIPS 140-3

Security requirements for cryptographic modules; not a substitute for system-level design.

IETF STANDARDTLS 1.3 / RFC 8446

A precise example of protocols combining authentication, key establishment, and protected records.

Sources reviewed July 2026. SP 800-57 Part 1 Rev. 5 remains NIST’s current final guidance; Rev. 6 is a public draft. Recheck publication status and organizational requirements before production use.