Azure Managed Identity vs Key Vault secrets — Ops Runbook — Practical Guide (Mar 30, 2026)

Azure Managed Identity vs Key Vault Secrets — Ops Runbook

body {font-family: Arial, sans-serif; line-height: 1.6; max-width: 800px; margin: 2rem auto; padding: 0 1rem; colour: #222;}
h2, h3 { colour: #005a9c;}
pre { background: #f5f7fa; padding: 1em; overflow-x: auto; border-radius: 4px; border: 1px solid #ddd;}
code { font-family: Consolas, monospace; font-size: 0.9em; }
p.audience { font-weight: bold; font-style: italic; }
p.social { margin-top: 3rem; font-style: italic; colour: #555; }

Azure Managed Identity vs Key Vault Secrets — Ops Runbook

Level: Intermediate (software engineers with some Azure experience)

As of date: March 30, 2026

Introduction

In modern cloud architectures on Azure, managing secret information securely and efficiently is paramount. Azure offers multiple ways to handle authentication and sensitive configuration data — primarily Azure Managed Identities and Azure Key Vault secrets. Understanding when and how to use each can greatly simplify operational practices, reduce risk, and improve maintainability.

This runbook provides practical guidance on choosing between Managed Identities and Key Vault secrets, alongside a step-by-step approach to implementing, validating, and troubleshooting these techniques within your Azure environments. The information here applies to Azure SDKs and services updated as of March 2026 and generally covers Azure SDK versions 1.10 and later, including Azure AD integration.

Prerequisites

Azure Subscription with Contributor or Owner role
Azure CLI (v2.50 or later) or Azure PowerShell (Az Module 10.x+)
Access to Azure Portal for resource provisioning
Basic familiarity with Azure AD, Azure Key Vault, and ARM/IaC concepts
Application code environment compatible with Azure Identity SDK and Key Vault SDK (e.g., .NET 7+, Python 3.10+, Java 20+)

Conceptual Overview

Azure Managed Identity: A feature of Azure AD that provides an automatically managed identity for Azure resources like VMs, App Services, Functions, Logic Apps, and Containers. It enables secure calls to other Azure services without storing credentials in code or configuration. The managed identity can be system-assigned or user-assigned.

Azure Key Vault Secrets: A secure storage in Azure for secrets like passwords, API keys, certificates and connection strings. Access is controlled through Azure AD and Key Vault access policies or RBAC. Secrets must be explicitly retrieved by applications, and you are responsible for rotating and managing them.

When to Choose Managed Identity vs Key Vault Secrets

Use Managed Identity when: You need to authenticate seamlessly to Azure resources or APIs without embedding secrets. Managed Identity is ideal for services that directly support Azure AD authentication, such as Azure Storage, Azure SQL, Cosmos DB, and Azure Key Vault itself.
Use Key Vault Secrets when: Your application requires dynamic, custom secrets that aren’t represented as identities—such as third-party tokens, legacy credentials, or non-Azure resource secrets. Also useful for secrets that require manual rotation or auditing.

Hands-on Steps

1. Enable and Use Managed Identity

Example: Assign a system-assigned managed identity to an Azure Function and grant access to a Storage Account.

# Enable system-assigned Managed Identity on existing Azure Function
az functionapp identity assign --name MyFunctionApp --resource-group MyResourceGroup

# Get the principal ID of the managed identity
az functionapp identity show --name MyFunctionApp --resource-group MyResourceGroup --query principalId --output tsv

# Assign role to managed identity to access Storage Blob Data
az role assignment create --assignee <principalId> --role "Storage Blob Data Contributor" --scope /subscriptions/<subId>/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/MyStorage

The function code uses the ManagedIdentityCredential from Azure SDK to obtain tokens automatically:

// In C# using Azure.Identity and Azure.Storage.Blobs
var credential = new ManagedIdentityCredential();
var blobServiceClient = new BlobServiceClient(new Uri("https://mystorage.blob.core.windows.net"), credential);
var containerClient = blobServiceClient.GetBlobContainerClient("my-container");
await foreach (var blobItem in containerClient.GetBlobsAsync())
{
    Console.WriteLine(blobItem.Name);
}

2. Store and Retrieve Secrets from Azure Key Vault

Create a Key Vault and add a secret:

# Create Key Vault
az keyvault create --name MyKeyVault --resource-group MyResourceGroup --location eastus

# Set a secret
az keyvault secret set --vault-name MyKeyVault --name "DbConnectionString" --value "Server=sqlserver;Database=mydb;User Id=admin;Password=MyP@ssw0rd;"

Configure access policy or RBAC to allow your app’s Managed Identity to get secrets:

# Assign Key Vault Reader role for managed identity (using principalId found earlier)
az role assignment create --assignee <principalId> --role "Key Vault Secrets User" --scope $(az keyvault show --name MyKeyVault --query id -o tsv)

Sample code to retrieve a secret with DefaultAzureCredential (which uses managed identity when running in Azure):

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

credential = DefaultAzureCredential()
vault_url = "https://mykeyvault.vault.azure.net/"
client = SecretClient(vault_url=vault_url, credential=credential)

retrieved_secret = client.get_secret("DbConnectionString")
print(f"Secret value: {retrieved_secret.value}")

Common Pitfalls

Managed Identity limitations: Not all Azure services support managed identity authentication natively. For example, some third-party services or legacy systems may require explicit secrets.
Role assignment delays: Azure role assignments can take a few minutes to propagate. Tests immediately after assignment may fail due to eventual consistency.
Key Vault network restrictions: If your Key Vault firewall or virtual network service endpoints are restrictive, managed identity access may be blocked.
Credential caching: SDK tokens are cached and refreshed automatically. Ensure the application is restarted if credentials or roles change.
Secret rotation: Managed Identities eliminate the need to manually rotate secrets, but Key Vault secrets still require a rotation strategy.

Validation

Connectivity checks: Use az login and az account get-access-token for your managed identity to verify permission.
Log SDK messages: Enable verbose logging on Azure Identity and Key Vault SDKs to check token acquisition and secret retrieval.
Access token validation: Decode the JWT token obtained by managed identity to check the audience, expiry and issuer claims.
Monitor metrics: Use Azure Monitor and Key Vault diagnostic logs to identify permission failures or throttling.

Checklist / TL;DR

Choose Managed Identity: When Azure resource supports Azure AD auth, want to reduce secret management overhead, and need automated credential rotation.
Choose Key Vault Secrets: When your application needs custom secrets, third-party tokens, or secrets for services without Azure AD integration.
Enable Managed Identity on your Azure resource before applying RBAC roles.
Grant least privilege roles to managed identity or users for Key Vault access.
Use Azure SDKs DefaultAzureCredential or ManagedIdentityCredential for seamless authentication.
Plan secret rotation policies for Key Vault secrets.
Validate using CLI token tests, SDK logs, and Azure Monitor.