Before settings and diagrams, we need a clear picture of the problem Key Vault solves and of the three kinds of treasure it keeps.

The short definition

Azure Key Vault is a cloud service for safely storing and managing secrets, cryptographic keys, and certificates. A secret is any small piece of sensitive text, such as a password, a connection string, or an application programming interface key. A key is a cryptographic key used to encrypt, decrypt, sign, or verify data. A certificate is a digital identity document, usually used to prove that a website or service is genuine and to encrypt traffic. Key Vault keeps all three behind one consistent set of identity checks, permissions, and audit logs.

The service exists because secrets scatter. Developers paste a password into a configuration file to get a demo working, the file is committed to a repository, copies spread to laptops and build servers, and months later nobody knows where all the copies are or who can read them. Key Vault replaces scattered copies with one controlled home. Applications ask for what they need at the moment they need it, prove who they are, and are logged. If a secret leaks, you change it in one place and every application picks up the new value.

Why not just use environment variables or files?

Files and variables are easy, but they have no built-in identity checks, no audit trail, no automatic versioning, and no protection against accidental sharing. Key Vault gives you each of these. It also offers features that files never could: hardware-backed keys that cannot be extracted, automatic renewal of certificates, soft deletion that rescues you from mistakes, and events that tell other systems when a secret is about to expire.

What it is not

Key Vault is not a general database. It is meant for small, sensitive items, not for storing large files or high-volume customer data. It is not a replacement for good application design: an application that fetches a secret on every request will be slow and may be throttled. It also does not make a bad process safe by itself, because a vault with careless permissions is only a nicer-looking box with the door open.

Why it matters to the business

Leaked credentials are among the most common causes of serious breaches. Attackers do not need clever tricks when a password sits in a public repository or an old configuration backup. A central vault reduces the number of places where secrets exist, shortens the time between a leak and a fix, and gives investigators a clear record of what was touched. For auditors, it provides evidence that sensitive items are controlled. For engineers, it removes the dull and risky chore of passing secrets around by hand.

A handful of terms appear in every conversation about Key Vault. Learn them once and the rest of the guide becomes easy to read.

Versions, identifiers, and addresses

Every vault has a unique domain name, and every object inside has an identifier made from the vault name, the object type, the object name, and a version. When you update a secret, you do not overwrite it. You create a new version, and the old one remains. An application can ask for the current version by leaving the version out, or for an exact version by including it. This simple design makes rotation safe, since you can add the new version, move consumers over, and still return to the old version if something goes wrong.

Attributes that guard each object

Each object carries attributes such as enabled or disabled, activation time, and expiry time. A disabled object cannot be used. An object with an expiry time warns you, or other systems, that it needs renewing. Tags let you add your own labels, such as the owner or the system a secret belongs to. These attributes are small, but they are the basis of good governance: you can find every secret that expires within a month, or every key with no owner tag.

Naming and addressing in practice

Vault names are globally unique and appear in web addresses, so choose them with care. A good name carries the application, environment, and region in a short, readable form, and avoids personal or secret details, since names are visible in logs and in network traffic. Object names should describe purpose rather than value, such as a database connection for the orders service, and should stay stable over time, because applications reference them. Changing a name later means changing every consumer.

The single most useful idea for understanding Key Vault security is that there are two separate planes, each with its own rules.

The management plane

The management plane, also called the control plane, is where vaults themselves are created, configured, and deleted. It runs through Azure Resource Manager, the standard Azure management layer. Here you choose the region, tier, network rules, soft delete settings, and diagnostic logging, and here you assign Azure roles that control who may manage vaults. Permissions on this plane are about the vault as a resource.

The data plane

The data plane is where objects are read, written, and used. When an application fetches a secret, signs data with a key, or downloads a certificate, it talks to the vault’s own address and uses its own authentication. Permissions on this plane decide what can be done with the contents. Today these permissions are given either through Azure role-based access control, the modern model, or through vault access policies, the older model.

flowchart TD
    subgraph MP[Management plane through Azure Resource Manager]
        ADM[Platform administrator] --> ARM[Create and configure vaults]
    end
    subgraph DP[Data plane through the vault address]
        APP[Application with managed identity] --> VAULT[Key Vault]
        DEV[Developer or operator] --> VAULT
    end
    ENTRA[Microsoft Entra ID] -->|Authenticates every caller| ARM
    ENTRA -->|Authenticates every caller| VAULT
    ARM --> VAULT
    VAULT --> LOG[Audit logs]
    VAULT --> EVT[Events for expiring objects]
        

Authentication first, then authorisation

Every request to either plane begins with authentication, in which Microsoft Entra ID verifies who the caller is and issues a token. Key Vault then checks authorisation, asking whether that caller has permission for the operation on that object. If either step fails, the request is refused. There is no way to reach Key Vault without an Entra identity, which is a strength: the same directory, the same conditional access rules, and the same sign-in logs apply to the vault as to every other Azure service.

What happens inside

Inside the service, secrets and keys are encrypted at rest. Software-protected keys are processed in secured software on hardened servers. Hardware-protected keys are created and used inside hardware security modules, and cryptographic operations happen inside the module, so the key material is never revealed. When an application asks the vault to sign or decrypt something, it sends the data to the vault and receives the result, never the key. This pattern, where the key stays home and the work comes to it, is the heart of safe key management.

