Stop Using Connection Strings: A Step-by-Step Guide to Azure Managed Identities in 2026

Stop Using Connection Strings:
A Step-by-Step Guide to Azure Managed Identities in 2026

Every hardcoded connection string in your codebase is a liability waiting to become an incident. Azure Managed Identities eliminate credentials entirely — no passwords, no rotation schedules, no leaked secrets in Git history. This guide walks through every scenario: App Service, Azure Functions, AKS, Azure SQL, Key Vault, Blob Storage, and Service Bus — with working code in Python, C#, and Bicep.

Root cause of cloud data breaches: exposed credentials — hardcoded secrets, leaked keys, and unrotated connection strings in source code and CI/CD pipelines

Zero

Credentials stored anywhere — in code, config files, environment variables, or deployment pipelines — when Managed Identity is implemented correctly

Auto

Azure rotates the underlying credential for Managed Identities automatically. There is no rotation schedule to manage and no expiry date to miss

1 line

The DefaultAzureCredential class — one import, one instantiation — handles authentication to every Azure service in both local development and production, with no code changes between environments

Why Connection Strings Are a Security Liability You Cannot Afford

A connection string with an embedded password is a credential that exists in at least five places you did not intend: your application config file, your deployment pipeline variables, your team's local environment files, your Git history (if a developer ever committed it by mistake), and the memory of every developer who has ever set up the application. Each of those locations is a potential exfiltration point.

The problem compounds as the credential ages. Rotation schedules are missed. New team members are onboarded with the old credentials. Old credentials accumulate in old CI/CD variable sets that nobody audits. The connection string that was "temporary" two years ago is now production-critical and nobody knows when it was last changed or who has access to it.

Azure Managed Identity eliminates all of this. It gives your Azure resource — a VM, an App Service, an Azure Function, an AKS pod — its own identity in Microsoft Entra ID. That identity can be granted precise RBAC permissions on target resources. When your code needs to access Azure SQL, Key Vault, or Blob Storage, it requests a short-lived access token using that identity. No password, no connection string, no rotation — Azure handles all of it automatically.

The security outcome is definitive: there is no credential to steal. The most sophisticated credential exfiltration attack cannot extract a password that was never created.

❌ Before — Connection string in App Settings

# appsettings or environment variable
DB_CONNECTION="Server=sql.database.windows.net;
Database=prod;User ID=appuser;
Password=S3cur3P@ssword!;
Encrypt=True;"

# Problems:
# - Password in config / Git / CI-CD
# - Manual rotation required
# - Leaked = full DB access

✓ After — Managed Identity + DefaultAzureCredential

# Connection string — no password
DB_CONNECTION="Server=sql.database.windows.net;
Database=prod;
Authentication=Active Directory Default;
Encrypt=True;"

# Benefits:
# - No credential anywhere
# - Azure rotates token automatically
# - RBAC-scoped access only

How Azure Managed Identity Works: The Authentication Flow

Understanding the token exchange flow is essential before implementing Managed Identity. The following diagram shows exactly what happens when your application code calls Azure SQL using a Managed Identity — and crucially, what does not happen (no password is ever transmitted or stored).

Figure 1 — Managed Identity token flow: how passwordless authentication works end-to-end

The App Service never handles a password. It requests a token from the Azure-internal IMDS endpoint. Entra ID validates the identity and returns a short-lived JWT. The JWT is presented to Key Vault, which validates it against RBAC. No credential is ever stored or transmitted.

System-Assigned vs User-Assigned: Which Type to Use and When

Managed Identities come in two types. Choosing the correct type for each scenario is a design decision — not a technical preference. The wrong choice creates either unnecessary complexity (user-assigned where system-assigned suffices) or permission sprawl (system-assigned where user-assigned is needed).

Figure 2 — System-Assigned vs User-Assigned Managed Identity: lifecycle and sharing model

Use System-Assigned for a single resource with unique permissions. Use User-Assigned when multiple resources (e.g., dev/staging/prod Function Apps) need identical access to the same Key Vault or SQL database — assign the RBAC role once to the User-Assigned MI, then attach it to all resources.

