Preparing for BYOK
Customer-managed keys (BYOK) remove BYOVault's shared master key from the trust model entirely, which means BYOVault also has no way to rescue a file if your own key becomes permanently unavailable. The mechanics of that failure mode are covered in Key Availability & Failure Behavior. This page is the practical checklist to walk through with your own team before flipping BYOK on.
There is no safety net if the key is gone for good
Under BYOK, every file gets a genuinely random File Key that only your own AWS KMS or Azure Key Vault key can unwrap. BYOVault never holds an independent copy of it.
As documented in Key Availability & Failure Behavior, a wrap or unwrap failure is never silently retried against BYOVault’s shared master key — it fails outright, on that file, by design.
That design is what makes BYOK meaningful, but it also means the cost of a mistake on your side — disabling the wrong key, or letting a deletion proceed past your provider’s grace period — is borne entirely by you, with no BYOVault-side recovery path.
The preparation below is about making sure the people who can act on your KMS key or Key Vault key never have to learn this distinction for the first time during an actual incident.
Know the difference between disabling and deleting, before you activate
Both AWS KMS and Azure Key Vault draw a hard line between disabling a key and deleting it, and the two are not equivalent in consequence:
| Action | Effect on BYOVault | Reversible? |
|---|---|---|
| Disable the key | The next daily reachability check detects it and sends a warning email. Backups and restores that depend on the key fail until it is re-enabled. | Yes — re-enabling restores full functionality immediately, with no data loss. |
| Schedule or request deletion | The key enters a provider-held recoverable state for a grace period, then is permanently destroyed. | Only until the grace period elapses. AWS KMS lets you choose a 7–30 day window at key creation; Azure Key Vault holds a deleted key or vault for up to 90 days when Purge Protection is enabled. |
See Set Up BYOK on AWS KMS and Set Up BYOK on Azure Key Vault for the exact setup steps, including enabling Purge Protection on Azure so the grace window is real rather than skippable.
Put the right people in front of the warning email
Once BYOK is active on a tenant, a daily reachability check runs against the configured key and sends a warning email the first time it finds the key unreachable.
Before activating BYOK, confirm two things:
- The mailbox or distribution list that receives this warning is actually monitored, and by someone who can reach whoever administers the KMS key or Key Vault — not a shared inbox nobody checks.
- That person understands, in advance, that the correct response depends entirely on why the key is unreachable: an intentional, in-progress change on your own side is generally fine to let resolve itself, while anything unexpected — and especially a deletion that was not requested — needs to be investigated immediately, before any provider grace period runs out.
Treat this email with the same urgency as a page, not as routine notification traffic. A key that stays unreachable long enough to cross a deletion grace period does not get a second chance.
Other things worth confirming before the first backup runs under BYOK
- Activating BYOK only affects files uploaded from that point forward — it never re-encrypts anything already backed up. Do not expect existing backups to gain BYOK protection retroactively; see Customer-Managed Keys (BYOK) for how the two populations of files coexist afterward.
- There is no supported key rotation workflow that re-wraps existing files under a new key. If your organization has a policy requiring periodic key rotation, confirm with whoever owns that policy how it will be reconciled with BYOK’s per-file key binding before activation, not after.
- AWS and Azure require different setup steps and grant different parties access to the key — see BYOK on AWS KMS: Architecture and BYOK on Azure Key Vault: Architecture to confirm which of your own administrators is actually in a position to grant, disable, or delete the key before you hand that responsibility to them.