What is Key Management?

What is Key Management?

Key management is the process of creating, storing, distributing, rotating, and retiring cryptographic keys used to protect encrypted data. Effective key management ensures that encryption actually delivers the confidentiality and integrity it promises — poorly managed keys can render even strong encryption useless.

Key lifecycle stages

• Generation — creating keys using cryptographically secure methods with appropriate key lengths
• Distribution — securely delivering keys to authorized systems or users
• Storage — protecting keys at rest using hardware security modules (HSMs), key vaults, or other secure storage
• Rotation — periodically replacing keys to limit the impact of a potential compromise
• Revocation — disabling keys that are no longer trusted or have been compromised
• Destruction — securely deleting keys that are no longer needed, ensuring they cannot be recovered

Why key management matters for security

Encryption is only as strong as the key management behind it. A 256-bit AES key offers no protection if it's stored in the same database as the data it encrypts — an attacker who compromises the database gets both the ciphertext and the key to decrypt it. This is not a theoretical concern; it's one of the most common encryption failures found in penetration tests and compliance assessments.

Key management failures create several categories of risk:

• Exposure of historical data — Without regular key rotation, a single key compromise exposes every record encrypted with that key, potentially spanning years of sensitive data. Rotating keys limits the blast radius of any individual compromise.
• Insider threats — If one administrator holds all key material with no split knowledge or dual control, that person can access every encrypted record in the organization. Proper key management distributes trust across multiple individuals.
• Compliance failures — Auditors don't just check that encryption is enabled. They verify that keys are managed according to documented procedures, rotated on schedule, and protected with controls proportional to the sensitivity of the data they protect.
• Incident response gaps — Organizations that lack documented key management procedures often cannot determine which data was exposed during a breach, which keys need emergency rotation, or how to restore encrypted backups after a key custodian leaves the company.

The bottom line: encryption without proper key management is security theater. It checks a box on a checklist without actually reducing risk. Organizations that invest in strong encryption algorithms but neglect key management are protecting data with a lock and then leaving the key under the doormat.

Key management architectures

There are three primary approaches to key management, each suited to different risk profiles, compliance requirements, and operational maturity levels. The right choice depends on what data you're protecting, which frameworks you're subject to, and how much operational complexity you can absorb.

Cloud KMS

Cloud key management services — including AWS KMS, Azure Key Vault, and GCP Cloud KMS — are the most common starting point for organizations running workloads in the cloud. These services provide:

• Envelope encryption — Data is encrypted with a data encryption key (DEK), and the DEK itself is encrypted with a key encryption key (KEK) managed by the cloud provider. This limits the number of calls to the KMS while keeping the master key material protected.
• Customer-managed keys (CMK) — You control key rotation schedules, access policies, and deletion. The cloud provider manages the underlying infrastructure but cannot use the key without your authorization.
• Provider-managed keys — The cloud provider handles all key management automatically. Simpler to operate, but offers less control and may not satisfy compliance requirements that mandate customer-controlled keys.
• Bring Your Own Key (BYOK) — You generate keys in your own environment (often an on-premises HSM) and import them into the cloud KMS. This satisfies requirements for key generation in a controlled environment while still leveraging cloud-native encryption integration.

Cloud KMS is appropriate for most SaaS applications, internal systems, and workloads where the cloud provider is already part of the trust boundary. For organizations subject to PCI DSS or SOC 2, cloud KMS with customer-managed keys typically satisfies key management requirements when combined with proper access policies and rotation schedules.

Most cloud KMS services also provide detailed audit logs of every key operation, which simplifies compliance evidence collection during assessments.

Hardware Security Modules (HSMs)

HSMs are dedicated hardware devices designed to generate, store, and manage cryptographic keys in a tamper-resistant environment. They are validated against FIPS 140-2 or FIPS 140-3 standards at various levels:

• Level 1 — Basic security requirements, no physical tamper resistance
• Level 2 — Tamper-evident coatings or seals, role-based authentication
• Level 3 — Tamper-resistant with active response mechanisms (e.g., zeroization of keys upon detection of physical intrusion)
• Level 4 — Full physical security envelope with environmental failure protection

HSMs are required or strongly recommended in several contexts:

• PCI DSS — Strongly recommended for protecting cardholder data encryption keys, and effectively required for PIN-based transaction processing
• Government and defense — CMMC, FedRAMP, and similar frameworks often require FIPS 140-2 Level 3 or higher for cryptographic key storage
• Certificate authorities — Root and intermediate CA private keys must be stored in HSMs per industry standards

Cloud-based HSM options (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM) provide FIPS 140-2 Level 3 validated hardware in cloud data centers, bridging the gap between on-premises HSM security and cloud operational convenience.

Software-based key stores

Software-based solutions like HashiCorp Vault, CyberArk Conjur, or application-level key management provide flexibility without dedicated hardware. These tools offer:

