Encryption & Key Management

Locking your data in a safe is useless if the key is taped to the safe. Managing the keys properly matters as much as the locking itself.

At a glance

• What it is: encrypting data at rest and in transit, plus managing the full lifecycle of the keys and certificates that encryption depends on — generation, storage, rotation, and revocation.
• Why it matters: encryption without proper key management is a false sense of security — most real-world encryption failures come from mishandled keys (hardcoded, unrotated, overly shared), not from broken algorithms.
• For developers: never hardcode a key or certificate in source code or a config file checked into version control — fetch it from a managed key store (KMS/HSM) at runtime.
• When to use it: for any data that’s sensitive, regulated, or valuable enough to matter if exposed — which includes essentially all production data in transit and most of it at rest.
• When not to use it: fully public, non-sensitive data has no encryption requirement, but the system boundary that decides what’s “public” should itself be reviewed carefully.
• Prerequisites: Data Privacy, Security & Compliance for deciding what needs protecting; this page covers how the protection and its keys are managed.

Mental model

flowchart LR
    D[Sensitive data] -->|encrypt| E[Encrypted data]
    K[Key management service / HSM] -->|issues + rotates| E
    E -->|decrypt with valid key| D2[Data in use]
    K -->|expired or compromised key| REV[Revoke and rotate]

Step-by-step walkthrough

1. Classify the data (see Data Privacy, Security & Compliance) to determine what needs encryption at rest and in transit.
2. Use a managed key management service (KMS) or hardware security module (HSM) to generate and store keys — never generate or store keys in application code.
3. Set an automatic rotation schedule for keys and certificates, rather than relying on someone to remember to rotate them manually.
4. Scope key access narrowly: only the specific services that need to decrypt a dataset should have permission to use its key.
5. Have a documented revocation process for compromised keys, so a suspected leak can be acted on immediately, not investigated for days first.

Worked example

A PCI-DSS audit of the payment gateway fails: its TLS certificates and encryption keys haven’t rotated in three years and live directly in a configuration file alongside the application code.

• Input: long-lived keys and certificates stored in plaintext configuration, with no rotation process and unclear who has access to them.
• Process: the team migrates key storage to a managed KMS/HSM, sets automatic rotation on a defined schedule, and scopes access so only the payment service’s runtime identity — not developers’ laptops or the config repository — can retrieve the live key.
• Output: keys rotate automatically without manual intervention, a compromised key can be revoked and replaced quickly, and the audit finding is resolved by removing keys from source control entirely.

var client = new SecretClient(new Uri("https://payment-gateway.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("payment-signing-key"); // fetched at runtime, never in config

The payment service authenticates to Azure Key Vault via its managed identity (no stored credential at all); Key Vault’s automatic rotation policy replaces the key on schedule, and DefaultAzureCredential means the service never holds the key outside of memory.

resource paymentStorage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stpaymentgateway'
  location: location
  kind: 'StorageV2'
  sku: { name: 'Standard_LRS' }
  properties: {
    encryption: {
      keySource: 'Microsoft.Keyvault'
      keyvaultproperties: { keyvaulturi: kv.properties.vaultUri, keyname: 'payment-signing-key' }
    }
  }
}

This is a customer-managed key (CMK) — the storage account’s encryption key lives in and rotates from Key Vault, instead of a Microsoft-managed key the team can neither rotate nor revoke themselves.

Common use cases

Use case	When to use	Notes
Storing sensitive data at rest	Always, for classified-sensitive data	Encrypt using keys from a managed KMS, not application-generated keys
Services communicating over a network	Always	Use TLS with certificates managed and rotated by a KMS/PKI, not manually renewed
A compliance audit requires key rotation evidence	Before the audit	Automate rotation so evidence is generated as a byproduct, not gathered manually
A key may have been exposed	Immediately on suspicion	Revoke and rotate rather than waiting for confirmation of compromise

Advanced details

• KMS vs. HSM: a key management service (KMS) is typically a managed cloud service for key lifecycle operations; a hardware security module (HSM) is dedicated hardware that never exposes raw key material, often required for the highest sensitivity/regulatory tiers.
• Envelope encryption: encrypting data with a data key, then encrypting that data key with a master key held in the KMS — limits how often the master key itself is used.
• Certificate lifecycle: certificates expire by design; automating renewal (e.g. via ACME/short-lived certs) avoids outages caused by a forgotten manual renewal.

Quick reference

Term	Meaning
KMS	Key Management Service — manages key generation, storage, rotation, and access
HSM	Hardware Security Module — dedicated hardware that protects key material
Key rotation	Periodically replacing keys/certificates so a compromised one has limited lifetime value
Envelope encryption	Encrypting a data key with a master key, rather than using the master key directly on data
Revocation	Invalidating a key or certificate immediately, typically after suspected compromise

Troubleshooting

Symptom	Likely cause	Fix
Keys or certificates found in source control	Keys generated/stored by the application instead of a KMS	Move key storage to a managed KMS/HSM and remove keys from the repository history
An audit finds keys haven’t rotated in years	No automated rotation schedule	Configure automatic rotation in the KMS instead of relying on manual renewal
Unclear who can access a sensitive key	Access wasn’t scoped at creation	Restrict key access to only the specific service identities that need it

Check your understanding

• Why is a hardcoded key in application code a bigger risk than the same data being encrypted at all?
• What’s the difference between a KMS and an HSM, and when would the added cost of an HSM be justified?

Related pages

Part of Introduction to Security Architecture. See also Security Governance & Compliance Frameworks, Data Privacy, Security & Compliance, Cloud Security Posture & Perimeter Defense, and the Glossary.