Skip to main content

Key Management Policy

Key Management Policy

Organization: {{ORG_NAME}} Policy Number: POL-SEC-KM-{{NUMBER}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}} Next Review: {{REVIEW_DATE}} Classification: Confidential — Restricted Distribution

Document History

Version Date Author Changes
0.1 {{DATE}} {{AUTHOR}} Initial draft

1. Purpose & Scope

Purpose: This policy defines the lifecycle management requirements for all cryptographic keys used by {{ORG_NAME}}, including generation, distribution, storage, usage, rotation, revocation, and destruction.

Scope: All cryptographic keys in use across:

  • All production, staging, and development environments
  • All cloud infrastructure and on-premises systems
  • All employee devices handling Confidential or Restricted data
  • All third-party integrations where {{ORG_NAME}} holds keys

Policy Owner: {{CISO_NAME}} ({{CISO_EMAIL}}) Operational Owner: {{SECURITY_TEAM}}

2. Key Types & Purposes

Key ID Type Algorithm Purpose Data Classification Protected Owner
KEK-01 Key Encryption Key AES-256 Master key for encrypting DEKs Restricted Security team
KEK-02 Key Encryption Key AES-256 Database field-level encryption master Restricted Security team
DEK-* Data Encryption Key AES-256-GCM Record-level data encryption Confidential/Restricted Application
TLS-EXT TLS Certificate Key ECDSA P-256 External HTTPS — Platform team
TLS-INT TLS Certificate Key Ed25519 Internal mTLS — Platform team
SIG-01 Signing Key Ed25519 Code/artifact signing — Security team
SIG-02 Signing Key HMAC-SHA-256 Webhook signatures — Engineering
AUTH-01 Auth Token Key RSA-4096 JWT signing (RS256) — Security team
AUTH-02 Auth Token Key Ed25519 JWT signing (EdDSA) — Security team
BACKUP-01 Backup Encryption Key AES-256-GCM Database backup encryption Restricted Security team
API-* API Key HMAC-SHA-256 Customer API authentication Confidential Engineering
MFA-* Secret Key TOTP (HMAC-SHA1/SHA256) User MFA secrets Restricted Application

3. Key Lifecycle

3.1 Lifecycle Overview

flowchart LR
    GEN[Generation] -->|"Secure, random"| DIST[Distribution]
    DIST -->|"Encrypted channel"| STORE[Storage]
    STORE -->|"Access controlled"| USE[Usage]
    USE -->|"Scheduled"| ROT[Rotation]
    ROT -->|"New key active"| USE
    ROT -->|"Old key retired"| ARCH[Archive / Revoke]
    ARCH -->|"End of life"| DEST[Destruction]

    REVOKE[Emergency Revocation] -->|"Compromise detected"| DEST
    USE --> REVOKE

3.2 Generation

Entropy requirements:

  • All keys MUST be generated using a cryptographically secure random number generator (CSPRNG)
  • Minimum entropy: 256 bits for symmetric keys, as specified for asymmetric
  • NEVER use: user-supplied passphrases, timestamps, UUIDs, or predictable values as keys
  • NEVER generate keys in userspace without an established crypto library

Approved key generation methods:

Key Type Generation Method Tool
Symmetric (AES-256) crypto.randomBytes(32) (Node.js) / os.urandom(32) (Python) OS CSPRNG
Asymmetric (Ed25519) openssl genpkey -algorithm ed25519 OpenSSL 1.1.1+
Asymmetric (ECDSA P-256) openssl ecparam -name prime256v1 -genkey OpenSSL
RSA-4096 openssl genrsa -aes256 4096 OpenSSL
KMS-managed KMS GenerateKey API Cloud KMS
HSM-managed HSM key generation {{HSM_PROVIDER}}

Generation environment:

  • Keys for Restricted data: MUST be generated within KMS or HSM — never in application code
  • Keys for Confidential data: MAY be generated in application code using OS CSPRNG
  • All key generation events MUST be logged

