Episode 29 · Module 7 · Data Protection

Key Management and Rotation

19 May 2026 · 8:19 · Security for Legal SaaS

8:19 8:19

In Episode 28, we covered encryption at rest and in transit — the two fundamental layers that protect legal data from eavesdroppers and stolen disks. But encryption without proper key management is theatre. A key stored next to the data it protects is like locking a filing cabinet and taping the key to the front. The lock exists, but the security does not. This episode focuses on the infrastructure that makes encryption actually work: how cryptographic keys are generated, stored, rotated, and retired — and why getting this wrong has caused some of the most damaging breaches in legal technology.

Today’s Lesson

Security for Legal SaaS — Episode 29: Key Management and Rotation

Your Encryption Is Only as Strong as Your Key Management

This episode focuses on the infrastructure that makes encryption actually work: how cryptographic keys are generated, stored, rotated, and retired — and why getting this wrong has caused some of the most damaging breaches in legal technology.

The Key Hierarchy: Master Keys, Data Keys, and Envelope Encryption

Modern key management uses a layered hierarchy rather than a single key for everything. The pattern is called envelope encryption, and it works like a chain of locked boxes:

Layer	Purpose	Example
Master key (root key)	Protects all other keys; never touches data directly	AWS KMS root key, GCP Cloud KMS key
Key-encrypting key (KEK)	Wraps data encryption keys for storage and transport	Intermediate key in a Vault transit backend
Data encryption key (DEK)	Encrypts actual data (documents, database fields, files)	AES-256 key generated per-record or per-tenant

When your case management system encrypts a client's document, it generates a fresh DEK, encrypts the document with that DEK, then encrypts the DEK itself with the master key. The encrypted DEK is stored alongside the encrypted document. The plaintext DEK is discarded immediately. To decrypt, the system asks the key management service (KMS) to unwrap the DEK using the master key, then uses the plaintext DEK to decrypt the document.¹

This means the master key never leaves the KMS boundary. Even if an attacker steals your entire database — encrypted documents and encrypted DEKs included — they cannot decrypt anything without access to the master key inside the KMS.²

Why this matters for legal SaaS: If your platform stores privileged attorney-client communications, opposing counsel's discovery documents, and merger negotiations in the same database, envelope encryption lets you use different DEKs per client matter. Compromising one matter's key does not expose another.

Key Management Services: The Hardware Behind the Trust

A key management service is a specialised system — often backed by tamper-resistant hardware called a Hardware Security Module (HSM) — that generates, stores, and performs cryptographic operations with master keys. The master key material never leaves the HSM boundary in plaintext.

Service	Provider	HSM Backing	Key Rotation	Pricing Model
AWS KMS	Amazon	FIPS 140-2 Level 3	Automatic (annual) or on-demand	Per-key + per-request
Cloud KMS	Google Cloud	FIPS 140-2 Level 3	Automatic (configurable period)	Per-key-version + per-operation
Azure Key Vault	Microsoft	FIPS 140-2 Level 2/3	Manual or policy-based	Per-operation + per-key
HashiCorp Vault	HashiCorp	Optional HSM backend	Policy-driven	Self-hosted or HCP managed

For a legal SaaS platform, the choice typically depends on your cloud provider. If you run on AWS, KMS is the natural default. The critical requirement is that the KMS is a separate trust boundary from your application servers and database. Your application can request encryption and decryption operations, but it never possesses the master key.³

Key Rotation: Why and How

Cryptographic keys should not last forever. NIST SP 800-57 defines cryptoperiods — the maximum lifespan during which a key is authorised for use. The reasons for rotation include:⁴

Limiting exposure. If a key is compromised without detection, limiting its cryptoperiod limits how much data the attacker can decrypt.
Reducing ciphertext volume. The more data encrypted with a single key, the more material an attacker has for cryptanalysis.
Compliance. PCI DSS, SOC 2, and various data protection regulations mandate periodic key rotation.

How Rotation Works Without Downtime

The elegant aspect of envelope encryption is that key rotation only rotates the master key — not every DEK in your system. When AWS KMS rotates a key, it generates new key material but retains all previous versions. New encryption operations use the new material. Decryption operations automatically select the correct version based on metadata in the ciphertext. No data needs to be re-encrypted.⁵

Rotation Type	How It Works	When to Use
Automatic rotation	KMS generates new key material on a schedule (e.g., annually)	Default for symmetric encryption keys
On-demand rotation	Triggered manually or by policy (e.g., after a suspected compromise)	Incident response, compliance events
Re-encryption	Decrypt all data with old key, re-encrypt with new key	When retiring a key entirely or migrating KMS providers