sequenceDiagram
    participant A as Application
    participant E as Microsoft Entra ID
    participant K as Key Vault
    A->>E: Prove identity with managed identity
    E-->>A: Access token
    A->>K: Request secret with token
    K->>K: Check token and permission
    K-->>A: Secret value
    K->>K: Write audit record
        

Regional design

A vault lives in one region and its data stays inside that geography. Azure also replicates vault contents to a paired region for resilience in most cases, and the service uses availability zones where regions support them. Chapter 13 covers these resilience features in detail. For now, remember that vault location matters: put each vault near the applications that use it, to keep delay low and to respect data residency rules.

Why the separation helps security

Splitting management from use limits damage. A person who can build or reconfigure vaults cannot automatically read what they hold, so a stolen administrator account does not instantly expose every secret. Likewise, an application that reads secrets cannot delete the vault. Auditors can review the two planes separately: who may change structure, and who may touch contents. This is why the modern permission model keeps role assignment itself as a protected action, available only to those with the right to grant access.

Each object type solves a different problem. Choosing the right one avoids awkward designs and security gaps.

Secrets

A secret is the simplest object. It is a named value up to a modest size limit, stored encrypted and returned in full to any caller with permission to read it. Typical secrets are database passwords, connection strings, tokens for external services, and configuration values that must not be public. Because the caller receives the actual value, a secret is only as safe as the application that holds it afterwards. That is why you keep secret values in memory, avoid writing them to logs, and prefer identities over passwords wherever the target service allows it.

Secrets can have a content type label, such as a password or a certificate bundle, an activation date, an expiry date, and tags. Each update creates a new version. Applications that fetch the latest version automatically receive the newest value, which makes rotation smooth when the application can reload secrets without restarting.

Keys

A key object holds a cryptographic key and lets authorised callers use it through operations such as encrypt, decrypt, sign, verify, wrap, and unwrap. Wrapping means protecting another key by encrypting it with this one. Keys can be created in the vault, imported from elsewhere, and, in premium vaults and managed hardware modules, protected by hardware. The great benefit is that the private part of the key never leaves the service. Many Azure services use customer-managed keys stored here to encrypt your data at rest, such as storage accounts, databases, and disks.

Key types include RSA keys, elliptic curve keys, and for some services symmetric keys. Keys carry permitted operations, so a key made only for signing cannot be misused for decryption. Keys also support an automatic rotation policy that creates new versions on a schedule and can notify other systems beforehand.

Certificates

A certificate object is built on top of a key and a secret. Behind the scenes, Key Vault holds the key pair and the certificate chain, and exposes them as a certificate object with its own management features. You can create a certificate with a policy that states the subject name, key type, validity, and renewal behaviour. Key Vault can request it from a supported certificate authority, watch its expiry, and renew it automatically. You can also import existing certificates. We cover the full lifecycle in Chapter 11.

flowchart TD
    Q{What do you need to protect} -->|A value your app must read| S[Use a secret]
    Q -->|Encryption or signing without exposing the key| K[Use a key]
    Q -->|A website or service identity with renewal| C[Use a certificate]
    S --> S1[Prefer managed identity if the target supports it]
    K --> K1[Choose software, premium HSM, or Managed HSM by risk]
    C --> C1[Pick a trusted authority and enable auto renewal]
        

A common confusion: certificates versus secrets

Because a certificate’s private key can be read as a secret with the same name, some teams treat certificates as plain secrets. This loses the lifecycle features: the renewal policy, the issuer integration, and the expiry warnings. Store real certificates as certificate objects and let the vault manage them. Reserve plain secrets for values that are truly just text.

Choosing good content types and tags

Small labels make large estates manageable. A content type tells readers what a secret contains, such as a connection string or a token, so tools can handle it correctly. Tags record the owner, the application, the environment, and the date of the last review. With consistent labels, a simple query can list every secret owned by a team, every key without an owner, or every object not reviewed this year. Without them, inventory becomes a guessing game during incidents and audits.

Azure offers several levels of protection. Choose by the strength of protection you need, the standards you must meet, and the money you can spend.

Standard vaults

The standard tier stores secrets, certificates, and software-protected keys. The cryptography runs in software on Azure servers. It is the right choice for most applications: connection strings, tokens, ordinary certificates, and encryption keys where software protection satisfies your rules. It is also the cheapest option, charged per operation with no large fixed fee.

Premium vaults

The premium tier adds hardware-protected keys. Keys are created and used inside hardware security modules validated to published standards, so even Microsoft staff cannot extract them. Premium vaults still hold secrets and certificates like standard ones, and the same permission model applies. Choose premium when regulations or internal policy require hardware protection but you do not need a dedicated single-tenant module.

Managed HSM

Managed HSM is a separate service: a dedicated, single-tenant pool of hardware security modules that Azure operates for you. You control the security domain, which is an encrypted bundle needed to recover the module, and you own the key material completely. It supports only hardware-protected keys, not secrets or certificates. It has its own access control system and its own higher limits, and it is billed hourly per instance, so it costs much more than a vault. It suits strict regulatory settings, very high key volumes, and workloads that need high throughput of cryptographic operations.

Other hardware options

Azure also offers other dedicated hardware options for specific legacy or compliance needs, where you manage the device yourself. They are rarely needed for new projects, and Microsoft’s own guidance steers most customers to Key Vault or Managed HSM. Always check current documentation for what is offered in your region and for the standards each option meets.