3.3 Distribution

Principles:

  • Never transmit keys in plaintext over any channel
  • Never include keys in source code, configuration files committed to VCS, or logs
  • Never send keys via email, Slack, or any messaging platform
  • Always use encrypted channels with mutual authentication for key distribution

Distribution methods:

Scenario Method Notes
Application runtime keys Cloud KMS API / Secrets Manager Keys fetched at runtime — never in environment files
Developer access to secrets HashiCorp Vault / cloud secrets Role-based access with MFA
CI/CD pipeline secrets CI platform secrets (encrypted at rest) Scoped to pipeline, rotated per project
Cross-system key sharing KMS key policies (no key material exchange) Grant access to KMS key, not key itself
Emergency key recovery {{ESCROW_PROCESS}} Requires dual approval — see §8

3.4 Storage

Storage hierarchy:

Level 1 — HSM (Hardware Security Module)
  ├── Master keys (KEKs) for Restricted data
  └── Root CA private keys

Level 2 — Cloud KMS (AWS KMS / Azure Key Vault / GCP Cloud KMS)
  ├── Key Encryption Keys for Confidential data
  ├── Service signing keys
  └── Encrypted DEK storage

Level 3 — Secrets Manager (HashiCorp Vault / AWS Secrets Manager)
  ├── Application secrets (DB passwords, API keys)
  ├── TLS certificate private keys
  └── Derived symmetric keys (encrypted by Level 2 keys)

Level 4 — Application memory (ephemeral only)
  ├── DEKs during active use
  └── Decrypted secrets during operation
  Note: NEVER persist Level 4 to disk

Prohibited storage locations:

  • Source code or config files in VCS
  • Application logs or error messages
  • Unencrypted database columns (for Restricted data)
  • Email attachments or messaging platforms
  • Shared drives or unencrypted file shares
  • Browser localStorage or sessionStorage
  • Environment variables in container images

3.5 Usage

Access control principles:

Principle Implementation
Least privilege Keys scoped to minimum necessary operations (encrypt-only, decrypt-only, sign-only)
Separation of duties No single person can generate + approve + deploy a key
Key purpose binding Encryption keys NOT used for signing; signing keys NOT used for encryption
Audit all access Every KMS/HSM operation logged with actor identity
Time-bound access Temporary access tokens for key operations — not persistent permissions

Key usage audit requirements:

  • All key operations logged: actor, operation, key ID, timestamp, source IP
  • Logs shipped to SIEM within 1 minute
  • Unusual access patterns alert within 5 minutes

3.6 Rotation Schedule

Key Type Rotation Period Method Owner Alert if Overdue
KEK (Master keys) Annual Manual + dual approval Security team Yes — 7 days overdue
Database encryption DEKs Quarterly Automated (key rotation API) Platform Yes — 3 days overdue
TLS certificates (external) 90 days Automated (cert-manager + ACME) Platform Yes — 14 days overdue
TLS certificates (internal) 30 days Automated (cert-manager) Platform Yes — 7 days overdue
JWT signing keys Quarterly Automated with overlap period Security Yes — 3 days overdue
API signing keys (webhooks) Quarterly Automated Engineering Yes — 3 days overdue
Backup encryption keys Annual Manual + dual approval Security Yes — 7 days overdue
Customer API keys On customer request OR 2 years Self-service portal Customer Notify customer 30 days before
MFA secrets On user request or suspected compromise Self-service User N/A

Rotation overlap period: Old key remains valid for {{OVERLAP_PERIOD}} after new key activation to allow in-flight operations to complete.

Key rotation monitoring dashboard: {{DASHBOARD_URL}}

3.7 Revocation Procedures

Trigger conditions for immediate revocation:

  • Known or suspected key compromise
  • Employee departure (for keys in personal custody)
  • System compromise where key was in use
  • Legal hold or regulatory requirement
  • Customer request (for customer API keys)