Legal SaaS scenario: A law firm client terminates their subscription. Your data retention policy requires you to destroy their data after 90 days. If each client matter used a separate DEK, you can crypto-shred — destroy the DEK, rendering the encrypted data permanently unrecoverable without touching the underlying storage. This is faster and more verifiable than attempting to delete every copy of the data across backups, replicas, and caches.⁶

Key Access Policies: Use vs. Manage

KMS platforms distinguish between two types of access:

Key users can request encryption and decryption operations but cannot view, export, or delete the key material.
Key administrators can create, rotate, disable, and delete keys but may not use them for cryptographic operations.

This separation of duties ensures that a compromised application server (which has key-use permissions) cannot delete or export master keys, and an administrator who can manage keys cannot decrypt production data. AWS KMS enforces this through IAM key policies, and HashiCorp Vault uses ACL policies with similar granularity.⁷

For legal SaaS, this maps directly to professional obligations. The lawyer-equivalent is the ethical wall: one team handles the key (the key administrator, like the conflicts department), another team uses it (the application, like the litigation team). Neither can do the other's job.

Disaster Recovery: The "What If We Lose the Key" Question

If you lose your master key, you lose access to every piece of data it protects. There is no backdoor, no recovery mechanism, no "forgot password" flow. This is by design — it is also terrifying.

Mitigation strategies:

Multi-region key replication. AWS KMS supports multi-region keys that replicate cryptographic material across regions. If one region fails, the replica can decrypt.⁸
Key escrow. Store encrypted copies of key material in a separate, offline system (e.g., a physical HSM in a vault). This is the nuclear option — use only for catastrophic recovery.
Dual-control procedures. Require multiple administrators to authorise key deletion, preventing a single compromised or rogue admin from destroying keys.
Deletion scheduling. AWS KMS enforces a minimum 7-day waiting period before key deletion takes effect, providing a window to cancel accidental deletions.⁹

Real-World Failures

Incident	What Went Wrong	Impact
Orrick, Herrington & Sutcliffe (2023)	Attackers accessed personal data of 600,000+ individuals; encryption controls insufficient to prevent exfiltration	$8 million settlement¹⁰
Uber (2016)	Encryption keys stored in a GitHub repository alongside code	Exposed 57 million user records; $148 million settlement
Adobe (2013)	3DES encryption with a single key for all 153 million passwords; identical passwords produced identical ciphertext	Enabled pattern analysis; largest credential breach at the time

What's Next

Episode 30 covers Secrets Management — the closely related problem of protecting API keys, database credentials, and service tokens that your application uses at runtime. If your encryption key is the crown jewels, your API keys are the ring of skeleton keys that opens every door in the building.

Sources & Further Reading

Sources & references

AWS, AWS KMS Concepts — Envelope Encryption.
AWS Prescriptive Guidance, Encryption Best Practices for AWS Key Management Service.
NIST, SP 800-57 Part 1 Rev. 5: Recommendation for Key Management.
NIST, SP 800-57 Part 1 Rev. 5 — Cryptoperiods, Section 5.3.
AWS, Rotate AWS KMS Keys.
AWS Prescriptive Guidance, Key Rotation for AWS KMS and Scope of Impact.
HashiCorp, Vault Secrets Management Tutorials.
AWS, Multi-Region Keys in AWS KMS.
AWS, Deleting AWS KMS Keys.
Embroker, Law Firm Cyberattacks: Stats and Trends for 2025.
Thales, NIST 800-57 Key Management Requirements Analysis.
TerraZone, NIST SP 800-57: Complete Guide to Cryptographic Key Management.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 29 — key management and rotation. Last episode we covered encryption at rest and in transit. This time we're talking about the keys themselves. Alice, why does key management matter if the encryption is already strong?

Alice: Because the encryption algorithm is only half the equation. Think of it this way — you've installed the best lock money can buy on your office door. AES-256, military-grade, unbreakable. But then you tape the key to the doorframe. The lock is perfect. The security is zero. That's what happens when you encrypt data but store the encryption key in the same database, or hardcode it in your application, or put it in a config file next to the code.

Dan: Mm. So the key needs its own protection.

Alice: Exactly. And the way modern systems handle this is through something called envelope encryption. Picture a chain of locked boxes. You have your actual data — say, a privileged client communication in your case management system. You generate a fresh key just for that document. That's your data encryption key, or DEK. You encrypt the document with the DEK. Then you take that DEK and encrypt it with a separate, more powerful key called the master key. The encrypted DEK gets stored alongside the encrypted document. The plaintext DEK is immediately destroyed.

