Notifications
Clear all
Topic starter
22/06/2026 10:10 am
TL;DR: Multi-tenant SaaS encryption at rest only protects data if the key boundary sits at the tenant layer, not the database layer, according to WorkOS. Cryptographic isolation turns application bugs into contained leaks instead of cross-tenant breaches, because each tenant’s ciphertext is wrapped by a different key boundary.
NHIMG editorial — based on content published by WorkOS: Cryptographic key isolation in multi-tenant SaaS
Questions worth separating out
Q: How should security teams implement tenant-level key isolation in multi-tenant SaaS?
A: Start by making the tenant identifier the default encryption context, then ensure each context resolves to a separate key-encryption key.
Q: Why does encryption at rest not prevent cross-tenant SaaS breaches?
A: Encryption at rest protects storage media, not the application paths that legitimately decrypt data.
Q: What breaks when all tenants share one encryption key?
A: A shared key makes every tenant's ciphertext part of the same blast radius.
Practitioner guidance
- Define tenant-level key boundaries first Set organizationId or an equivalent tenant identifier as the default encryption context for every customer from day one, then extend it only when a second boundary such as data type is truly required.
- Remove manual key registries Let the key service derive and resolve KEKs from stored context instead of maintaining a separate database mapping tenants to key IDs, because registry drift is an operational failure mode.
- Separate regulated data into distinct contexts Use a second context dimension for sensitive classes such as PII, credentials, or payment data so regulated objects do not share the same key boundary as general application secrets.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how key context resolves the correct KEK for each tenant and object
- Implementation examples for envelope encryption and just-in-time key creation across SaaS workflows
- Concrete threat-model walkthroughs for compromised CMKs, tenant-specific access, and containment scope
- Operational limits for context objects, including how many key-value pairs and value lengths are supported
👉 Read WorkOS's analysis of cryptographic key isolation in multi-tenant SaaS →
Key context in SaaS encryption: what it means for tenant isolation?
Explore further
22/06/2026 10:58 am
Cryptographic isolation is the control that converts a tenant bug into a bounded incident. In multi-tenant SaaS, the failure is rarely that encryption is absent. The failure is that the key boundary sits too wide, so one broken authorization path can still expose every tenant's plaintext. The practitioner conclusion is simple: blast radius is a key-design problem, not only an access-control problem.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: What is the difference between logical isolation and cryptographic isolation?
A: Logical isolation depends on code, such as tenant IDs, schemas, or row-level policies, to keep records separated. Cryptographic isolation uses different keys so even leaked ciphertext remains unreadable outside the intended boundary. The first can fail through a bug or privileged session. The second still holds if the key separation is correct.
👉 Read our full editorial: Cryptographic key isolation for multi-tenant SaaS blast radius
