Azure Policy built-in definitions for Key Vault
This page is an index of Azure Policy built-in policy definitions for Key Vault. For additional Azure Policy built-ins for other services, see Azure Policy built-in definitions.
The name of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the Version column to view the source on the Azure Policy GitHub repo.
Key Vault (service)
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| [Preview]: Azure Key Vault Managed HSM should disable public network access | Disable public network access for your Azure Key Vault Managed HSM so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link#allow-trusted-services-to-access-managed-hsm. | Audit, Deny, Disabled | 1.0.0-preview |
| [Preview]: Azure Key Vault Managed HSM should use private link | Private link provides a way to connect Azure Key Vault Managed HSM to your Azure resources without sending traffic over the public internet. Private link provides defense in depth protection against data exfiltration. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link | Audit, Disabled | 1.0.0-preview |
| [Preview]: Certificates should be issued by one of the specified non-integrated certificate authorities | Manage your organizational compliance requirements by specifying custom or internal certificate authorities that can issue certificates in your key vault. | Audit, Deny, Disabled | 1.0.0-preview |
| [Preview]: Configure Azure Key Vault Managed HSM to disable public network access | Disable public network access for your Azure Key Vault Managed HSM so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link#allow-trusted-services-to-access-managed-hsm. | Modify, Disabled | 2.0.0-preview |
| [Preview]: Configure Azure Key Vault Managed HSM with private endpoints | Private endpoints connect your virtual networks to Azure services without a public IP address at the source or destination. By mapping private endpoints to Azure Key Vault Managed HSM, you can reduce data leakage risks. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link. | DeployIfNotExists, Disabled | 1.0.0-preview |
| Azure Key Vault Managed HSM should have purge protection enabled | Malicious deletion of an Azure Key Vault Managed HSM can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge Azure Key Vault Managed HSM. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted Azure Key Vault Managed HSM. No one inside your organization or Microsoft will be able to purge your Azure Key Vault Managed HSM during the soft delete retention period. | Audit, Deny, Disabled | 1.0.0 |
| Azure Key Vault should disable public network access | Disable public network access for your key vault so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/akvprivatelink. | Audit, Deny, Disabled | 1.1.0 |
| Azure Key Vault should have firewall enabled | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. Optionally, you can configure specific IP ranges to limit access to those networks. Learn more at: https://docs.microsoft.com/azure/key-vault/general/network-security | Audit, Deny, Disabled | 3.2.1 |
| Azure Key Vault should use RBAC permission model | Enable RBAC permission model across Key Vaults. Learn more at: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration | Audit, Deny, Disabled | 1.0.1 |
| Azure Key Vaults should use private link | Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to key vault, you can reduce data leakage risks. Learn more about private links at: https://aka.ms/akvprivatelink. | [parameters('audit_effect')] | 1.2.1 |
| Certificates should be issued by the specified integrated certificate authority | Manage your organizational compliance requirements by specifying the Azure integrated certificate authorities that can issue certificates in your key vault such as Digicert or GlobalSign. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should be issued by the specified non-integrated certificate authority | Manage your organizational compliance requirements by specifying one custom or internal certificate authorities that can issue certificates in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.1 |
| Certificates should have the specified lifetime action triggers | Manage your organizational compliance requirements by specifying whether a certificate lifetime action is triggered at a specific percentage of its lifetime or at a certain number of days prior to its expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.2.1 |
| Certificates should not expire within the specified number of days | Manage certificates that will expire within a specified number of days to ensure your organization has sufficient time to rotate the certificate prior to expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.1 |
| Certificates should use allowed key types | Manage your organizational compliance requirements by restricting the key types allowed for certificates. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using elliptic curve cryptography should have allowed curve names | Manage the allowed elliptic curve names for ECC Certificates stored in key vault. More information can be found at https://aka.ms/akvpolicy. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using RSA cryptography should have the specified minimum key size | Manage your organizational compliance requirements by specifying a minimum key size for RSA certificates stored in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Configure Azure Key Vaults with private endpoints | Private endpoints connect your virtual networks to Azure services without a public IP address at the source or destination. By mapping private endpoints to key vault, you can reduce data leakage risks. Learn more about private links at: https://aka.ms/akvprivatelink. | DeployIfNotExists, Disabled | 1.0.1 |
| Configure key vaults to enable firewall | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: https://docs.microsoft.com/azure/key-vault/general/network-security | Modify, Disabled | 1.1.1 |
| Deploy - Configure diagnostic settings for Azure Key Vault to Log Analytics workspace | Deploys the diagnostic settings for Azure Key Vault to stream resource logs to a Log Analytics workspace when any Key Vault which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 2.0.1 |
| Deploy - Configure diagnostic settings to a Log Analytics workspace to be enabled on Azure Key Vault Managed HSM | Deploys the diagnostic settings for Azure Key Vault Managed HSM to stream to a regional Log Analytics workspace when any Azure Key Vault Managed HSM which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 1.0.0 |
| Deploy - Configure diagnostic settings to an Event Hub to be enabled on Azure Key Vault Managed HSM | Deploys the diagnostic settings for Azure Key Vault Managed HSM to stream to a regional Event Hub when any Azure Key Vault Managed HSM which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 1.0.0 |
| Deploy Diagnostic Settings for Key Vault to Event Hub | Deploys the diagnostic settings for Key Vault to stream to a regional Event Hub when any Key Vault which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 3.0.1 |
| Deploy Diagnostic Settings for Key Vault to Log Analytics workspace | Deploys the diagnostic settings for Key Vault to stream to a regional Log Analytics workspace when any Key Vault which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 3.0.0 |
| Enable logging by category group for Key vaults (microsoft.keyvault/vaults) to Event Hub | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to an Event Hub for Key vaults (microsoft.keyvault/vaults). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.2.0 |
| Enable logging by category group for Key vaults (microsoft.keyvault/vaults) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Key vaults (microsoft.keyvault/vaults). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.1.0 |
| Enable logging by category group for Key vaults (microsoft.keyvault/vaults) to Storage | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Storage Account for Key vaults (microsoft.keyvault/vaults). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.1.0 |
| Enable logging by category group for Managed HSMs (microsoft.keyvault/managedhsms) to Event Hub | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to an Event Hub for Managed HSMs (microsoft.keyvault/managedhsms). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.2.0 |
| Enable logging by category group for Managed HSMs (microsoft.keyvault/managedhsms) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Managed HSMs (microsoft.keyvault/managedhsms). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.1.0 |
| Enable logging by category group for Managed HSMs (microsoft.keyvault/managedhsms) to Storage | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Storage Account for Managed HSMs (microsoft.keyvault/managedhsms). | DeployIfNotExists, AuditIfNotExists, Disabled | 1.1.0 |
| Key Vault keys should have an expiration date | Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault secrets should have an expiration date | Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault should use a virtual network service endpoint | This policy audits any Key Vault not configured to use a virtual network service endpoint. | Audit, Disabled | 1.0.0 |
| Key vaults should have deletion protection enabled | Malicious deletion of a key vault can lead to permanent data loss. You can prevent permanent data loss by enabling purge protection and soft delete. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Microsoft will be able to purge your key vaults during the soft delete retention period. Keep in mind that key vaults created after September 1st 2019 have soft-delete enabled by default. | Audit, Deny, Disabled | 2.1.0 |
| Key vaults should have soft delete enabled | Deleting a key vault without soft delete enabled permanently deletes all secrets, keys, and certificates stored in the key vault. Accidental deletion of a key vault can lead to permanent data loss. Soft delete allows you to recover an accidentally deleted key vault for a configurable retention period. | Audit, Deny, Disabled | 3.0.0 |
| Keys should be backed by a hardware security module (HSM) | An HSM is a hardware security module that stores keys. An HSM provides a physical layer of protection for cryptographic keys. The cryptographic key cannot leave a physical HSM which provides a greater level of security than a software key. | Audit, Deny, Disabled | 1.0.1 |
| Keys should be the specified cryptographic type RSA or EC | Some applications require the use of keys backed by a specific cryptographic type. Enforce a particular cryptographic key type, RSA or EC, in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have a rotation policy ensuring that their rotation is scheduled within the specified number of days after creation. | Manage your organizational compliance requirements by specifying the maximum number of days after key creation until it must be rotated. | Audit, Disabled | 1.0.0 |
| Keys should have more than the specified number of days before expiration | If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a key can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Keys should not be active for longer than the specified number of days | Specify the number of days that a key should be active. Keys that are used for an extended period of time increase the probability that an attacker could compromise the key. As a good security practice, make sure that your keys have not been active longer than two years. | Audit, Deny, Disabled | 1.0.1 |
| Keys using elliptic curve cryptography should have the specified curve names | Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys using RSA cryptography should have a specified minimum key size | Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. | Audit, Deny, Disabled | 1.0.1 |
| Resource logs in Azure Key Vault Managed HSM should be enabled | To recreate activity trails for investigation purposes when a security incident occurs or when your network is compromised, you may want to audit by enabling resource logs on Managed HSMs. Please follow the instructions here: https://docs.microsoft.com/azure/key-vault/managed-hsm/logging. | AuditIfNotExists, Disabled | 1.1.0 |
| Resource logs in Key Vault should be enabled | Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes when a security incident occurs or when your network is compromised | AuditIfNotExists, Disabled | 5.0.0 |
| Secrets should have content type set | A content type tag helps identify whether a secret is a password, connection string, etc. Different secrets have different rotation requirements. Content type tag should be set on secrets. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have more than the specified number of days before expiration | If a secret is too close to expiration, an organizational delay to rotate the secret may result in an outage. Secrets should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should not be active for longer than the specified number of days | If your secrets were created with an activation date set in the future, you must ensure that your secrets have not been active for longer than the specified duration. | Audit, Deny, Disabled | 1.0.1 |
Key Vault (objects)
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| [Preview]: Certificates should be issued by one of the specified non-integrated certificate authorities | Manage your organizational compliance requirements by specifying custom or internal certificate authorities that can issue certificates in your key vault. | Audit, Deny, Disabled | 1.0.0-preview |
| Certificates should be issued by the specified integrated certificate authority | Manage your organizational compliance requirements by specifying the Azure integrated certificate authorities that can issue certificates in your key vault such as Digicert or GlobalSign. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should be issued by the specified non-integrated certificate authority | Manage your organizational compliance requirements by specifying one custom or internal certificate authorities that can issue certificates in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.1 |
| Certificates should have the specified lifetime action triggers | Manage your organizational compliance requirements by specifying whether a certificate lifetime action is triggered at a specific percentage of its lifetime or at a certain number of days prior to its expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.2.1 |
| Certificates should not expire within the specified number of days | Manage certificates that will expire within a specified number of days to ensure your organization has sufficient time to rotate the certificate prior to expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.1 |
| Certificates should use allowed key types | Manage your organizational compliance requirements by restricting the key types allowed for certificates. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using elliptic curve cryptography should have allowed curve names | Manage the allowed elliptic curve names for ECC Certificates stored in key vault. More information can be found at https://aka.ms/akvpolicy. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using RSA cryptography should have the specified minimum key size | Manage your organizational compliance requirements by specifying a minimum key size for RSA certificates stored in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Key Vault keys should have an expiration date | Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault secrets should have an expiration date | Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets. | Audit, Deny, Disabled | 1.0.2 |
| Keys should be backed by a hardware security module (HSM) | An HSM is a hardware security module that stores keys. An HSM provides a physical layer of protection for cryptographic keys. The cryptographic key cannot leave a physical HSM which provides a greater level of security than a software key. | Audit, Deny, Disabled | 1.0.1 |
| Keys should be the specified cryptographic type RSA or EC | Some applications require the use of keys backed by a specific cryptographic type. Enforce a particular cryptographic key type, RSA or EC, in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have a rotation policy ensuring that their rotation is scheduled within the specified number of days after creation. | Manage your organizational compliance requirements by specifying the maximum number of days after key creation until it must be rotated. | Audit, Disabled | 1.0.0 |
| Keys should have more than the specified number of days before expiration | If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a key can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Keys should not be active for longer than the specified number of days | Specify the number of days that a key should be active. Keys that are used for an extended period of time increase the probability that an attacker could compromise the key. As a good security practice, make sure that your keys have not been active longer than two years. | Audit, Deny, Disabled | 1.0.1 |
| Keys using elliptic curve cryptography should have the specified curve names | Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys using RSA cryptography should have a specified minimum key size | Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have content type set | A content type tag helps identify whether a secret is a password, connection string, etc. Different secrets have different rotation requirements. Content type tag should be set on secrets. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have more than the specified number of days before expiration | If a secret is too close to expiration, an organizational delay to rotate the secret may result in an outage. Secrets should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should not be active for longer than the specified number of days | If your secrets were created with an activation date set in the future, you must ensure that your secrets have not been active for longer than the specified duration. | Audit, Deny, Disabled | 1.0.1 |
Next steps
- See the built-ins on the Azure Policy GitHub repo.
- Review the Azure Policy definition structure.
- Review Understanding policy effects.