Encryption Key Lifecycle Template

Overview

Encryption key lifecycle management defines how keys are created, stored, used, rotated, and retired. Poor key management can undermine encryption entirely by exposing keys, keeping them too long, or failing to revoke them when no longer needed. This template provides policies, procedures, and roles for managing symmetric and asymmetric keys across applications, databases, backups, and cloud services.

When to Use

• For alternatives, see Data Retention Policy Template.

• Designing a key management strategy for a new application or platform.

• Selecting or configuring a key management service (KMS) or hardware security module (HSM).

• Establishing a key rotation policy for compliance or risk reduction.

• Responding to a key compromise or suspected unauthorized key access.

• Offboarding a system or retiring a service that holds encrypted data.

Prerequisites

• A key management service such as AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault, or an HSM.
• A classification of data that requires encryption at rest, in transit, or in use.
• A list of systems and services that generate or use encryption keys.
• Defined roles for key custodians, users, and auditors.

Solution

Template

1. Key Classification

Key Type	Purpose	Example	Protection Level
Data encryption key (DEK)	Encrypts data at rest	AES-256 database key	High
Key encryption key (KEK)	Encrypts DEKs	RSA key in KMS	Critical
Transport key	Encrypts data in transit	TLS private key	High
Signing key	Signs code or artifacts	ECDSA code signing key	Critical
API key	Authenticates API calls	HMAC secret	Medium
Backup key	Encrypts backups	AES-256 backup key	High

2. Key Lifecycle Stages

Stage	Activities	Owner	Artifacts
Generation	Create key with approved algorithm and length	Platform team	Key metadata, algorithm
Distribution	Securely deliver key to authorized systems	Security team	Access log, key alias
Storage	Store in KMS, HSM, or vault	Platform team	Key location, policy
Usage	Enforce least-privilege and audit all operations	Application team	Access policy, audit logs
Rotation	Replace key periodically or after incident	Security team	Rotation schedule, new key
Compromise	Revoke, rotate, and assess impact	Security team	Incident report, new key
Destruction	Securely delete key when no longer needed	Platform team	Destruction certificate
Archive	Retain key metadata for compliance without key material	Compliance team	Retention record

3. Key Rotation Policy

Key Type	Rotation Frequency	Trigger	Automatic
KEK / KMS key	2 years	Scheduled	Yes
TLS certificate key	1 year	Certificate expiry	Yes
Database DEK	1 year	Scheduled	No, planned maintenance
Signing key	1 year	Scheduled or suspected compromise	Semi-automatic
API HMAC secret	90 days	Scheduled or credential leak	Yes
Backup key	1 year	Scheduled	No

4. Access Control Matrix

Role	Generate	Use	Rotate	Destroy	Audit
Application service	No	Yes	No	No	No
Platform engineer	Yes	No	Yes	No	Yes
Security engineer	No	No	Yes	No	Yes
Key custodian	Yes	No	Yes	No	Yes
Auditor	No	No	No	No	Yes
Compliance officer	No	No	No	Yes with approval	Yes

5. Compromise Response Procedure

Step	Action	Owner	Timeline
1	Revoke or disable the compromised key	Security team	Within 1 hour
2	Identify all systems and data protected by the key	Security team	Within 4 hours
3	Rotate to a new key and re-encrypt data	Platform team	Within 24 hours
4	Notify stakeholders and customers if required	Incident commander	Within 24 hours
5	Preserve audit logs and evidence	Security team	Immediate
6	Update incident report and lessons learned	Security team	Within 1 week

6. Destruction Checklist

• Key is no longer used by any application or service.
• Encrypted data has been decrypted with the new key or securely deleted.
• All backups and replicas containing the key are identified.
• Key material is deleted from KMS, HSM, or vault.
• Destruction is logged and signed by key custodian and compliance officer.
• Retention period for metadata is documented and enforced.

Explanation

Encryption is only as strong as the keys that protect it. The lifecycle template ensures that keys are generated with strong algorithms, stored in approved services, accessed with least privilege, rotated regularly, and destroyed securely when no longer needed. Separating duties between key custodians, users, and auditors prevents any single person from controlling the entire lifecycle.

AWS KMS Key Rotation Policy