Dan: Right. So even if someone steals the database, they get encrypted documents and encrypted keys. They can't do anything with either one.

Alice: Correct. Because the master key lives in a completely separate system — a key management service, or KMS. Think of it as a vault within a vault. AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault — they all work on this principle. The master key never leaves the KMS boundary. Your application sends data to the KMS and says "encrypt this" or "decrypt this," but it never holds the master key itself. It's like a bank safety deposit box — the bank lets you use what's inside, but you can't take the vault door home.

Dan: Hmm. And these services are backed by specialised hardware?

Alice: Most of the major cloud KMS offerings are backed by Hardware Security Modules — HSMs. These are tamper-resistant chips certified to federal standards, specifically FIPS 140-2 Level 3 in most cases. They're designed so that if someone physically tries to open the module, the key material self-destructs. You're not trusting software alone — you're trusting purpose-built hardware.

Dan: Yeah, that's a meaningful level of paranoia. Now, you mentioned key rotation in the episode title. Why can't you just create a good key and use it forever?

Alice: <sigh> If only. NIST — the US National Institute of Standards and Technology — publishes guidance called SP 800-57 that defines something called cryptoperiods. That's the maximum time a key should remain in active use. The logic is straightforward. The longer a key is in use, the more data gets encrypted with it. More encrypted data means more material for an attacker to analyse. And if a key gets compromised without you knowing — which happens — a shorter cryptoperiod limits the damage. You're containing the blast radius.

Dan: Mm-hmm. So how does rotation work in practice? If I've encrypted millions of documents with one key, do I need to decrypt and re-encrypt everything?

Alice: This is the elegant part of envelope encryption. When you rotate the master key, you're only rotating the top of the chain. The cloud KMS generates new key material but keeps all the old versions. Any new encryption uses the new material. Any old ciphertext still decrypts correctly because the KMS knows which version of the key was used and automatically selects it. You don't touch a single document. The rotation is invisible to your application.

Dan: That's much less painful than I expected. What about access controls — who's allowed to use these keys?

Alice: This is where key management gets interesting from a legal perspective. KMS platforms separate two roles: key users and key administrators. A key user — that's your application server — can request encrypt and decrypt operations. It cannot view, export, or delete the key. A key administrator can create, rotate, disable, and delete keys — but they may not be able to use the key for actual encryption. It's a separation of duties. Think of it like an ethical wall at a law firm. The conflicts department manages which matters can access which information. The litigation team uses that information. Neither can do the other's job.

Dan: Right. That makes sense. What about disaster recovery? What happens if you lose the master key?

Alice: Then every piece of data it protected is gone. Permanently. There's no backdoor, no recovery mechanism, no calling tech support. This is by design — the same property that makes encryption secure makes key loss catastrophic. So the mitigations are critical. Multi-region key replication, so if one data centre fails, you have a copy. Deletion safeguards — AWS KMS won't let you delete a key instantly; there's a mandatory waiting period of at least seven days, during which you can cancel. And dual-control procedures, meaning no single administrator can unilaterally destroy a key. You need two people to turn the key, like a nuclear launch.

Dan: Mm. That's sobering. Let me ask about a practical scenario. A law firm client terminates their contract. You need to delete their data. How does key management help there?

Alice: Great question. It's called crypto-shredding. If each client matter has its own data encryption key, you don't need to hunt down every copy of their data across your production database, backups, replicas, and caches. You just destroy their DEK. Without the key, the encrypted data is mathematically unrecoverable. It's faster, more complete, and more auditable than trying to find and delete every byte. For legal SaaS platforms that handle data subject access requests under GDPR or client offboarding, crypto-shredding is one of the cleanest architectural patterns available.

Dan: Yeah, that's a powerful pattern. Any real-world cautionary tales to close on?

Alice: Adobe, 2013. They encrypted 153 million passwords using 3DES — an old algorithm — but the critical failure was using the same key for every single password. Identical passwords produced identical ciphertext. Attackers didn't need to crack the key. They just looked for the most common ciphertext pattern, assumed it was "123456," and worked backwards. A hundred and fifty-three million accounts, and the key management was functionally nonexistent. More recently, the Orrick Herrington breach in 2023 exposed data on over 600,000 individuals and resulted in an eight million dollar settlement. The point is the same — encryption exists, but the key infrastructure around it determines whether it actually protects anything.

Dan: Next episode — Secrets Management. API keys, database passwords, service tokens — the other set of keys that keep your entire system running.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.