Microsoft Azure Services – Azure Key Vault

Azure Key Vault is Microsoft’s cloud service for storing and controlling access to cryptographic keys, secrets, and certificates. It matters because every credential an application needs (encryption keys, connection strings, TLS certificates) becomes a single point of compromise if left in code or config files instead of a managed vault. Recommended action: use Key Vault with Azure RBAC and managed identities by default, and reserve Managed HSM for workloads with a documented dedicated-hardware requirement.

Published: February 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Key Management Team.

For how Azure Key Vault fits into a broader compliance program, see How You Can Make Organizations More Complaint With Microsoft Azure?. For how Key Vault compares to AWS and GCP’s key management services, see AWS KMS Vs Azure Key Vault Vs GCP KMS. For cloud HSM options generally, see Comparison between Cloud-based HSM versus On-Premises HSM, and for certificate-based identity across clouds, see What is Cloud-based PKI Architecture?.

What Is Azure Key Vault?

Azure Key Vault is a cloud service that acts as a central, access-controlled store for an organization’s sensitive material, organized into three resource types: secrets (connection strings, passwords, API keys, up to 10 KB each), keys (cryptographic keys used for encryption, signing, and key wrapping, which never leave the vault’s secure boundary in usable form), and certificates (SSL/TLS X.509 certificates that Key Vault can provision, renew, and deploy to integrated Azure services). By design, even Microsoft cannot extract or view customer key material; every operation happens inside the vault or HSM boundary and is logged for audit.

How Does Native vs. External Key Control Work in Azure Key Vault?

Azure Key Vault and its related services offer several tiers of key custody, trading off cost, isolation, and who ultimately controls the key material:

Key-control tier	Protection level	Best fit
Standard tier (native, software)	FIPS 140-2 Level 1, software cryptographic module.	Default for most secrets, keys, and certificates.
Premium tier (native, HSM-backed)	FIPS 140-3 Level 3 on current HSM Platform 2 hardware, shared multi-tenant pool.	Workloads needing hardware-backed keys without dedicated HSM cost.
Managed HSM (native, dedicated)	FIPS 140-3 Level 3, dedicated single-tenant HSM pool; every key is HSM-protected, no software-key option.	Regulated workloads needing full administrative control over a dedicated HSM.
Azure Dedicated HSM (customer-controlled)	Customer-administered physical HSM appliance; Microsoft does not operate it.	A compliance mandate that the cloud provider never administer the HSM itself.
BYOK (imported key material)	Key material generated outside Azure, often in an on-premises HSM, imported into Key Vault or Managed HSM.	Organizations needing to prove key provenance or already generating keys on-prem.

Default to Standard or Premium unless a named requirement calls for Managed HSM’s dedicated pool or Dedicated HSM’s customer-administered hardware; both cost meaningfully more and are worth it only when a specific mandate requires that level of isolation.

What Are the Core Azure Key Vault Concepts You Need to Know?

• Secret: a small data blob (up to 10 KB) such as an authentication key, password, token, or .pfx file, retrieved by an authorized caller rather than embedded in application code.
• Key: a cryptographic key used for encrypt/decrypt, wrap/unwrap, or sign/verify operations; unlike secrets, key material never leaves the vault’s secure boundary.
• Key Vault owner: the administrator who creates the vault and authorizes users and applications for specific operations.
• Service principal: the identity an application uses to authenticate to Azure Active Directory (Microsoft Entra ID) and, in turn, to Key Vault.
• Access policy vs. role assignment: the legacy, vault-scoped permission model versus Azure RBAC’s role-based permission model, described below.

How Should IAM Be Structured for Azure Key Vault?

Azure RBAC is Microsoft’s recommended permission model for Key Vault, replacing the older vault-level access-policy system with the same granular, auditable role assignments used across the rest of Azure.

1. Migrate vaults still on the legacy access-policy model to Azure RBAC, since RBAC integrates with Conditional Access and produces a consistent audit trail across services.
2. Separate the Key Vault Crypto Officer role (key lifecycle: create, rotate, delete) from Key Vault Crypto User (encrypt/decrypt/sign only), granting each to different identities.
3. Grant secrets and certificates access through the equivalent Key Vault Secrets User and Key Vault Certificates Officer roles rather than a single broad Key Vault Administrator grant.
4. Scope role assignments at the vault level, or the individual key/secret/certificate level for finer control, rather than at the subscription level.
5. Review role assignments on the same cadence as other production access reviews, since a stale Crypto User grant is equivalent to standing decrypt access.

How Do You Authenticate an Application to Azure Key Vault?

Microsoft’s current recommendation is to authenticate applications with a managed identity rather than a service-principal client secret, since a managed identity removes the need to store any credential at all:

1. Enable a system-assigned or user-assigned managed identity on the application’s Azure resource (App Service, VM, Function, or similar).
2. Grant that managed identity the appropriate RBAC role (Crypto User, Secrets User, or Certificates Officer) on the target vault.
3. The application requests a token from Azure Active Directory using its managed identity, with no client secret involved.
4. The application presents that token to Key Vault, which validates it and returns the requested secret, key operation result, or certificate.
5. For applications that cannot use a managed identity (multi-cloud or on-premises callers), fall back to a service principal with a certificate credential rather than a client secret, and rotate that credential on a defined schedule.

How Should You Handle Key Rotation in Azure Key Vault?

