The Shared Master Key

Every tenant on the default key path derives its encryption key from one master key. This page covers where that master key itself is stored, and what hardening it does and does not provide.

Where the key comes from

The master key is held as a secret in a dedicated managed key vault, not in BYOVault’s application configuration. Access to it is independently authenticated and logged by the vault itself, and the key value is never copied into any deployment artifact. If the key cannot be retrieved, the operation fails outright rather than proceeding without one.

Hardening, not a BYOK substitute
Holding the master key in a managed key vault changes where the key is stored and who can observe access to it — it does not change who can derive it. Every tenant on the default path still has its encryption key derived from this one shared master key (see Key Derivation & Hierarchy), and BYOVault, as the operator of the service that accesses this key, can still derive any default-path tenant’s key from it. Vault-backed storage is an infrastructure-security improvement against the key leaking from BYOVault’s own infrastructure. It is not equivalent to a customer-held key, and it does not remove BYOVault from the set of parties that can derive tenant keys.

A tenant that requires BYOVault to be structurally unable to derive its key — not merely trusted not to — needs the customer-managed key path instead. See Customer-Managed Keys (BYOK) for the alternative where a genuinely random, per-file key is wrapped by a key the customer holds in their own KMS or Key Vault, never derived from anything BYOVault controls.

No key rotation
There is no rotation mechanism for this master key. Even if a new key value were put in place, data already written under the previous key is never re-derived or re-encrypted on any schedule.
PreviousKey Derivation & HierarchyNextCustomer-Managed Keys (BYOK)