flowchart TD
    START[What do you need to protect] --> Q1{Secrets or certificates too}
    Q1 -->|Yes| Q2{Must keys be hardware protected}
    Q2 -->|No| STD[Standard vault]
    Q2 -->|Yes| PRE[Premium vault]
    Q1 -->|Keys only| Q3{Single tenant control or very high key volume}
    Q3 -->|No| Q2
    Q3 -->|Yes| MHSM[Managed HSM]
        

Customer-managed keys and the tier choice

Many Azure services can encrypt data with a key you own. The tier you choose for those keys decides how strongly they are protected. For ordinary data, a software key in a standard vault is often enough. For highly regulated data, an HSM-backed key in a premium vault or Managed HSM may be required. Remember that the vault now becomes a dependency of the encrypted service, so its availability and access rules need the same care as the data itself.

Practical limits worth knowing

Vaults have no fixed cap on the number of objects, but each vault has transaction limits per ten-second window that differ by operation and key type. Managed HSM instances have their own caps, such as a limited number of keys per instance and a limited number of instances per subscription per region. These numbers change, so read the current limits page before sizing a design.

The best secret is one that never has to exist. Choosing the right identity method removes the “first secret” problem and shrinks your risk.

The first-secret problem

To fetch a secret from the vault, an application must first prove who it is. If it proves this with a password stored in a configuration file, you have only moved the problem: the password to the vault is now the most valuable secret in the system. Good design breaks this circle by using an identity that the platform itself provides.

Managed identities

A managed identity is an identity in Microsoft Entra ID attached to an Azure resource, such as a web app, function, virtual machine, container app, or Kubernetes workload. The platform creates it, rotates its credentials automatically, and hands tokens to code running on the resource. There are two kinds. A system-assigned identity lives and dies with its resource and belongs to it alone. A user-assigned identity is a separate resource that you create and can attach to several resources, which is helpful when many instances share the same permissions or when you need the identity to exist before the resource does.

Service principals

A service principal is the identity of an application registered in Entra ID. It can authenticate with a client secret or with a certificate. Both options need a credential that someone must store and rotate, so they are second choices, used when the caller runs outside Azure and cannot use a managed identity. Where possible, use workload identity federation, which lets an external system such as a build pipeline or another cloud exchange its own trusted token for an Entra token with no stored secret.

People

Humans sign in with their own Entra accounts, ideally with multi-factor authentication and conditional access policies that check device health and location. For sensitive vaults, use groups and just-in-time elevation so that nobody holds permanent powerful rights. Avoid shared accounts, because the audit log then cannot tell who did what.

flowchart TD
    Q{Where does the code run} -->|On an Azure resource| MI[Use a managed identity]
    Q -->|In a build pipeline or other cloud| FED[Use workload identity federation]
    Q -->|On a server outside Azure| ARC{Can it use Azure Arc}
    ARC -->|Yes| MI2[Use the Arc managed identity]
    ARC -->|No| SP[Service principal with certificate and short life]
        

Layers around identity

Identity is also protected by the tenant. Conditional access can block sign-in from unusual places. Privileged Identity Management can require approval and time limits for powerful roles. Sign-in logs record every authentication, and identity protection can flag risky sign-ins. These controls belong to Entra ID rather than Key Vault, but they decide how safe the vault really is.

Short-lived tokens and caching of tokens

Tokens issued by Entra ID last a limited time, commonly about an hour, and libraries cache and refresh them automatically. This short life is a feature: a stolen token becomes useless soon. Applications should use the official identity libraries that handle caching and renewal, rather than requesting a new token for every call. Misusing them, by creating a new credential object per request, is a frequent cause of slowness and of throttling at the identity service rather than at the vault.

After identity comes permission. Key Vault has had two models, and Microsoft is steering everyone towards one of them.

The old model: vault access policies

Access policies are a list stored inside each vault. Each entry names a principal and ticks permissions for keys, secrets, and certificates, such as get, list, set, delete, sign, and so on. They are simple, but they have drawbacks. They apply to the whole vault, so you cannot give someone access to just one secret. The list lives inside each vault, which makes central review hard. Anyone who can edit the vault as a resource can add themselves to the list and then read every secret, a weakness known as privilege escalation. They also lack the conditions, scopes, and approval workflows that Azure role assignments support.

The modern model: Azure role-based access control

With Azure RBAC, permissions are given by assigning built-in or custom roles to principals at a scope. The scope can be a management group, subscription, resource group, vault, or even a single object, which allows fine control. Role assignments are visible in one place across the estate, can be audited by standard tools, can be time-limited through Privileged Identity Management, and are written down by the same processes as other Azure permissions. Because adding a role assignment needs separate rights, a person who can manage a vault cannot silently grant themselves access to its contents.

The 2026 change in the default

Microsoft has announced that, with the Key Vault control plane API version 2026-02-01, Azure RBAC becomes the default access model for newly created vaults. Existing vaults keep their current model. Teams that create vaults through templates, scripts, or code and do not state the model explicitly may therefore get an RBAC vault where they expected access policies, and see denied requests until they assign roles. In addition, Microsoft has stated that older control plane API versions are retired on 27 February 2027, so templates and tools that pin older versions need updating. Treat these dates as pointers and confirm them in the official announcement and documentation.

Choosing scopes

Assign roles at the smallest scope that works. An application that needs one secret can receive a role on that single secret. An application that uses several secrets from one vault gets a role on that vault. Broad roles at the subscription level are convenient but let a compromise reach every vault below. Use groups for people, and use managed identities for applications, so the number of direct assignments stays small and reviewable.

