Set Up BYOK on Azure Key Vault

Customer-managed encryption keys (BYOK) mean your files are encrypted with a key that lives entirely in your own Azure Key Vault — BYOVault never has independent access to it. This procedure does not affect files already backed up.

1. Create a Key Vault

  1. Go to the Azure Portal → search Key Vault → click + Create.
  2. Pick or create a resource group and a globally unique vault name (e.g. acme-byok-vault).
  3. Pricing tier: Standard.
  4. On the Access configuration tab, choose Azure role-based access control (RBAC) — not “Vault access policy”. The role you’ll assign in step 4 is an RBAC role.
  5. Click Review + Create, then Create.

2. Create a key inside it

  1. Open the vault → Objects → Keys (left sidebar) → + Generate/Import.
  2. Options: Generate, Key type RSA, RSA key size 2048.
  3. Choose any name (for example, byok-file-key) and click Create.
Enable Purge Protection
Purge Protection guarantees the deletion grace window is real — without it, a deleted vault or key can be permanently purged early, skipping the window BYOVault’s health check relies on to warn you before data becomes unrecoverable. Enable it under the vault’s Properties tab.

3. Install BYOVault's app into your tenant

BYOVault authenticates to your Key Vault as one platform-wide multi-tenant application — the same app every BYOK customer installs, each granting it access only to their own key.

Installing it doesn’t give it any key. It only ever acts on whichever vault/key you explicitly grant it access to in step 4.

Sign in as an admin on your own tenant and open the link below, replacing YOUR_TENANT_ID with your own Azure AD tenant ID (Microsoft Entra ID → Overview → Tenant ID):

https://login.microsoftonline.com/YOUR_TENANT_ID/adminconsent?client_id=b8927c4b-567d-4b5f-9113-8e30eefee76e
Use your real tenant ID, not /common
The generic /common path lets Azure guess which tenant to use from whichever account happens to be signed in — if you have more than one Microsoft account signed in in the same browser, this can land you in the wrong tenant and fail with “account does not exist in tenant ‘Default Directory’.” Using your own real tenant ID avoids this entirely.

Approve the consent screen for “BYOVault BYOK Multi-Tenant”. You’ll land on a confirmation page showing your tenant is connected — this is expected, and the app has no access to anything yet at this point; that only happens in the next step.

4. Grant it access to your key

  1. Go to your Key Vault → Access control (IAM) → + Add → Add role assignment.
  2. Role: Key Vault Crypto Service Encryption User.
  3. Members → Select members → search “BYOVault BYOK Multi-Tenant” (it appears here once you’ve completed step 3) → select it.
  4. Click Review + assign.
Wrap/unwrap only — never raw key export
This role permits using the key to encrypt/decrypt data, never extracting the key material itself. This role does not permit key export by any party, including BYOVault.
You never need the Secrets blade
This setup only ever touches the vault’s Keys blade and the role assignment above — there is no reason for you or BYOVault to open or manage anything under Secrets. If you click into Secrets and see “You are unauthorized to view these contents,” that is expected and not a problem to fix: it is a separate, unrelated data-plane permission (e.g. Key Vault Secrets Officer) that this setup does not require.

5. Enter it into BYOVault

On the tenant’s own Encryption Key page. The provider and key fields do not appear until the consent checkbox acknowledging that deletion of the key is irreversible has been checked.

Once the fields appear, choose Azure Key Vault. Enter your vault’s URI (shown on its Overview page, e.g. https://acme-byok-vault.vault.azure.net/) and the key name from step 2, then click Verify and activate.

BYOVault performs a real wrap/unwrap round trip against your key before saving — a wrong URI or missing role assignment is caught here, not discovered later at your first backup.

Disabling vs. deleting your key
Disabling your key in Key Vault is instant and fully reversible — BYOVault’s daily health check will detect it and alert you, and re-enabling it restores everything immediately. Deleting it is different: Azure holds it in a recoverable, soft-deleted state for a grace period (up to 90 days with Purge Protection), after which it is permanently, irreversibly gone — and so is every file BYOVault encrypted with it. Disable a key you want to pause; never delete one you might still need.

See The Shared Master Key for how this compares to BYOVault’s default shared-master-key path.

PreviousInstalling the File Server AgentNextBYOK on AWS KMS