Factor	System-Assigned	User-Assigned
Lifecycle	Tied to the Azure resource. Deleted automatically when the resource is deleted.	Independent Azure resource. Survives deletion of attached resources. Must be deleted separately.
Sharing	One identity per resource. Cannot be shared.	One identity can be attached to multiple resources simultaneously.
RBAC assignment	Must be done per resource. 10 App Services = 10 RBAC assignments on Key Vault.	Assign RBAC once to the User-Assigned MI. All attached resources inherit access.
Best for	Single resource with unique access requirements. Most common for production VMs and App Services with dedicated Key Vaults.	Multiple resources needing identical permissions. Dev/staging/prod parity. Resources frequently replaced (containers, AKS pods).
IaC complexity	Simpler — enable on the resource in Bicep/Terraform, then assign RBAC.	Requires creating an Microsoft.ManagedIdentity/userAssignedIdentities resource separately, then referencing it in the compute resource and RBAC assignment.
Recommendation	Default choice for App Service, Azure Functions (single-environment), and VMs.	Choose for AKS workloads, multi-environment Function Apps, and any scenario with 3+ resources sharing identical permissions.

Implementation Scenarios

Scenario 1App Service + Azure Key Vault: Passwordless Secret RetrievalMost Common

The most common Managed Identity use case: your App Service needs to read secrets from Azure Key Vault — database passwords (for services that don't yet support Entra auth), third-party API keys, TLS certificates — without storing those secrets in application settings or config files.

1

Enable System-Assigned Managed Identity on the App Service

Portal: App Service → Identity → System assigned → Status: On → Save. CLI: az webapp identity assign --name YOUR-APP --resource-group YOUR-RG. Note the Object (principal) ID from the output — you need it for the RBAC assignment.

2

Create a Key Vault (if not already existing)

az keyvault create --name YOUR-KV --resource-group YOUR-RG --location eastus --enable-rbac-authorization true. The --enable-rbac-authorization flag switches Key Vault from the legacy access policy model to RBAC — the recommended approach in 2026. If your vault already exists with access policies, migrate to RBAC in the Key Vault → Access configuration blade.

3

Assign "Key Vault Secrets User" role to the App Service MI

az role assignment create --assignee OBJECT-ID-FROM-STEP-1 --role "Key Vault Secrets User" --scope /subscriptions/SUB-ID/resourceGroups/YOUR-RG/providers/Microsoft.KeyVault/vaults/YOUR-KV. This grants read-only access to secrets. Use "Key Vault Secrets Officer" if the app also needs to set or update secrets.

4

Use Key Vault References in App Settings (zero code change)

Replace any secret value in App Settings with a Key Vault reference: @Microsoft.KeyVault(SecretUri=https://YOUR-KV.vault.azure.net/secrets/SECRET-NAME/). The App Service resolves the reference at runtime using its Managed Identity — your application reads the setting as a normal environment variable. No SDK required.

5

Alternative: Read secrets in code using the SDK

Install azure-keyvault-secrets and azure-identity. Use DefaultAzureCredential() to authenticate. Shown in the code block below.

Python — Read Key Vault secret using Managed Identity# pip install azure-keyvault-secrets azure-identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

# DefaultAzureCredential uses Managed Identity when deployed to Azure
# and uses az login / VS Code credentials when running locally
credential = DefaultAzureCredential()

client = SecretClient(
    vault_url="https://YOUR-KV.vault.azure.net",
    credential=credential
)

# Fetch the secret — no password, no connection string
db_password = client.get_secret("db-password").value
api_key = client.get_secret("external-api-key").value

# Use the values normally — they are plain strings
print(f"Connected. API key retrieved: {api_key[:4]}****")

Scenario 2Azure Functions + Azure SQL Database: Passwordless ConnectionHigh Impact

Azure SQL Database natively supports Microsoft Entra authentication. This means your Function App can connect to SQL using its Managed Identity — presenting a JWT token instead of a username and password. The SQL driver handles the token exchange transparently.

1

Enable Managed Identity on the Function App

az functionapp identity assign --name YOUR-FUNC --resource-group YOUR-RG. Note the principal ID from the output.

2

Set a Microsoft Entra Admin on the Azure SQL Server

The SQL server must have a Microsoft Entra admin before you can create Entra-backed database users. Portal: SQL Server → Microsoft Entra ID → Set admin → select your admin user or group. CLI: az sql server ad-admin create --server-name YOUR-SQL --resource-group YOUR-RG --display-name "SQL Admin" --object-id YOUR-ENTRA-USER-OBJECT-ID

3

Create a database user mapped to the Function App's MI

Connect to the target database as the Entra admin (not SQL auth) and run these T-SQL statements. Replace my-function-app with your actual Function App name.

4

Update the connection string — remove the password

Set the App Setting on the Function App: Server=tcp:YOUR-SQL.database.windows.net,1433;Database=YOUR-DB;Authentication=Active Directory Default;Encrypt=True;. The Authentication=Active Directory Default directive instructs the Microsoft.Data.SqlClient driver to use DefaultAzureCredential — no password in the string.

T-SQL — Create database user for the Function App's Managed Identity-- Connect as the Entra admin (NOT SQL auth) to the target database
-- Run these in the target database, not master

-- Create the external user mapped to the MI
CREATE USER [my-function-app] FROM EXTERNAL PROVIDER;

-- Grant read + write access
ALTER ROLE db_datareader ADD MEMBER [my-function-app];
ALTER ROLE db_datawriter ADD MEMBER [my-function-app];

-- Optional: allow stored procedure execution
GRANT EXECUTE TO [my-function-app];

-- Verify
SELECT name, type_desc FROM sys.database_principals
WHERE name = 'my-function-app';

C# — Connect to Azure SQL using DefaultAzureCredential (no password)// NuGet: Microsoft.Data.SqlClient, Azure.Identity
using Microsoft.Data.SqlClient;
using Azure.Identity;

public class DatabaseService
{
    private readonly string _connectionString;

    public DatabaseService(IConfiguration config)
    {
        // No password in connection string
        _connectionString = config["SqlConnectionString"];
        // e.g. "Server=tcp:...;Database=mydb;Authentication=Active Directory Default;Encrypt=True;"
    }

    public async Task<IEnumerable<string>> GetProductsAsync()
    {
        // SqlClient uses DefaultAzureCredential under the hood
        // when Authentication=Active Directory Default is set
        await using var conn = new SqlConnection(_connectionString);
        await conn.OpenAsync(); // Token acquired automatically — no password
        var cmd = new SqlCommand("SELECT Name FROM Products", conn);
        var reader = await cmd.ExecuteReaderAsync();
        var results = new List<string>();
        while (await reader.ReadAsync()) results.Add(reader.GetString(0));
        return results;
    }
}

Scenario 3App Service + Azure Blob Storage: Passwordless File AccessCommon Pattern

Azure Blob Storage supports Entra-based authentication via RBAC roles. Instead of putting a storage account key or SAS token in your application config, assign the appropriate Storage RBAC role to your App Service's Managed Identity and access blobs using DefaultAzureCredential. This also eliminates the rotation risk of storage account keys.

1

Assign the correct Storage RBAC role to the Managed Identity

Navigate to the Storage Account → Access Control (IAM) → Add Role Assignment. Choose: Storage Blob Data Reader (read-only), Storage Blob Data Contributor (read + write), or Storage Blob Data Owner (full control including ACLs). Assign to your App Service's Managed Identity. Scope it to the specific container if the app should only access one container.

2

Store only the storage account URL in App Settings

Add an App Setting: STORAGE_URL=https://YOUR-ACCOUNT.blob.core.windows.net. No account key, no SAS token, no connection string with credentials.

3

Use BlobServiceClient with DefaultAzureCredential in code

Install azure-storage-blob and azure-identity. Instantiate the client with the credential — shown below.

Python — Blob Storage access using Managed Identity# pip install azure-storage-blob azure-identity
import os
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# No account key — just the URL and DefaultAzureCredential
credential = DefaultAzureCredential()
storage_url = os.environ["STORAGE_URL"] # e.g. https://myaccount.blob.core.windows.net

blob_service = BlobServiceClient(account_url=storage_url, credential=credential)
container = blob_service.get_container_client("my-container")

# Upload a file
with open("report.pdf", "rb") as data:
    container.upload_blob(name="reports/report.pdf", data=data, overwrite=True)

# Download a file
blob = container.get_blob_client("reports/report.pdf")
download = blob.download_blob()
content = download.readall()

Scenario 4AKS Workload Identity: Pods Without SecretsAdvanced

Kubernetes pods running on AKS cannot use System-Assigned Managed Identity directly (that is assigned to the node VM, not the pod). AKS Workload Identity is the Microsoft-recommended solution: it federates a Kubernetes Service Account with a User-Assigned Managed Identity in Entra ID, allowing specific pods to acquire tokens for Azure services without any credentials in the pod spec or container image.

1

Enable OIDC Issuer and Workload Identity on the AKS cluster

az aks update --name YOUR-CLUSTER --resource-group YOUR-RG --enable-oidc-issuer --enable-workload-identity. Get the OIDC issuer URL: az aks show --name YOUR-CLUSTER --resource-group YOUR-RG --query "oidcIssuerProfile.issuerUrl" -o tsv

2

Create a User-Assigned Managed Identity

az identity create --name workload-identity --resource-group YOUR-RG. Note the clientId and principalId from the output. Assign the necessary Azure RBAC roles to this identity (e.g., Key Vault Secrets User on your Key Vault).

3

Create the Kubernetes Service Account with MI annotation

Create a Kubernetes Service Account annotated with the MI's client ID and configure the federated identity credential — shown in the YAML below.

4

Create the Federated Identity Credential

az identity federated-credential create --name aks-fed-cred --identity-name workload-identity --resource-group YOUR-RG --issuer OIDC-ISSUER-URL --subject system:serviceaccount:YOUR-NAMESPACE:YOUR-SERVICE-ACCOUNT --audiences api://AzureADTokenExchange

5

Reference the Service Account in your pod spec

Add serviceAccountName: YOUR-SERVICE-ACCOUNT to your Deployment pod spec. Pods using this Service Account will automatically receive a projected token that DefaultAzureCredential exchanges for Azure access tokens — no secrets mounted in the pod.

YAML — Kubernetes Service Account + Deployment with Workload Identity# service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
  annotations:
    azure.workload.identity/client-id: "YOUR-USER-ASSIGNED-MI-CLIENT-ID"
  labels:
    azure.workload.identity/use: "true"

---
# deployment.yaml — pod references the Service Account
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: my-app-sa # Use the annotated SA
      containers:
      - name: app
        image: myregistry.azurecr.io/my-app:latest
        # No environment variables with secrets
        # DefaultAzureCredential picks up the projected token automatically

DefaultAzureCredential: The One Class That Works Everywhere

DefaultAzureCredential is the Azure Identity SDK class that makes passwordless authentication work in both local development and production without any code changes between environments. It tries authentication methods in a defined sequence and uses the first one that succeeds:

Figure 3 — DefaultAzureCredential resolution chain: local dev vs Azure production

DefaultAzureCredential is the bridge between local development (where Managed Identity is not available) and Azure production (where it is). The same code, unchanged, authenticates correctly in both environments.

Local Dev Tip

For local development, run az login once in your terminal. DefaultAzureCredential will use your Azure CLI session. To simulate a specific Managed Identity locally (for testing RBAC assignments), set the environment variables AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and AZURE_TENANT_ID for a Service Principal — DefaultAzureCredential will pick these up first in its chain. Never commit these values. Use a .env file excluded from Git.

Provisioning Managed Identity with Bicep and Terraform

Managed Identity and RBAC assignments should always be in your Infrastructure-as-Code — not configured manually in the portal. Manual configurations are invisible to code review, are not version-controlled, and are the first thing to drift in a multi-environment deployment.

Bicep — App Service with System-Assigned MI + Key Vault Secrets User RBAC// Key Vault
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: keyVaultName
  location: location
  properties: {
    sku: { family: 'A', name: 'standard' }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // RBAC model, not legacy access policies
  }
}

// App Service with System-Assigned Managed Identity
resource appService 'Microsoft.Web/sites@2023-01-01' = {
  name: appServiceName
  location: location
  identity: {
    type: 'SystemAssigned' // Enables System-Assigned MI
  }
  properties: { serverFarmId: appServicePlan.id }
}

// RBAC: Grant the App Service MI "Key Vault Secrets User" role
var keyVaultSecretsUserRoleId = '4633458b-17de-408a-b874-0445c86b69e6'

resource kvRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, appService.id, keyVaultSecretsUserRoleId)
  scope: keyVault
  properties: {
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleId)
    principalId: appService.identity.principalId // The MI's object ID
    principalType: 'ServicePrincipal'
  }
}