Custom roles and just-in-time access

Built-in roles cover most needs, but sometimes a team needs a precise mix, such as permission to list and read secrets but never to change them. A custom role can express this. For people, combine roles with just-in-time activation so that powerful rights exist only for an hour, with a reason and an approver recorded. Standing administrator rights on production vaults are a habit worth breaking, because an unused permanent right is a target waiting for an attacker.

Even with perfect permissions, there is no reason to leave a vault visible to the whole internet. Network rules add a second wall.

The default and why to change it

By default, a vault’s endpoint is reachable from the public internet, protected by authentication and authorisation. That is already strong, but defence in depth says to reduce who can reach the door. The vault firewall lets you deny public traffic and allow only chosen sources.

Firewall rules and service endpoints

The firewall can allow specific public addresses, such as your office or build servers, and specific virtual network subnets using service endpoints. Service endpoints keep traffic on the Azure backbone but the vault still has a public address. This approach is easy and cheap, and suits many teams.

Private endpoints

A private endpoint gives the vault a private address inside your virtual network. Applications reach it through that address, traffic never crosses the public internet, and you can turn off public access completely. Private endpoints need correct name resolution: the vault’s normal name must resolve to the private address from inside your network, usually through a private DNS zone. On-premises networks need forwarding rules to resolve it too. Most private endpoint problems are really name resolution problems.

Trusted services

Some Azure services, such as storage, backup, and disk encryption, need to reach the vault on your behalf even when the firewall blocks public traffic. A setting lets trusted Microsoft services bypass the firewall. Use it deliberately, with the narrowest set of services you need, and understand that those services still need permission through roles.

flowchart LR
    subgraph VNET[Your virtual network]
        APP[Application] --> PE[Private endpoint]
    end
    PE --> KV[Key Vault with public access disabled]
    ONP[On-premises network] -->|VPN or private circuit with DNS forwarding| PE
    NET[Public internet] -.->|Blocked by firewall| KV
    TS[Trusted Azure service] -->|Allowed if bypass is enabled and roles permit| KV
        

Choosing a network posture

Network settings and the platform

Some Azure services that read secrets, such as app hosting services and function platforms, need network integration of their own to reach a private vault. Plan the whole path: the application’s outbound network, the private endpoint, the DNS, and the role assignment. A failure at any step looks like “cannot read secret” even though each piece looks fine alone.

Testing network changes safely

Treat network changes to a vault like production releases. Apply them first to a test vault with the same pattern of endpoints and DNS. Use a test virtual machine inside the network to prove that name resolution points to the private address and that a read succeeds. Record the rollback step, which is usually to re-enable public access temporarily from a trusted address. Announce the change window to application teams, because the first sign of a mistake is often a flood of timeouts in a service nobody expected to be affected.

Storing secrets safely is half the work. The other half is how applications fetch, hold, and refresh them without causing slowness or outages.

Ways to read secrets

Caching and refreshing

An application that calls the vault on every request will be slow and may be throttled. Cache values in memory for a sensible time, and handle failure with care: if a refresh fails, keep using the last good value and retry later, rather than failing the user. When a secret changes, applications should pick up the new version without a restart where possible, by reloading on a schedule or on an event. Never write secrets into logs, error messages, or crash dumps.

Rotation without drama

Rotation means replacing a secret regularly or after a suspected leak. It is safest when two valid values exist for a short time. A common design for databases uses two credentials in turn: the vault holds the active one, a new one is created and stored as a new version, applications move to it, and only then is the old one removed. Services that support Entra authentication avoid the whole problem, because there is no password to rotate.

sequenceDiagram
    participant R as Rotation process
    participant T as Target service
    participant V as Key Vault
    participant A as Applications
    V-->>R: Event says secret near expiry
    R->>T: Create new credential
    R->>V: Store as new secret version
    A->>V: Reload on schedule
    V-->>A: New version
    A->>T: Connect with new credential
    R->>T: Retire old credential after grace period
        

Events and automation

Key Vault can publish events through Azure Event Grid when an object is near expiry, has expired, or has a new version. These events can start a function or workflow that rotates the secret, updates a dependent system, or opens a ticket. Short expiry dates on secrets, combined with these events, turn rotation from a yearly emergency into a routine job.

What to avoid

Do not copy secrets from the vault into other stores, because each copy escapes the audit trail and the rotation. Do not email or chat secret values. Do not put them in image layers, templates, or source repositories. Use secret scanning tools in your repositories so that accidents are caught early, and treat any secret that appeared in a repository as compromised, even if it was deleted afterwards.

Local development without real secrets

Developers need to run applications on laptops without receiving production secrets. Use separate development vaults with harmless values, and let the identity libraries pick up the developer’s own signed-in account, which has a role only on the development vault. This way, the same code runs everywhere, only the identity changes, and no secret is ever copied to a laptop. Production secrets then stay reachable only by production identities.

Keys in the vault protect your data in storage and in motion. Understanding envelope encryption explains almost every Azure service that uses a customer-managed key.

Envelope encryption

Encrypting large data directly with a vault key would be slow and would send huge amounts of data to the vault. Instead, services generate a data encryption key to encrypt the data quickly. They then ask the vault to wrap that data key with a key encryption key stored in the vault. The wrapped key is stored beside the data. To read the data later, the service asks the vault to unwrap the data key, then decrypts locally. Only the small key crosses to the vault, and the master key never leaves it.

