Azure Key Vault is a managed cloud service for safely storing and controlling access to secrets, encryption keys, and certificates.

First, What Is a Secret?

Applications constantly need small pieces of private information in order to work. A web application needs a password to open its database. A program that sends email needs an access token for the mail service. A payment system needs a special key to talk to a bank. These private values are commonly called secrets. If a secret falls into the wrong hands, an attacker can pretend to be your application, read private data, or run up large bills.

The traditional but risky habit is to paste secrets directly into program files, configuration files, or chat messages. From there they easily get copied into code repositories, backups, screenshots, and logs, where they live forever. Key Vault exists to end that habit.

The Short Definition

Azure Key Vault is a secure, centralized place in the cloud where you store secrets, cryptographic keys, and digital certificates. “Managed” means Microsoft runs the hardware and software, protects it, and keeps it available, so you do not build your own safe. Your applications ask Key Vault for what they need at the moment they need it, rather than carrying secrets around inside their own files. Every request is checked against permissions and can be recorded in a log.

Secrets scattered across files and machines are among the most common causes of security breaches.

Life Without a Central Safe

Picture a team of developers building an online shop. One stores the database password in a configuration file. Another emails an access token to a colleague. A third copies a certificate onto a laptop so it can be tested, and the laptop is later lost. Months pass. Nobody remembers who has which secret, when it was last changed, or where copies exist. When an employee leaves, nobody can be sure which secrets they knew.

Real incidents follow this pattern again and again. Secrets are accidentally uploaded to public code-sharing sites, where automated scanners find them within minutes. Expired certificates silently break websites at three in the morning because nobody tracked the expiry date. Keys are shared so widely that no one can say who is responsible for them.

What You Gain

Key Vault holds three object types, each designed for a different job.

Secrets

A secret is any small piece of text you want to keep private: a password, a connection string for a database, an access token, or an application setting that must not be public. When an application asks for a secret, Key Vault returns its value, provided the caller is allowed. Secrets can have an expiry date, an activation date, and an on-off switch. Every time you change a secret, Key Vault stores a new version, and older versions remain available for a time, which makes rollbacks possible.

Keys

A cryptographic key is a special value used to lock (encrypt) and unlock (decrypt) data, or to create and check digital signatures. Keys behave differently from secrets in one important way: with a key, you usually do not take the key out. Instead, you send the data to Key Vault and say “please lock this” or “please sign this,” and Key Vault performs the operation inside protected hardware and hands back the result. The raw key stays inside the safe the whole time.

Certificates

A certificate is a digital identity card that proves a website, server, or application is really who it claims to be. It is what makes the padlock appear in a browser. Certificates expire, and they must be renewed, which is a classic source of outages when forgotten. Key Vault can create, import, store, and renew certificates, and it can warn you before they expire. Behind the scenes, a certificate in Key Vault is built from a key and a secret working together, but you manage it as one item.

flowchart TD
  V["Azure Key Vault"] --> S["Secrets - passwords, tokens, connection strings"]
  V --> K["Keys - encrypt, decrypt, sign, verify"]
  V --> C["Certificates - identity with renewal"]
  S --> A1["Application reads the value when needed"]
  K --> A2["Application asks the vault to perform the operation"]
  C --> A3["Service receives certificate for secure connections"]
        

Azure offers more than one way to hold keys, depending on how strong a guarantee you need.

The Vault as a Container

A vault is the Azure resource you create to hold items. It lives in a specific region and belongs to a subscription and resource group. Each vault has its own web address, its own access rules, and its own settings. You can create many vaults, which is common: teams often use separate vaults for separate applications and environments.

Standard and Premium Tiers

When you create a vault, you pick a pricing tier. The Standard tier protects keys with software. The Premium tier adds the option to protect keys with a hardware security module, often shortened to HSM. An HSM is a tamper-resistant device built specifically to hold cryptographic keys. Even Microsoft staff cannot extract keys from it. Organizations with strict regulations often choose HSM-protected keys.

Managed HSM