Key Vault supports built-in automatic rotation policies, letting an organization define a rotation period and an optional notification window before expiry. As with every major cloud’s key management service, rotation only creates a new key version for future operations; it does not re-encrypt data already protected by a previous version and does not delete that previous version automatically. A complete rotation plan needs a separate re-encryption step and an explicit schedule for retiring old key versions once nothing depends on them. Certificates follow their own renewal schedule, separate from key rotation, and Key Vault can automatically request renewal from an integrated certificate authority before expiry.

What Should You Log for Azure Key Vault?

• Key Vault diagnostic logs, sent to Azure Monitor or Log Analytics, covering every secret, key, and certificate operation, caller identity, and the specific object version used.
• Role assignment changes on the vault, since a new RBAC grant is itself a security-relevant event.
• Certificate renewal and expiry events, so a failed automatic renewal is caught before the certificate actually expires.
• Firewall and network-rule changes on the vault, since Key Vault also supports restricting access to specific virtual networks or private endpoints.

What Does Azure Key Vault Cost?

Standard tier is billed per operation on secrets, keys, and certificates at a low per-10,000-operation rate. Premium tier adds a per-HSM-protected-key-operation charge on top of the same base rate, to cover the shared HSM pool. Managed HSM bills a flat hourly rate per HSM pool plus per-key-version and per-operation charges, materially higher than Standard or Premium, to cover dedicated single-tenant hardware. Azure Dedicated HSM bills hourly per physical appliance regardless of usage. Confirm current per-unit rates against Microsoft’s own pricing pages before budgeting a Managed HSM or Dedicated HSM migration, since the cost gap between tiers is substantial.

What Does Multi-Cloud Key Management Look Like Across Azure, AWS, and GCP?

Each major cloud implements the same conceptual tiers, a low-cost software-protected default, a shared HSM-backed tier, and a dedicated single-tenant HSM option, under different names and with different FIPS validation histories. A consistent multi-cloud architecture standardizes access-control and rotation policy across each cloud’s native key vault rather than trying to run one key management service across all three, since none of the three natively manages another’s keys.

See our comparison of AWS KMS, Azure Key Vault, and GCP KMS for the full breakdown of how these three differ on rotation, IAM, and cost specifically.

What Are the Limitations of Azure Key Vault?

• Standard tier’s software-protected keys carry only FIPS 140-2 Level 1 validation, which will not satisfy a mandate requiring hardware-backed key custody.
• Migrating vaults from the legacy access-policy model to RBAC needs careful planning, since the two models do not map one-to-one and a rushed migration can either over-grant or lock out legitimate access.
• Managed HSM and Dedicated HSM both carry substantially higher cost than Standard or Premium, which needs to be justified against an actual compliance requirement.
• Rotation does not re-encrypt existing data automatically; re-encryption and old-version cleanup are the customer’s responsibility.

Decision Checklist: Choosing the Right Azure Key Vault Tier

1. Default to Standard tier for secrets and software-protected keys; move to Premium only when a workload needs HSM-backed keys.
2. Reserve Managed HSM or Dedicated HSM for a named requirement for dedicated, single-tenant hardware.
3. Migrate any vault still on the legacy access-policy model to Azure RBAC, separating key administration from key use.
4. Authenticate applications with managed identities, falling back to certificate-based service principals only when necessary.
5. Enable automatic rotation and document the separate re-encryption process for existing data.

What Would Encryption Consulting Recommend?

Most Azure environments we assess still have applications authenticating with a long-lived service-principal secret instead of a managed identity, and vaults still running the legacy access-policy model years after RBAC became the recommended approach. Encryption Consulting’s Cloud Key Management services design the RBAC role structure and managed-identity migration for your Key Vault estate, our HSM-as-a-Service offering gives you hardware-backed key custody without operating HSMs directly, and our PKI-as-a-Service extends that to full certificate lifecycle management.

Frequently Asked Questions

What is the difference between Azure Key Vault Standard and Premium?

Standard tier protects keys in software, FIPS 140-2 Level 1 validated; Premium tier protects keys inside a shared Hardware Security Module pool, now FIPS 140-3 Level 3 validated on Microsoft’s current HSM platform.

Is Managed HSM the same as Key Vault Premium?

No. Premium is a shared, multi-tenant HSM pool inside a standard Key Vault; Managed HSM is a dedicated, single-tenant HSM pool with its own administrative model, and every key in it is HSM-protected with no software-key option.

Should I still use vault access policies instead of Azure RBAC?

No. Azure RBAC is Microsoft’s current recommended permission model for Key Vault; access policies are the legacy approach and existing vaults should be migrated.

Can Azure Key Vault work with an external key manager like Thales?

Key Vault supports importing externally generated key material through BYOK. For a scenario where the cloud provider should never hold usable key material at all, Azure Dedicated HSM, administered directly by the customer, is the closest option to a HYOK model.

Does key rotation in Key Vault re-encrypt existing data?

No. Rotation only creates a new active key version for future operations; data already encrypted under the previous version stays dependent on it until an explicit re-encryption process runs.

Need help structuring Azure Key Vault RBAC roles and migrating off legacy access policies? Talk to Encryption Consulting’s Cloud Key Management team.

References

Azure Key Vault overview – learn.microsoft.com

About keys in Azure Key Vault (FIPS validation levels) – learn.microsoft.com

About keys in Managed HSM – learn.microsoft.com