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)
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, deny, disabled 2.0.0-preview
Certificates should be issued by the specified non-integrated certificate authority Manage your organizational compliance requirements by specifying the custom or internal certificate authorities that can issue certificates in your key vault. audit, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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, deny, disabled 2.1.0-preview
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, deny, disabled 2.0.0-preview
Certificates should use allowed key types Manage your organizational compliance requirements by restricting the key types allowed for certificates. audit, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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 2.0.0
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 1.0.0
Diagnostic logs in Key Vault should be enabled Audit enabling of diagnostic 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 3.0.0
Firewall should be enabled on Key Vault Key vault's firewall prevents unauthorized traffic from reaching your key vault and provides an additional layer of protection for your secrets. Enable the firewall to make sure that only traffic from allowed networks can access your key vault. Audit, Disabled 1.0.2-preview
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.1-preview
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.1-preview
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 purge protection enabled Malicious deletion of a key vault can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge key vaults. 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. Audit, Deny, Disabled 1.1.1
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 accidently deleted key vault for a configurable retention period. Audit, Deny, Disabled 1.0.1
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
Private endpoint should be configured for Key Vault Private link provides a way to connect Key Vault to your Azure resources without sending traffic over the public internet. Private link provides defense in depth protection against data exfiltration. Audit, Disabled 1.0.2-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview

Key Vault (objects)

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
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, deny, disabled 2.0.0-preview
Certificates should be issued by the specified non-integrated certificate authority Manage your organizational compliance requirements by specifying the custom or internal certificate authorities that can issue certificates in your key vault. audit, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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, deny, disabled 2.1.0-preview
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, deny, disabled 2.0.0-preview
Certificates should use allowed key types Manage your organizational compliance requirements by restricting the key types allowed for certificates. audit, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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, deny, disabled 2.0.0-preview
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.1-preview
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.1-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview
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.0-preview

Next steps