For the highest level of control, Azure also offers a separate service called Managed HSM. It is a dedicated, single-customer HSM pool that you manage with its own administrators, designed for demanding compliance needs. It is more specialized and costs more than ordinary vaults, so most teams begin with a standard or premium vault and move to Managed HSM only when rules require it.

Following one secret request from an application to the vault reveals where each security check sits.

The Journey in Plain Words

Suppose a web application needs its database password to start. The application does not carry the password. Instead, it first proves its identity to Microsoft Entra ID, Azure’s identity service, and receives a short-lived token that says “this is the order-service application.” It then sends a request to the vault’s address, presenting that token and asking for the secret named “database-password.”

Before returning anything, the vault checks several things. Is the token valid and unexpired? Does this identity have permission to read secrets in this vault? Is the request coming from an allowed network? If every check passes, the vault returns the secret value over an encrypted connection and writes a record of the access to the log. If any check fails, the request is refused and that is recorded too.

sequenceDiagram
  participant A as Application
  participant E as Microsoft Entra ID
  participant N as Network Rules
  participant V as Key Vault
  participant L as Audit Log
  A->>E: Proves its identity
  E->>A: Issues a short-lived token
  A->>V: Requests secret and presents token
  V->>E: Confirms token is valid
  V->>N: Checks request source against network rules
  V->>V: Checks permissions for this identity
  V->>A: Returns secret over an encrypted connection
  V->>L: Records the access
        

The cleverest part of the story: applications can reach the vault without holding any password at all.

The Chicken-and-Egg Problem

Here is a puzzle. If an application needs a secret from the vault, it must first prove who it is to the vault. But proving identity usually requires another secret, such as a password or key. Where does that secret live? If it sits in a configuration file, we have simply moved the problem, not solved it.

The Solution: Managed Identity

A managed identity solves this puzzle. It is an identity that Azure creates and manages for a resource, such as a web app, a virtual machine, or a container. The resource can ask Azure for tokens on its own behalf, and Azure vouches for it, with no password stored anywhere. Azure rotates the underlying credentials automatically, and no human ever sees them. You then grant that managed identity permission to read specific items from the vault.

There are two flavors. A system-assigned identity is tied to one resource and disappears when the resource is deleted. A user-assigned identity is a separate, reusable object that can be attached to several resources, which is helpful when many instances of an application should share the same permissions.

Key Vault separates managing the vault from using what is inside it, which is a crucial security idea.

Two Planes of Access

Access to a vault happens on two separate levels. The management plane is about the vault itself: creating it, deleting it, changing its settings and network rules. The data plane is about what is inside: reading a secret, using a key, or fetching a certificate. These are controlled separately. Someone may be allowed to manage a vault without being able to read its secrets, and the reverse. This separation prevents a general administrator from automatically seeing everyone’s passwords.

Two Permission Models

For the data plane there are two models. The older one is the vault access policy, where each vault carries its own list of who may do what. The recommended modern model is Azure role-based access control, usually shortened to RBAC. With RBAC, permissions are given through roles managed in the same system as the rest of Azure, which makes them consistent, easier to review across the organization, and assignable at different levels such as a whole vault or even a single item.

Common Built-In Roles

Secrets are the most commonly used item type, so it helps to understand how versions, expiry, and referencing work.

Versions and Rotation

Every time you set a new value for a secret, Key Vault creates a new version and keeps the older ones. Applications can ask for “the latest version” by name, or for a specific version. Asking for the latest means that when you rotate a secret, applications pick up the new value the next time they fetch it, without code changes. Rotation means regularly replacing a secret with a fresh one, so that a leaked value stops working after a limited time.

Activation and Expiry Dates

Each secret can have a “not before” date, which prevents use before a planned time, and an expiry date, after which the vault will no longer serve it. Expiry dates encourage regular rotation, and Azure can send events when a secret is nearing expiry so that someone or something can replace it in time.

Referencing Secrets Without Copying Them

Many Azure services can fetch secrets from a vault directly. A web app can be configured so that one of its settings simply points at a vault secret, and the platform fetches the value at runtime using the app’s managed identity. Container platforms can mount vault secrets into containers as if they were files. This means the secret value never needs to be copied into deployment scripts, build logs, or configuration files.

