Platform18 Aug 2026 · 7 min read

Cross-Tenant Deduplication and Per-Tenant Keys Cannot Both Be True

Any vendor claiming both should be asked which one they implemented

By Kapardyn Engineering

Two claims appear together in a lot of multi-tenant backup material. The first is global deduplication: identical files across your whole client base are stored once, which reduces the storage footprint substantially. The second is per-tenant encryption: each client's data is isolated by its own key.

Both are good properties. They cannot both be present in the same system, and the reason is not that it is hard.

Why the two are exclusive

Deduplication works by recognising that two objects are byte-identical, usually by comparing a hash of their contents. If the hashes match, store one copy and reference it twice.

Encryption with distinct keys destroys exactly that property. The same plaintext encrypted under tenant A's key and tenant B's key produces different ciphertext — that is the definition of the guarantee. A storage layer looking at the two encrypted objects sees no relationship, because there is none to see.

THE SAME FILE, TWO TENANTS
Identical file stored for two tenantssame bytes
Encrypted under tenant A's data keyciphertext A
Encrypted under tenant B's data keyciphertext B
Do the ciphertexts match?no
Cross-tenant dedup under per-tenant keysimpossible
Blast radius if one tenant's key is compromised1 tenant
To deduplicate across tenants you must encrypt them under a shared key, or store them unencrypted, or hold a cross-tenant index of plaintext hashes. Each of those is a different security model to the one "per-tenant encryption" describes.

Which trade-off this platform took, and what it costs

We chose isolation. Every tenant gets its own AES-256-GCM data key, wrapped under that tenant's own key, with the master held in a managed key store. A compromise of one tenant's key decrypts exactly one tenant's data.

The cost is real: identical files across different clients are stored more than once, and we pay for that storage. Deduplication still happens within a tenant, where it is both safe and effective — the same attachment across a hundred mailboxes in one client is stored once.

Stating the cost is deliberate. A vendor claiming both properties is either describing within-tenant dedup in language that implies more, or has a shared-key model they have not made explicit. Neither is necessarily wrong; both are things you would want to know before signing.

The question to ask

If deduplication is global across your client base, what key is the data encrypted under? There is a coherent answer to that. There is no coherent answer that also preserves per-tenant key isolation.

Why blast radius is the right lens

Key architecture is usually discussed in terms of algorithm strength, which is the least interesting part — everyone is using AES-256, and nobody is breaking it. The question that separates designs is what a single compromised key opens.

Under a shared pool key, the answer is everything in that pool. Under per-tenant keys, the answer is one tenant. That difference does not show up in a feature comparison, and it is the difference that determines what a bad day looks like.

More in Platform →
See what's shipping

Every price we quote is published in full, no form required, on pricing. For what the platform protects, VentraID.