Choose the key identity before creating an encrypted Elastic SAN volume group

Source facts

A new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.

The key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. Microsoft Learn.

Applicability

Use this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.

DSE recommendation

DSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.

Verification

Rehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.

Official references

Microsoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN. Source retrieved September 9, 2026.