Keys let you protect large amounts of data without ever handing the master key to an application.

Envelope Encryption in Plain Words

Encrypting very large amounts of data directly with a vault key would be slow. Instead, systems use a technique called envelope encryption. The data is encrypted with a fast, temporary data key. Then that data key itself is locked with a stronger master key held in Key Vault. The locked data key is stored next to the data. To read the data, the system sends the locked data key to the vault, which unlocks it using the master key, and the system then decrypts the data.

The advantage is that the master key never leaves the vault, and if you want to change the master key, you only need to re-lock the small data keys, not re-encrypt all the data.

flowchart LR
  D["Your data"] --> E["Encrypted with a data key"]
  DK["Data key"] --> E
  DK --> W["Data key is wrapped by the master key in Key Vault"]
  W --> S["Wrapped data key stored beside the data"]
  E --> S
  S --> R["To read: ask the vault to unwrap the data key"]
  R --> P["Data key decrypts the data"]
        

Customer-Managed Keys

Many Azure services, such as storage accounts, databases, and disks, encrypt your data automatically using keys that Microsoft manages. Some organizations want more control, for example to prove they can revoke access instantly or to meet a rule. These services therefore support customer-managed keys, where the master key is stored in your own Key Vault. If you disable that key, the service can no longer decrypt your data, which acts as an emergency off switch.

Bring Your Own Key

Some organizations generate keys in their own hardware and then import them into the vault, an approach commonly called bring your own key. This gives control over how the key was created, though it also adds responsibility for handling it safely before import.

Key Rotation

Keys can also be rotated, and the vault can be set up with a rotation policy that creates new versions automatically on a schedule. Services that use customer-managed keys can often follow the newest key version automatically, which makes regular rotation practical.

Certificates expire on a schedule, so managing their lifecycle prevents embarrassing outages.

Why Certificates Cause Outages

A certificate has a start date and an end date. When the end date passes, browsers and programs refuse to trust it, and a website suddenly shows frightening warnings or stops working entirely. Many well-known outages were caused by nothing more than a forgotten certificate renewal. Because certificates are installed on many machines, nobody wants to renew them by hand.

What Key Vault Does

Key Vault can create certificates, import ones you already have, and renew them. You can set a policy describing how the certificate should be made, how long it should last, and when to renew, for example when thirty percent of its lifetime remains. For certificates from supported certificate authorities, Key Vault can request renewals automatically. For others, it can send notifications so that people or automation can complete the renewal. It can also use self-signed certificates, which are suitable for testing but not for public websites.

Even with strong identity checks, limiting where requests can come from adds another layer of protection.

Default Behavior

By default, a vault can be reached through the public internet, protected by identity and permission checks. This is already secure for many uses, because an attacker still needs valid credentials. But a determined attacker who steals a credential could then use it from anywhere in the world. Network rules reduce that risk by also restricting where requests may come from.

Layers of Network Control

Mistakes happen, so Key Vault is designed to let you undo deletions within a safety period.

Soft Delete

When you delete a vault or an item inside it, it is not erased immediately. With soft delete, it moves into a recoverable state for a retention period that you choose within a documented range. During that time you can restore it exactly as it was. Soft delete is now on by default for vaults and cannot be turned off, which reflects how many painful accidents it has prevented.

Purge Protection

A soft-deleted item can still be permanently erased on purpose through a “purge” action. Purge protection is an extra setting that blocks purging until the retention period has fully passed, even for administrators. Once enabled, it cannot be undone. This protects against both honest mistakes and malicious insiders or attackers who try to destroy keys to cause damage.

Backup and Restore

Individual items can also be backed up and restored into another vault, within certain limits such as staying in the same Azure geography. This helps with moving items between vaults and adds a further safety net. Remember that a backup of a secret or key is itself sensitive and must be handled with the same care as the original.

A vault that nobody watches cannot warn you when something unusual happens.

What Gets Logged

Key Vault can record each request made to it: who asked, what they asked for, when, from where, and whether it succeeded. These records are not stored in the vault itself. You turn on a diagnostic setting to send them to a destination such as a Log Analytics workspace, a storage account for long-term keeping, or an event stream for other systems. Without this setting, you will have no history to examine after an incident.