Emergency revocation procedure (< 1 hour):

Step 1: Alert Security Lead immediately
Step 2: Identify all systems using the compromised key
Step 3: Generate replacement key (see §3.2)
Step 4: KMS: Disable/revoke compromised key
Step 5: Deploy new key to all systems (use zero-downtime rotation)
Step 6: Verify all systems using new key
Step 7: Audit for unauthorized usage of compromised key
Step 8: Document in incident log
Step 9: Post-mortem within 48 hours

Certificate revocation:

  • Immediately upon compromise: Revoke via CA and push CRL update
  • OCSP response: Must reflect revocation within {{OCSP_UPDATE_TIME}}
  • Notify all certificate consumers

3.8 Destruction

When destruction is required:

  • Key has been rotated out and overlap period expired
  • System decommissioned
  • Crypto-shredding (delete encrypted data by destroying its key — GDPR erasure)

Destruction methods:

Key Location Destruction Method Verification
HSM HSM secure erase command HSM audit log
Cloud KMS KMS scheduled key deletion (min 7-30 day waiting period) KMS audit log
Secrets Manager Delete secret + verify Audit log
Application memory Explicitly zero memory (memset/SecureZeroMemory) Code review
Local file Secure delete (shred -vzu / sdelete) Hash verification
Backup media Physical destruction + certificate Destruction certificate

Verification: Key destruction must be verified — check that decryption with destroyed key fails.

Destruction log: Every key destruction event recorded in {{KEY_DESTRUCTION_LOG_LOCATION}}

4. Key Hierarchy

Root of Trust: HSM / Cloud KMS Root
    │
    ├── KEK-01: Database Encryption Master Key (annual rotation)
    │       ├── DEK-DB-{ID}: Per-table encryption key (quarterly rotation)
    │       │       └── Encrypts: Database field-level PII
    │       └── DEK-BACKUP-{ID}: Backup encryption key (annual rotation)
    │               └── Encrypts: Database backup files
    │
    ├── KEK-02: Application Secrets Master Key (annual rotation)
    │       ├── DEK-MFA-{ID}: MFA secret encryption key
    │       │       └── Encrypts: User TOTP secrets in database
    │       └── DEK-APIKEY-{ID}: API key material encryption
    │               └── Encrypts: API key secrets in database
    │
    ├── TLS Root CA (10-year validity)
    │       ├── Intermediate CA (2-year validity)
    │       │       ├── External TLS Certificates (90-day)
    │       │       └── Internal mTLS Certificates (30-day)
    │       └── Code Signing CA
    │               └── Release Signing Certificates (1-year)
    │
    └── JWT Signing Keys (Ed25519, quarterly rotation)
            └── Signs: JWT access + refresh tokens

5. Key Management System

Primary KMS: {{KMS_TOOL}} (e.g., AWS KMS, Azure Key Vault, HashiCorp Vault) Secondary/Backup KMS: {{SECONDARY_KMS}} (separate region/provider) HSM: {{HSM_PROVIDER}} (for highest-classification keys)

KMS access control:

Role Permissions MFA Required
key-admin Create, rotate, schedule deletion — NO decrypt YES
key-user-encrypt Encrypt only YES
key-user-decrypt Decrypt only YES
key-auditor List, describe, view audit logs — NO cryptographic ops YES
CI/CD pipeline Encrypt only (specific key IDs) N/A (service account)
Application service Encrypt + Decrypt (specific key IDs, specific operations) N/A (service account + VPC constraint)

6. Access Controls for Key Operations

Separation of duties requirements:

Operation Required Roles Approval Process
Create new KEK Security Lead + CISO Dual approval via KMS IAM
Rotate KEK Security Lead (proposer) + CISO (approver) Dual approval
Emergency revocation Security Lead (any one of) Single with immediate incident ticket
Destroy key Security Lead + CISO + Legal (if litigation hold) Triple approval
Grant new service access to key Security Lead + system owner Peer review + approval

