Azure Key Vault: The Strongroom for Your Passwords, Keys, and Certificates
A beginner-friendly guide to Azure Key Vault. Learn what secrets, keys, and certificates are, how access is controlled, how applications read secrets safely, and how to protect, monitor, and manage the vault itself.
Imagine a bank with a strongroom in the basement. Customers do not keep their jewels in a drawer at home, where anyone could grab them. They place them in a safety deposit box. A guard checks each visitor’s identity, a logbook records every visit, and the strongroom door is built to resist attack. Software has its own jewels: database passwords, encryption keys, and security certificates. Keeping them in configuration files, chat messages, or source code is like leaving jewels in a drawer. Azure Key Vault is the strongroom where such valuables are kept safely, checked carefully, and logged every time they are touched.
1What Is Azure Key Vault?
Start with a plain definition, then add the details one layer at a time.
Azure Key Vault is a cloud service for safely storing and managing sensitive items that applications and people need. These items are secrets, cryptographic keys, and certificates. Instead of copying such items into many places, you store them once in a vault, and authorized applications fetch them when needed.
The service is fully managed by Microsoft. You do not run servers or worry about the hardware that protects the vault. You decide what goes in, who may use it, and how long things live. Every access is checked against your rules, and every request can be recorded in a log.
A Key Vault is a bank strongroom with a very strict guard. Valuables go inside. Only approved visitors get in, and each visitor can open only the boxes they are allowed to open. A logbook records who came, when, and what they did.
2The Problem Key Vault Solves
A tool makes sense when you know the pain it removes.
Applications need many sensitive values to do their work: the password to reach a database, the key to call a payment service, the certificate that proves a website is genuine. Developers often take the easy path and put these values directly into code, configuration files, or messages. This creates serious risks.
Secrets in source code
Code is copied, shared, and stored in history forever. A password committed once can leak years later.
Secrets everywhere
The same password gets copied into many files and machines. Changing it means finding every copy.
No record of use
When a password sits in a file, nobody knows who read it or when.
Forgotten expiry
Certificates and keys expire. When nobody notices, websites break and services stop at the worst moment.
Weak protection of keys
Encryption keys kept on ordinary disks are easier to steal than keys kept inside hardened hardware.
Key Vault addresses these problems with one central, protected, logged place for sensitive values, with strict access control, versioning, expiry tracking, and hardware-backed protection options.
3Secrets, Keys, and Certificates Explained
Three kinds of objects live in a vault, and they behave differently.
Secrets
A secret is any small piece of sensitive text that an application needs to read back, such as a database password, an access token, or a connection string. When you ask for a secret, the vault gives you its value. Secrets have a size limit, so they are meant for small values, not large files.
Keys
A cryptographic key is a special value used for operations such as encrypting, decrypting, signing, and verifying. The important difference is that, with a key, you usually do not take the key out of the vault. Instead you send data to the vault and ask it to perform the operation, and the key never leaves the protected boundary. Keys can be created inside the vault or imported, and they can be protected by software or by hardware security modules.
Certificates
A certificate is a digital document that proves identity, most often used for secure websites and for signing in between services. Key Vault can store certificates, create them, and renew them. A certificate in Key Vault is built from three connected pieces: the certificate itself, a key, and a secret holding the full package for apps that need to download it.
| Object | What it is | Can you read the value out? | Typical use |
|---|---|---|---|
| Secret | Small sensitive text value | Yes, authorized callers can read it | Passwords, tokens, connection strings |
| Key | Cryptographic key | Usually not, you ask the vault to use it | Encrypting data, signing, protecting other keys |
| Certificate | Identity document with lifecycle management | Yes, the public part and, if allowed, the full package | Secure websites, service-to-service sign-in |
A secret is a note kept in a safety deposit box that you can take out and read. A key is a master stamp that never leaves the strongroom: you hand in a document, the clerk stamps it inside, and hands it back. A certificate is an official ID card that the bank prints, renews, and lets you show to others.
Every secret, key, and certificate has versions. When you update a secret, the old version is kept, and applications that ask for the latest get the newest one. This makes rotation and rollback much easier.
4Vault Types and Service Tiers
Azure offers more than one product for storing keys, so choose with your needs in mind.
Key Vault Standard
Keys are protected by software. A good, affordable choice for most applications that need secrets, certificates, and software-protected keys.
Key Vault Premium
Adds the option for keys protected by hardware security modules, which are tamper-resistant devices built to guard keys.
Managed HSM
A dedicated, single-tenant service built on validated hardware security modules for the strictest compliance needs. It focuses on keys and gives you full control of the security domain.
| Point | Vault Standard | Vault Premium | Managed HSM |
|---|---|---|---|
| Key protection | Software | Software or hardware | Dedicated hardware modules |
| Stores secrets and certificates | Yes | Yes | Primarily keys |
| Tenancy | Shared service | Shared service | Dedicated to you |
| Best for | Most applications | Regulated workloads needing hardware-backed keys | Highest assurance and sole control of keys |
| Relative cost | Lowest | Higher | Highest, billed for the running pool |
Product names, compliance levels, features, and prices change over time, and some regions differ. Always check the current documentation and pricing before choosing a tier.
Standard is a good bank vault. Premium is a vault with a hardened inner safe built to resist tampering. Managed HSM is your own private bank branch with a guard dedicated only to you. Most people are well served by the first, and only a few need the last.
5Core Building Blocks
Learn these words once and the rest of the topic becomes much easier.
Vault
The Azure resource that holds your secrets, keys, and certificates. It has a unique web address and its own settings.
Vault URI
The address applications use to reach a vault, based on the vault name.
Management plane
The side used to create and configure vaults, set access rules, and manage the resource itself.
Data plane
The side used to read and write the contents of the vault: secrets, keys, and certificates.
Microsoft Entra ID
The identity service that proves who is calling the vault, whether a person, an application, or an Azure resource.
Managed identity
An identity that Azure creates and manages for a resource, such as a web app, so it can sign in to the vault without any stored password.
Azure RBAC
Role-based access control: assigning roles that define what an identity may do at a given scope.
HSM
Hardware Security Module, a tamper-resistant device that stores and uses keys without exposing them.
flowchart TD
SUB["Azure Subscription"] --> RG["Resource Group"]
RG --> KV["Key Vault"]
KV --> S["Secrets: database password, API token"]
KV --> K["Keys: encryption key, signing key"]
KV --> C["Certificates: website certificate"]
S --> V1["Version 1"]
S --> V2["Version 2: current"]
The management plane is the bank’s building manager who decides how many strongrooms exist and who works there. The data plane is the clerk inside who actually opens boxes. Being the building manager does not automatically let you open any box.
6How a Request to the Vault Works
Follow one request from an application to the secret it needs.
The application needs a secret
For example, a web app starts up and needs the password of its database.
It proves who it is
The application asks Microsoft Entra ID for an access token, using its managed identity. No password is stored in the app.
It calls the vault
The application sends the token with a request for the secret to the vault’s address.
The vault checks permission and network rules
The vault verifies the token, confirms the identity has a suitable role, and checks that the request comes from an allowed network.
The secret is returned
If everything is allowed, the vault returns the secret value over a secure connection.
The request is logged
The vault records the request in its audit log, including who asked, what for, and the result.
sequenceDiagram
participant App as Web App with Managed Identity
participant AAD as Microsoft Entra ID
participant KV as Key Vault
participant Log as Audit Log
App->>AAD: Request access token for Key Vault
AAD-->>App: Access token
App->>KV: Get secret, with the token
KV->>KV: Check identity, role, and network rules
KV-->>App: Secret value
KV->>Log: Record the request
The application shows its staff badge at the front desk, which issues a short visitor pass. It then shows the pass at the strongroom. The guard checks the pass, checks the list of who may open which box, hands over the item, and writes the visit in the logbook.
7Access Control: Who Can Do What
A vault is only as safe as its access rules.
Two things protect every call to a vault. First, authentication proves who is calling, and this is done by Microsoft Entra ID. Second, authorization decides what that caller may do, and this is done either by Azure role-based access control or by older vault access policies.
Azure RBAC (recommended)
Uses the same role system as the rest of Azure. Roles can be assigned at the vault level or even to a single secret, key, or certificate. It offers consistent management, auditing, and conditional access features.
Vault access policies (legacy)
An older model where each vault holds a list of identities and their permissions. It is less flexible and harder to manage at scale, so new vaults should prefer RBAC.
Common built-in roles
| Role idea | What it allows | Who needs it |
|---|---|---|
| Key Vault Administrator | Full control over the contents of the vault | A very small group of trusted administrators |
| Key Vault Secrets User | Read secret values | Applications that fetch secrets |
| Key Vault Secrets Officer | Create and manage secrets | Teams that publish and rotate secrets |
| Key Vault Crypto User | Use keys for operations such as encrypt and sign | Applications using keys for cryptography |
| Key Vault Crypto Officer | Create and manage keys | Security teams managing keys |
| Key Vault Certificates Officer | Manage certificates | Teams that handle certificate issuance and renewal |
| Key Vault Reader | See vault metadata but not the secret values | Auditors and monitoring tools |
Give applications only the read role they need, and only on the vault, or even only on the single secret they use. Reserve administrator roles for people, not for applications.
Problem
Giving every application and developer the administrator role on the vault so that nothing ever fails with a permission error.
Why It’s Harmful
One compromised application or account can read, change, or delete every secret and key. It also makes audit logs less meaningful because everyone can do everything.
Correct Approach
Grant narrow roles, such as a secrets reader for applications, at the smallest scope that works, and keep administrator access for a small, monitored group.
Handing out the administrator role to everyone is like giving every employee a master key to every box in the strongroom. Giving each person a key to only the box they need means that losing one key causes only a small problem.
8Managed Identities: Passwordless Access
The best secret is the one you never have to store.
There is a funny puzzle at the heart of secret storage. An application needs a password to open the vault, but where should it keep that password? If it is stored in a file, you have just moved the problem. Managed identities solve this puzzle. Azure gives the resource its own identity and handles its credentials behind the scenes. The application simply asks Azure for a token, and Azure provides one, proving that this resource is who it claims to be.
System-assigned identity
Tied to one resource and deleted with it. Simple, and good when one resource needs its own access.
User-assigned identity
Created separately and attached to one or many resources. Good when several resources share the same access, or when the identity should outlive a resource.
Turn on a managed identity
Enable it on the web app, function, virtual machine, or container app that needs secrets.
Assign a role on the vault
Give that identity the secrets reader role on the vault, or on a single secret.
Allow the network path
Make sure the vault’s network rules permit the resource to reach it, for example through a private endpoint.
Fetch secrets at runtime
The application reads secrets when it starts or when needed, without any stored credentials of its own.
A managed identity is like a staff fingerprint reader. You do not carry a card that can be stolen or copied. The building recognizes you directly, and when you leave the company, your access disappears automatically.
Applications running outside Azure, such as on-premises servers or other clouds, cannot use Azure managed identities directly, but there are options such as Azure Arc and federated credentials. Check current documentation for the best fit.
9Using Key Vault from Azure Services
Many Azure services can read from a vault with very little effort.
App Service and Azure Functions
Application settings can point to a secret in a vault using a special reference. The platform reads the value using the app’s managed identity, so the secret never appears in your configuration or code.
Azure Container Apps
Secrets in a container app can refer to Key Vault secrets, using a managed identity to fetch them.
Azure Kubernetes Service
A secrets store driver can mount vault secrets into pods as files or provide them as environment values, authenticating with workload identity.
Virtual machines
Applications on a virtual machine can use the machine’s managed identity to read secrets, and extensions can fetch certificates automatically.
Azure Data Factory, Logic Apps, and Synapse
Connections to databases and other systems can read credentials from the vault so they are not stored in pipeline definitions.
CI/CD pipelines
Deployment pipelines can fetch secrets at deploy time from the vault instead of keeping long-lived copies in the pipeline system.
flowchart LR
KV["Key Vault"]
WA["App Service or Functions"] -->|Managed identity| KV
CA["Container Apps"] -->|Managed identity| KV
AKS["Kubernetes pods with workload identity"] -->|Secrets store driver| KV
VM["Virtual Machines"] -->|Managed identity| KV
ADF["Data Factory and Logic Apps"] -->|Managed identity| KV
PIPE["Deployment pipelines"] -->|Federated identity| KV
An application setting that points to a vault secret is like a sticky note saying “ask the strongroom for the box labelled database password”. The note itself is harmless. Only the right employee can actually fetch the contents.
10Encrypting Data with Your Own Keys
Key Vault is also the home for keys that protect data in other Azure services.
Most Azure services encrypt your data automatically using keys managed by Microsoft. Some organizations must control their own keys, for example to satisfy regulations or internal rules. This is called a customer-managed key. You keep the key in Key Vault or Managed HSM, and the service uses it to protect the actual data encryption keys.
Azure Storage
Use a customer-managed key to protect stored blobs, files, queues, and tables.
Azure SQL and managed databases
Use a key as the protector for transparent data encryption.
Managed disks and virtual machines
Use disk encryption sets backed by a key in the vault.
Cosmos DB, Azure Monitor, and others
Many services support customer-managed keys for stronger control over data.
Bring your own key
Some organizations generate keys in their own hardware and then import them into the vault, called bring your own key. This lets them prove where the key came from and keep a copy under their control. Premium and Managed HSM support importing keys protected by hardware.
flowchart TD
KEK["Key in Key Vault or Managed HSM"] -->|Wraps and unwraps| DEK["Data encryption key used by the service"]
DEK -->|Encrypts| DATA["Your stored data"]
SVC["Azure service with managed identity"] --> KEK
If a customer-managed key is deleted or becomes inaccessible, the data it protects may become unreadable forever. This is why soft delete and purge protection are essential for vaults that hold such keys.
Envelope encryption is like locking your documents in a small box, then locking that small box’s key inside the bank strongroom. Anyone who wants the documents must ask the strongroom for the small key first, and the strongroom can refuse.
11Certificates and Their Life Cycle
Certificates expire, and expired certificates cause outages. Key Vault helps you stay ahead.
A certificate has a start date and an end date. After it ends, browsers and services refuse to trust it. Many teams have suffered embarrassing outages simply because a certificate expired and nobody noticed. Key Vault can create certificates, import existing ones, and renew them automatically before they expire.
Self-signed certificates
Created by the vault itself. Fine for testing, but not trusted by the public.
Integrated certificate authorities
The vault can work with certain trusted authorities to request and renew public certificates automatically. The list of supported partners can change.
Other authorities
You can create a request to send to any authority and then merge the signed result back into the vault.
Imported certificates
Upload an existing certificate with its private key and let the vault store and track it.
Create or import
Add the certificate with a policy that says how long it lasts, what it is for, and how it should renew.
Use
Services such as application gateways and web apps read the certificate from the vault and use it.
Renew before expiry
At a chosen time before the end date, the vault requests a new version automatically, or sends a notification.
Pick up the new version
Consumers that follow the latest version pick up the renewed certificate, often with no manual action.
Set up notifications and alerts for approaching expiry on every certificate, even ones that renew automatically. Automation can fail, and a warning email days before the deadline is cheaper than an outage.
A certificate is like a passport. It has an expiry date. The vault is the clerk who reminds you early, renews it for you, and places the new passport in your drawer so you never turn up at the airport with an expired one.
12Rotation and Expiry: Keeping Secrets Fresh
A secret that never changes becomes more dangerous every year.
The longer a password or key stays the same, the more people may have seen it, and the greater the chance it has leaked. Rotation means replacing a value with a new one on a regular schedule. Key Vault supports this through versions, expiration dates, and rotation policies for keys, plus events that tell other systems when something is about to expire.
Versions
Each update creates a new version, so you can roll out a new value without deleting the old one at once.
Activation and expiration dates
A secret or key can be set to become valid at a time and to expire at a time, after which the vault refuses to use it.
Key rotation policy
Define how often a key is automatically rotated, and when to notify before expiry.
Event notifications
The vault can publish events through Event Grid when an item is near expiry or has been rotated, triggering functions or workflows.
Create the new value
Generate a new password or key, for example in the target database or service.
Store it as a new version
Add the new value to the vault as the latest version of the same secret.
Let applications pick it up
Applications that read the latest version receive the new value on their next refresh.
Disable the old value
After a safe overlap, disable the old version and revoke the old password in the target system.
Pinning an application to a specific secret version. The vault now holds the new value, but the application keeps using the old one and fails when the old value is retired. Reference the latest version unless there is a clear reason not to.
Rotation is like changing the lock on the shop door regularly. You cut new keys first, hand them to the staff, make sure everyone can open the door, and only then throw away the old keys.
13Protecting Against Accidents: Soft Delete and Purge Protection
A strongroom that can be emptied by one wrong click is not very safe.
Soft delete
When you delete a vault or an item, it is not removed at once. It moves to a recoverable state for a retention period that you choose within allowed limits. During that time you can recover it. Soft delete is on by default for new vaults and cannot be turned off.
Purge protection
When turned on, even an administrator cannot permanently remove a deleted vault or item until the retention period ends. This guards against both accidents and malicious deletion. Once enabled, it cannot be disabled, so decide carefully.
flowchart LR
ACT["Active item"] -->|Delete| SOFT["Soft-deleted: recoverable"]
SOFT -->|Recover| ACT
SOFT -->|Purge, if purge protection is off| GONE["Permanently deleted"]
SOFT -->|Retention period ends| GONE
| Setting | What it does | Recommended for |
|---|---|---|
| Soft delete | Keeps deleted items recoverable for a period | All vaults, and it is on by default |
| Purge protection | Blocks permanent removal during the retention period | Production vaults, and required for some features such as certain customer-managed key setups |
Soft delete is the recycle bin on your computer. Purge protection is a lock on the recycle bin that nobody, not even the boss, can open until the waiting period is over. Together they make an accidental or malicious deletion recoverable.
Vault names are globally unique. A soft-deleted vault still holds its name, so you cannot reuse the name until the vault is recovered or purged. Plan names with that in mind.
14Network Security for the Vault
Even with strong identity checks, you should limit who can reach the vault at all.
Public access with firewall rules
Allow only certain addresses or ranges to reach the vault. Everything else is refused before authentication.
Virtual network service endpoints
Allow only chosen subnets to reach the vault over Microsoft’s backbone network.
Private endpoints
Give the vault a private address inside your virtual network, and disable public access entirely. This is the strongest and most common choice for production.
Trusted Azure services
An option that lets certain Microsoft services bypass the firewall to reach the vault, for scenarios such as backup or disk encryption.
flowchart LR
NET["Public Internet"] -. blocked .-> KV["Key Vault with public access disabled"]
APP["App in Virtual Network"] -->|Private Endpoint| KV
OFF["Office network via VPN or ExpressRoute"] -->|Private Endpoint| KV
Using a private endpoint but forgetting the name resolution part. Applications keep resolving the vault name to a public address and fail once public access is off. Link the private DNS zone for Key Vault to your virtual networks.
Firewall rules are a guest list at the door of the bank. A private endpoint is an internal corridor connecting your office directly to the strongroom, so visitors never even walk down the public street.
15Monitoring and Auditing
A strongroom needs a logbook and an alarm.
Key Vault can send detailed audit logs to a Log Analytics workspace, a storage account, or an event hub through diagnostic settings. The logs record every data-plane request: who called, from where, what operation, and whether it succeeded. They also help you spot unusual patterns, such as a sudden burst of failed requests or a secret being read by an unexpected identity.
Audit events
Every read, write, delete, and failed attempt, with the caller identity and time.
Metrics
Request counts, latency, and availability, useful for capacity and health checks.
Activity log
Management actions on the vault resource itself, such as changing access rules or network settings.
Defender alerts
Microsoft Defender for Key Vault can flag suspicious access patterns where it is enabled.
Turn on diagnostic logs
Send audit events to a central workspace and keep them long enough for investigations and compliance.
Build queries and dashboards
Track who reads which secrets, failed attempts, and new identities calling the vault.
Create alerts
Alert on bursts of failures, access from unexpected places, deletions, and permission changes.
Review regularly
Check role assignments and access patterns on a schedule and remove what is no longer needed.
Audit logs are the strongroom’s visitor book and camera footage. Alerts are the alarm that rings when someone tries the wrong door ten times in a minute.
16Availability, Backup, and Disaster Recovery
If the vault is unavailable, applications that depend on it may fail to start.
Key Vault is designed for high availability. Within a region it stores data redundantly, and data is also replicated to a paired region. If the primary region has a serious failure, the vault can fail over to the secondary region, where it is typically available in read-only mode until the primary returns. The exact behavior depends on the region pair and service updates, so confirm current details.
Cache secrets in the application
Fetch secrets at startup and cache them for a short time instead of calling the vault on every request. This reduces load and protects against brief outages.
Handle throttling politely
The service limits how many requests it accepts in a period. If you receive a too-many-requests response, wait and retry with increasing delays.
Use a vault per application and environment
Separate vaults reduce the blast radius of problems, avoid shared throttling limits, and keep access rules simple.
Back up important items
Individual secrets, keys, and certificates can be backed up and restored, and Managed HSM has its own full backup process. Protect backups as carefully as the originals.
Plan a second vault for cross-region needs
For applications running in more than one region, consider a vault in each region with synchronized content, so each region reads from a nearby vault.
Problem
Reading the same secret from the vault on every single request an application receives.
Why It’s Harmful
It adds delay, can hit the service’s request limits during busy periods, and makes the whole application fail whenever the vault has a hiccup.
Correct Approach
Read secrets at startup or on a refresh schedule, keep them in memory for a reasonable time, and refresh when they change.
Calling the vault for every request is like walking to the bank every time you need to know your own phone number. Write it down in your pocket diary after the first visit and only go back when you hear it has changed.
17Governance with Azure Policy
In a large organization, you want vaults to follow the same rules everywhere.
Azure Policy can check and enforce vault settings across many subscriptions. This turns your security standards into automatic guardrails, rather than documents that people may forget to read.
| Policy idea | What it does |
|---|---|
| Require soft delete and purge protection | Flags or blocks vaults without these protections |
| Require private endpoints or restricted network access | Ensures vaults are not open to the whole internet |
| Require diagnostic logs | Deploys diagnostic settings so every vault sends audit logs to the central workspace |
| Prefer Azure RBAC over access policies | Keeps access management consistent |
| Require expiration dates on secrets and keys | Prevents never-expiring secrets from piling up |
| Limit key types and sizes | Makes sure only approved cryptographic strengths are used |
| Control certificate validity and renewal settings | Avoids very long-lived certificates and ensures renewal is planned |
flowchart TD
POL["Azure Policy definitions"] --> MG["Management Group or Subscription"]
MG --> V1["Vault A"]
MG --> V2["Vault B"]
MG --> V3["New vaults created later"]
V1 --> CMP["Compliance report"]
V2 --> CMP
V3 --> CMP
Policies are the building code for strongrooms. Every new strongroom in the city must have a thick door, a camera, and a logbook, and inspectors check that the rules are followed.
18Cost and Limits
Key Vault is usually inexpensive, but a few things affect the bill.
Pricing is generally based on the number of operations, such as reading a secret or performing a key operation, with different rates for different types of operations and for certificates. Premium and hardware-protected keys cost more, and Managed HSM is billed for the running service pool. Prices, tiers, and free allowances change, so use the official pricing page and the Azure pricing calculator.
Operation counts
Frequent reads multiply cost and risk throttling. Caching reduces both.
Key protection level
Hardware-protected keys cost more than software-protected keys.
Certificate renewals
Automatic renewals from integrated authorities may carry extra charges from the authority.
Managed HSM pools
A dedicated pool is billed by the hour while it exists.
Logging and private endpoints
Audit logs sent to a workspace and private endpoints have their own charges.
The service enforces limits such as the maximum size of a secret and the number of requests per period. These limits can change, so check the current limits page when planning large or busy applications.
Paying per operation is like paying per visit to the safety deposit box. A few visits cost almost nothing. Walking in thousands of times a day for the same note costs more and annoys the guard.
19Real-World Use Cases
See how different organizations use Key Vault every day.
A web store keeping database passwords out of code
The store’s web app uses a managed identity to read its database password from the vault. Developers never see the password, and rotation happens without changing any code.
A bank encrypting data with its own keys
The bank stores keys in Managed HSM and uses them to protect storage and databases. Auditors can see exactly when keys were used and by which service.
A company automating website certificates
Certificates are created and renewed in Key Vault. An application gateway reads them automatically, so websites never show an expiry warning to customers.
A software team securing deployments
The deployment pipeline signs in to Azure without stored passwords and fetches only the secrets it needs at deployment time, for the environment being deployed.
A healthcare provider protecting patient data
Customer-managed keys protect storage and databases. Private endpoints close public access, and audit logs go to a central security workspace with alerts for unusual activity.
A SaaS company signing tokens
The company keeps a signing key inside the vault and asks it to sign tokens, so the key itself never appears in application memory or configuration.
20Key Vault Compared with Related Options
Several services store settings or secrets. Knowing the differences prevents misuse.
| Option | What it is | Choose it when |
|---|---|---|
| Azure Key Vault | Secure store for secrets, keys, and certificates | You handle anything sensitive that needs protection, auditing, and lifecycle control |
| Azure Managed HSM | Dedicated hardware-backed key service | You need the highest key assurance and sole control of the security domain |
| Azure App Configuration | Central store for non-secret settings and feature flags | You manage ordinary settings shared by many applications. Secrets can be referenced from Key Vault |
| Application settings in App Service | Per-app settings | Simple, non-sensitive settings, or Key Vault references for secrets |
| Environment variables or files in source code | Plain storage on disk or in a repository | Never for secrets that matter |
| Managed identities | Passwordless identities for Azure resources | You want to avoid having a credential at all |
| Third-party secret managers | Other vault products | Your organization standardized on them across several clouds |
First try to avoid secrets entirely by using managed identities. Where a secret is unavoidable, keep it in Key Vault. Keep non-sensitive settings in App Configuration or app settings.
21Advantages and Trade-offs
An honest look helps you decide with open eyes.
Advantages
- One central, protected place for secrets, keys, and certificates
- Strong identity-based access control and full audit logging
- Passwordless access for Azure resources through managed identities
- Hardware-backed key protection options for strict compliance
- Versioning, expiry dates, rotation, and certificate renewal support
- Deep integration with Azure services for encryption and secret references
Disadvantages / Trade-offs
- Applications depend on the vault, so poor handling of outages and throttling can hurt availability
- Misconfigured roles or networks can block legitimate access in confusing ways
- Purge protection and deleted-key mistakes can have permanent consequences
- Hardware-backed options and dedicated HSMs add cost
- The vault protects stored secrets but cannot stop an application from leaking a secret after reading it
- Rotation still requires design work, because applications and target systems must cooperate
22Best Practices and Mistakes to Avoid
Habits that keep your secrets safe, your applications running, and your auditors happy.
Avoid secrets where you can
Use managed identities and federated credentials so there is nothing to store, and keep the vault for what is truly needed.
Use one vault per application and environment
Keep development, test, and production separate, with their own vaults and access rules.
Use Azure RBAC with least privilege
Give applications read-only secret access, give people limited officer roles, and keep administrators few.
Turn on soft delete and purge protection
Protect against accidental and malicious deletion, especially for vaults that hold encryption keys.
Lock down the network
Prefer private endpoints, disable public access where possible, and set up private DNS correctly.
Log, alert, and review
Send audit logs to a central workspace, alert on unusual activity, and review role assignments regularly.
Set expiry and rotate
Give secrets and keys expiration dates, rotate on a schedule, and use event notifications to trigger rotation workflows.
Design applications for resilience
Cache secrets, retry politely when throttled, and test what happens if the vault is briefly unreachable.
Problem
Storing the vault’s own access credentials, such as a client secret for the application, in a configuration file next to the application code.
Why It’s Harmful
You have only moved the problem. Anyone who finds the file can open the vault and read every secret, so the vault adds little real protection.
Correct Approach
Use managed identities or workload identity federation so the application authenticates to the vault without any stored credential.
Problem
Putting every team’s secrets for every environment into one shared vault.
Why It’s Harmful
Permissions become tangled, one compromised account may reach everything, and heavy use by one application can throttle all the others.
Correct Approach
Create separate vaults per application and environment, with narrow roles and clear ownership.
Problem
Copying a secret out of the vault into a ticket, a chat message, or a spreadsheet to share it with a colleague.
Why It’s Harmful
The copy lives on in places with no access control or audit trail, defeating the purpose of the vault.
Correct Approach
Grant the colleague or their application appropriate access to the vault instead of sharing the value itself.
Problem
Letting secrets and certificates live forever with no expiry, no owner, and no rotation plan.
Why It’s Harmful
Old credentials accumulate, nobody knows what depends on them, and a leaked value stays dangerous for years. Meanwhile surprise certificate expiries cause outages.
Correct Approach
Assign an owner, set expiry dates, automate renewal and rotation where possible, and receive notifications before expiry.
23Frequently Asked Questions
A secret is a small sensitive value you read back, such as a password. A key is a cryptographic key that normally stays inside the vault while the vault performs operations for you. A certificate is an identity document, often for secure websites, with lifecycle features such as renewal.
Use a managed identity. Azure gives your web app, function, container, or virtual machine its own identity. You assign that identity a role on the vault, and the application requests tokens from Azure to read secrets, with no stored credential.
Azure RBAC is recommended for new vaults. It is consistent with the rest of Azure, supports finer scopes, and works better with governance tools. Access policies are an older model that remains for compatibility.
With soft delete, which is on by default, the item or vault stays recoverable for the retention period. If purge protection is on, nobody can permanently remove it until that period ends. After the period, or after an allowed purge, it is gone permanently.
Creating or managing the vault is a management-plane right. Reading its contents is a data-plane right and needs its own role or policy. Also check network rules, because a firewall or disabled public access can block requests even from authorized identities.
Only if your requirements demand it, for example strict regulatory rules, a single-tenant key service, or full control of the security domain. Many organizations are well served by Key Vault Standard or Premium. Compare compliance needs and cost before deciding.
Use a certificate policy with automatic renewal, make sure consumers use the latest version, and set up expiry notifications and alerts as a safety net. Test the renewal process before it matters.
You can, but it is not the best tool. Use Azure App Configuration for ordinary settings and feature flags, and reference Key Vault from it for the few values that are truly sensitive.
24Summary and Key Takeaways
Azure Key Vault is Azure’s strongroom for secrets, keys, and certificates. It keeps sensitive values out of code and configuration, checks every request against identity and permission rules, and records the activity in audit logs. Managed identities let applications read from the vault without any stored password, and Azure RBAC with least privilege keeps access narrow. Keys can be protected by hardware, used to encrypt data in other Azure services, and rotated on a schedule. Certificates can be renewed automatically, soft delete and purge protection guard against deletion, and private endpoints keep traffic off the public internet. Azure Policy spreads good rules across all vaults. Design applications to cache secrets and handle throttling, separate vaults by application and environment, and your sensitive values will stay both safe and available.
Key Takeaways
- One strongroom for sensitive values — Key Vault stores secrets, keys, and certificates with versioning, logging, and strong access control.
- Prefer passwordless access — use managed identities so applications fetch secrets without any stored credential, and avoid secrets entirely where you can.
- Apply least privilege with Azure RBAC — separate management rights from data rights, give applications read-only roles, and keep administrators few.
- Protect against loss — turn on soft delete and purge protection, especially for vaults holding encryption keys that protect other data.
- Lock down the network — use private endpoints or firewall rules, and set up private DNS so applications can still resolve the vault.
- Keep things fresh — set expiry dates, rotate secrets and keys, renew certificates automatically, and alert before expiry.
- Watch and design for resilience — send audit logs to a central workspace, alert on unusual access, cache secrets, retry when throttled, and separate vaults by application and environment.