# Check Elastic SAN's iSCSI feature exclusions before copying a target design

> Can an existing CHAP-dependent iSCSI design be moved unchanged to Azure Elastic SAN?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-137-check-elastic-san-s-iscsi-feature-exclusions-before-copying-a-target-design/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:39+00:00
- Modified: 2026-09-10T00:52:39+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

Can an existing CHAP-dependent iSCSI design be moved unchanged to Azure Elastic SAN?

## Potentially affected

Use this compatibility gate before moving an existing iSCSI workload to Elastic SAN. Identify the source target's actual authentication, recovery and target-to-LUN assumptions; protocol naming alone does not establish equivalent features.

## DSE recommendation

Make unsupported initiator assumptions an explicit migration decision.

## Article

## Source facts

Azure Elastic SAN supports iSCSI but does not support CHAP authorization or initiator registration. Microsoft also lists iSCSI Error Recovery Levels 1 and 2 and more than one LUN per target as unsupported. Network access is configured at the volume-group level through private endpoints or service endpoints, and volumes inherit that configuration. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-planning).

## Applicability

Use this compatibility gate before moving an existing iSCSI workload to Elastic SAN. Identify the source target’s actual authentication, recovery and target-to-LUN assumptions; protocol naming alone does not establish equivalent features.

## DSE recommendation

Make unsupported initiator assumptions an explicit migration decision. Have the storage and security owners compare the existing design with Elastic SAN’s current support list. If CHAP or another excluded feature is required by the approved architecture, do not remove that requirement silently to make a connection succeed. Assess whether a separately approved network and access design can meet the workload’s needs, or whether another target service is required.

## Verification

In a controlled pilot, inspect the intended volume-group network boundary and the initiator’s target configuration. Test the agreed permitted and denied client paths and the application’s recovery behavior using the supported feature set. Record every requirement that remains unmet. Do not accept a basic iSCSI login as evidence that CHAP, initiator registration or advanced recovery behavior was preserved from the source system.

## Official references

[Microsoft Learn: Plan for an Azure Elastic SAN deployment](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-planning).

## Primary reference

- Name: Plan for an Azure Elastic SAN deployment | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-planning
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Check Elastic SAN's iSCSI feature exclusions before copying a target design,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-137-check-elastic-san-s-iscsi-feature-exclusions-before-copying-a-target-design/
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.