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

> Distinguish customer-managed-key setup during volume-group creation from configuration of an existing group.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:31:38+00:00
- Modified: 2026-09-10T00:32:00+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Distinguish customer-managed-key setup during volume-group creation from configuration of an existing group.

## Potentially affected

Azure Elastic SAN volume groups using customer-managed encryption keys.

## DSE recommendation

Prepare a user-assigned identity for creation-time key access, and review later identity changes separately.

## Article

## 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](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys).

## 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](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys). Source retrieved September 9, 2026.

## Primary reference

- Name: Configure Customer-Managed Keys for Azure Elastic SAN | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Choose the key identity before creating an encrypted Elastic SAN volume group,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/
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.