• Centralized secret and key management across multiple applications and environments
• Dynamic secrets that are generated on demand and automatically revoked after use
• Audit logging of all key access and operations
• Integration with identity providers for policy-based access control

Software key stores are appropriate when:

• Compliance requirements do not mandate HSMs
• You need to manage secrets and keys across hybrid or multi-cloud environments
• Your threat model does not include sophisticated physical or hardware-level attacks

They are not appropriate when:

• Regulations explicitly require hardware-based key protection (e.g., PCI PIN security, certain government classifications)
• Your risk assessment identifies nation-state or advanced persistent threats targeting cryptographic material
• You need to provide cryptographic proof that keys have never been exposed to software

Key management requirements by framework

Different compliance frameworks impose different key management requirements. Understanding these differences is critical when an organization is subject to multiple frameworks simultaneously — which is increasingly common. The following table provides a practical comparison across five major frameworks:

Reading this table:

• PCI DSS is the most prescriptive. Requirement 3.6 specifies exactly what key management procedures must include, from key generation through destruction. Annual key rotation is a minimum baseline, and split knowledge/dual control is mandatory whenever keys are managed manually.
• ISO 27001 takes a risk-based approach. Annex A control A.8.24 requires a policy on the use of cryptographic controls including key management, but the specific controls depend on your risk assessment and Statement of Applicability.
• HIPAA is the least prescriptive on key management specifically. Encryption of ePHI is an "addressable" implementation specification, meaning organizations must implement it or document why an equivalent alternative is appropriate. Key management requirements follow from the encryption decision.
• SOC 2 addresses key management through the Common Criteria, particularly CC6.1 (logical access) and CC6.7 (data transmission). The specific expectations depend on the trust services criteria in scope and the auditor's interpretation.
• CMMC references NIST SP 800-171 for key management requirements. At Level 2, control SC.L2-3.13.10 requires establishing and managing cryptographic keys when cryptography is employed. Higher levels add additional requirements.

Common key management mistakes

Even organizations with mature security programs make key management errors. These mistakes are found repeatedly in audit findings, penetration test reports, and breach post-mortems. The most frequent include:

• Storing keys alongside encrypted data — Placing encryption keys in the same database, file system, or backup as the data they protect. If an attacker gains access to the data store, they get the keys too. Keys must be stored in a separate system with independent access controls.
• Hardcoding keys in source code — Embedding encryption keys, API keys, or other secrets directly in application code. These keys end up in version control history, CI/CD logs, and developer laptops. Use a secrets manager or environment variable injection instead.
• No key rotation policy — Using the same encryption keys indefinitely. Without rotation, a single compromise exposes all data ever encrypted with that key. Define rotation schedules based on data sensitivity and framework requirements.
• Single person with all key access — Concentrating key custody in one individual with no split knowledge or dual control. This creates both a security risk (insider threat) and an operational risk (key unavailability if that person is unreachable).
• No documented recovery procedures — Failing to plan for key loss, corruption, or custodian departure. Organizations discover this gap during an incident, when they cannot decrypt backups or rotate compromised keys because the procedure was never written down or tested.
• Using weak or predictable key generation — Generating keys with insufficient entropy, predictable seeds, or non-cryptographic random number generators. Always use cryptographically secure random number generators (CSPRNGs) and key lengths appropriate for the algorithm and data sensitivity.
• Ignoring key state tracking — Not maintaining an inventory of which keys are active, retired, or compromised. Without a key inventory, organizations cannot answer basic questions during an audit or incident: how many keys exist, who has access, and when they were last rotated.
• Failing to test key recovery — Having a documented recovery procedure that has never been exercised. Recovery procedures degrade over time as infrastructure changes, personnel rotate, and backup systems are modified. Regular testing is the only way to ensure recovery will work when it matters.

Key management in compliance frameworks

• PCI DSS — Requirement 3.5 and 3.6 detail specific key management procedures for protecting cardholder data (PAN)
• ISO 27001 — Annex A control A.8.24 covers the use of cryptography including key management policies
• HIPAA — the Security Rule requires encryption of ePHI, which implies proper key management
• SOC 2 — CC6.1 and CC6.7 address encryption and key management as part of logical access controls

Best practices

• Use hardware security modules (HSMs) or cloud key management services (AWS KMS, Azure Key Vault, GCP Cloud KMS) rather than storing keys in application code or configuration files
• Enforce separation of duties so that key custodians cannot access the data those keys protect
• Document key rotation schedules and automate rotation where possible
• Maintain an inventory of all cryptographic keys, their owners, and their expiration dates
• Test key recovery procedures regularly

How episki helps

episki tracks key management policies, links them to encryption controls, and monitors rotation schedules to ensure cryptographic practices stay compliant. Learn more on our compliance platform.