Dev/staging use different keys than prod

CWE-321 (hard-coded cryptographic key) covers key reuse across environments as much as literal key embedding: when dev and prod share an encryption key, a developer database compromise — a much lower-bar attacker target — exposes the key that also decrypts production data. NIST SC-12 requires that key management procedures account for environment lifecycle boundaries. Cross-environment key sharing also violates the broader key-management lifecycle expectations in PCI-DSS v4.0 Requirement 3.7 — dev/prod key separation is the only way trust boundaries remain meaningful under those procedures. Environment-specific keys constrain the blast radius of a dev credential compromise to the dev environment only.

Use environment-specific KMS key IDs for each environment, managed through environment variables that differ per deployment target. In your deployment pipeline:

// src/lib/kms.ts — environment key selection at init time
const KMS_KEY_ID = (() => {
  const env = process.env.NODE_ENV;
  if (env === 'production') return process.env.AWS_KMS_KEY_ID_PROD!;
  if (env === 'test') return process.env.AWS_KMS_KEY_ID_TEST!;
  return process.env.AWS_KMS_KEY_ID_DEV!;
})();

if (!KMS_KEY_ID) throw new Error('KMS_KEY_ID not configured for environment');

In CI/CD, store AWS_KMS_KEY_ID_PROD, AWS_KMS_KEY_ID_STAGING, and AWS_KMS_KEY_ID_DEV as separate secrets in your CI secrets manager (GitHub Actions, Vercel Environment Variables). Add a pre-deploy assertion that the key ID matches the expected ARN prefix for the target environment — fail the deploy if they don't match.