Azure Key Vault Complete Guide: Secret/Key/Certificate Management, Managed Identity Integration, Security Best Practices

Azure Key Vault is a Microsoft-managed secrets management service that centrally stores Secrets (passwords, connection strings, API keys), Keys (cryptographic keys), and Certificates (TLS certificates). It is the foundational service for building secretless apps on Azure: applications eliminate hardcoded credentials and fetch them dynamically via Managed Identity. This article comprehensively covers tier selection, when to use Secrets vs Keys vs Certificates, RBAC, Managed Identity integration, and security best practices.

Tier Selection: Standard vs Premium vs Managed HSM

Secret / Key / Certificate

Secret

• Stores arbitrary strings (passwords, connection strings, API keys, tokens, JSON)
• Up to 25 KB
• The most general-purpose; about 80% of new Key Vault use cases are Secrets
• Versioning (previous versions are kept automatically on update)
• Activation Date / Expiration Date can be set

Key

• Stores cryptographic keys (RSA 2048/3072/4096, EC P-256/P-384/P-521, oct AES)
• Runs Sign / Verify / Encrypt / Decrypt / Wrap / Unwrap operations inside Key Vault (keys cannot be exported)
• Customer-Managed Key for TDE (Transparent Data Encryption)
• Customer-Managed Key for SSE (Storage Service Encryption)
• Customer-Managed Key for Azure Disk Encryption

Certificate

• Stores X.509 certificates
• The public portion can be retrieved as a Secret; the private key is stored as a Key
• Auto Renewal supported (via Let's Encrypt and other CA integrations)
• Ideal for managing SSL certificates on App Service / Application Gateway

RBAC-Based Access Control

Microsoft's current recommendation is RBAC (Azure Role-Based Access Control)-based authorization. Key Vault Access Policies are the legacy approach.

Key RBAC Roles

• Key Vault Administrator: full Key Vault permissions (RBAC, Secret, Key, and Certificate operations)
• Key Vault Reader: metadata read only (cannot read Secret values)
• Key Vault Secrets Officer: all Secret operations (create, read, update, delete)
• Key Vault Secrets User: Secret read only (for applications)
• Key Vault Crypto Officer: all Key operations
• Key Vault Crypto User: Key cryptographic operations only (Sign / Encrypt, etc.)
• Key Vault Certificates Officer: all Certificate operations

Choose 'Use RBAC' for new Key Vaults and migrate existing Access Policies-based vaults to RBAC.

Managed Identity Integration Pattern

The standard pattern for modern secretless apps:

1. Enable a System-assigned or User-assigned Managed Identity on the Azure resource (VM, App Service, Functions, etc.)
2. Grant the Managed Identity the Key Vault Secrets User role via Key Vault RBAC
3. Use the Azure Identity SDK (DefaultAzureCredential) in the application
4. Fetch secrets dynamically with the Key Vault Secret Client (e.g. client.getSecret('db-connection-string'))

This completely removes the need to put connection strings or API keys in App Settings / environment variables, eliminating the risk of leaking secrets through Git commits. It is Microsoft's recommended modern implementation pattern and should be adopted for every new Azure application.

Soft Delete and Purge Protection

Enabling Purge Protection blocks attackers with compromised credentials from completely wiping a Key Vault. It becomes your last line of defense for data recovery against threats like ransomware. It is a required setting for production.

Network Isolation

The standard for production Key Vaults is to disable the public endpoint and allow access only via a Private Endpoint.

Setup Steps

1. Under Network → Firewalls and virtual networks, choose 'Disable public access'
2. Create a Private Endpoint in your VNet
3. Integrate with the privatelink.vaultcore.azure.net Private DNS Zone (auto-configuration)
4. From on-prem, resolve via VPN / ExpressRoute + Azure DNS Private Resolver

The Selected Networks approach (allow only specific IPs / VNets) is useful combined with Service Endpoints for limited scenarios. See Private Endpoint vs Service Endpoint for details.

Security Best Practices

1. Enable Purge Protection (required in production)
2. Public Access Disable + Private Endpoint
3. RBAC-based access control (migrate from Access Policies)
4. Managed Identity authentication (secretless apps)
5. Microsoft Defender for Key Vault enabled (anomalous access detection)
6. Send Diagnostic Logs to Microsoft Sentinel
7. Set Expiration Date on Secrets / Keys / Certificates (regular rotation)
8. Regular backups (mandatory for BYOK Keys)
9. Encrypt the Key Vault itself with a Customer-Managed Key (CMK) (Premium only)
10. Standardize Key Vault naming (include environment, region, and use case)

Automatic Certificate Renewal

The biggest benefit of Key Vault Certificates is automatic renewal.

• Integrate Key Vault with public CAs (DigiCert, GlobalSign, etc.) to automate certificate purchase and renewal end-to-end
• Auto-renew free certificates via Let's Encrypt integrations (e.g. open-source Acmebot Function Apps)
• App Service / Application Gateway can reference certificates directly via Key Vault Reference, with automatic propagation on renewal
• Expiration alerts (Event Grid notifications when renewal fails)

Pricing

For typical use, Key Vault Standard runs for a few hundred to a few thousand yen per month, so cost is rarely a barrier. Pick Premium only when HSM-protected Keys are required, and consider Managed HSM only when financial or healthcare requirements demand a fully isolated HSM.

Related Certifications

• AZ-204 (Developer Associate): domain 3 (Security, 20-25%) tests retrieving secrets via the Key Vault SDK in depth.
• AZ-104 (Administrator): Key Vault configuration and RBAC.
• AZ-305 (Solutions Architect Expert): secret management strategy in architecture.
• SC-300 (Identity Admin): combining RBAC and Managed Identity.
• SC-100 (Cybersecurity Architect Expert): data protection and encryption strategy.
• DP-300 (DBA): TDE Customer-Managed Keys for SQL DB.
• SC-400 (Information Protection): compliance.

Frequently Asked Questions

Technical information in this article is based on the Azure Key Vault Documentation. This article is not an official Microsoft Corporation product and has no affiliation or sponsorship relationship. Microsoft, Azure, and Microsoft Entra are trademarks of the Microsoft group of companies. Information is current as of the official public materials available on May 24, 2026. Always check the official pages for the latest details.