Terraform — User-Assigned Managed Identity + AKS Workload Identity federated credential# Create User-Assigned Managed Identity
resource "azurerm_user_assigned_identity" "workload_mi" {
  name        = "workload-identity"
  resource_group_name = var.resource_group_name
  location    = var.location
}

# Assign Key Vault Secrets User role to the MI
resource "azurerm_role_assignment" "kv_secrets_user" {
  scope             = azurerm_key_vault.main.id
  role_definition_name = "Key Vault Secrets User"
  principal_id       = azurerm_user_assigned_identity.workload_mi.principal_id
}

# Federated identity credential linking AKS Service Account to the MI
resource "azurerm_federated_identity_credential" "aks_fed" {
  name            = "aks-workload-fed-cred"
  resource_group_name = var.resource_group_name
  audience        = ["api://AzureADTokenExchange"]
  issuer          = azurerm_kubernetes_cluster.main.oidc_issuer_url
  parent_id       = azurerm_user_assigned_identity.workload_mi.id
  subject         = "system:serviceaccount:my-namespace:my-app-sa"
}

Local Development Without Breaking the Passwordless Pattern

Managed Identity is only available on Azure-hosted resources. When developers work locally, they need an equivalent mechanism that does not require secrets. These are the three approaches in priority order:

Azure CLI login (recommended for most scenarios): Run az login in your terminal. DefaultAzureCredential picks up the session automatically. No environment variables needed. This works for Key Vault, Blob Storage, Service Bus, and most Azure SDK clients.
Visual Studio / VS Code login: DefaultAzureCredential uses the account signed in to Visual Studio or the Azure Account extension in VS Code. Useful for .NET developers who live in the IDE.
Service Principal with environment variables (for CI/CD or team environments): Create a Service Principal with the same RBAC roles as the Managed Identity: az ad sp create-for-rbac --name local-dev-sp. Set AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID in a .env file. Add .env to .gitignore — never commit it.

