Every security questionnaire asks the question, and every SaaS answers it the same way: “Do you encrypt data at rest?” — “Yes, AES-256.” Box ticked, nobody learned anything. The interesting question is the one that follows two pages later, usually phrased as “Describe your key management practices” — who can decrypt, under what policy, with what audit trail, and what happens when a customer wants their key back. AES-256 is a commodity; the keys are the system. This part is about that system.
It is also the quiet foundation under everything so far. Part 1’s tenant isolation has a cryptographic expression. Part 2’s identity work decides who may call Decrypt. Part 3’s audit logs are where every key use lands. And the incident from Part 6 has a favorite lever: revoke the key, and the stolen ciphertext becomes a paperweight.
One architecture, and it’s not negotiable
The only at-rest encryption design worth building in a multi-tenant SaaS is envelope encryption, and the reason is operational, not mathematical. Data is encrypted with a data encryption key (DEK) — fast, local, symmetric. The DEK itself is encrypted (“wrapped”) by a master key (KEK) that lives in a KMS and never leaves it. You store the ciphertext plus the encrypted DEK (EDEK) side by side. The DEK exists in memory for exactly as long as the operation takes, then it’s wiped — never persisted, never logged, never in an environment variable.
What this buys is a decoupling that pays out for years. A database dump yields ciphertext and wrapped keys — both useless without an authorized, logged KMS call, which turns Part 3’s audit trail into the key-usage record auditors ask for by name. Master-key rotation becomes cheap (re-wrap the EDEKs, don’t touch the data), while the KMS becomes the single choke point where policy lives: which service role may unwrap which key, from which network, during which hours. PCI DSS 4.0 Requirement 3 formalizes the hygiene the questionnaire is probing for: documented lifecycle, dual control for key components, rotation at least annually or whenever a key custodian leaves. The math was never the hard part; the custody is.
Per-tenant keys: Part 1, but cryptographic
Give every tenant their own DEK hierarchy and three things fall out immediately. Blast radius: a key compromised or mis-scoped exposes one tenant, not the platform — the cryptographic version of Part 1’s row-level discipline, except this one is provable to an auditor rather than merely asserted. Targeted revocation: in the Part 6 incident, you can freeze one tenant’s data access without touching anyone else. And the sleeper feature, crypto shredding: deleting a tenant’s key renders their data unrecoverable, instantly, everywhere — including in backups you can’t selectively edit. GDPR erasure requests and enterprise offboarding both collapse from “a multi-week data hunt” to “a key deletion, with a log entry.”
The costs are real but modest: a KMS call per cold read (cache DEKs briefly, in memory only), and a key inventory to govern. What you should not do is the halfway version — one key per environment, or per database — which concentrates exactly the blast radius per-tenant keys exist to shrink.
BYOK, HYOK, and the alphabet soup of trust
Sooner or later an enterprise prospect writes BYOK into the questionnaire, and what happens next depends on knowing what they’re actually buying. The acronym soup — BYOK, CMK, EKM, HYOK, CHEK — reduces to one question: whose infrastructure does the key live on, and who can be compelled, breached, or subpoenaed into silence?
- BYOK / CMK — the customer generates a key and imports it into your KMS. They get ownership theater that is still genuinely useful: clean rotation, a named key per customer, a revocation lever. But the key now lives in your infrastructure, so the trust model hasn’t fundamentally changed — you (and anyone who can compel you) can still use it.
- HYOK / EKM — the key never leaves the customer’s HSM or external key manager. Every decryption is a brokered call to their endpoint: they see every use in their own log, and a 403 makes the data instantly unreadable. This is the answer to “can you read my data without me knowing?” — no, and here’s the evidence. It’s why Salesforce Shield, Dynamics on Azure Key Vault, and AWS’s ISV patterns (the data-key-broker sessions were a re:Invent 2025 staple) all converge on it for regulated buyers.
The price is why HYOK is an enterprise-tier feature, not a default: latency on every cold decrypt, availability coupling (the customer’s key outage becomes your product’s outage, on your status page), and an onboarding flow that looks suspiciously like Part 2’s SSO setup. Offer it when the deal size justifies the pager. And notice the elegant symmetry: HYOK hands your customer exactly what Part 3 taught you to build — a tamper-evident, self-serve log of every access to their data. You become someone else’s audit-log vendor.
The quantum footnote that isn’t a footnote
One migration is already underway whether you participate or not. NIST finalized the post-quantum standards in August 2024 — ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures, with HQC selected as a backup in March 2025 — and the deployment since has been fast: hybrid X25519MLKEM768 key exchange is on by default in Chrome and Firefox, Cloudflare expects the majority of its traffic post-quantum-protected by the end of this year, and Signal and iMessage moved their protocols over already. The driver is harvest now, decrypt later: adversaries recording ciphertext today to read when a cryptographically relevant quantum computer exists. NIST’s timeline — classical RSA/ECC deprecated by 2030, disallowed by 2035 — is for compliance; the HNDL window says long-lived data is exposed now.
The pragmatic triage for a SaaS is short. Your symmetric crypto is largely fine (AES-256 stays; quantum merely halves effective strength). Your TLS key exchange is mostly your edge provider’s problem — and they’re already solving it. What’s yours: anything you sign with a long-lived key (software updates, tokens with long validity), any encrypted archive expected to stay confidential for a decade, and the inventory itself — you cannot migrate what you haven’t mapped. The discipline being asked of you has a name, crypto-agility: algorithms behind configuration, keys versioned, rotation rehearsed. Teams that built envelope encryption properly are most of the way there; teams that hard-coded RSA in 2019 are about to find out where.
Where the series goes next
Current thinking for the next door: secure SDLC and the supply chain — the pipeline that ships the code everything else protects, from dependency provenance to build attestation, and why your CI is now the most privileged system you own. Data privacy engineering — retention, residency, and the DSAR treadmill — is the other strong candidate. As before: the order is decided when we get there.
Practice
- Inventory your keys today: every secret, where it lives, who can use it, and how you’d rotate it. If the honest answer includes “environment variables” or “we’re not sure,” that’s the finding — no questionnaire required.
- Build the envelope-encryption slice for one table: per-tenant DEK, KMS-wrapped, EDEK beside the ciphertext. Then run the shred test — delete a test tenant’s key and prove, to a skeptical colleague, that the data is unrecoverable including from yesterday’s backup.
- Rehearse the BYOK answer: if next week’s prospect asks “can we hold our own key?”, write the honest two paragraphs — what you’d support (imported CMK now, brokered HYOK later), what it costs them (latency, availability coupling), and what it costs you (one quarter of one engineer). Deals die on improvising this live.