BYOK on Azure Key Vault: Architecture
Azure's cross-tenant authorization model is structurally different from AWS's. This page covers how BYOVault authenticates into a customer's own Azure AD tenant with no shared secret ever stored anywhere.
For the step-by-step procedure of creating a Key Vault, creating a key, and installing BYOVault’s app, see Set Up BYOK on Azure Key Vault. This page instead covers the trust model underneath those steps: what is actually installed, and what it can and cannot do.
One multi-tenant application, not one per customer
BYOVault registers a single Entra (Azure AD) application, platform-wide, marked multi-tenant. Every BYOK customer on Azure installs this same application into their own tenant.
BYOVault does not register a separate application per customer, and no customer-specific application credential is created as part of onboarding.
This application authenticates using a federated identity mechanism rather than a stored client secret. No client secret for this application is generated, stored, or rotated anywhere in BYOVault’s infrastructure.
There is no secret value that reaching any BYOVault system, database, or environment would expose.
The customer-side one-time action
A customer activating Azure BYOK performs two actions, once, entirely inside their own tenant:
- Admin consent. A tenant administrator visits a Microsoft admin-consent URL for BYOVault’s multi-tenant application, which creates a service principal for that application inside the customer’s own tenant. Installing the application by itself grants it no access to any key — it creates a principal that can be granted a role, nothing more.
- Role assignment. The customer creates their own Key Vault and key, then assigns a role scoped specifically to wrap/unwrap operations against that vault (or that key) to the service principal created in step 1.
There is no role assignment that would let BYOVault, or the customer, export the key itself out of Key Vault; the key never leaves the vault it was created in, under any role.
Because the role is scoped to the customer’s own vault or key, revoking it at any time immediately and unilaterally cuts off BYOVault’s access, independent of anything on BYOVault’s side.
Revoking can mean either of the following:
- Removing the role assignment
- Disabling the key
No single point of compromise
BYOVault’s side of this exchange holds no long-lived, storable secret whose exposure would grant access to any customer’s key. Access to a specific customer’s Key Vault key is governed entirely by the role assignment that customer makes on their own vault, described above — nothing on BYOVault’s side can grant that access independently of it.
Call shape: one Key Vault operation per file
Each file’s protection uses a random 32-byte File Key, generated locally, which encrypts that file’s content using the same AES-256-GCM mechanics as BYOVault’s default key path (see Encryption Algorithm).
Only the small File Key itself is ever sent to your Key Vault, to be wrapped (on backup) or unwrapped (on restore) — once per file, never once per chunk. Call volume stays proportional to file count rather than to file size.
Your actual file content never passes through this exchange at all.
Health checks
A separate, side-effect-free health check periodically confirms your key is still reachable and enabled — never a real wrap or unwrap operation. See Set Up BYOK on Azure Key Vault for what happens when a key is disabled or deleted.