# AWS KMS key with automatic rotation
Resources:
  EncryptionKey:
    Type: AWS::KMS::Key
    Properties:
      Description: Application data encryption key
      EnableKeyRotation: true
      KeyPolicy:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub 'arn:aws:iam::${AWS::AccountId}:role/app-role'
            Action:
              - kms:Encrypt
              - kms:Decrypt
              - kms:ReEncrypt*
              - kms:GenerateDataKey*
              - kms:DescribeKey
            Resource: '*'
          - Effect: Allow
            Principal:
              AWS: !Sub 'arn:aws:iam::${AWS::AccountId}:root'
            Action:
              - kms:CreateAlias
              - kms:DeleteAlias
              - kms:UpdateAlias
              - kms:ScheduleKeyDeletion
              - kms:EnableKeyRotation
            Resource: '*'
      PendingWindowInDays: 30

Key Rotation Automation Script

#!/bin/bash
# Check and report key rotation status across AWS KMS
set -euo pipefail

REGION="us-east-1"
ALERT_DAYS=7

for key_id in $(aws kms list-keys --region $REGION --query 'Keys[*].KeyId' --output text); do
  rotation_status=$(aws kms get-key-rotation-status --key-id $key_id --region $REGION --query 'KeyRotationEnabled' --output text 2>/dev/null || echo "N/A")
  key_desc=$(aws kms describe-key --key-id $key_id --region $REGION --query 'KeyMetadata.Description' --output text 2>/dev/null || echo "N/A")
  creation_date=$(aws kms describe-key --key-id $key_id --region $REGION --query 'KeyMetadata.CreationDate' --output text 2>/dev/null || echo "N/A")

  echo "Key: $key_id | Description: $key_desc | Rotation: $rotation_status | Created: $creation_date"

  if [ "$rotation_status" = "False" ]; then
    echo "WARNING: Key $key_id does not have automatic rotation enabled"
  fi
done

Key Compromise Response Runbook

=== Key Compromise Response ===

1. CONTAIN (immediate, 0-15 min)
   - Disable the compromised key in KMS/HSM
   - Revoke all access policies for the key
   - Identify all data encrypted with the compromised key

2. ASSESS (15-60 min)
   - Determine scope: which services, databases, backups affected
   - Check access logs for unauthorized key usage
   - Notify security team and key custodian

3. REPLACE (1-4 hours)
   - Create new key with same policy
   - Re-encrypt all affected data with new key
   - Update application configurations to use new key ARN/ID
   - Deploy updated configurations

4. DESTROY (after verification)
   - Schedule deletion of compromised key
   - Verify all data uses new key
   - Document incident and update key inventory

5. POST-INCIDENT (within 1 week)
   - Review root cause of compromise
   - Update access policies and monitoring
   - Conduct full key inventory audit
   - Update key lifecycle documentation

Variants

• Cloud KMS key lifecycle: Uses AWS KMS, Azure Key Vault, or Google Cloud KMS with automatic rotation and IAM policies.
• HSM-backed key lifecycle: Adds physical or cloud HSM protection for high-assurance keys.
• Application-level key lifecycle: Focuses on keys generated and managed within a single application or service.
• Database encryption key lifecycle: Covers transparent data encryption (TDE) and column-level keys.
• Backup encryption key lifecycle: Ensures long-term keys can be recovered for archive retention while remaining secure.

What Works

• Use a centralized KMS or HSM instead of storing keys in application code.
• Separate key encryption keys from data encryption keys.
• Rotate keys automatically when the service supports it.
• Log every key usage and administrative action.
• Limit key export to non-extractable keys unless required.
• Test rotation and destruction procedures before an incident.
• Maintain an inventory of all keys, owners, and rotation dates.
• Require multi-person approval for high-impact actions like destruction.

Common Mistakes

• Hardcoding keys in source code or configuration files.
• Never rotating keys despite compliance requirements.
• Sharing keys across multiple applications or environments.
• Allowing key export without approval or audit.
• Not backing up key metadata or KEKs before destruction.
• Ignoring compromised key response procedures.
• Storing old keys indefinitely after rotation.

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: configure log filters to redact tokens, passwords, and keys. Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: use report-only mode first, then enforce. Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the encryption and key-management guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply encryption key lifecycle template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.