Per-Tenant Keys and Isolation for a Multi-Tenant SaaS Platform

Use envelope encryption with a separation of duties, and stop storing data keys beside ciphertext.

• Root of trust: a per-region HSM-backed KEK, non-exportable, with quorum-controlled administrative operations. EU tenant data is wrapped only by the EU KEK.
• Per-tenant KEK wrapped by the region KEK; per-object DEK wrapped by the tenant KEK. Cache unwrapped DEKs in service memory with a short TTL keyed by tenant and region, so the 8-12 ms unwrap is paid once per session rather than per query and you stay inside the 150 ms p95 budget.
• The application service performs unwrap, not the database. An operator with database access sees ciphertext and wrapped keys; unwrap needs an authenticated service identity plus an HSM policy condition, and every unwrap is logged with tenant context.

For isolation, standardise on one code path with tiered backends rather than three products a six-person team must operate: row-level security with a session-level tenant setting for most tenants, per-tenant schema for the top tier where blast radius matters, dedicated database only where a contract pays for it. Enforce tenant context in the data-access layer and run a cross-tenant read test suite on every build, because RLS bugs are silent and catastrophic.

For the enterprise tenant, BYOK: their key lives in their HSM and you store only a reference. That changes your availability model, which you must price and contract for.

BYOK converts a tenant's key-management outage into your outage, so design for it explicitly.

• Unwrap failure: if the tenant revokes their key or their HSM is down, their data becomes unreadable. Define the behaviour: fail closed for that tenant only, never for the platform; circuit breaker, bounded retries, clear error surfaces to the tenant.
• Cache is the availability buffer. Keep unwrapped DEKs in memory with a TTL long enough to ride out short KMS outages (for example 15 minutes) and short enough to limit exposure after revocation. State the trade-off openly: revocation takes effect at cache expiry, not instantly.
• Break-glass: a dual-control, time-boxed procedure using a provider-held recovery key, only where the contract permits it. If the contract does not permit it, say so plainly - the tenant owns the availability risk and must accept it in writing.
• Residency and disaster recovery: key material must not leave the region; replicate HSM clusters within region and define the regional-loss scenario. Run key-rotation and revocation drills at least twice a year, because an untested BYOK path is a latent outage discovered by a customer.
• Monitor unwrap latency and error rate per tenant and alert the tenant as well as your on-call, so they see a key problem before their users do.

Split the request.

Dedicated database: yes, at a price. It reduces blast radius and satisfies most auditors, but it is an operational cost (patching, backups, per-tenant migrations), so it belongs in the contract as a paid tier with a defined SLA rather than as a silent engineering promise.

Raw key material: no. Handing over the keys that protect data you still operate defeats the purpose - the tenant cannot verify how you used them, and you can no longer credibly claim you cannot read their data. Offer instead:

• BYOK: their key in their HSM, you hold only a reference, so revocation is a control they genuinely own.
• HYOK for exports and archives: they encrypt before upload and you never see plaintext.
• Evidence: per-tenant audit logs of every unwrap, crypto-shredding on deletion with a certificate, and third-party attestation of the HSM configuration.

Also say the trade-off out loud in the sales conversation: BYOK shifts availability risk to them and adds a dependency on their key service. The 60-day promise is unrealistic for the full capability. Deliver per-tenant keys and EU residency first, BYOK for this tenant second, and put the dates in writing before the contract is signed.