Edit

Secure your Azure Key Vault

Azure Key Vault protects cryptographic keys, certificates (and the private keys associated with the certificates), and secrets (such as connection strings and passwords) in the cloud. When storing sensitive and business-critical data, however, you must take steps to maximize the security of your vaults and the data stored in them.

The security recommendations in this article implement Zero Trust principles: "Verify explicitly", "Use least privilege access", and "Assume breach". For comprehensive Zero Trust guidance, see the Zero Trust Guidance Center.

This article provides security recommendations to help protect your Azure Key Vault deployment.

Service-specific security

Azure Key Vault has unique security considerations related to vault architecture and appropriate use of the service for storing cryptographic materials.

  • Use one Key Vault per application, region, and environment: Create separate Key Vaults for development, preproduction, and production environments to reduce the impact of breaches.

    Key vaults define security boundaries for stored secrets. Grouping secrets into the same vault increases the blast radius of a security event because attacks might be able to access secrets across concerns. To mitigate access across concerns, consider what secrets a specific application should have access to, and then separate your key vaults based on this delineation. Separating key vaults by application is the most common boundary. Security boundaries, however, can be more granular for large applications, for example, per group of related services.

  • Use one Key Vault per tenant in multitenant solutions: For multitenant SaaS solutions, use a separate Key Vault for each tenant to maintain data isolation. This approach provides secure isolation of customer data and workloads. For more information, see Multitenancy and Azure Key Vault.

  • Don't use Key Vault as a data store for customer or service configuration: Services should use Azure Storage with encryption at rest or Azure App Configuration. These options are more performant for configuration scenarios.

  • Don't store certificates (customer or service owned) as secrets: Store service-owned certificates as Key Vault certificates and configure them for autorotation. For more information, see Azure key vault: Certificates and Understanding autorotation in Azure Key Vault.

  • Don't store customer content in Key Vault: Key Vault isn't a data store and isn't built to scale like one. Instead, use Azure Cosmos DB or Azure Storage. Customers who want Bring Your Own Key (BYOK) for encryption at rest can store the wrapping key in Azure Key Vault and use it to encrypt data in Azure Storage.

Network security

Reducing network exposure is critical to protecting Azure Key Vault from unauthorized access. Configure network restrictions based on your organization's requirements and use case. For detailed information and step-by-step configuration instructions, see Configure network security for Azure Key Vault.

These network security features are listed from most restricted to least restricted capabilities. Pick the configuration that best suits your organization's use case.

  • Disable public network access and use Private Endpoints only: Deploy Azure Private Link to establish a private access point from a virtual network to Azure Key Vault and prevent exposure to the public internet. Disabling public access blocks data-plane connections; the vault's public DNS records remain resolvable by design (see Public DNS visibility of a private key vault). For implementation steps, see Integrate Key Vault with Azure Private Link.

  • Enable Key Vault Firewall: Limit access to public static IP addresses or your virtual networks. For full details, see Configure network security: Firewall settings.

    • Some customer scenarios require trusted Microsoft services to bypass the firewall, in such cases the vault might need to be configured to allow Trusted Microsoft Services. Only services in the Trusted services table are admitted by this option; Microsoft services that aren't on the list (for example, Azure DevOps) still need a firewall IP rule, a virtual network rule, or a private endpoint.

  • Use Network Security Perimeter: Define a logical network isolation boundary for PaaS resources (for example, Azure Key Vault, Azure Storage and SQL Database) that are deployed outside your organization's virtual network perimeter and/or public static IP addresses. For full details, see Configure network security: Network Security Perimeter.

    • publicNetworkAccess: SecuredByPerimeter overrides "Allow trusted Microsoft services to bypass the firewall", meaning that some scenarios that require that trust will not work.

  • Enforce TLS version control on clients: Azure Key Vault supports TLS 1.2 and 1.3. Because the Key Vault front end is a multitenant service where vaults from different customers can share the same public IP address, each HTTPS request is authenticated and authorized independently. Clients participate in TLS negotiation, so pin your clients to TLS 1.2 or 1.3 to ensure every connection uses the corresponding level of protection. For more information, see Key Vault logging for sample Kusto queries to monitor TLS versions used by clients.