sequenceDiagram
    participant S as Azure service
    participant V as Key Vault
    S->>S: Create data encryption key
    S->>S: Encrypt data with data key
    S->>V: Wrap the data key with vault key
    V-->>S: Wrapped data key
    S->>S: Store wrapped key beside data
    Note over S,V: Later, S asks V to unwrap the data key, then decrypts locally
        

Customer-managed keys in Azure services

By default, Azure services encrypt data at rest with keys that Microsoft manages. Many services let you bring your own key from Key Vault or Managed HSM instead, including storage, databases, disks, backup, messaging, and analytics services. The service uses a managed identity with a narrow encryption role on your key. Benefits are control over the key lifecycle, the ability to revoke access to data by disabling the key, and meeting rules that require customer control. The cost is responsibility: if the key is deleted, disabled, or becomes unreachable, the data becomes unreadable.

Safety settings you must have

Services that use a customer-managed key usually require both soft delete and purge protection on the vault, because accidental deletion of the key would destroy the data. Even where it is not enforced, treat it as mandatory. Also protect the key from careless rotation or disablement through tight permissions and alerts on key operations.

Key rotation

Keys can rotate on a schedule defined by a policy, producing new versions. Services that use the key either follow the latest version automatically or must be told to use the new one. Rotation of the master key is cheap in envelope designs, since only wrapped data keys need re-wrapping, not the data itself. Define how often keys rotate, who is notified, and what happens to old versions, which must stay available for as long as any data depends on them.

Bring your own key and key import

Organisations that generate keys in their own hardware can import them into premium vaults or Managed HSM using a protected transfer process, so the key travels encrypted from your device to the target module. This is often called bring your own key. It satisfies rules that demand on-premises key creation, but it adds procedures and risks around the original copy, so keep records of where copies exist and who can use them.

Other uses of vault keys

Expired certificates are among the most common and most embarrassing causes of outages. Key Vault can take over the routine work that people forget.

What a certificate object contains

A certificate in Key Vault is more than a file. It combines the public certificate, the private key held safely, and a policy that describes how it was made and how it should be renewed. The vault creates an addressable key and an addressable secret linked to the certificate, which lets services retrieve the full bundle when allowed, while the policy controls everything else.

Creating certificates

There are three main routes. In the first, you create a self-signed certificate inside the vault, useful for development and internal tests, though no outside party trusts it. In the second, you ask a certificate authority that is integrated with Key Vault to issue one, and the vault handles the request and the issued result. In the third, you ask any other authority, such as a company’s own, by creating a signing request in the vault, getting it signed outside, and merging the result back. You may also import an existing certificate with its key, which is common during migrations.

The policy

The certificate policy states the subject and alternative names, the key type and size, whether the key can be exported, the validity period, the content type, and what to do near expiry. Near expiry, the vault can renew automatically at a chosen percentage of lifetime or number of days before the end, or it can send an email notice to named contacts so a person acts. Automatic renewal is available for self-signed certificates and for integrated authorities. For others, plan a reminder process.

stateDiagram-v2
    [*] --> Created: Create with policy
    Created --> PendingIssue: Request sent to authority
    PendingIssue --> Active: Issued and stored
    Active --> NearExpiry: Renewal threshold reached
    NearExpiry --> Active: Auto renewed with new version
    NearExpiry --> Notified: Manual path, contacts emailed
    Notified --> Active: Person renews or merges
    Active --> Expired: Missed renewal
    Expired --> [*]
        

Getting certificates to where they are used

Many Azure services can fetch certificates directly from the vault: application gateways for listener certificates, web apps for custom domains, and API management for backends. They poll for new versions, so renewal can reach them without human action. Where a service cannot, an automation reads the new version and installs it. Test this path before the first real expiry, since a renewed certificate that never reaches the load balancer is still an outage.

Private keys and exportability

Decide whether the private key can ever leave the vault. A non-exportable key is the safest, because even an authorised reader cannot take it, but then only services that use the vault for the operation can use the certificate. An exportable key allows deployment to machines but creates copies that live outside the vault. Choose per certificate based on where it must work.

Certificate hygiene

Handling certificates for internal and test systems

Not every certificate needs a public authority. Internal services can use certificates from a private authority that your devices trust, with policies that issue short lives and renew often. Test environments may use self-signed certificates, but keep them clearly labelled and out of production paths. Mixing them up causes puzzling errors where a browser or client refuses a certificate that works elsewhere. Keep a simple map of which authority serves which environment, and review it whenever teams create new domains.

Losing a key can mean losing the data it protects. Key Vault gives you several safety nets, and you should use all of them.

Soft delete

When soft delete is on, deleting a vault or an object moves it into a recoverable state rather than destroying it. During the retention period you can list deleted items and recover them with all their versions and settings. The retention period can be set between seven and ninety days, with ninety as the default. Soft delete is on by default for new vaults and cannot be switched off, so mistakes are survivable. While an object is in the deleted state, its name stays reserved, so you cannot create a new object with the same name until you recover or purge the old one.

Purge protection

Purging means permanently deleting a soft-deleted item before its retention period ends. With purge protection enabled, nobody can purge, not even an administrator, until the period expires. Once you turn purge protection on, you cannot turn it off, and the vault itself can be permanently removed only after the retention time. Many services that use customer-managed keys require it. The price is that a mistaken vault name stays reserved for the retention period, so plan naming carefully for test vaults.

Backup and restore of objects

