# Validate the hosted identity separately in a passwordless Queue migration

> DSE recommends recording the expected local principal and the expected hosted principal as two separate entries in the migration plan.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-097-validate-the-hosted-identity-separately-in-a-passwordless-queue-migration/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:33:23+00:00
- Modified: 2026-09-17T16:38:46+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: IT
- Reading time: 1 minutes

## What you need to know

DSE recommends recording the expected local principal and the expected hosted principal as two separate entries in the migration plan.

## Potentially affected

Use this guide when an existing application is being migrated from a secret-based Queue Storage connection to the documented passwordless approach.

## DSE recommendation

DSE recommends recording the expected local principal and the expected hosted principal as two separate entries in the migration plan.

## Article

## Source facts

Microsoft’s migration guide configures a developer’s user permissions for local execution and then configures a managed identity for the deployed application. DefaultAzureCredential chooses among supported authentication methods at runtime, allowing local and deployed environments to use different methods. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/queues/passwordless-migrate-queues)

## Applicability

Use this guide when an existing application is being migrated from a secret-based Queue Storage connection to the documented passwordless approach.

## DSE recommendation

DSE recommends recording the expected local principal and the expected hosted principal as two separate entries in the migration plan. Verify the intended hosted identity association and its required queue permissions before deployment. Ask the application owner to define a small end-to-end message test that can be repeated in both environments. Keep any old connection-secret retirement as a later controlled step after the deployed path has been validated.

## Verification

Run the agreed test locally and again in the actual hosting environment. For each run, retain enough configuration evidence to identify the intended principal and target queue without exposing credentials or message content. Investigate a hosted authorization failure as its own finding, and do not infer deployment readiness solely from the developer’s successful local run.

## Official references

- [Microsoft: Migrate applications to use passwordless authentication with Azure Queue Storage – Azure Storage | Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/queues/passwordless-migrate-queues)

## Primary reference

- Name: Migrate applications to use passwordless authentication with Azure Queue Storage - Azure Storage | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/queues/passwordless-migrate-queues
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Validate the hosted identity separately in a passwordless Queue migration,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-097-validate-the-hosted-identity-separately-in-a-passwordless-queue-migration/
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.