7. Key Escrow & Recovery

Escrow policy: KEKs and backup encryption keys must be escrowed.

Escrow process:

  1. Key generated in KMS/HSM
  2. Key material exported (encrypted under escrow master key) — only where KMS allows export
  3. Exported material split into {{N}} shares using Shamir's Secret Sharing (requires {{K}} of {{N}} shares to reconstruct)
  4. Shares distributed to: {{SHARE_HOLDER_1}}, {{SHARE_HOLDER_2}}, {{SHARE_HOLDER_3}}
  5. Share holders store in secure location (safe deposit box or equivalent)
  6. Quarterly: Verify shares exist and holders still accessible

Recovery procedure (requires {{K}} share holders):

  1. Incident Commander opens emergency key recovery ticket
  2. {{K}} share holders convene (in person or secure video call)
  3. Shares combined to reconstruct key material
  4. Key imported into KMS
  5. Full event logged and post-mortem required

Note: For cloud KMS-only keys that cannot be exported: Rely on KMS redundancy (multi-region replication) — no separate escrow needed.

8. Audit Logging for Key Operations

All key operations logged, including:

  • Key generation (actor, key ID, key type, timestamp)
  • Key encryption/decryption (actor, key ID, data context, timestamp)
  • Key rotation (actor, old key ID, new key ID, timestamp)
  • Key revocation (actor, key ID, reason, timestamp)
  • Key destruction (actor, key ID, verification hash, timestamp)
  • Access grant/revoke (actor, grantee, key ID, permissions, timestamp)
  • Failed access attempts (actor, key ID, reason, timestamp)

Log destination: {{SIEM_TOOL}} — immutable, append-only Log retention: 2 years (PCI-DSS) / 3 years (SOC 2) — whichever is longer Alert on: Unusual access volume, off-hours access to KEKs, failed access attempts > 3 in 5 minutes

9. Compliance Mapping

Requirement Standard Control
Encryption key management PCI-DSS Req. 3.7 This policy + KMS implementation
Cryptographic key protection PCI-DSS Req. 3.7.1 HSM for KEKs + KMS for DEKs
Key custodian documentation PCI-DSS Req. 3.7.2 Key inventory table (§2)
Key rotation PCI-DSS Req. 3.7.4 Rotation schedule (§3.6)
Retired key replacement PCI-DSS Req. 3.7.5 Rotation + revocation procedures
Split knowledge PCI-DSS Req. 3.7.6 Shamir's Secret Sharing (§7)
Key destruction PCI-DSS Req. 3.7.7 Destruction procedures (§3.8)
Access controls SOC 2 CC6.1 Access controls table (§6)
Cryptographic controls ISO 27001 A.10 This entire policy
Personal data encryption GDPR Art. 32 See data-encryption-policy.md

10. Emergency Procedures — Key Compromise

Immediate response checklist (execute within 1 hour of suspected compromise):

□ Activate incident response: #incident-key-compromise-{{DATE}}
□ Notify: Security Lead + CISO + Engineering Lead
□ Identify scope: Which data was accessible with compromised key?
□ Revoke key immediately (see §3.7)
□ Generate new replacement key
□ Re-encrypt all data that was protected by compromised key
□ Rotate all derived keys that used compromised key as source
□ Audit logs: What was decrypted using the compromised key in the past 30 days?
□ Assess if breach notification required (see data-breach-response-plan.md §5)
□ Document everything in incident log

Re-encryption priority order:

  1. Most sensitive data first (Restricted → Confidential → Internal)
  2. Most recently accessed data first (likely to have been targeted)
  3. Oldest data last (historical data, lower immediate risk)

Estimated re-encryption time for {{N}} records: {{ESTIMATE}} — plan for {{ESTIMATE × SAFETY_FACTOR}}

Approval

Role Name Date Signature
Author
CISO
CTO
DPO (compliance relevance)
Management
Back to top