⚠ Common Mistake

Do not add ManagedIdentityCredential or ChainedTokenCredential with hard-coded fallback secrets to work around local dev issues. The correct solution is DefaultAzureCredential plus az login. Any workaround that introduces a credential for local development undermines the entire passwordless model and creates exactly the secret you were trying to eliminate.

Migration Checklist: From Connection Strings to Managed Identity

Use this checklist when migrating an existing application from hardcoded credentials to Managed Identity. Work through it in order — skipping steps is the most common cause of authentication failures during migration.

Pre-Migration

Inventory all connection strings, account keys, and passwords currently in App Settings, Key Vault, environment variables, and code. Document each one: what service it accesses, what permissions it uses, and which application uses it.

Verify the target service supports Microsoft Entra authentication. Azure SQL, Blob Storage, Key Vault, Service Bus, Event Hubs, Cosmos DB, and Azure Cache for Redis all do. Some third-party SaaS integrations do not — those still need credentials stored in Key Vault, accessed via MI.

Switch your Key Vault(s) from Access Policies to RBAC mode. In Key Vault → Access configuration → Permission model → Azure role-based access control. Existing access policies are not automatically converted — re-add them as RBAC assignments after switching.

Confirm your application's SDK packages support DefaultAzureCredential: azure-identity ≥ 1.5 (Python), Azure.Identity ≥ 1.3 (.NET), @azure/identity ≥ 2.0 (Node.js). Older SDK versions may not support the full credential chain.

