At some point an enterprise buyer will ask whether their data is encrypted with a key that is theirs alone. It is a reasonable question and the honest answer for most products is no — data at rest is encrypted, with one key, at the volume or the field level, for everybody.
Moving to a key per tenant is achievable and it does buy something specific. It is worth being precise about what, because the feature is often sold on a benefit it does not provide.
What it does and does not protect against
It does not protect against a compromise of your running application. Your service must be able to decrypt a tenant's data to serve their requests, so anything that can make it serve requests can read the plaintext. Per-tenant keys are not a defence against your own code being exploited.
What they do give you is a clean boundary in the places data sits still. A leaked storage snapshot or a misdirected backup yields ciphertext under keys held elsewhere. A bug that reads the wrong row fails to decrypt instead of returning it. And deletion becomes provable: destroy the key and the remaining ciphertext is unrecoverable, including the copies in backups you cannot selectively edit.
- Strong: storage-layer exposure, misdirected backups, provable deletion
- Weak: a compromise of the running service, which must hold the plaintext anyway
- Useful side effect: cross-tenant reads fail loudly instead of quietly succeeding
- Contractual: it is frequently what a buyer means by data isolation
Destroying a key deletes the data everywhere it was ever copied, including the backups you cannot edit.
The operational bill
A key per tenant means a key management call in the path of requests, which needs caching, and a cache of unwrapped keys is a new sensitive store with its own lifetime rules. It means a rotation job that iterates tenants. It means restores that depend on a key store as well as a data store, so your recovery procedure now has two dependencies that must both be healthy.
It also means the number of keys grows with your customer list, and key stores have quotas and per-operation costs. None of this is prohibitive, and all of it is easier to build early than to retrofit onto a system where the key is a constant in a configuration file.
Customer-managed keys are a different conversation
The next request after a key per tenant is usually a key the customer controls in their own infrastructure. That inverts an important property: they can revoke it, and when they do, your service loses access to their data immediately and by design. That is the feature, and it needs to be built as a supported state rather than encountered as an incident.
Decide in advance what your product does when a key becomes unavailable — degrade to a clear message, stop background jobs, avoid retry storms against their key store — and say so in the documentation. A customer who understands the consequence will use the control carefully. One who discovers it on a Friday will call it an outage.
- Treat key unavailability as a designed state with a clear user-facing message
- Do not retry aggressively against a customer key store you do not operate
- Cache unwrapped keys briefly, in memory, never on disk
- Log key use and key access failures; both are questions a reviewer will ask
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.