Key Vault lets you back up an individual secret, key, or certificate. The backup is an encrypted blob that includes all versions. You can restore it into a vault, but with limits: the restore target must be in the same subscription and Azure geography, and the backup can be decrypted only by the Key Vault service in that scope. Backups are therefore protection against loss and a way to copy objects between vaults in the same area, not a portable export. Objects with a very large number of versions may fail to back up, so avoid unbounded version growth.

Managed HSM backup

Managed HSM supports full backup of the whole module to a storage account and restore to the same or another module, together with its security domain. The security domain, which you download when you first set up the module, is a critical recovery asset: without it, a lost module cannot be recovered. Store it in more than one safe, offline location, split among several trusted people according to the quorum you choose.

flowchart TD
    DEL[Someone deletes a key or vault] --> SD{Soft delete on}
    SD -->|Yes, always| RET[Item kept for retention period]
    RET --> PP{Purge protection on}
    PP -->|Yes| LOCK[Nobody can purge early]
    PP -->|No| RISK[An administrator could purge]
    LOCK --> REC[Recover within the period]
    RET --> REC
        

Recovery practice

Who may delete, and how to limit it

Deletion rights deserve special care. Separate the right to create or update objects from the right to delete them, and give delete rights to very few people or to a protected automation. Resource locks stop accidental removal of the vault itself, and policy can require purge protection so nobody forgets. Add alerts on deletions so that a worrying event is seen within minutes, while the recovery window is still wide open. Together, these habits make the destructive path hard to take by accident and easy to notice on purpose.

When Key Vault is unreachable, the applications and services that depend on it may stop. Plan its availability like that of any critical dependency.

What Azure provides by default

The service stores vault contents redundantly. Within a region it uses availability zones where the region supports them, so the loss of a data centre does not remove the vault. In most regions, vault data is also replicated to a paired region, and if the primary region suffers a major outage, Microsoft can fail the vault over to the paired region, where it is typically available in read-only form until the primary returns. During that time you can read secrets and use keys, but you cannot change objects. Details differ by region and can change, so check the current reliability documentation for your location.

What it means for your design

Read-only failover is good enough for many applications, which mostly read. But operations that write, such as creating new secrets, rotating, or renewing certificates, will fail during the event. Applications should cope: cache values, retry sensibly, and avoid writing to the vault in their normal paths. Remember too that failover changes where requests are served, which can briefly increase delay.

Multi-region patterns

For applications deployed in several regions, a common pattern is one vault per region, each holding the same secrets, with each regional application using its local vault. This avoids cross-region delay and keeps each region independent if another fails. The cost is keeping the copies in sync, which is done through a deployment pipeline or rotation process that writes to every vault. Keep the process simple and test that all copies stay equal.

flowchart TD
    subgraph R1[Region one]
        A1[Application] --> V1[Vault one]
    end
    subgraph R2[Region two]
        A2[Application] --> V2[Vault two]
    end
    PIPE[Deployment and rotation pipeline] --> V1
    PIPE --> V2
    V1 -.->|Platform replication to paired region| P1[Paired region copy]
    V2 -.->|Platform replication to paired region| P2[Paired region copy]
        

Dependencies on the vault

Map who depends on each vault. Storage accounts with customer-managed keys, databases with transparent encryption keys, disks, and web gateways may all fail or lose access if a vault or key is unreachable or disabled. The more services depend on one vault, the larger the impact of an outage, which is another reason to avoid a single giant vault. Choose recovery targets that reflect this dependency, and include the vault in business continuity tests.

Recovery steps for common failures

Testing your recovery assumptions

Run a drill where the primary vault is made unavailable to a test application. Observe what the application does: does it keep serving with cached values, does it retry politely, does it alert the right people, and does it recover on its own when access returns? Many teams discover that one forgotten code path reads a secret on every request, or that a start-up routine fails hard when the vault is slow. Fixing such defects in a drill costs hours, while fixing them during a real outage costs far more.

A vault without logs is a locked room without a visitors’ book. Monitoring tells you who used what, how the service is behaving, and when something looks wrong.

Audit logs

Through diagnostic settings, a vault can send audit logs to a Log Analytics workspace, a storage account, or an event hub. Each record shows the caller identity, the operation, the object, the result, the source address, and the time. These logs answer the vital questions: who read this secret yesterday, which application keeps failing to authenticate, and who changed a role. Make sure logs go to a protected place that vault administrators cannot edit, since an intruder will try to hide.

Metrics

Azure Monitor metrics for a vault include total requests, availability, latency of service API calls, and saturation, which shows how close you are to limits. Watching saturation and the count of throttled responses warns you before applications fail. Charts of requests by result code quickly show a surge of denied or failed calls.

Alerts worth having

Threat detection

Microsoft Defender for Cloud offers protection for Key Vault that analyses access patterns and raises alerts for suspicious activity, such as access from unusual locations, unusual lists of many secrets, or access by identities that rarely touch the vault. Alerts appear in Defender and can flow to your security operations tools. Treat them as prompts to investigate, with the audit logs as your evidence.

flowchart LR
    KV[Key Vault] --> DS[Diagnostic settings]
    KV --> MET[Metrics]
    KV --> EG[Event Grid events]
    DS --> LA[Log Analytics workspace]
    MET --> AL[Alert rules]
    LA --> AL
    EG --> AUTO[Automation for rotation and tickets]
    KV --> DEF[Defender threat detection]
    DEF --> SOC[Security team]
    AL --> OPS[Operations team]
        