Identity and access management

Azure Key Vault uses Microsoft Entra ID for authentication. Access is controlled through two interfaces: the control plane (for managing Key Vault itself) and the data plane (for working with keys, secrets, and certificates). For details on the access model and endpoints, see Azure RBAC for Key Vault data plane operations.

  • Enable managed identities: Use Azure managed identities for all app and service connections to Azure Key Vault to eliminate hard-coded credentials. Managed identities help secure authentication while removing the need for explicit credentials. For authentication methods and scenarios, see Azure Key Vault authentication.

  • Use role-based access control: Use Azure Role-Based Access Control (RBAC) to manage access to the Azure Key Vault. For more information, see Azure RBAC for Key Vault data plane operations.

    • Don't use legacy access policies: Legacy access policies have known security vulnerabilities and lack support for Privileged Identity Management (PIM). Don't use them for critical data and workloads. Azure RBAC mitigates potential unauthorized Key Vault access risks. For more information, see Azure role-based access control (Azure RBAC) vs. access policies (legacy).

    The RBAC permission model allows vault-level role assignments for persistent access and eligible (JIT) assignments for privileged operations. Object-scope assignments only support read operations; administrative operations like network access control, monitoring, and object management require vault-level permissions. For secure isolation across application teams, use one Key Vault per application.

  • Assign just-in-time (JIT) privileged roles: Use Azure Privileged Identity Management (PIM) to assign eligible JIT Azure RBAC roles for administrators and operators of Key Vault. For more information, see Privileged Identity Management (PIM) overview.

  • Enable Microsoft Entra Conditional Access Policies: Key Vault supports Microsoft Entra Conditional Access policies to apply access controls based on conditions such as user location or device. For more information, see Conditional Access overview.

  • Apply the principle of least privilege: Limit the number of users with administrative roles and ensure users are granted only the minimum permissions required for their role. For more information, see Enhance security with the principle of least privilege.

Data protection

Protecting data stored in Azure Key Vault requires enabling soft delete, purge protection, and implementing automated rotation of cryptographic materials.

Logging and monitoring

Comprehensive logging and monitoring enable detection of suspicious activities and compliance with audit requirements.

  • Enable audit logging: Key Vault logging saves information about operations performed on the vault. For more information, see Key Vault logging.

  • Enable Microsoft Defender for Key Vault: Enable Microsoft Defender for Key Vault to monitor for and alert on suspicious activity. For more information, see Microsoft Defender for Key Vault introduction.

  • Enable log alerts for security events: Set up alerts to be notified when critical events are logged, such as access failures or secret deletions. For more information, see Monitoring and alerting for Azure Key Vault.

  • Monitor and alert: Integrate Key Vault with Event Grid to receive notifications on changes to keys, certificates, or secrets. For more information, see Monitoring Key Vault with Azure Event Grid.

Compliance and governance

Regular compliance audits and governance policies ensure your Key Vault deployment adheres to security standards and organizational requirements.

Backup and recovery

Regular backups ensure business continuity and protect against data loss from accidental or malicious deletion.

  • Enable native backup for Azure Key Vault: Configure and use the Azure Key Vault native backup feature to back up secrets, keys, and certificates, ensuring recoverability. For more information, see Azure Key Vault backup.

  • Ensure backups for secrets that can't be recreated: Back up Key Vault objects (like encryption keys) that can't be recreated from other sources. For more information, see Azure Key Vault backup.

  • Test backup and recovery procedures: To verify the effectiveness of backup processes, regularly test the restoration of Key Vault secrets, keys, and certificates. For more information, see Azure Key Vault backup.

  • Understand backup copy independence: A key restored from a backup to another vault is fully independent of the original. Disabling, deleting, or purging the original key does not affect any restored copies. Disabling or deleting the key also takes all dependent data services offline (for example, SQL TDE databases become inaccessible and Storage accounts with customer-managed keys return errors). If a key is suspected compromised, rotate to a new key and migrate dependent services before disabling the old one. For full details, see Backup security considerations and Key compromise response.

For security best practices specific to keys, secrets, and certificates, see:

Next steps

  • Last updated on