What to Watch For

Be Kind to the Service: Caching

Key Vault limits how many requests can be made in a given time. Applications that ask for the same secret on every user request can hit these limits and slow down or fail. A better approach is to fetch a secret once at startup, keep it in memory for a short period, and refresh it periodically. This is faster for the application and gentler on the vault.

If your applications depend on the vault to start, the vault must stay available.

Built-In Resilience

Key Vault is designed for high availability. Data is stored redundantly within a region, and in regions that support it, across separate datacenter zones so that one building failing does not take the service down. In many regions, the service also replicates vault contents to a paired region in the same geography. If an entire region becomes unavailable, requests can fail over to the paired region, usually in a read-only mode until the primary returns. This failover is handled by Microsoft rather than by you.

Designing for Failure

One giant vault for everything is convenient on day one and painful forever after.

Why Splitting Helps

Permissions and network rules apply to a whole vault. If everything lives in one vault, any application that needs one secret may effectively gain access to many. Request limits are also shared per vault, so a busy application can slow down everyone else. Splitting vaults by purpose keeps blast radius small, meaning a problem in one area cannot easily spread to another.

Common Splitting Strategies

No technology is perfect. Seeing both sides helps you decide how to use Key Vault well.

Comparing Ways to Handle Secrets

Teams repeat the same successes and the same mistakes. Learn from both.

Patterns Worth Copying

Anti-Patterns to Avoid

Across industries, teams use Key Vault to remove secrets from places they should never be.

A short checklist that captures the lessons from earlier chapters.

Best Practices

Common Mistakes

A secret is a private text value such as a password that is returned to authorized callers. A key is a cryptographic key used for operations like encrypting and signing, usually without ever leaving the vault. A certificate is a managed digital identity with an expiry date and renewal process.

By using a managed identity. Azure creates and manages the identity for your resource, vouches for it, and rotates its credentials automatically, so you store no password anywhere.

Azure role-based access control is the recommended model. It is consistent with the rest of Azure, easier to review, and can be scoped to a vault or an individual item. Access policies are the older approach.

Not automatically. Managing the vault and reading its contents are separate permissions. Someone can manage settings without having permission to read secret values, unless they are also given a data role.

With soft delete, which is on by default, the item can be restored during the retention period. Purge protection prevents anyone from permanently erasing it until that period ends.

No. Once enabled, purge protection cannot be turned off. Decide carefully, especially for test vaults, since deleted vault names stay reserved until the retention period completes.

Vaults limit the number of requests per period. Applications that fetch secrets on every request can exceed this. Fetch values once, cache them for a short time, and refresh periodically.

Create a private endpoint so the vault has a private address inside your network, then disable public network access. Plan for name resolution and for the sources, such as pipelines, that still need to reach it.

When rules or risk require hardware-protected keys. Premium vaults offer HSM-backed keys, and Managed HSM gives a dedicated, single-tenant HSM pool for the strictest needs. Most teams storing only secrets and certificates are fine with standard.

Turn on diagnostic logging to send access records to a Log Analytics workspace or storage account. Without that setting, no history of requests is kept for you to review.

A common starting point is one vault per application per environment, adjusted for regions and sensitivity. Avoid a single shared vault for everything and avoid creating a vault for every tiny item.

Design for it. Retry with waiting, cache values in memory once fetched, and test how the application behaves when the vault is unreachable. During regional failover, reads usually continue while writes may be unavailable.

Azure Key Vault is a managed safe for the private values that make applications work. It stores secrets that are read when needed, keys that perform cryptographic operations without leaving protected storage, and certificates whose lifecycle it helps renew. Applications prove their identity through managed identities, and permissions are granted with narrow roles, with management and data access kept separate. Network rules, soft delete, purge protection, logging, and alerts surround the vault with extra layers of defense.

Success comes from keeping secrets out of code, giving each application only the access it needs, splitting vaults sensibly, rotating values on a schedule, protecting against deletion, and watching the logs. A vault does not remove the need for good habits, but it makes good habits practical and bad habits visible.