Azure Key Vault Overview

What Key Vault stores

Key Vault organises its contents into three distinct object types. Each type has different capabilities and is suited to different use cases.

Secrets

A secret is any arbitrary string value you want to protect: database connection strings, API keys, OAuth client secrets, SMTP passwords, or any other credential your application needs. Key Vault stores secrets encrypted at rest, versions them automatically when you update them, and lets you set expiry dates so you are reminded (or can be automatically notified) when a secret needs rotating.

Keys

A key in Key Vault is a cryptographic key used for encryption and signing operations. The critical distinction from secrets is that Key Vault can perform cryptographic operations using the key without ever exposing the key material to your application. Your code asks Key Vault to encrypt or decrypt data; the key itself never leaves the vault. For hardware-backed key storage, Key Vault supports Hardware Security Module (HSM) tiers where keys are generated inside and never leave the HSM boundary.

Certificates

Key Vault can store and manage TLS/SSL certificates, including their associated private keys. It integrates with certificate authorities (CAs) like DigiCert and GlobalSign to automate the full certificate lifecycle: issuance, renewal, and rotation. When a certificate in Key Vault is renewed, services that reference it automatically pick up the new version without any manual deployment.

Controlling access: policies vs RBAC

Key Vault has two distinct access models, and understanding the difference matters when you set up a vault.

Access policies (older model)

The original model assigns permissions directly on the vault to a service principal, managed identity, or user. You grant a set of permissions per object type — for example, “get, list” on secrets and “get, decrypt” on keys. Access policies operate at the vault level only: you cannot grant access to a single secret within a vault using this model. If you need to give two different applications access to different subsets of secrets in the same vault, access policies force you to either grant both apps access to all secrets in that vault or create separate vaults.

RBAC (recommended model)

The newer and now-recommended model uses standard Azure role-based access control. You assign built-in roles like Key Vault Secrets User (read secrets), Key Vault Secrets Officer (create and manage secrets), or Key Vault Reader (list vault properties but not read secret values). These assignments can be scoped to the vault, to a specific secret, or even to a specific secret version. Because it uses the same RBAC system as all other Azure resources, you manage Key Vault access in the same place you manage access to storage accounts, VMs, and everything else — no separate blade, no different audit trail.

Soft-delete and purge protection

Key Vault has two safeguards against accidental data loss that you should understand before you start storing production secrets.

Soft-delete means that when you delete a secret, key, certificate, or the vault itself, it is not immediately destroyed. Instead, it enters a “deleted” state and remains recoverable for a configurable retention period (7 to 90 days, defaulting to 90). Soft-delete is enabled by default on all new vaults and cannot be disabled once enabled.

Purge protection goes one step further. With purge protection enabled, even an administrator cannot permanently delete (purge) a deleted object until the retention period has elapsed. This prevents a scenario where an attacker or a mistaken operator deletes a vault and immediately purges it before anyone notices. If you are using Key Vault to store keys that protect customer data — especially if you are using customer-managed keys — purge protection should be considered mandatory, because losing those keys means losing access to the data they protect.

Enable purge protection when creating a vault:

az keyvault create \
  --name my-prod-vault \
  --resource-group my-rg \
  --location eastus \
  --enable-soft-delete true \
  --retention-days 90 \
  --enable-purge-protection true

End-to-end: a web application retrieving a database connection string

The most common Key Vault use case is a web application that needs a database connection string at startup. Here is the complete setup, from creating the vault to the application reading the secret, using a managed identity so no credentials are stored anywhere.

Step 1: Create the vault and store the secret

# Create a resource group (if you don't already have one)
az group create --name my-app-rg --location eastus

# Create the Key Vault with RBAC enabled
az keyvault create \
  --name my-app-vault \
  --resource-group my-app-rg \
  --location eastus \
  --enable-rbac-authorization true \
  --enable-purge-protection true

# Store the database connection string as a secret
az keyvault secret set \
  --vault-name my-app-vault \
  --name "db-connection-string" \
  --value "Server=mydb.database.windows.net;Database=appdb;User Id=appuser;Password=s3cr3t;"

Step 2: Enable a system-assigned managed identity on the web app

# Enable managed identity on an App Service web app
az webapp identity assign \
  --name my-web-app \
  --resource-group my-app-rg

# The command outputs the principalId of the identity — save this
PRINCIPAL_ID=$(az webapp identity show \
  --name my-web-app \
  --resource-group my-app-rg \
  --query principalId \
  --output tsv)

Step 3: Grant the managed identity access to the vault

# Get the vault's resource ID
VAULT_ID=$(az keyvault show \
  --name my-app-vault \
  --resource-group my-app-rg \
  --query id \
  --output tsv)

# Assign Key Vault Secrets User role to the managed identity
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Secrets User" \
  --scope $VAULT_ID

Step 4: Application code reads the secret at startup

In Python using the Azure SDK:

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

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

db_connection_string = client.get_secret("db-connection-string").value

DefaultAzureCredential automatically uses the managed identity when running on Azure, and falls back to your developer account (via Azure CLI login) when running locally. The connection string never appears in source code, environment variables baked into container images, or deployment pipelines.

Key Vault vs environment variables

Environment variables on their own are not a secure secret store. They are readable by any process with access to the environment, they show up in process listings on some platforms, they get logged in CI/CD systems, and they end up in screenshots and bug reports. Most importantly, they do not give you a centralised audit trail of who read what value and when.

That said, Key Vault is not always the right answer either. For local development, environment variables in a .env file that is listed in .gitignore are often pragmatic. For non-sensitive configuration (feature flags, timeout values, region names), environment variables are fine. Key Vault is specifically for values that would cause harm if exposed: passwords, connection strings, private keys, API tokens with write access.

The clearest signal that you need Key Vault is when the answer to “what happens if this value leaks?” is “we have a serious incident”. If it’s “someone can read our staging cache”, that’s worth protecting but perhaps not with the full Key Vault setup. If it’s “someone can exfiltrate our customer database”, use Key Vault.

Standard vs Premium tier

Key Vault comes in two tiers. The Standard tier uses software-protected keys. The Premium tier adds support for HSM-backed keys, where cryptographic operations happen inside a FIPS 140-2 Level 2 validated hardware device and key material never exists in software memory. For most applications, Standard is sufficient. Premium is typically required when your compliance framework (PCI DSS, HIPAA, financial regulations) explicitly requires HSM-protected keys, or when you need the strongest possible guarantee that a key cannot be extracted.

Azure also offers Azure Dedicated HSM and Azure Managed HSM as separate services for organisations that need single-tenant, FIPS 140-2 Level 3 validated hardware, or need to own the full HSM domain — though these are more complex and significantly more expensive than Key Vault Premium.