Implementation

Enable Managed Identity on each Azure resource (App Service, Function App, VM, AKS cluster). For AKS, enable OIDC issuer and Workload Identity on the cluster.

Assign the minimum required RBAC role to each Managed Identity on each target resource. Use least-privilege: Key Vault Secrets User (not Contributor), Storage Blob Data Reader (not Owner), db_datareader + db_datawriter (not db_owner).

For Azure SQL: set a Microsoft Entra admin on the SQL server, connect as that admin, and create a database user mapped to each Managed Identity's external provider.

Replace all credential-based client instantiation in code with DefaultAzureCredential(). Replace all connection strings containing passwords with passwordless equivalents (Authentication=Active Directory Default for SQL; account URL only for Storage).

Add all Managed Identity and RBAC assignments to Bicep or Terraform — not just the portal. Code review of IaC changes is the governance mechanism for identity permissions.

Validation and Cleanup

Test locally using az login and confirm DefaultAzureCredential resolves successfully. Test in a staging environment with the actual Managed Identity before deploying to production.

In Microsoft Entra ID → Sign-in logs, filter by the Managed Identity's principal ID to confirm token requests are succeeding. Any authentication failure appears here before it surfaces as an application error.

After confirming passwordless authentication works in production, remove the old connection strings and credentials from App Settings, Key Vault, and CI/CD pipeline variables.

