Not always. OWASP's multi-tenant guidance says to use tenant-specific encryption keys when risk or compliance requires cryptographic isolation, and says a shared managed key with enforced access context can be acceptable otherwise. Decide by what your buyers handle and what they ask, then describe your choice exactly.
What the guidance says
The OWASP Multi-Tenant Security Cheat Sheet covers per-tenant encryption under its storage and backup sections. Its position is balanced: tenant-specific keys when risk or compliance calls for cryptographic isolation, and a shared managed key with enforced access context where that is enough. It also notes that tenant keys should be retired during offboarding under the documented retention policy.
Three options
| Option | What it gives | Cost to you |
|---|---|---|
| Shared managed key | Encryption at rest, simple to run | One key covers all tenants |
| Key per tenant, you manage | Cryptographic separation between customers, key retirement at offboarding | More key management and testing |
| Customer supplied or controlled key | Customer can revoke access to their data | Highest complexity, new failure modes |
Ask what you gain at each step. A key per tenant limits what a bug in the access layer can expose only if the key itself is protected by a separate check. It is a second wall, not a replacement for the first.
Questions to ask before you build
- Do any current or target buyers ask for it in writing? Collect the real requests.
- Which data is sensitive enough to justify it? Maybe only some fields or stores.
- What happens during key loss or rotation? Test restore for one tenant.
- Who can use the keys, and how is each use logged?
- How will backups be handled, since old backups use old keys?
OWASP's restore advice is relevant here: recover one tenant into a separate resource and confirm no other tenant's data appears.
How to word the answer
If you use a shared key: "Data is encrypted at rest with keys managed in our cloud provider's key service. Access to keys is limited by role and logged. We do not currently offer per-customer keys, and we will evaluate customer managed keys on request."
If you use per-tenant keys: "Each customer's data is encrypted under a key specific to their tenant, managed in our key service. Keys are retired at offboarding per our retention policy."
Do not say "customer controlled" if you hold the keys. That phrase tells a buyer they can revoke access, which is a different claim.
When to wait
For a first enterprise deal, most reviewers accept strong encryption at rest with tight key access. Building a key per customer before anyone asks can slow product work. Put the roadmap in writing, and revisit when two or more buyers ask.
Quick check
Is a shared encryption key a failing answer?
Not by itself. OWASP says a shared managed key with enforced access context can be acceptable when cryptographic isolation is not required.
Does a tenant key replace access control checks?
No. It is an additional layer. Keep tenant checks in application and data layers.
Safeguard's policies, gates and guardrails help enforce secure configuration checks on changes, and its compliance evidence automation can collect settings for your records. The free scan covers your dependencies.
Sources
- OWASP, Multi-Tenant Security Cheat Sheet: per-tenant encryption, restore testing, key retirement. Paraphrased.
Last reviewed: 19 October 2026.
