Authorize the customer's local application identity for cross-tenant disk keys

Source facts

Microsoft’s cross-tenant disk-key design combines a provider’s multitenant application and federated user-assigned identity with a customer-side service principal and key vault. Installing the application preserves its client ID but creates a different object ID for the customer’s service principal. Key access must use the vault’s active authorization mechanism. The managed disks and customer key vault must share an Azure region, although subscriptions may differ. Microsoft Learn.

Applicability

Use this check when the disk resource and encryption key belong to different Microsoft Entra tenants. Identify both tenants, the provider’s disk encryption set and identity, and the customer’s installed application instance. Confirm regional and disk-type availability before preparing the authorization exchange.

DSE recommendation

Reconcile the application client ID and the customer’s service-principal object ID before granting key access. Have the customer verify the installed application against the provider’s approved registration, then select its local identity for the applicable vault permission. Exchange identifiers and the approved key location through the agreed channel; do not substitute the provider application’s object ID merely because its display name matches.

Verification

Inspect the resulting customer-side permission and the provider’s disk-encryption-set configuration together. In an approved test, confirm that the intended disk can use the customer-held key without broadening access to unrelated identities. Retain the two-tenant identifier mapping, authorization scope, and test outcome without key material or tokens. Resolve a mismatch at the identity or permission boundary before investigating the encryption setting itself.

Official references

Microsoft Learn: Encrypt managed disks with cross-tenant customer-managed keys. Source reviewed September 9, 2026.