Key Derivation & Hierarchy
This page covers the default (non-BYOK) path only: how the per-tenant encryption key used for a given operation is derived, held, and discarded.
Derivation function
On the default path, a tenant’s encryption key is not stored anywhere. It is derived on demand, at the start of a backup or restore operation, using a standard, industry-vetted key-derivation function.
The key is derived from the shared master key and the tenant’s own tenant ID, producing a 256-bit key — the size AES-256-GCM requires.
The same derivation is used consistently across BYOVault’s backup service, so a backup produced by one part of the system can always be restored by another. The derivation is validated with a shared set of test cases to guarantee that consistency.
Unique per tenant
The derivation binds the derived key to each tenant’s own identity: the same master key, combined with a different tenant ID, produces a completely different 256-bit key. No two tenants on the default path ever encrypt with the same derived key, even though every one of them ultimately traces back to the same underlying master key.
In-memory lifecycle
The derived key exists only in memory, and only for the duration of the operation that needs it. It is never written to disk, logged, or cached across operations.
At the start of a backup or restore operation, the key is derived once and used to encrypt or decrypt the data for that operation.
A fresh key is derived again, from scratch, the next time an operation for that tenant runs. There is no long-lived key held in memory across operations, and no key cache to invalidate.
Where derivation does not apply
This entire derivation step is specific to the default path.
A tenant with an active customer-managed key configuration uses a genuinely random File Key generated fresh per file and wrapped by the tenant’s own KMS key — that key is never derived from the shared master key, and this derivation process is not involved at all. See Customer-Managed Keys (BYOK) for that path in full.