Key Availability & Failure Behavior
A customer-managed key (BYOK) is held entirely in your own AWS KMS or Azure Key Vault. BYOVault never has an independent copy of it. This page covers what that means operationally: how a wrap or unwrap failure is handled, how key reachability is monitored, and what happens if the key is permanently lost.
There is no fallback to the shared master key
For a tenant with an active BYOK configuration, every file backed up generates a genuinely random, per-file File Key locally, which is then wrapped by a call to the tenant’s own KMS key.
The wrap call can fail for a few reasons:
- The key has been disabled.
- The KMS or Key Vault endpoint cannot be reached.
- Permissions to use the key were revoked.
If it fails for any of these reasons, the backup of that specific file fails outright. There is no fallback to BYOVault’s shared master key when a BYOK wrap call fails — doing so would silently defeat the purpose of BYOK for that file. Deactivating BYOK takes effect from the next file onward.
Restore always uses the original key
Restore behaves the same way in reverse. A BYOK-protected file’s unwrap call always uses the same key reference that wrapped it at backup time — never whichever BYOK configuration happens to be active for the tenant today.
This matters because a tenant can later deactivate or reconfigure BYOK: doing so does not change which key an already-backed-up file resolves to. An older file always unwraps against the specific configuration that wrapped it, even after the tenant has moved on to a different key or provider. If that specific unwrap call fails, the restore of that file fails outright, with no fallback key to try instead.
The daily reachability check
Once a tenant’s BYOK configuration is first activated, a per-tenant scheduled check begins running once daily. Each run performs a read-only reachability check against the tenant’s key — never a real wrap or unwrap — and records the result.
- If the key is reachable, the tenant’s configuration is marked healthy and any previously recorded unreachable state is cleared. A key that recovers stops looking broken.
- If the key is unreachable and this is the first time that has been observed, BYOVault sends a warning email to the tenant’s account immediately, while the most time remains to act.
- If the key is unreachable and was already known to be unreachable from a previous day’s check, no repeat email is sent for the same ongoing incident, so the warning does not become routine noise.
A tenant with no active BYOK configuration is never checked.
A customer’s KMS key becomes permanently unavailable in two cases:
- It is disabled past the point of recovery.
- It is deleted and the provider’s own grace period has elapsed.
When that happens, every file wrapped under that specific key becomes permanently unrecoverable — including to BYOVault. BYOVault never holds an independent copy of a customer-managed key or of the File Keys it wraps, so the wrapped File Key recorded against each file is only ever useful if the key that wrapped it can still unwrap it.
This is not a support-escalatable problem once a provider’s deletion grace window closes.
Disabling a key, by contrast, is immediately reversible: re-enabling it restores full functionality with no data loss, since the key material itself was never destroyed.
What to do if the warning email arrives
If the key was disabled intentionally — a rotation in progress on your own side, or a policy change in your KMS or Key Vault — re-enabling it resolves the condition with no data loss, and the next daily check will clear the unreachable state automatically.
If the key is scheduled for deletion, cancelling that deletion before your provider’s grace period elapses is the only way to prevent the files wrapped under it from becoming permanently unrecoverable.
See Customer-Managed Keys (BYOK) for how a File Key is generated and wrapped in the first place, and Preparing for BYOK for what to have in place before activating a customer-managed key.