Reviewing access regularly

Every quarter, list who holds roles on each vault and who actually used them. Remove roles that are unused, and move people from standing access to time-limited elevation. Compare the list of identities seen in logs with the list expected; a surprise in either direction deserves a conversation. Pair the review with a check of expiry dates and of any vault that lost its private endpoint or logging.

Writing runbooks for vault alerts

An alert is only useful if the receiver knows what to do. For each alert, write a short runbook that says what the alert means, which log query to open first, who owns the vault, how to tell a harmless cause from a dangerous one, and how to escalate. For a sudden burst of secret reads, the runbook might direct the responder to list the calling identities, compare them with expected ones, and rotate the affected secrets if any caller is unknown. Review runbooks after every incident and remove steps that nobody used.

Key Vault was designed for retrieving secrets at start-up, not for being queried like a database on every request. Understanding limits keeps applications fast and steady.

How limits work

Limits are counted per vault, per region, in windows of ten seconds, and they differ by operation. The documentation currently describes a limit of a few hundred operations per window for creating secrets and importing certificates or keys, a much higher limit of several thousand for all other transactions, and much lower limits for creating or releasing keys, especially hardware-protected ones. Limits for reading keys depend on the key type and size: larger and hardware-backed keys cost more of the budget, so you can do fewer such operations. A broader limit applies across the whole subscription in a region. Treat all numbers as examples and check the current limits page.

What throttling looks like

When a client goes over a limit, the vault answers with a “too many requests” response, commonly seen as status code 429. Requests rejected this way do not count against the budget, but the client must slow down. Good clients wait and retry with exponentially increasing pauses, and honour any hint the service gives about how long to wait. Retrying immediately makes things worse because it keeps the vault saturated.

Ways to stay under the limits

When the limits are not enough

Very high rates of key operations may call for Managed HSM, which has its own capacity and higher throughput for certain operations such as secure key release. If you must store millions of customer keys, do not put each one in the vault. Store them encrypted in a database and keep only the master key in the vault. Also remember that some limits apply to the number of versions of an object. Very large numbers of versions can break backups and slow operations, so clean up or restructure objects that rotate very often.

flowchart TD
    REQ[Application needs a secret] --> C{In memory cache and still valid}
    C -->|Yes| USE[Use cached value]
    C -->|No| CALL[Call Key Vault]
    CALL --> R{Response}
    R -->|Success| STORE[Cache and use]
    R -->|Too many requests| WAIT[Wait with growing pauses, then retry]
    WAIT --> CALL
    R -->|Denied| FIX[Alert and check roles and network]
        

Measuring before tuning

Before redesigning anything, look at the vault’s own numbers. Check requests by operation, the share of throttled responses, and the saturation metric over a busy week. Identify which application produces the most calls and whether those calls ask for the same few values. Most problems turn out to be one chatty component, not a general shortage. Fixing that one component with a cache is cheaper and safer than splitting vaults or buying dedicated hardware.

At scale, Key Vault needs rules, budgets, and a plan for change. This chapter ties together policy, cost, naming, and the migrations you should expect.

Policy as guardrails

Azure Policy turns written rules into automatic checks. Built-in definitions can require soft delete and purge protection, require RBAC authorisation, require private endpoints or disabled public access, require diagnostic logging, require expiry dates on secrets and keys, restrict key types and minimum key sizes, limit certificate validity, and require certificates from approved authorities. Policies can audit, deny, or deploy fixes automatically. Start in audit mode to learn what would be blocked, then move the important ones to deny.

Naming, tagging, and ownership

Names should reveal application, environment, and region, within the limits of vault naming rules, which require globally unique names. Tag vaults with owner, cost centre, data classification, and expiry review date. Tag objects too, with the system that uses them. Ownership matters most of all: every vault, secret, key, and certificate needs a named team accountable for rotation and removal.

How the bill is made

Standard vaults charge per ten thousand operations, with different rates for secrets, keys, and certificate operations, and extra charges for certificate renewal requests with integrated authorities. Premium vaults add a monthly charge per hardware-protected key, with lower rates for additional versions, and per-operation costs for hardware key operations. Managed HSM is billed hourly per instance, so a dedicated instance running all month is a significant fixed cost. Prices differ by region and change, so use the official pricing page and calculator.

Managing change and retirements

Key Vault evolves. The shift to RBAC as the default, and the retirement of older control plane API versions on the dates Microsoft has announced, are recent examples. Other changes concern tightening defaults for new vaults, new key types and algorithms, and the lifetimes of public certificates. Assign someone to follow service announcements, keep an inventory of templates and tools that touch vaults, and test them against new API versions in a non-production subscription before deadlines.

Reviewing exceptions

Every rule needs a way out, and every way out needs a record. When a team needs public access for a vault, a longer certificate lifetime, or a secret without expiry, capture the reason, the owner, the compensating controls, and a review date. Review exceptions every quarter and close those that no longer apply. A short, visible exceptions list keeps standards honest, because it shows where reality differs from policy and who has agreed to carry the risk.

Patterns are proven answers to repeated problems. This chapter gathers the ones seen in almost every well-run estate, together with the traps to avoid and a checklist for reviews.

Helpful patterns

flowchart LR
    PIPE[Pipeline with federated identity] --> KVA[Vault for app A production]
    PIPE --> KVB[Vault for app B production]
    APPA[App A managed identity] -->|Secrets User on its vault only| KVA
    APPB[App B managed identity] -->|Secrets User on its vault only| KVB
    KVA --> LOGS[Central log workspace]
    KVB --> LOGS
    POL[Policy] -->|Audit and enforce standards| KVA
    POL --> KVB
        

