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

> Which identity must receive access when an Azure disk encryption set uses a key in another tenant?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-050-authorize-the-customer-s-local-application-identity-for-cross-tenant-disk-keys/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:31:06+00:00
- Modified: 2026-09-10T00:32:01+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Which identity must receive access when an Azure disk encryption set uses a key in another tenant?

## Potentially affected

Service providers and customers configuring Azure managed disks with customer-managed keys held in a different Microsoft Entra tenant.

## DSE recommendation

Reconcile the application client ID and the customer's service-principal object ID before granting key access.

## Article

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-cross-tenant-customer-managed-keys).

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-cross-tenant-customer-managed-keys). Source reviewed September 9, 2026.

## Primary reference

- Name: Use a disk encryption set across Microsoft Entra tenants - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-cross-tenant-customer-managed-keys
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Authorize the customer's local application identity for cross-tenant disk keys,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-050-authorize-the-customer-s-local-application-identity-for-cross-tenant-disk-keys/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.