What Is Key Management? Enterprise Cryptographic Key Governance

AES-256 is unbreakable. RSA-4096 is computationally infeasible to factor. The algorithms are fine. The keys are the problem.

Key management is the discipline of handling cryptographic keys securely throughout their entire lifecycle — from generation through active use, rotation, archival, and destruction. Every encryption system is only as secure as its key management. A perfectly encrypted database with the key stored in a plaintext config file on the same server provides zero security.

---

Why Key Management Is the Weak Link

Every major encryption breach in the last decade was a key management failure:

Incident	What Happened	Root Cause
Capital One (2019)	100M records exposed	Misconfigured IAM role allowed access to encryption keys
Uber (2022)	Internal systems breached	Hardcoded credentials in PowerShell script
Codecov (2021)	Customer secrets leaked	CI/CD environment variables (including keys) exfiltrated
SolarWinds (2020)	Signed malware distributed	Signing key accessible from compromised build system

None of these were algorithm failures. The encryption was fine. The key protection was not.

---

The Key Lifecycle

Every cryptographic key passes through defined stages:

Generation

• Use hardware RNG (HSM) or OS CSPRNG (/dev/urandom)
• Never application-level PRNGs (Math.random())
• Generate on the system that will use the key (or in HSM)
• Document: algorithm, size, purpose, owner

Distribution

• Deliver via secure channels (KMS API, HSM-to-HSM, TLS)
• Never: email, chat, source code, unencrypted transfer
• Minimize copies (each copy = additional attack surface)

Active Use

• Restrict access to minimum necessary systems
• Log all key usage (who, when, what operation)
• Monitor for anomalies (unusual volume, unexpected source)

Rotation

• Replace at end of crypto-period (NIST SP 800-57: 1-2 years for symmetric)
• Old key retained for decrypting existing data (deactivated state)
• New key used for all new operations

Destruction

• Permanently delete when no longer needed
• HSM: hardware zeroization
• Software: overwrite + delete (shred -vfz -n 5 key.pem)
• Document: date, method, authorization

---

Key Storage: The Hierarchy of Protection

Tier	Storage	Security	Use For
1	HSM (FIPS 140-2 Level 3)	Key never extractable	CA keys, payment keys
2	Cloud KMS (AWS KMS, Azure Key Vault)	Non-exportable, API-only	Data encryption, signing
3	Secrets Manager (Vault, AWS Secrets Manager)	Encrypted, delivered to apps	DB passwords, API keys
4	Encrypted file (chmod 600)	Minimum acceptable	Dev environments
5	Plaintext (config file, env var, source code)	NEVER	Nothing — this is a breach

---

Key Management in Practice

AWS KMS (Cloud-Managed)

# Create key (generated inside HSM, never extractable)
aws kms create-key --key-spec SYMMETRIC_DEFAULT --key-usage ENCRYPT_DECRYPT

# Encrypt data (key never leaves KMS)
aws kms encrypt --key-id alias/my-key --plaintext fileb://data.json

# Enable automatic annual rotation
aws kms enable-key-rotation --key-id alias/my-key

HashiCorp Vault (Self-Managed)

# Transit engine — encryption as a service
vault write transit/encrypt/my-key plaintext=$(echo "secret" | base64)
# Returns ciphertext. Key never exposed.

# Automatic key rotation
vault write -f transit/keys/my-key/rotate
# New version created. Old data still decryptable.

TLS Key Management (Automated)

# cert-manager generates new key at every renewal
# No manual key management needed
apiVersion: cert-manager.io/v1
kind: Certificate
spec:
  privateKey:
    rotationPolicy: Always  # New key pair at each renewal

---

Compliance Requirements

Framework	Key Management Requirement
PCI DSS 4.0	Req 3.5-3.6: Documented procedures for generation, storage, rotation, destruction
HIPAA	§164.312: Encryption key management as addressable safeguard
SOC 2	CC6.1: Logical access controls for cryptographic keys
NIST 800-57	Complete lifecycle guidance (the reference standard)
ISO 27001	A.10.1: Cryptographic controls policy
FIPS 140-2/3	Validated modules for key storage and operations

---

Common Mistakes

1. Keys in source code — committed to Git, visible in history forever
2. Same key across environments — dev compromise exposes production
3. No rotation schedule — key active for 5+ years
4. Key stored with data — encryption key in the same database it protects
5. No destruction process — old keys accumulate in backups
6. Shared keys — multiple services using one key
7. No inventory — nobody knows how many keys exist

---

FAQ

Q: What’s the difference between key management and secrets management? A: Key management handles cryptographic keys (perform operations — encrypt, sign). Secrets management handles credentials (deliver to applications — passwords, tokens). KMS: app says “encrypt this.” Secrets manager: app says “give me the password.” You often need both.

Q: How often should I rotate keys? A: NIST SP 800-57: 1-2 years for symmetric encryption keys. TLS keys: at every certificate renewal (90 days). SSH keys: annually. CA signing keys: 3-5 years (intermediate).

Q: Do I need an HSM? A: For CA signing keys (WebTrust), payment processing (PCI PIN), and government (FIPS Level 3): yes. For application encryption: cloud KMS (Level 2) is sufficient and simpler.

Q: What happens if I lose an encryption key? A: All data encrypted with that key is permanently unrecoverable. This is why key backup is critical — plan it at generation time, not after failure.

Q: Is key management the same as certificate management? A: Related but different. Key management covers all cryptographic keys (symmetric, asymmetric, signing, encryption). Certificate management specifically covers X.509 certificates (which contain public keys). Certificate management is a subset of the broader key/crypto management discipline.

---

Need help managing cryptographic keys across your infrastructure? Our professional services team can assess your current key management posture and build a governance program aligned with NIST SP 800-57. Get in touch →