More anti-patterns

Common mistakes and their fixes

A pre-launch checklist

Every service has strengths and costs. Here is an honest look at what Key Vault gives you and what it asks in return.

When Key Vault is the right fit

It is the natural choice when your workloads run on Azure, when you want one audited home for sensitive items, and when you want Azure services to use your own keys. It also fits hybrid cases through Azure Arc and applications elsewhere that can authenticate with Entra identities or federation. For most teams, a standard vault per application and environment is the sensible start.

When to think twice

If you must keep millions of per-customer secrets, a vault is not the right database. If your estate spans several clouds and you already run another secrets platform, think about which platform is the source of truth, to avoid duplicate copies and split audit trails. If a team needs only a feature flag or a non-sensitive setting, an application configuration service is the better home, with the vault holding only references to real secrets.

Comparing with other approaches

Some teams keep secrets in files encrypted with a tool and stored in the repository. This is cheap and portable, but the encryption key itself needs a home, rotation is manual, and auditing is weak. Others run an open-source secrets platform on their own servers, gaining flexibility but taking on upgrades, availability, and unsealing procedures. Cloud-native vaults from other providers offer similar features inside their own clouds. Key Vault stands out for its tight integration with Azure identity, policy, networking, and services that use customer-managed keys, which is why it is the default choice for Azure-centred estates.

These short stories show how the concepts fit together in situations you may recognise.

flowchart TD
    N[Need arises] --> T{Type of need}
    T -->|Remove passwords from code| A[Managed identity, Secrets User role, platform references]
    T -->|Control encryption keys| B[Premium vault or Managed HSM with purge protection]
    T -->|Avoid certificate outages| C[Certificate objects with auto renewal and alerts]
    T -->|Handle heavy read traffic| D[Caching, back-off, vault per workload]
    T -->|Meet strict network rules| E[Private endpoints and disabled public access]
    A --> G[Review roles, logs, and expiry regularly]
    B --> G
    C --> G
    D --> G
    E --> G
        

What these stories have in common

In every scenario, success came from decisions made early and boring habits kept over time. Teams that used identities instead of passwords had nothing to leak. Teams that gave each application its own vault and narrow role kept incidents small. Teams that cached and backed off survived busy moments. Teams that rehearsed recovery found gaps while they were cheap to fix. None of this needed exotic technology, only clear ownership, sensible defaults, and regular review.

Short, direct answers to questions that beginners and busy teams often ask.

A secret is a value your application reads, such as a password. A key is a cryptographic key that stays in the vault while it performs operations. A certificate bundles a public certificate, its key, and a renewal policy.

A vault is a shared service that holds secrets, keys, and certificates. Managed HSM is a dedicated, single-tenant pool of hardware modules that holds only hardware-protected keys, with its own access control and higher fixed cost.

Standard stores keys protected by software and suits most needs. Premium adds hardware-protected keys for rules that require them. Both hold secrets and certificates.

Use Azure RBAC. It is the modern model, offers finer scopes and better auditing, and has become the default for newly created vaults under the newest API version. Existing vaults keep their current model until you change it.

The new vault may use RBAC by default, so the application’s identity needs a role such as Secrets User on the vault. Access policies from an old vault do not carry over.

Give the application a managed identity, assign it the Secrets User role on the vault, and have it request tokens from the platform. No stored credential is needed.

Soft delete keeps deleted vaults and objects recoverable for a retention period of seven to ninety days. Purge protection stops anyone from permanently deleting them early. Once purge protection is on, it cannot be turned off.

Not while it is in the soft-deleted state, because the name stays reserved. Recover it, or wait until the retention period ends if purge protection is on.

Create the new credential in the target, store it as a new version, let applications reload it, and retire the old credential after a grace period. Events can automate the steps.

You are exceeding the vault’s per-window limits. Cache values in memory, spread load across vaults, stagger start-ups, and retry with growing pauses.

Yes. Use a private endpoint with correct private DNS and disable public network access. Test the private path before turning public access off.

They use envelope encryption. The service encrypts data with its own data key and asks the vault to wrap that key with your key, so only small keys travel to the vault.

In most regions, the vault can fail over to a paired region, usually in read-only mode, so reads and cryptographic operations continue while changes wait. Applications should cache values and avoid writes in normal paths.

Object backups restore only within the same subscription and Azure geography. Plan copies and recovery with that limit in mind.

Cache to reduce operations, use hardware-protected keys only where required, share Managed HSM instances across workloads, delete unused objects, and send only needed log categories.

Enable diagnostic settings so audit logs flow to a protected workspace. Each record shows the caller, the object, the operation, the result, and the time.

Azure Key Vault is the strong room for your applications. It keeps secrets, keys, and certificates in one place, checks every caller through Microsoft Entra ID, and records every use. A good design chooses the right tier and object type, gives each application its own vault and a narrow role through a managed identity, keeps the vault private, and uses envelope encryption so that precious keys stay inside. It protects against mistakes with soft delete, purge protection, locks, and tested recovery, plans for throttling and regional failure through caching and independent vaults, and watches the service with logs, alerts, and threat detection. It also keeps pace with change, such as the move of newly created vaults to Azure RBAC and the retirement of older API versions, while governance, policy, and cost reviews keep everything orderly.