Skip to main content
cd ../lexicon
sys/docs/lexicon/azure-key-vault.md
Lexicon
Azure Key Vault

Azure Key Vault

Azure Key Vault is Microsoft Azure's managed service for storing secrets, encryption keys and certificates behind an auditable, identity-based permission model.
Difficulty: Intermediate
6 min read
Updated 2026-08-13

In plain English

Plain definition

Azure Key Vault is Microsoft Azure's managed service for storing secrets, encryption keys and certificates behind an auditable, identity-based permission model.

Technical Definition

Azure Key Vault is a managed service that provides centralised storage and access control for three categories of protected material: secrets (arbitrary key-value data such as connection strings), cryptographic keys (used for signing and encryption, optionally backed by hardware security modules) and X.509 certificates. Access is governed either by Azure role-based access control (RBAC) or by a vault-level access policy model, and callers typically authenticate using a Microsoft Entra ID (Azure Active Directory) identity, including a managed identity assigned to an Azure compute resource. Exact deletion-recovery behaviour, permission-model interaction and API version details vary by configuration and should be confirmed against current Microsoft documentation before being relied upon operationally.

Operational Relevance

Practitioners use Key Vault to centralise the lifecycle of sensitive material: rotation, revocation and audit happen in one place rather than being scattered across applications. This reduces the blast radius of a single leaked credential and removes the need for long-lived secrets inside deployment pipelines when combined with managed identities. Observable success for a Key Vault integration is straightforward to define: an application retrieves the correct secret value only through an authenticated identity call, no static credential appears in its configuration, and every retrieval is visible afterwards in the vault’s diagnostic logs.

Architecture Relationship

Key Vault does not operate in isolation. It relies on Microsoft Entra ID for authentication, on Azure Monitor and diagnostic logging for auditability, and is typically referenced by compute resources such as App Service, Azure Functions, virtual machines and AKS workloads through managed identity or workload identity federation. Network exposure can be constrained with private endpoints and firewall rules so that retrieval traffic does not need to cross the public internet. Vaults, and the access assignments attached to them, are usually deployed and versioned through Azure Resource Manager or infrastructure-as-code alongside the resources that consume them, so that access changes are traceable rather than made ad hoc.

Example

A common pattern is an application that retrieves a secret at start-up using its assigned managed identity, rather than reading a value from an environment variable that someone had to place there manually:

using var client = new SecretClient(vaultUri, new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync('example-secret-name');
// DefaultAzureCredential resolves the caller's managed identity at runtime;
// no static credential is stored in application configuration.

This is illustrative only: it shows the shape of the interaction, not a command to run against a live environment.

Misunderstanding

A frequent misunderstanding is treating Azure Key Vault as a general-purpose end-user password manager rather than an application- and infrastructure-facing service governed by identity and policy. Another is assuming that removing a secret, key or vault is always immediately and irreversibly destructive; some deletion behaviour in Azure is recoverable for a period, but the exact retention, soft-delete and purge-protection behaviour that applies to a given vault should be confirmed against current Microsoft documentation rather than assumed, since it affects how a mistaken deletion can be recovered.

  • Managed Identity
  • Microsoft Entra ID (Azure Active Directory)
  • Role-Based Access Control (RBAC)
  • Hardware Security Module (HSM)
  • Azure Resource Manager

Further Reading

This generation pass had access to only one verified source, the RFC Editor’s RFC Series, which establishes general Internet standards context but does not document Azure Key Vault specifically. Product-specific behaviour, current API versions, pricing tiers and regional availability were deliberately left general or flagged for review rather than asserted, and should be checked against Microsoft’s current official Azure Key Vault documentation before this entry is treated as fully verified for publication.