Rotate and then revoke the old SQL user password, storage account key, or API key that was replaced. This invalidates any copies that may have leaked without surfacing any production impact.

Search your Git history for the old credentials using git log -p | grep "old-password-value". If found in history, treat the credential as compromised and revoke it immediately regardless of rotation status.

Key Takeaways

→There is no credential to steal. Managed Identity eliminates the attack surface entirely. The most sophisticated credential exfiltration attack — scanning Git history, reading environment variables, intercepting network traffic — cannot extract a password that was never created.

→DefaultAzureCredential is the bridge between local and production. The same code, with the same import and the same instantiation, authenticates with your Azure CLI session locally and with the Managed Identity in Azure — with zero code changes between environments.

→Use System-Assigned for one resource with unique permissions. Use User-Assigned for multiple resources sharing the same permissions. Assigning RBAC roles to a User-Assigned MI once and attaching it to 10 Function Apps is dramatically simpler than managing 10 separate RBAC assignments.

→Switch Key Vault to RBAC mode. The legacy Access Policies model is functional but harder to audit, harder to manage at scale, and not compatible with Azure Policy-based RBAC governance. Every new Key Vault should use RBAC from day one.

→For AKS, use Workload Identity — not pod identity or node-level MI. AKS Workload Identity is the current Microsoft-recommended approach. It scopes credentials to individual pods via Kubernetes Service Account federation, not to the entire node VM.

→All Managed Identity and RBAC assignments belong in IaC. Bicep and Terraform changes to identity and permissions go through code review. Manual portal configurations do not. Any RBAC assignment not in code will eventually drift from the documented security posture.

→After migration, rotate and revoke the old credentials immediately. Working passwordless authentication does not expire the old credentials. Any leaked copy of the old connection string remains valid until explicitly revoked. Rotation followed by revocation is the final step — not an optional one.

Frequently Asked Questions

Can I use Managed Identity to access resources in a different Azure tenant?

No — Managed Identity is a same-tenant feature. A Managed Identity in Tenant A cannot directly authenticate to resources in Tenant B. For cross-tenant access, use a Service Principal registered in the target tenant and store the client secret in your Key Vault (accessed via Managed Identity). For Azure workloads that run outside Azure entirely (on-premises servers, GitHub Actions pipelines), use Federated Identity Credentials with a Service Principal — the same Workload Identity mechanism used for AKS, applied to external identity providers like GitHub's OIDC endpoint.

What happens if I delete an App Service that has a System-Assigned Managed Identity?

The Managed Identity is automatically deleted from Microsoft Entra ID when the App Service is deleted — this is the lifecycle-coupling property of System-Assigned identities. Any RBAC assignments made to that identity are also automatically cleaned up. This is generally correct behavior, but it means that if you delete and recreate an App Service (e.g., during a migration), the new App Service gets a new identity with a different Object ID, and you must recreate all RBAC assignments. For resources that are frequently recreated, use User-Assigned Managed Identity instead — it survives the deletion of the attached compute resource.

My third-party service (e.g., Twilio, Stripe) does not support Entra authentication. Do I still need a connection string?

Yes — but the credential lives in Key Vault, not in your application code or configuration. Store the third-party API key as a Key Vault secret. Your application accesses Key Vault using Managed Identity (passwordless) and retrieves the third-party credential at runtime. This is the recommended pattern for any service that does not natively support Entra authentication: Managed Identity → Key Vault → third-party credential. The credential still exists, but it is in one secure, audited location rather than scattered across code and deployment pipelines.

How do I verify that my application is actually using Managed Identity and not a leftover connection string?

Three checks: (1) In Microsoft Entra ID → Sign-in logs → filter by the MI's principal ID — you should see successful token acquisitions timed with your application requests. (2) Remove the old connection string entirely from App Settings and confirm the application continues to work. (3) In Azure Monitor / Application Insights, verify that no SQL authentication failures are appearing under the MI's context — a fallback to SQL auth would surface here. The definitive test is deploying with only the passwordless connection string and no credential — if the app functions, Managed Identity is working correctly.

FAVORITE Azure Engineering, AI & Real-World Fixes