Azure Key Vault

About Azure Key Vault

Azure Key Vault is Microsoft's managed Azure service for protecting application secrets, cryptographic keys and certificates. It helps teams keep sensitive material out of source code, deployment files and unmanaged credential stores while centralizing identity, authorization, auditing, recovery and lifecycle controls. Key Vault has Standard and Premium vault tiers, while Azure Managed HSM is a separate resource type for organizations that need dedicated HSM-backed key management. Buyers should choose based on what they need to protect, expected transaction volume, authorization model, networking, recovery requirements and whether HSM-backed keys are required.

What is Azure Key Vault used for?

Azure Key Vault is used to store and control access to passwords, API keys, tokens, connection credentials, encryption keys and certificates. Microsoft groups the service around secrets management, key management and certificate management. Applications can retrieve protected values at runtime instead of embedding them in code or distributing them manually across servers.

Key Vault can support applications hosted in Azure, another cloud or on premises. The main value is centralized control of sensitive material so teams can rotate, revoke and audit access without redeploying every application that consumes a secret or key. It is a security dependency, so applications should also plan for caching, retries and controlled failure behavior instead of making unnecessary vault calls on every request.

What is the difference between Standard, Premium and Managed HSM?

Standard Key Vault supports software-protected RSA and elliptic curve keys together with secrets and certificates. Premium adds HSM-protected keys for workloads that need hardware-backed cryptographic protection. Azure Managed HSM is a separate resource type with dedicated HSM instances and its own limits, roles, billing and operational model.

HSM protection should not be described as one identical hardware level for every historical key version. Microsoft's current key documentation states that HSM Platform 1 protects key versions with FIPS 140-2 Level 2 hardware, while HSM Platform 2 protects key versions with FIPS 140-3 Level 3 hardware. All new HSM-backed keys and key versions are now protected by HSM Platform 2. Teams can inspect the hsmPlatform attribute to determine which platform protects a specific key version.

How does access control work in Key Vault?

Azure Key Vault separates management of the vault resource from data-plane access to keys, secrets and certificates. Microsoft recommends Azure role-based access control for data-plane permissions. Starting with control-plane API version 2026-02-01, Azure RBAC is the default access model when a new vault is created unless enableRbacAuthorization is explicitly set to false.

Existing vaults do not automatically switch models simply because they are updated with API version 2026-02-01 or later. Vaults using legacy access policies can continue to do so, although Microsoft recommends migration to Azure RBAC for stronger separation of duties and centralized role management. Managed identities can also reduce the need to distribute application credentials.

What changes before February 27, 2027?

Microsoft states that all Azure Key Vault control-plane API versions earlier than 2026-02-01 retire on February 27, 2027. Vaults and their stored data do not disappear on that date, but management clients must use control-plane API version 2026-02-01 or later. Data-plane APIs are not affected by this retirement.

Organizations should review ARM and Bicep templates, Terraform configurations, REST calls, SDK versions, automation scripts and Cloud Shell workflows before the deadline. This is especially important for older infrastructure-as-code templates that assume the previous access-control default. A deployment can otherwise behave differently when a newer API version creates a vault with Azure RBAC by default.

What transaction and scale limits matter?

Key Vault applies transaction limits per vault and region. Microsoft's current service limits list up to 4,000 all-other transactions per 10 seconds for secrets, certificates, managed storage account keys and general vault transactions. Create-secret, import-certificate and import-key operations share a combined limit of 300 transactions per 10 seconds.

Cryptographic key operations have different limits depending on key type, size and protection method. For example, RSA 2048 software-key all-other transactions can reach 4,000 per 10 seconds per vault per region, while RSA 2048 HSM-key all-other transactions are limited to 2,000. Larger RSA HSM keys have lower transaction ceilings. A subscription-wide limit for each transaction type is five times the individual vault limit.

Key Vault does not impose a fixed count limit on the number of keys, secrets or certificates stored in a vault, but transaction limits still determine practical throughput. Backup operations support up to 500 versions of an individual key, secret or certificate. Large version histories can also affect backup performance.

How should applications handle Key Vault throttling?

When clients exceed Key Vault service limits they can receive HTTP 429 responses. Microsoft recommends retry behavior with backoff, caching retrieved secrets in memory where appropriate, and avoiding unnecessary repeated reads. Applications with separate security or availability domains can also use separate vaults, regions or subscriptions when that architecture is justified.

Caching should still respect rotation and revocation needs. A long-lived cached value can defeat a carefully designed rotation process if the application never refreshes it. Teams should define how long a value can remain cached, what triggers a refresh, and how an application behaves when Key Vault is temporarily unavailable.

How should teams protect against deletion?

Soft delete keeps deleted vaults, keys, secrets and certificates recoverable for a configured retention period from 7 to 90 days. The default is 90 days. Microsoft states that the retention interval is chosen when the vault is created and cannot be changed afterward. Soft delete is enabled by default for new vaults and, once enabled, cannot be disabled.

Purge protection adds a stronger time-based safeguard that prevents permanent deletion until the retention period has elapsed. When a vault is recovered, some integrated resources are not automatically restored. Microsoft specifically notes that Azure RBAC role assignments and Event Grid subscriptions must be recreated after recovery. Teams should therefore treat recovery as a tested operational process rather than assume that restoring the vault restores every dependency around it.

How does Azure Key Vault pricing work?

Azure Key Vault does not have one flat subscription price. Microsoft prices Standard and Premium vault usage by operations, with additional charges for qualifying HSM-protected keys and other metered activities. Managed HSM is billed separately as provisioned HSM capacity. Key Vault itself has no setup fee.

Pricing was rechecked against Microsoft's Azure Key Vault pricing page on September 4, 2026. Exact rates can vary by agreement, currency and commercial context, so Brandligo does not hard-code one amount as the universal cost of Key Vault. Buyers should estimate secret and key transaction volume, certificate activity, active HSM key versions, rotation activity and any Managed HSM requirements.

What are the main limitations and tradeoffs?

Key Vault is not a general configuration database. Placing every non-sensitive setting in the vault can add latency, transaction volume and troubleshooting complexity without improving security. Applications that retrieve protected data during startup or on every request need a resilient access pattern and should not assume the vault can be queried without limits.

Authorization and networking can also create operational friction. RBAC, private endpoints, managed identities, deployment pipelines and recovery permissions need to be designed together. HSM-backed protection costs more and can introduce stricter operational requirements. Teams should match the protection level to actual risk, compliance and cryptographic requirements rather than selecting the most restrictive option by default.

Who should choose something else?

Teams that only need non-sensitive application configuration should use an appropriate configuration service or application settings rather than forcing all configuration into Key Vault. Organizations that need dedicated HSM capacity, tighter HSM role separation or higher secure key release throughput should evaluate Azure Managed HSM. Workloads that require one secrets control plane across several cloud providers may also compare specialist multicloud secrets platforms.

Azure Key Vault is strongest when an organization wants Azure-native management of secrets, keys and certificates with Microsoft Entra identity, Azure RBAC, recovery controls and integration across Azure services. It is a better fit when centralized security and lifecycle management matter more than keeping credentials inside individual applications or servers.