Microsoft cloud security benchmark v2 control to Azure Built-in Policy mapping

This article lists Azure Policy built-in policy initiative definitions related to Microsoft cloud security benchmark v2. Each control from the benchmark is mapped to one or more Azure Policy definitions. Refer to the full Azure Policy Initiative definition file for any additional details.

Compliant in Azure Policy refers only to the policy definitions themselves; this doesn't ensure you're fully compliant with all requirements of a control. The compliance standard includes controls that aren't addressed by any Azure Policy definitions at this time. Therefore, compliance in Azure Policy is only a partial view of your overall compliance status.

The associations between controls and Azure Policy definitions for this compliance standard may change over time.

AI-1: Ensure use of approved models

For more information, see Artificial Intelligence Security: AI-1: Ensure use of approved models.

Name	Description	Effect(s)	Version
[Preview]: Azure Machine Learning Deployments should only use approved Registry Models	Restrict the deployment of Registry models to control externally created models used within your organization	Audit; Deny; Disabled	1.0.0-preview
[Preview]: Cognitive Services Deployments should only use allowed completion content filtering	Mandate minimum levels of content filtering for completion content for model deployments within your organization.	Audit; Disabled	1.0.0-preview
[Preview]: Cognitive Services Deployments should only use allowed control	Mandate minimum levels of multi-severity content filtering for harmful content for model deployments within your organization.	Audit; Disabled	1.0.0-preview
[Preview]: Cognitive Services Deployments Should Only Use Allowed Control Mode	Mandate content filtering mode for model deployments within your organization.	Audit; Disabled	1.0.0-preview
[Preview]: Cognitive Services Deployments should only use allowed prompt content filtering	Mandate minimum levels of content filtering for prompt content for model deployments within your organization.	Audit; Disabled	1.0.0-preview

AM-2: Use only approved services

For more information, see Asset Management: AM-2: Use only approved services.

Name	Description	Effect(s)	Version
Azure API Management platform version should be stv2	Azure API Management stv1 compute platform version will be retired effective 31 August 2024, and these instances should be migrated to stv2 compute platform for continued support. Learn more at API Management stv1 platform retirement - Global Azure cloud (August 2024)	Audit; Deny; Disabled	1.0.0
Storage accounts should be migrated to new Azure Resource Manager resources	Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management	Audit; Deny; Disabled	1.0.0
Storage accounts should be migrated to new Azure Resource Manager resources	Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management	Audit; Deny; Disabled	1.0.0
Virtual machines should be migrated to new Azure Resource Manager resources	Use new Azure Resource Manager for your virtual machines to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management	Audit; Deny; Disabled	1.0.0

AM-3: Ensure security of asset lifecycle management

For more information, see Asset Management: AM-3: Ensure security of asset lifecycle management.

Name	Description	Effect(s)	Version
API endpoints that are unused should be disabled and removed from the Azure API Management service	As a security best practice, API endpoints that haven't received traffic for 30 days are considered unused and should be removed from the Azure API Management service. Keeping unused API endpoints may pose a security risk to your organization. These may be APIs that should have been deprecated from the Azure API Management service but may have been accidentally left active. Such APIs typically do not receive the most up to date security coverage.	AuditIfNotExists; Disabled	1.0.1

BR-1: Ensure regular automated backups

For more information, see Backup and Recovery: BR-1: Ensure regular automated backups.

Name	Description	Effect(s)	Version
Azure Backup should be enabled for Virtual Machines	Ensure protection of your Azure Virtual Machines by enabling Azure Backup. Azure Backup is a secure and cost effective data protection solution for Azure.	AuditIfNotExists; Disabled	3.0.0
Configure backup on virtual machines without a given tag to a new recovery services vault with a default policy	Enforce backup for all virtual machines by deploying a recovery services vault in the same location and resource group as the virtual machine. Doing this is useful when different application teams in your organization are allocated separate resource groups and need to manage their own backups and restores. You can optionally exclude virtual machines containing a specified tag to control the scope of assignment. See https://aka.ms/AzureVMAppCentricBackupExcludeTag.	AuditIfNotExists; DeployIfNotExists; Disabled	9.5.0
Configure backup on virtual machines without a given tag to an existing recovery services vault in the same location	Enforce backup for all virtual machines by backing them up to an existing central recovery services vault in the same location and subscription as the virtual machine. Doing this is useful when there is a central team in your organization managing backups for all resources in a subscription. You can optionally exclude virtual machines containing a specified tag to control the scope of assignment. See https://aka.ms/AzureVMCentralBackupExcludeTag.	AuditIfNotExists; DeployIfNotExists; Disabled	9.5.0
Geo-redundant backup should be enabled for Azure Database for MariaDB	Azure Database for MariaDB allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
Geo-redundant backup should be enabled for Azure Database for MySQL	Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
Geo-redundant backup should be enabled for Azure Database for PostgreSQL	Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
Geo-redundant storage should be enabled for Storage Accounts	Use geo-redundancy to create highly available applications	Audit; Disabled	1.0.0
Long-term geo-redundant backup should be enabled for Azure SQL Databases	This policy audits any Azure SQL Database with long-term geo-redundant backup not enabled.	AuditIfNotExists; Disabled	2.0.0
[Preview]: Multi-User Authorization (MUA) must be enabled for Backup Vaults.	This policy audits if Multi-User Authorization (MUA) is enabled for Backup Vaults. MUA helps in securing your Backup Vaults by adding an additional layer of protection to critical operations. To learn more, visit https://aka.ms/mua-for-bv.	Audit; Disabled	1.0.0-preview

BR-2: Protect backup and recovery data

For more information, see Backup and Recovery: BR-2: Protect backup and recovery data.

Name	Description	Effect(s)	Version
Azure Backup should be enabled for Virtual Machines	Ensure protection of your Azure Virtual Machines by enabling Azure Backup. Azure Backup is a secure and cost effective data protection solution for Azure.	AuditIfNotExists; Disabled	3.0.0
Geo-redundant backup should be enabled for Azure Database for MariaDB	Azure Database for MariaDB allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
Geo-redundant backup should be enabled for Azure Database for MySQL	Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
Geo-redundant backup should be enabled for Azure Database for PostgreSQL	Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create.	Audit; Disabled	1.0.1
[Preview]: Immutability must be enabled for backup vaults	This policy audits if the immutable vaults property is enabled for Backup vaults in the scope. This helps protect your backup data from being deleted before its intended expiry. Learn more at Concept of Immutable vault for Azure Backup.	Audit; Disabled	1.0.1-preview
[Preview]: Immutability must be enabled for Recovery Services vaults	This policy audits if the immutable vaults property is enabled for Recovery Services vaults in the scope. This helps protect your backup data from being deleted before its intended expiry. Learn more at Concept of Immutable vault for Azure Backup.	Audit; Disabled	1.0.1-preview
[Preview]: Soft delete must be enabled for Recovery Services Vaults.	This policy audits if soft delete is enabled for Recovery Services Vaults in the scope. Soft delete can help you recover your data even after it has been deleted. Learn more at https://aka.ms/AB-SoftDelete.	Audit; Disabled	1.0.0-preview
[Preview]: Soft delete should be enabled for Backup Vaults	This policy audits if soft delete is enabled for Backup vaults in the scope. Soft delete can help you recover your data after it has been deleted. Learn more at Overview of enhanced soft delete for Azure Backup	Audit; Disabled	1.0.0-preview

DP-1: Discover, classify, and label sensitive data

For more information, see Data Protection: DP-1: Discover, classify, and label sensitive data.

Name	Description	Effect(s)	Version
Microsoft Defender for APIs should be enabled	Microsoft Defender for APIs brings new discovery, protection, detection, & response coverage to monitor for common API based attacks & security misconfigurations.	AuditIfNotExists; Disabled	1.0.3

DP-2: Monitor anomalies and threats targeting sensitive data

For more information, see Data Protection: DP-2: Monitor anomalies and threats targeting sensitive data.

Name	Description	Effect(s)	Version
Azure Defender for Azure SQL Database servers should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL servers on machines should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for open-source relational databases should be enabled	Azure Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more about the capabilities of Azure Defender for open-source relational databases at Overview of Defender for Open-Source Relational Databases. Important: Enabling this plan will result in charges for protecting your open-source relational databases. Learn about the pricing on Security Center's pricing page: Pricing - Microsoft Defender for Cloud	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for APIs should be enabled	Microsoft Defender for APIs brings new discovery, protection, detection, & response coverage to monitor for common API based attacks & security misconfigurations.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender for Storage should be enabled	Microsoft Defender for Storage detects potential threats to your storage accounts. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption. The new Defender for Storage plan includes Malware Scanning and Sensitive Data Threat Detection. This plan also provides a predictable pricing structure (per storage account) for control over coverage and costs.	AuditIfNotExists; Disabled	1.0.0

DP-3: Encrypt sensitive data in transit

For more information, see Data Protection: DP-3: Encrypt sensitive data in transit.

Name	Description	Effect(s)	Version
A custom IPsec/IKE policy must be applied to all Azure virtual network gateway connections	This policy ensures that all Azure virtual network gateway connections use a custom Internet Protocol Security(Ipsec)/Internet Key Exchange(IKE) policy. Supported algorithms and key strengths - https://aka.ms/AA62kb0	Audit; Disabled	1.0.0
API Management APIs should use only encrypted protocols	To ensure security of data in transit, APIs should be available only through encrypted protocols, like HTTPS or WSS. Avoid using unsecured protocols, such as HTTP or WS.	Audit; Disabled; Deny	2.0.2
App Service app slots should enable end to end encryption	Enabling end to end encryption ensures front-end intra-cluster traffic between App Service front-ends and the workers running application workloads is encrypted.	Audit; Deny; Disabled	1.0.0
App Service app slots should only be accessible over HTTPS	Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.	Audit; Disabled; Deny	2.0.0
App Service app slots should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	1.2.0
App Service apps should enable end to end encryption	Enabling end to end encryption ensures front-end intra-cluster traffic between App Service front-ends and the workers running application workloads is encrypted.	Audit; Deny; Disabled	1.0.0
App Service apps should only be accessible over HTTPS	Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.	Audit; Disabled; Deny	4.0.0
App Service apps should require FTPS only	Enable FTPS enforcement for enhanced security.	AuditIfNotExists; Disabled	3.0.0
App Service apps should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	2.2.0
App Service Environment should be configured with strongest TLS Cipher suites	The two most minimal and strongest cipher suites required for App Service Environment to function correctly are : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.	Audit; Disabled	1.0.0
App Service Environment should have internal encryption enabled	Setting InternalEncryption to true encrypts the pagefile, worker disks, and internal network traffic between the front ends and workers in an App Service Environment. To learn more, refer to Custom configuration settings for App Service Environments.	Audit; Disabled	1.0.1
App Service Environment should have TLS 1.0 and 1.1 disabled	TLS 1.0 and 1.1 are out-of-date protocols that do not support modern cryptographic algorithms. Disabling inbound TLS 1.0 and 1.1 traffic helps secure apps in an App Service Environment.	Audit; Deny; Disabled	2.0.1
Azure Batch pools should have disk encryption enabled	Enabling Azure Batch disk encryption ensures that data is always encrypted at rest on your Azure Batch compute node. Learn more about disk encryption in Batch at Create a pool with disk encryption enabled.	Audit; Disabled; Deny	1.0.0
Azure Front Door Standard and Premium should be running minimum TLS version of 1.2	Setting minimal TLS version to 1.2 improves security by ensuring your custom domains are accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they are weak and do not support modern cryptographic algorithms.	Audit; Deny; Disabled	1.0.0
Azure HDInsight clusters should use encryption in transit to encrypt communication between Azure HDInsight cluster nodes	Data can be tampered with during transmission between Azure HDInsight cluster nodes. Enabling encryption in transit addresses problems of misuse and tampering during this transmission.	Audit; Deny; Disabled	1.0.0
Azure SQL Database should be running TLS version 1.2 or newer	Setting TLS version to 1.2 or newer improves security by ensuring your Azure SQL Database can only be accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities.	Audit; Disabled; Deny	2.0.0
Azure Synapse Workspace SQL Server should be running TLS version 1.2 or newer	Setting TLS version to 1.2 or newer improves security by ensuring your Azure Synapse workspace SQL server can only be accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities.	Audit; Deny; Disabled	1.1.0
Bot Service endpoint should be a valid HTTPS URI	Data can be tampered with during transmission. Protocols exist that provide encryption to address problems of misuse and tampering. To ensure your bots are communicating only over encrypted channels, set the endpoint to a valid HTTPS URI. This ensures the HTTPS protocol is used to encrypt your data in transit and is also often a requirement for compliance with regulatory or industry standards. Please visit: Bot Framework security guidelines.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Container Apps should only be accessible over HTTPS	Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. Disabling 'allowInsecure' will result in the automatic redirection of requests from HTTP to HTTPS connections for container apps.	Audit; Deny; Disabled	1.0.1
Enforce SSL connection should be enabled for MySQL database servers	Azure Database for MySQL supports connecting your Azure Database for MySQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server.	Audit; Disabled	1.0.1
Enforce SSL connection should be enabled for PostgreSQL database servers	Azure Database for PostgreSQL supports connecting your Azure Database for PostgreSQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server.	Audit; Disabled	1.0.1
Function app slots should enable end to end encryption	Enabling end to end encryption ensures front-end intra-cluster traffic between App Service front-ends and the workers running application workloads is encrypted.	Audit; Deny; Disabled	1.1.0
Function app slots should only be accessible over HTTPS	Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.	Audit; Disabled; Deny	2.1.0
Function app slots should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	1.3.0
Function apps should enable end to end encryption	Enabling end to end encryption ensures front-end intra-cluster traffic between App Service front-ends and the workers running application workloads is encrypted.	Audit; Deny; Disabled	1.1.0
Function apps should only be accessible over HTTPS	Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.	Audit; Disabled; Deny	5.1.0
Function apps should require FTPS only	Enable FTPS enforcement for enhanced security.	AuditIfNotExists; Disabled	3.1.0
Function apps should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	2.3.0
[Preview]: Host and VM networking should be protected on Azure Stack HCI systems	Protect data on the Azure Stack HCI hosts network and on virtual machine network connections.	Audit; Disabled; AuditIfNotExists	1.0.0-preview
Kubernetes clusters should be accessible only over HTTPS	Use of HTTPS ensures authentication and protects data in transit from network layer eavesdropping attacks. This capability is currently generally available for Kubernetes Service (AKS), and in preview for Azure Arc enabled Kubernetes. For more info, visit Understand Azure Policy for Kubernetes clusters	audit; Audit; deny; Deny; disabled; Disabled	8.2.0
Only secure connections to your Azure Cache for Redis should be enabled	Audit enabling of only connections via SSL to Azure Cache for Redis. Use of secure connections ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking	Audit; Deny; Disabled	1.0.0
PostgreSQL flexible servers should be running TLS version 1.2 or newer	This policy helps audit any PostgreSQL flexible servers in your environment which is running with TLS version less than 1.2.	AuditIfNotExists; Disabled	1.1.0
Secure transfer to storage accounts should be enabled	Audit requirement of Secure transfer in your storage account. Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking	Audit; Deny; Disabled	2.0.0
SQL Managed Instance should have the minimal TLS version of 1.2	Setting minimal TLS version to 1.2 improves security by ensuring your SQL Managed Instance can only be accessed from clients using TLS 1.2. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities.	Audit; Disabled	1.0.1
Storage accounts should have the specified minimum TLS version	Configure a minimum TLS version for secure communication between the client application and the storage account. To minimize security risk, the recommended minimum TLS version is the latest released version, which is currently TLS 1.2.	Audit; Deny; Disabled	1.0.0
Windows machines should be configured to use secure communication protocols	To protect the privacy of information communicated over the Internet, your machines should use the latest version of the industry-standard cryptographic protocol, Transport Layer Security (TLS). TLS secures communications over a network by encrypting a connection between machines.	AuditIfNotExists; Disabled	4.1.1

DP-4: Enable data at rest encryption by default

For more information, see Data Protection: DP-4: Enable data at rest encryption by default.

Name	Description	Effect(s)	Version
A Microsoft Entra administrator should be provisioned for MySQL servers	Audit provisioning of a Microsoft Entra administrator for your MySQL server to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services	AuditIfNotExists; Disabled	1.1.1
Automation account variables should be encrypted	It is important to enable encryption of Automation account variable assets when storing sensitive data	Audit; Deny; Disabled	1.1.0
Azure Data Box jobs should enable double encryption for data at rest on the device	Enable a second layer of software-based encryption for data at rest on the device. The device is already protected via Advanced Encryption Standard 256-bit encryption for data at rest. This option adds a second layer of data encryption.	Audit; Deny; Disabled	1.0.0
Azure Edge Hardware Center devices should have double encryption support enabled	Ensure that devices ordered from Azure Edge Hardware Center have double encryption support enabled, to secure the data at rest on the device. This option adds a second layer of data encryption.	Audit; Deny; Disabled	2.0.0
Azure HDInsight clusters should use encryption at host to encrypt data at rest	Enabling encryption at host helps protect and safeguard your data to meet your organizational security and compliance commitments. When you enable encryption at host, data stored on the VM host is encrypted at rest and flows encrypted to the Storage service.	Audit; Deny; Disabled	1.0.0
Azure Monitor Logs clusters should be created with infrastructure-encryption enabled (double encryption)	To ensure secure data encryption is enabled at the service level and the infrastructure level with two different encryption algorithms and two different keys, use an Azure Monitor dedicated cluster. This option is enabled by default when supported at the region, see Azure Monitor customer-managed keys.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Azure MySQL flexible server should have Microsoft Entra Only Authentication enabled	Disabling local authentication methods and allowing only Microsoft Entra Authentication improves security by ensuring that Azure MySQL flexible server can exclusively be accessed by Microsoft Entra identities.	AuditIfNotExists; Disabled	1.0.1
Azure NetApp Files SMB Volumes should use SMB3 encryption	Disallow the creation of SMB Volumes without SMB3 encryption to ensure data integrity and data privacy.	Audit; Deny; Disabled	1.0.0
Azure NetApp Files Volumes of type NFSv4.1 should use Kerberos data encryption	Only allow the use of Kerberos privacy (5p) security mode to ensure data is encrypted.	Audit; Deny; Disabled	1.0.0
Azure Stack Edge devices should use double-encryption	To secure the data at rest on the device, ensure it's double-encrypted, the access to data is controlled, and once the device is deactivated, the data is securely erased off the data disks. Double encryption is the use of two layers of encryption: BitLocker XTS-AES 256-bit encryption on the data volumes and built-in encryption of the hard drives. Learn more in the security overview documentation for the specific Stack Edge device.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Azure Synapse Analytics dedicated SQL pools should enable encryption	Enable transparent data encryption for Azure Synapse Analytics dedicated SQL pools to protect data-at-rest and meet compliance requirements. Please note that enabling transparent data encryption for the pool may impact query performance. More details can refer to https://go.microsoft.com/fwlink/?linkid=2147714	AuditIfNotExists; Disabled	1.0.0
Cognitive Services accounts should use customer owned storage	Use customer owned storage to control the data stored at rest in Cognitive Services. To learn more about customer owned storage, visit https://aka.ms/cogsvc-cmk.	Audit; Deny; Disabled	2.0.0
Disk encryption should be enabled on Azure Data Explorer	Enabling disk encryption helps protect and safeguard your data to meet your organizational security and compliance commitments.	Audit; Deny; Disabled	2.0.0
Double encryption should be enabled on Azure Data Explorer	Enabling double encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. When double encryption has been enabled, data in the storage account is encrypted twice, once at the service level and once at the infrastructure level, using two different encryption algorithms and two different keys.	Audit; Deny; Disabled	2.0.0
Event Hub namespaces should have double encryption enabled	Enabling double encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. When double encryption has been enabled, data in the storage account is encrypted twice, once at the service level and once at the infrastructure level, using two different encryption algorithms and two different keys.	Audit; Deny; Disabled	1.0.0
Infrastructure encryption should be enabled for Azure Database for MySQL servers	Enable infrastructure encryption for Azure Database for MySQL servers to have higher level of assurance that the data is secure. When infrastructure encryption is enabled, the data at rest is encrypted twice using FIPS 140-2 compliant Microsoft managed keys.	Audit; Deny; Disabled	1.0.0
Infrastructure encryption should be enabled for Azure Database for PostgreSQL servers	Enable infrastructure encryption for Azure Database for PostgreSQL servers to have higher level of assurance that the data is secure. When infrastructure encryption is enabled, the data at rest is encrypted twice using FIPS 140-2 compliant Microsoft managed keys	Audit; Deny; Disabled	1.0.0
Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost.	Although a virtual machine's OS and data disks are encrypted-at-rest by default using platform managed keys; resource disks (temp disks), data caches, and data flowing between Compute and Storage resources are not encrypted. Use Azure Disk Encryption or EncryptionAtHost to remediate. Visit Overview of managed disk encryption options to compare encryption offerings. This policy requires two prerequisites to be deployed to the policy assignment scope. For details, visit Understand Azure Machine Configuration.	AuditIfNotExists; Disabled	1.2.1
Managed disks should be double encrypted with both platform-managed and customer-managed keys	High security sensitive customers who are concerned of the risk associated with any particular encryption algorithm, implementation, or key being compromised can opt for additional layer of encryption using a different encryption algorithm/mode at the infrastructure layer using platform managed encryption keys. The disk encryption sets are required to use double encryption. Learn more at Server-side encryption of Azure managed disks.	Audit; Deny; Disabled	1.0.0
Service Bus namespaces should have double encryption enabled	Enabling double encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. When double encryption has been enabled, data in the storage account is encrypted twice, once at the service level and once at the infrastructure level, using two different encryption algorithms and two different keys.	Audit; Deny; Disabled	1.0.0
Service Fabric clusters should have the ClusterProtectionLevel property set to EncryptAndSign	Service Fabric provides three levels of protection (None, Sign and EncryptAndSign) for node-to-node communication using a primary cluster certificate. Set the protection level to ensure that all node-to-node messages are encrypted and digitally signed	Audit; Deny; Disabled	1.1.0
Storage accounts should have infrastructure encryption	Enable infrastructure encryption for higher level of assurance that the data is secure. When infrastructure encryption is enabled, data in a storage account is encrypted twice.	Audit; Deny; Disabled	1.0.0
Temp disks and cache for agent node pools in Azure Kubernetes Service clusters should be encrypted at host	To enhance data security, the data stored on the virtual machine (VM) host of your Azure Kubernetes Service nodes VMs should be encrypted at rest. This is a common requirement in many regulatory and industry compliance standards.	Audit; Deny; Disabled	1.0.1
Transparent Data Encryption must be enabled for Arc SQL managed instances.	Enable transparent data encryption (TDE) at-rest on an Azure Arc-enabled SQL Managed Instance. Learn more at Encrypt a database with transparent data encryption manually in SQL Managed Instance enabled by Azure Arc.	Audit; Disabled	1.0.0
Transparent Data Encryption on SQL databases should be enabled	Transparent data encryption should be enabled to protect data-at-rest and meet compliance requirements	AuditIfNotExists; Disabled	2.0.0
Virtual machines and virtual machine scale sets should have encryption at host enabled	Use encryption at host to get end-to-end encryption for your virtual machine and virtual machine scale set data. Encryption at host enables encryption at rest for your temporary disk and OS/data disk caches. Temporary and ephemeral OS disks are encrypted with platform-managed keys when encryption at host is enabled. OS/data disk caches are encrypted at rest with either customer-managed or platform-managed key, depending on the encryption type selected on the disk. Learn more at Enable end-to-end encryption using encryption at host.	Audit; Deny; Disabled	1.0.0
Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost.	Although a virtual machine's OS and data disks are encrypted-at-rest by default using platform managed keys; resource disks (temp disks), data caches, and data flowing between Compute and Storage resources are not encrypted. Use Azure Disk Encryption or EncryptionAtHost to remediate. Visit Overview of managed disk encryption options to compare encryption offerings. This policy requires two prerequisites to be deployed to the policy assignment scope. For details, visit Understand Azure Machine Configuration.	AuditIfNotExists; Disabled	1.1.1

DP-5: Use customer-managed key option in data at rest encryption when required

For more information, see Data Protection: DP-5: Use customer-managed key option in data at rest encryption when required.

Name	Description	Effect(s)	Version
App Configuration should use a customer-managed key	Customer-managed keys provide enhanced data protection by allowing you to manage your encryption keys. This is often required to meet compliance requirements.	Audit; Deny; Disabled	1.1.0
Azure AI Search services should use customer-managed keys to encrypt data at rest	Enabling encryption at rest using a customer-managed key on your Azure AI Search services provides additional control over the key used to encrypt data at rest. This feature is often applicable to customers with special compliance requirements to manage data encryption keys using a key vault.	AuditIfNotExists; Disabled	2.1.0
Azure AI Services resources should encrypt data at rest with a customer-managed key (CMK)	Using customer-managed keys to encrypt data at rest provides more control over the key lifecycle, including rotation and management. This is particularly relevant for organizations with related compliance requirements. This is not assessed by default and should only be applied when required by compliance or restrictive policy requirements. If not enabled, the data will be encrypted using platform-managed keys. To implement this, update the 'Effect' parameter in the Security Policy for the applicable scope.	Audit; Deny; Disabled	2.2.0
Azure API for FHIR should use a customer-managed key to encrypt data at rest	Use a customer-managed key to control the encryption at rest of the data stored in Azure API for FHIR when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys.	audit; Audit; disabled; Disabled	1.1.0
Azure Automation accounts should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your Azure Automation Accounts. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Encryption of secure assets in Azure Automation.	Audit; Deny; Disabled	1.0.0
Azure Batch account should use customer-managed keys to encrypt data	Use customer-managed keys to manage the encryption at rest of your Batch account's data. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Batch account data encryption.	Audit; Deny; Disabled	1.0.1
Azure Cache for Redis Enterprise should use customer-managed keys for encrypting disk data	Use customer-managed keys (CMK) to manage the encryption at rest of your on-disk data. By default, customer data is encrypted with platform-managed keys (PMK), but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Configure disk encryption in Azure Cache for Redis.	Audit; Deny; Disabled	1.0.0
Azure Container Instance container group should use customer-managed key for encryption	Secure your containers with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data.	Audit; Disabled; Deny	1.0.0
Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your Azure Cosmos DB. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Configure Customer-Managed Keys.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Azure Data Box jobs should use a customer-managed key to encrypt the device unlock password	Use a customer-managed key to control the encryption of the device unlock password for Azure Data Box. Customer-managed keys also help manage access to the device unlock password by the Data Box service in order to prepare the device and copy data in an automated manner. The data on the device itself is already encrypted at rest with Advanced Encryption Standard 256-bit encryption, and the device unlock password is encrypted by default with a Microsoft managed key.	Audit; Deny; Disabled	1.0.0
Azure Data Explorer encryption at rest should use a customer-managed key	Enabling encryption at rest using a customer-managed key on your Azure Data Explorer cluster provides additional control over the key being used by the encryption at rest. This feature is oftentimes applicable to customers with special compliance requirements and requires a Key Vault to managing the keys.	Audit; Deny; Disabled	1.0.0
Azure data factories should be encrypted with a customer-managed key	Use customer-managed keys to manage the encryption at rest of your Azure Data Factory. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Encrypt Azure Data Factory with customer-managed key.	Audit; Deny; Disabled	1.0.1
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption	Only allow Databricks workspace with Premium Sku that your organization can deploy to support features like Private Link, customer-managed key for encryption. Learn more at: Configure back-end private connectivity to Azure Databricks.	Audit; Deny; Disabled	1.0.1
Azure Device Update accounts should use customer-managed key to encrypt data at rest	Encryption of data at rest in Azure Device Update with customer-managed key adds a second layer of encryption on top of the default service-managed keys, enables customer control of keys, custom rotation policies, and ability to manage access to data through key access control. Learn more at:Data encryption for Device Update for IoT Hub.	Audit; Deny; Disabled	1.0.0
Azure HDInsight clusters should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your Azure HDInsight clusters. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Double encryption for data at rest.	Audit; Deny; Disabled	1.0.1
Azure Health Bots should use customer-managed keys to encrypt data at rest	Use customer-managed keys (CMK) to manage the encryption at rest of the data of your healthbots. By default, the data is encrypted at rest with service-managed keys, but CMK are commonly required to meet regulatory compliance standards. CMK enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Configure Customer Managed Keys for data encryption in healthcare agent service	Audit; Disabled	1.0.0
Azure load testing resource should use customer-managed keys to encrypt data at rest	Use customer-managed keys(CMK) to manage the encryption at rest for your Azure Load Testing resource. By default the encryptio is done using Service managed keys, customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Configure customer-managed keys for Azure Load Testing with Azure Key Vault.	Audit; Deny; Disabled	1.0.0
Azure Machine Learning workspaces should be encrypted with a customer-managed key	Manage encryption at rest of Azure Machine Learning workspace data with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Create a workspace with Azure Resource Manager template.	Audit; Deny; Disabled	1.1.0
Azure Machine Learning workspaces should be encrypted with the use of a customer-managed key	Manage encryption at rest of Azure Machine Learning workspace data with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Create a workspace with Azure Resource Manager template.	AuditIfNotExists; Disabled	1.0.0
Azure Monitor Logs clusters should be encrypted with customer-managed key	Create Azure Monitor logs cluster with customer-managed keys encryption. By default, the log data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance. Customer-managed key in Azure Monitor gives you more control over the access to you data, see Configure customer-managed keys in Azure Monitor.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
[Preview]: Azure Recovery Services vaults should use customer-managed keys for encrypting backup data	Use customer-managed keys to manage the encryption at rest of your backup data. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at https://aka.ms/AB-CmkEncryption.	Audit; Deny; Disabled	1.0.0-preview
[Preview]: Azure Stack HCI systems should have encrypted volumes	Use BitLocker to encrypt the OS and data volumes on Azure Stack HCI systems.	Audit; Disabled; AuditIfNotExists	1.0.0-preview
Azure Stream Analytics jobs should use customer-managed keys to encrypt data	Use customer-managed keys when you want to securely store any metadata and private data assets of your Stream Analytics jobs in your storage account. This gives you total control over how your Stream Analytics data is encrypted.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Azure Synapse workspaces should use customer-managed keys to encrypt data at rest	Use customer-managed keys to control the encryption at rest of the data stored in Azure Synapse workspaces. Customer-managed keys deliver double encryption by adding a second layer of encryption on top of the default encryption with service-managed keys.	Audit; Deny; Disabled	1.0.0
Bot Service should be encrypted with a customer-managed key	Azure Bot Service automatically encrypts your resource to protect your data and meet organizational security and compliance commitments. By default, Microsoft-managed encryption keys are used. For greater flexibility in managing keys or controlling access to your subscription, select customer-managed keys, also known as bring your own key (BYOK). Learn more about Azure Bot Service encryption: Azure AI Bot Service encryption for data at rest.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys	Encrypting OS and data disks using customer-managed keys provides more control and greater flexibility in key management. This is a common requirement in many regulatory and industry compliance standards.	Audit; Deny; Disabled	1.0.1
Container registries should be encrypted with a customer-managed key	Use customer-managed keys to manage the encryption at rest of the contents of your registries. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Customer-Managed Keys for Azure Container Registry.	Audit; Deny; Disabled	1.1.2
Customer managed key encryption must be used as part of CMK Encryption for Arc SQL managed instances.	As a part of CMK encryption, Customer managed key encryption must be used. Learn more at Encrypt a database with transparent data encryption manually in SQL Managed Instance enabled by Azure Arc.	Audit; Disabled	1.0.0
DICOM Service should use a customer-managed key to encrypt data at rest	Use a customer-managed key to control the encryption at rest of the data stored in Azure Health Data Services DICOM Service when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys.	Audit; Disabled	1.0.0
ElasticSan Volume Group should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your VolumeGroup. By default, customer data is encrypted with platform-managed keys, but CMKs are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you, with full control and responsibility, including rotation and management.	Audit; Disabled	1.0.0
Event Hub namespaces should use a customer-managed key for encryption	Azure Event Hubs supports the option of encrypting data at rest with either Microsoft-managed keys (default) or customer-managed keys. Choosing to encrypt data using customer-managed keys enables you to assign, rotate, disable, and revoke access to the keys that Event Hub will use to encrypt data in your namespace. Note that Event Hub only supports encryption with customer-managed keys for namespaces in dedicated clusters.	Audit; Disabled	1.0.0
FHIR Service should use a customer-managed key to encrypt data at rest	Use a customer-managed key to control the encryption at rest of the data stored in Azure Health Data Services FHIR Service when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys.	Audit; Disabled	1.0.0
Fluid Relay should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your Fluid Relay server. By default, customer data is encrypted with service-managed keys, but CMKs are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you, with full control and responsibility, including rotation and management. Learn more at Customer-managed keys for Azure Fluid Relay encryption.	Audit; Disabled	1.0.0
HPC Cache accounts should use customer-managed key for encryption	Manage encryption at rest of Azure HPC Cache with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management.	Audit; Disabled; Deny	2.0.0
[Preview]: IoT Hub device provisioning service data should be encrypted using customer-managed keys (CMK)	Use customer-managed keys to manage the encryption at rest of your IoT Hub device provisioning service. The data is automatically encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. Learn more about CMK encryption at https://aka.ms/dps/CMK.	Audit; Deny; Disabled	1.0.0-preview
Logic Apps Integration Service Environment should be encrypted with customer-managed keys	Deploy into Integration Service Environment to manage encryption at rest of Logic Apps data using customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management.	Audit; Deny; Disabled	1.0.0
Managed disks should be double encrypted with both platform-managed and customer-managed keys	High security sensitive customers who are concerned of the risk associated with any particular encryption algorithm, implementation, or key being compromised can opt for additional layer of encryption using a different encryption algorithm/mode at the infrastructure layer using platform managed encryption keys. The disk encryption sets are required to use double encryption. Learn more at Server-side encryption of Azure managed disks.	Audit; Deny; Disabled	1.0.0
Managed disks should use a specific set of disk encryption sets for the customer-managed key encryption	Requiring a specific set of disk encryption sets to be used with managed disks give you control over the keys used for encryption at rest. You are able to select the allowed encrypted sets and all others are rejected when attached to a disk. Learn more at Server-side encryption of Azure managed disks.	Audit; Deny; Disabled	2.0.0
MySQL servers should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your MySQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management.	AuditIfNotExists; Disabled	1.0.4
OS and data disks should be encrypted with a customer-managed key	Use customer-managed keys to manage the encryption at rest of the contents of your managed disks. By default, the data is encrypted at rest with platform-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at Server-side encryption of Azure managed disks.	Audit; Deny; Disabled	3.0.0
PostgreSQL flexible servers should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your PostgreSQL flexible servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management.	Audit; Deny; Disabled	1.1.0
PostgreSQL servers should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your PostgreSQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management.	AuditIfNotExists; Disabled	1.0.4
Queue Storage should use customer-managed key for encryption	Secure your queue storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data.	Audit; Deny; Disabled	1.0.0
Service Bus Premium namespaces should use a customer-managed key for encryption	Azure Service Bus supports the option of encrypting data at rest with either Microsoft-managed keys (default) or customer-managed keys. Choosing to encrypt data using customer-managed keys enables you to assign, rotate, disable, and revoke access to the keys that Service Bus will use to encrypt data in your namespace. Note that Service Bus only supports encryption with customer-managed keys for premium namespaces.	Audit; Disabled	1.0.0
SQL managed instances should use customer-managed keys to encrypt data at rest	Implementing Transparent Data Encryption (TDE) with your own key provides you with increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement.	Audit; Deny; Disabled	2.0.0
SQL servers should use customer-managed keys to encrypt data at rest	Implementing Transparent Data Encryption (TDE) with your own key provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement.	Audit; Deny; Disabled	2.0.1
Storage account containing the container with activity logs must be encrypted with BYOK	This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here https://aka.ms/azurestoragebyok.	AuditIfNotExists; Disabled	1.0.0
Storage account encryption scopes should use customer-managed keys to encrypt data at rest	Use customer-managed keys to manage the encryption at rest of your storage account encryption scopes. Customer-managed keys enable the data to be encrypted with an Azure key-vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about storage account encryption scopes at Encryption scopes for Blob storage.	Audit; Deny; Disabled	1.0.0
Storage account encryption scopes should use double encryption for data at rest	Enable infrastructure encryption for encryption at rest of your storage account encryption scopes for added security. Infrastructure encryption ensures that your data is encrypted twice.	Audit; Deny; Disabled	1.0.0
Storage accounts should use customer-managed key for encryption	Secure your blob and file storage account with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data.	Audit; Disabled	1.0.3
Table Storage should use customer-managed key for encryption	Secure your table storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data.	Audit; Deny; Disabled	1.0.0

DP-6: Use a secure key management process

For more information, see Data Protection: DP-6: Use a secure key management process.

Name	Description	Effect(s)	Version
API Management secret named values should be stored in Azure Key Vault	Named values are a collection of name and value pairs in each API Management service. Secret values can be stored either as encrypted text in API Management (custom secrets) or by referencing secrets in Azure Key Vault. To improve security of API Management and secrets, reference secret named values from Azure Key Vault. Azure Key Vault supports granular access management and secret rotation policies.	Audit; Disabled; Deny	1.0.2
Azure Cosmos DB accounts should not exceed the maximum number of days allowed since last account key regeneration.	Regenerate your keys in the specified time to keep your data more protected.	Audit; Disabled	1.0.0
Azure Data Factory linked services should use Key Vault for storing secrets	To ensure secrets (such as connection strings) are managed securely, require users to provide secrets using an Azure Key Vault instead of specifying them inline in linked services.	Audit; Deny; Disabled	1.0.0
[Preview]: Azure Key Vault Managed HSM keys should have an expiration date	To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. 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
[Preview]: Azure Key Vault Managed HSM Keys should have more than the specified number of days before expiration	To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. 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-preview
[Preview]: Azure Key Vault Managed HSM keys using elliptic curve cryptography should have the specified curve names	To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. 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-preview
[Preview]: Azure Key Vault Managed HSM keys using RSA cryptography should have a specified minimum key size	To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. 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-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 Kubernetes Clusters should enable Key Management Service (KMS)	Use Key Management Service (KMS) to encrypt secret data at rest in etcd for Kubernetes cluster security. Learn more at: https://aka.ms/aks/kmsetcdencryption.	Audit; 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
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 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
Storage account keys should not be expired	Ensure the user storage account keys are not expired when key expiration policy is set, for improving security of account keys by taking action when the keys are expired.	Audit; Deny; Disabled	3.0.0

DP-7: Use a secure certificate management process

For more information, see Data Protection: DP-7: Use a secure certificate management process.

Name	Description	Effect(s)	Version
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.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; Deny; 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; Deny; 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 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; Deny; 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; Deny; 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; Deny; Disabled	2.1.0

DP-8: Ensure security of key and certificate repository

For more information, see Data Protection: DP-8: Ensure security of key and certificate repository.

Name	Description	Effect(s)	Version
Azure Defender for Key Vault should be enabled	Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts.	AuditIfNotExists; Disabled	1.0.3
Azure Key Vault should have firewall enabled or public network access disabled	Enable the key vault firewall so that the key vault is not accessible by default to any public IPs or disable public network access for your key vault so that it's not accessible over the public internet. Optionally, you can configure specific IP ranges to limit access to those networks. Learn more at: Network security for Azure Key Vault and Integrate Key Vault with Azure Private Link	Audit; Deny; Disabled	3.3.0
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: Integrate Key Vault with Azure Private Link.	Audit; Deny; Disabled	1.2.1
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.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

DS-6: Secure the workload lifecycle

For more information, see DevOps Security: DS-6: Secure the workload lifecycle.

Name	Description	Effect(s)	Version
Azure registry container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)	Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. Resolving vulnerabilities can greatly improve your security posture, ensuring images are safe to use prior to deployment.	AuditIfNotExists; Disabled	1.0.1
Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)	Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. This recommendation provides visibility to vulnerable images currently running in your Kubernetes clusters. Remediating vulnerabilities in container images that are currently running is key to improving your security posture, significantly reducing the attack surface for your containerized workloads.	AuditIfNotExists; Disabled	1.0.1

ES-1: Use Endpoint Detection and Response (EDR)

For more information, see Endpoint Security: ES-1: Use Endpoint Detection and Response (EDR).

Name	Description	Effect(s)	Version
Azure Defender for servers should be enabled	Azure Defender for servers provides real-time threat protection for server workloads and generates hardening recommendations as well as alerts about suspicious activities.	AuditIfNotExists; Disabled	1.0.3
[Preview]: Deploy Microsoft Defender for Endpoint agent on Linux hybrid machines	Deploys Microsoft Defender for Endpoint agent on Linux hybrid machines	DeployIfNotExists; AuditIfNotExists; Disabled	2.0.1-preview
[Preview]: Deploy Microsoft Defender for Endpoint agent on Linux virtual machines	Deploys Microsoft Defender for Endpoint agent on applicable Linux VM images.	DeployIfNotExists; AuditIfNotExists; Disabled	3.0.0-preview
[Preview]: Deploy Microsoft Defender for Endpoint agent on Windows Azure Arc machines	Deploys Microsoft Defender for Endpoint on Windows Azure Arc machines.	DeployIfNotExists; AuditIfNotExists; Disabled	2.0.1-preview
[Preview]: Deploy Microsoft Defender for Endpoint agent on Windows virtual machines	Deploys Microsoft Defender for Endpoint on applicable Windows VM images.	DeployIfNotExists; AuditIfNotExists; Disabled	2.0.1-preview

ES-2: Use modern anti-malware software

For more information, see Endpoint Security: ES-2: Use modern anti-malware software.

Name	Description	Effect(s)	Version
Microsoft Antimalware for Azure should be configured to automatically update protection signatures	This policy audits any Windows virtual machine not configured with automatic update of Microsoft Antimalware protection signatures.	AuditIfNotExists; Disabled	1.0.0
Microsoft IaaSAntimalware extension should be deployed on Windows servers	This policy audits any Windows server VM without Microsoft IaaSAntimalware extension deployed.	AuditIfNotExists; Disabled	1.1.0
Windows Defender Exploit Guard should be enabled on your machines	Windows Defender Exploit Guard uses the Azure Policy Guest Configuration agent. Exploit Guard has four components that are designed to lock down devices against a wide variety of attack vectors and block behaviors commonly used in malware attacks while enabling enterprises to balance their security risk and productivity requirements (Windows only).	AuditIfNotExists; Disabled	2.0.0

IM-1: Use centralized identity and authentication system

For more information, see Identity Management: IM-1: Use centralized identity and authentication system.

Name	Description	Effect(s)	Version
A Microsoft Entra administrator should be provisioned for PostgreSQL servers	Audit provisioning of a Microsoft Entra administrator for your PostgreSQL server to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services	AuditIfNotExists; Disabled	1.0.1
An Azure Active Directory administrator should be provisioned for SQL servers	Audit provisioning of an Azure Active Directory administrator for your SQL server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services	AuditIfNotExists; Disabled	1.0.0
App Service apps should have authentication enabled	Azure App Service Authentication is a feature that can prevent anonymous HTTP requests from reaching the web app, or authenticate those that have tokens before they reach the web app.	AuditIfNotExists; Disabled	2.0.1
App Service apps should have local authentication methods disabled for FTP deployments	Disabling local authentication methods for FTP deployments improves security by ensuring that App Services exclusively require Microsoft Entra identities for authentication. Learn more at: Disabling basic auth on App Service.	AuditIfNotExists; Disabled	1.0.3
App Service apps should have local authentication methods disabled for SCM site deployments	Disabling local authentication methods for SCM sites improves security by ensuring that App Services exclusively require Microsoft Entra identities for authentication. Learn more at: Disabling basic auth on App Service.	AuditIfNotExists; Disabled	1.0.3
Application Insights components should block non-Azure Active Directory based ingestion.	Enforcing log ingestion to require Azure Active Directory authentication prevents unauthenticated logs from an attacker which could lead to incorrect status, false alerts, and incorrect logs stored in the system.	Deny; Audit; Disabled	1.0.0
Azure AI Search services should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure AI Search services exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/azure-cognitive-search/rbac. Note that while the disable local authentication parameter is still in preview, the deny effect for this policy may result in limited Azure AI Search portal functionality since some features of the Portal use the GA API which does not support the parameter.	Audit; Deny; Disabled	1.0.1
Azure AI Services resources should have key access disabled (disable local authentication)	Key access (local authentication) is recommended to be disabled for security. Azure OpenAI Studio, typically used in development/testing, requires key access and will not function if key access is disabled. After disabling, Microsoft Entra ID becomes the only access method, which allows maintaining minimum privilege principle and granular control. Learn more at: Authentication in Foundry Tools	Audit; Deny; Disabled	1.1.0
Azure Automation account should have local authentication method disabled	Disabling local authentication methods improves security by ensuring that Azure Automation accounts exclusively require Azure Active Directory identities for authentication.	Audit; Deny; Disabled	1.0.0
Azure Event Grid domains should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Event Grid domains exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/aeg-disablelocalauth.	Audit; Deny; Disabled	1.0.0
Azure Event Grid partner namespaces should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Event Grid partner namespaces exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/aeg-disablelocalauth.	Audit; Deny; Disabled	1.0.0
Azure Event Grid topics should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Event Grid topics exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/aeg-disablelocalauth.	Audit; Deny; Disabled	1.0.0
Azure Event Hub namespaces should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Event Hub namespaces exclusively require Microsoft Entra ID identities for authentication. Learn more at: https://aka.ms/disablelocalauth-eh.	Audit; Deny; Disabled	1.0.1
Azure Kubernetes Service Clusters should enable Microsoft Entra ID integration	AKS-managed Microsoft Entra ID integration can manage the access to the clusters by configuring Kubernetes role-based access control (Kubernetes RBAC) based on a user's identity or directory group membership. Learn more at: Enable AKS-managed Microsoft Entra integration on an Azure Kubernetes Service cluster.	Audit; Disabled	1.0.2
Azure Kubernetes Service Clusters should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Kubernetes Service Clusters should exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/aks-disable-local-accounts.	Audit; Deny; Disabled	1.0.1
Azure Machine Learning Computes should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Machine Learning Computes require Azure Active Directory identities exclusively for authentication. Learn more at: Azure Policy Regulatory Compliance controls for Azure Machine Learning.	Audit; Deny; Disabled	2.1.0
[Preview]: Azure PostgreSQL flexible server should have Microsoft Entra Only Authentication enabled	Disabling local authentication methods and allowing only Microsoft Entra Authentication improves security by ensuring that Azure PostgreSQL flexible server can exclusively be accessed by Microsoft Entra identities.	Audit; Disabled	1.0.0-preview
Azure Service Bus namespaces should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Service Bus namespaces exclusively require Microsoft Entra ID identities for authentication. Learn more at: https://aka.ms/disablelocalauth-sb.	Audit; Deny; Disabled	1.0.1
Azure SQL Database should have Microsoft Entra-only authentication enabled	Require Azure SQL logical servers to use Microsoft Entra-only authentication. This policy doesn't block servers from being created with local authentication enabled. It does block local authentication from being enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Create Server with Microsoft Entra-Only Authentication Enabled.	Audit; Deny; Disabled	1.0.0
Azure SQL Database should have Microsoft Entra-only authentication enabled during creation	Require Azure SQL logical servers to be created with Microsoft Entra-only authentication. This policy doesn't block local authentication from being re-enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Create Server with Microsoft Entra-Only Authentication Enabled.	Audit; Deny; Disabled	1.2.0
Azure SQL Managed Instance should have Microsoft Entra-only authentication enabled	Require Azure SQL Managed Instance to use Microsoft Entra-only authentication. This policy doesn't block Azure SQL Managed instances from being created with local authentication enabled. It does block local authentication from being enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Create Server with Microsoft Entra-Only Authentication Enabled.	Audit; Deny; Disabled	1.0.0
Azure SQL Managed Instances should have Microsoft Entra-only authentication enabled during creation	Require Azure SQL Managed Instance to be created with Microsoft Entra-only authentication. This policy doesn't block local authentication from being re-enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Create Server with Microsoft Entra-Only Authentication Enabled.	Audit; Deny; Disabled	1.2.0
Azure Web PubSub Service should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Azure Web PubSub Service exclusively require Azure Active Directory identities for authentication.	Audit; Deny; Disabled	1.0.0
Bot Service should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that a bot uses AAD exclusively for authentication.	Audit; Deny; Disabled	1.0.0
Container registries should have anonymous authentication disabled.	Disable anonymous pull for your registry so that data is not accessible by unauthenticated user. Disabling local authentication methods like admin user, repository scoped access tokens and anonymous pull improves security by ensuring that container registries exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/acr/authentication.	Audit; Deny; Disabled	1.0.0
Container registries should have ARM audience token authentication disabled.	Disable Azure Active Directory ARM audience tokens for authentication to your registry. Only Azure Container Registry (ACR) audience tokens will be used for authentication. This will ensure only tokens meant for usage on the registry can be used for authentication. Disabling ARM audience tokens does not affect admin user's or scoped access tokens' authentication. Learn more at: https://aka.ms/acr/authentication.	Audit; Deny; Disabled	1.0.0
Container registries should have local admin account disabled.	Disable admin account for your registry so that it is not accessible by local admin. Disabling local authentication methods like admin user, repository scoped access tokens and anonymous pull improves security by ensuring that container registries exclusively require Azure Active Directory identities for authentication. Learn more at: Azure Container Registry Authentication Options Explained.	Audit; Deny; Disabled	1.0.1
Container registries should have repository scoped access token disabled.	Disable repository scoped access tokens for your registry so that repositories are not accessible by tokens. Disabling local authentication methods like admin user, repository scoped access tokens and anonymous pull improves security by ensuring that container registries exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/acr/authentication.	Audit; Deny; Disabled	1.0.0
Cosmos DB database accounts should have local authentication methods disabled	Disabling local authentication methods improves security by ensuring that Cosmos DB database accounts exclusively require Azure Active Directory identities for authentication. Learn more at: Connect to Azure Cosmos DB for NoSQL using role-based access control and Microsoft Entra ID.	Audit; Deny; Disabled	1.1.0
Function apps should have authentication enabled	Azure App Service Authentication is a feature that can prevent anonymous HTTP requests from reaching the Function app, or authenticate those that have tokens before they reach the Function app.	AuditIfNotExists; Disabled	3.1.0
Log Analytics Workspaces should block non-Azure Active Directory based ingestion.	Enforcing log ingestion to require Azure Active Directory authentication prevents unauthenticated logs from an attacker which could lead to incorrect status, false alerts, and incorrect logs stored in the system.	Deny; Audit; Disabled	1.0.0
Service Fabric clusters should only use Azure Active Directory for client authentication	Audit usage of client authentication only via Azure Active Directory in Service Fabric	Audit; Deny; Disabled	1.1.0
Storage accounts should prevent shared key access	Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft.	Audit; Deny; Disabled	2.0.0
Storage accounts should prevent shared key access (excluding storage accounts created by Databricks)	Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft.	Audit; Deny; Disabled	1.0.0
Synapse Workspaces should have Microsoft Entra-only authentication enabled	Require Synapse Workspaces to use Microsoft Entra-only authentication. This policy doesn't block workspaces from being created with local authentication enabled. It does block local authentication from being enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Azure Synapse Analytics.	Audit; Deny; Disabled	1.0.0
Synapse Workspaces should use only Microsoft Entra identities for authentication during workspace creation	Require Synapse Workspaces to be created with Microsoft Entra-only authentication. This policy doesn't block local authentication from being re-enabled on resources after create. Consider using the 'Microsoft Entra-only authentication' initiative instead to require both. Learn more at: Azure Synapse Analytics.	Audit; Deny; Disabled	1.2.0
VPN gateways should use only Azure Active Directory (Azure AD) authentication for point-to-site users	Disabling local authentication methods improves security by ensuring that VPN Gateways use only Azure Active Directory identities for authentication. Learn more about Azure AD authentication at Configure P2S VPN gateway for Microsoft Entra ID authentication	Audit; Deny; Disabled	1.0.0

IM-2: Protect identity and authentication systems

For more information, see Identity Management: IM-2: Protect identity and authentication systems.

Name	Description	Effect(s)	Version
Users must authenticate with multi-factor authentication to create or update resources	This policy definition blocks resource create and update operations when the caller is not authenticated via MFA. For more information, visit Plan for mandatory Microsoft Entra multifactor authentication (MFA).	Audit; Deny; Disabled	1.0.1

IM-3: Manage application identities securely and automatically

For more information, see Identity Management: IM-3: Manage application identities securely and automatically.

Name	Description	Effect(s)	Version
[Preview]: A managed identity should be enabled on your machines	Resources managed by Automanage should have a managed identity.	Audit; Disabled	1.0.0-preview
[Preview]: Add user-assigned managed identity to enable Guest Configuration assignments on virtual machines	This policy adds a user-assigned managed identity to virtual machines hosted in Azure that are supported by Guest Configuration. A user-assigned managed identity is a prerequisite for all Guest Configuration assignments and must be added to machines before using any Guest Configuration policy definitions. For more information on Guest Configuration, visit https://aka.ms/gcpol.	AuditIfNotExists; DeployIfNotExists; Disabled	2.1.0-preview
App Service app slots should use managed identity	Use a managed identity for enhanced authentication security	AuditIfNotExists; Disabled	1.0.0
App Service apps should use managed identity	Use a managed identity for enhanced authentication security	AuditIfNotExists; Disabled	3.0.0
[Preview]: Assign Built-In User-Assigned Managed Identity to Virtual Machine Scale Sets	Create and assign a built-in user-assigned managed identity or assign a pre-created user-assigned managed identity at scale to virtual machine scale sets. For more detailed documentation, visit aka.ms/managedidentitypolicy.	AuditIfNotExists; DeployIfNotExists; Disabled	1.1.0-preview
[Preview]: Assign Built-In User-Assigned Managed Identity to Virtual Machines	Create and assign a built-in user-assigned managed identity or assign a pre-created user-assigned managed identity at scale to virtual machines. For more detailed documentation, visit aka.ms/managedidentitypolicy.	AuditIfNotExists; DeployIfNotExists; Disabled	1.1.0-preview
Automation Account should have Managed Identity	Use Managed Identities as the recommended method for authenticating with Azure resources from the runbooks. Managed identity for authentication is more secure and eliminates the management overhead associated with using RunAs Account in your runbook code .	Audit; Disabled	1.0.0
Azure Data Factory linked services should use system-assigned managed identity authentication when it is supported	Using system-assigned managed identity when communicating with data stores via linked services avoids the use of less secured credentials such as passwords or connection strings.	Audit; Deny; Disabled	2.1.0
Azure Kubernetes Service Clusters should use managed identities	Use managed identities to wrap around service principals, simplify cluster management and avoid the complexity required to managed service principals. Learn more at: https://aka.ms/aks-update-managed-identities	Audit; Disabled	1.0.1
Azure Machine Learning workspaces should use user-assigned managed identity	Manange access to Azure ML workspace and associated resources, Azure Container Registry, KeyVault, Storage, and App Insights using user-assigned managed identity. By default, system-assigned managed identity is used by Azure ML workspace to access the associated resources. User-assigned managed identity allows you to create the identity as an Azure resource and maintain the life cycle of that identity. Learn more at Set up authentication between Azure Machine Learning and other services.	Audit; Deny; Disabled	1.0.0
Cognitive Services accounts should use a managed identity	Assigning a managed identity to your Cognitive Service account helps ensure secure authentication. This identity is used by this Cognitive service account to communicate with other Azure services, like Azure Key Vault, in a secure way without you having to manage any credentials.	Audit; Deny; Disabled	1.0.0
Communication service resource should use a managed identity	Assigning a managed identity to your Communication service resource helps ensure secure authentication. This identity is used by this Communication service resource to communicate with other Azure services, like Azure Storage, in a secure way without you having to manage any credentials.	Audit; Deny; Disabled	1.0.0
Create and assign a built-in user-assigned managed identity	Create and assign a built-in user-assigned managed identity at scale to SQL virtual machines.	AuditIfNotExists; DeployIfNotExists; Disabled	1.8.0
Function apps should use managed identity	Use a managed identity for enhanced authentication security	AuditIfNotExists; Disabled	3.1.0
[Preview]: Managed Identity Federated Credentials from Azure Kubernetes should be from trusted sources	This policy limits federeation with Azure Kubernetes clusters to only clusters from approved tenants, approved regions, and a specific exception list of additional clusters.	Audit; Disabled; Deny	1.0.0-preview
[Preview]: Managed Identity Federated Credentials from GitHub should be from trusted repository owners	This policy limits federation with GitHub repos to only approved repository owners.	Audit; Disabled; Deny	1.0.1-preview
[Preview]: Managed Identity Federated Credentials should be from allowed issuer types	This policy limits whether Managed Identities can use federated credentials, which common issuer types are allowed, and provides a list of allowed issuer exceptions.	Audit; Disabled; Deny	1.0.0-preview
Managed Identity should be enabled for Container Apps	Enforcing managed identity ensures Container Apps can securely authenticate to any resource that supports Azure AD authentication	Audit; Deny; Disabled	1.0.1
Stream Analytics job should use managed identity to authenticate endpoints	Ensure that Stream Analytics jobs only connect to endpoints using managed identity authentication.	Deny; Disabled; Audit	1.0.0
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity	The Guest Configuration extension requires a system assigned managed identity. Azure virtual machines in the scope of this policy will be non-compliant when they have the Guest Configuration extension installed but do not have a system assigned managed identity. Learn more at Understand Azure Machine Configuration	AuditIfNotExists; Disabled	1.0.1

IM-4: Authenticate server and services

For more information, see Identity Management: IM-4: Authenticate server and services.

Name	Description	Effect(s)	Version
API endpoints in Azure API Management should be authenticated	API endpoints published within Azure API Management should enforce authentication to help minimize security risk. Authentication mechanisms are sometimes implemented incorrectly or are missing. This allows attackers to exploit implementation flaws and to access data. Learn More about the OWASP API Threat for Broken User Authentication here: Recommendations to mitigate OWASP API Security Top 10 threats using API Management	AuditIfNotExists; Disabled	1.0.1
API Management calls to API backends should be authenticated	Calls from API Management to backends should use some form of authentication, whether via certificates or credentials. Does not apply to Service Fabric backends.	Audit; Disabled; Deny	1.0.1
API Management calls to API backends should not bypass certificate thumbprint or name validation	To improve the API security, API Management should validate the backend server certificate for all API calls. Enable SSL certificate thumbprint and name validation.	Audit; Disabled; Deny	1.0.2
App Service app slots should have Client Certificates (Incoming client certificates) enabled	Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. This policy applies to apps with Http version set to 1.1.	AuditIfNotExists; Disabled	1.0.0
Azure SQL Database should be running TLS version 1.2 or newer	Setting TLS version to 1.2 or newer improves security by ensuring your Azure SQL Database can only be accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities.	Audit; Disabled; Deny	2.0.0

IM-6: Use strong authentication controls

For more information, see Identity Management: IM-6: Use strong authentication controls.

Name	Description	Effect(s)	Version
Authentication to Linux machines should require SSH keys	Although SSH itself provides an encrypted connection, using passwords with SSH still leaves the VM vulnerable to brute-force attacks. The most secure option for authenticating to an Azure Linux virtual machine over SSH is with a public-private key pair, also known as SSH keys. Learn more: Detailed steps: Create and manage SSH keys for authentication to a Linux VM in Azure.	AuditIfNotExists; Disabled	3.2.0

IM-8: Restrict the exposure of credentials and secrets

For more information, see Identity Management: IM-8: Restrict the exposure of credentials and secrets.

Name	Description	Effect(s)	Version
API Management secret named values should be stored in Azure Key Vault	Named values are a collection of name and value pairs in each API Management service. Secret values can be stored either as encrypted text in API Management (custom secrets) or by referencing secrets in Azure Key Vault. To improve security of API Management and secrets, reference secret named values from Azure Key Vault. Azure Key Vault supports granular access management and secret rotation policies.	Audit; Disabled; Deny	1.0.2
Machines should have secret findings resolved	Audits virtual machines to detect whether they contain secret findings from the secret scanning solutions on your virtual machines.	AuditIfNotExists; Disabled	1.0.2

IR-2: Preparation - setup incident notification

For more information, see Incident Response: IR-2: Preparation - setup incident notification.

Name	Description	Effect(s)	Version
Email notification for high severity alerts should be enabled	To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, enable email notifications for high severity alerts in Security Center.	AuditIfNotExists; Disabled	1.2.0
Email notification to subscription owner for high severity alerts should be enabled	To ensure your subscription owners are notified when there is a potential security breach in their subscription, set email notifications to subscription owners for high severity alerts in Security Center.	AuditIfNotExists; Disabled	2.1.0
Subscriptions should have a contact email address for security issues	To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, set a security contact to receive email notifications from Security Center.	AuditIfNotExists; Disabled	1.0.1

IR-3: Detection and analysis - create incidents based on high-quality alerts

For more information, see Incident Response: IR-3: Detection and analysis - create incidents based on high-quality alerts.

Name	Description	Effect(s)	Version
Azure Defender for App Service should be enabled	Azure Defender for App Service leverages the scale of the cloud, and the visibility that Azure has as a cloud provider, to monitor for common web app attacks.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Azure SQL Database servers should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for Key Vault should be enabled	Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Resource Manager should be enabled	Azure Defender for Resource Manager automatically monitors the resource management operations in your organization. Azure Defender detects threats and alerts you about suspicious activity. Learn more about the capabilities of Azure Defender for Resource Manager at Microsoft Defender for Resource Manager - Benefits and Features . Enabling this Azure Defender plan results in charges. Learn about the pricing details per region on Security Center's pricing page: Pricing - Microsoft Defender for Cloud .	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL servers on machines should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL should be enabled for unprotected Azure SQL servers	Audit SQL servers without Advanced Data Security	AuditIfNotExists; Disabled	2.0.1
Azure Defender for SQL should be enabled for unprotected MySQL flexible servers	Audit MySQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected PostgreSQL flexible servers	Audit PostgreSQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for open-source relational databases should be enabled	Azure Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more about the capabilities of Azure Defender for open-source relational databases at Overview of Defender for Open-Source Relational Databases. Important: Enabling this plan will result in charges for protecting your open-source relational databases. Learn about the pricing on Security Center's pricing page: Pricing - Microsoft Defender for Cloud	AuditIfNotExists; Disabled	1.0.0
Azure Defender for servers should be enabled	Azure Defender for servers provides real-time threat protection for server workloads and generates hardening recommendations as well as alerts about suspicious activities.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender CSPM should be enabled	Defender Cloud Security Posture Management (CSPM) provides enhanced posture capabilities and a new intelligent cloud security graph to help identify, prioritize, and reduce risk. Defender CSPM is available in addition to the free foundational security posture capabilities turned on by default in Defender for Cloud.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for APIs should be enabled	Microsoft Defender for APIs brings new discovery, protection, detection, & response coverage to monitor for common API based attacks & security misconfigurations.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender for Containers should be enabled	Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multi-cloud Kubernetes environments.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for SQL should be enabled for unprotected Synapse workspaces	Enable Defender for SQL to protect your Synapse workspaces. Defender for SQL monitors your Synapse SQL to detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for Storage should be enabled	Microsoft Defender for Storage detects potential threats to your storage accounts. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption. The new Defender for Storage plan includes Malware Scanning and Sensitive Data Threat Detection. This plan also provides a predictable pricing structure (per storage account) for control over coverage and costs.	AuditIfNotExists; Disabled	1.0.0
SQL server-targeted autoprovisioning should be enabled for SQL servers on machines plan	To ensure your SQL VMs and Arc-enabled SQL Servers are protected, ensure the SQL-targeted Azure Monitoring Agent is configured to automatically deploy. This is also necessary if you've previously configured autoprovisioning of the Microsoft Monitoring Agent, as that component is being deprecated. Learn more: Migrate to Defender for SQL on machines using AMA	AuditIfNotExists; Disabled	1.0.0

IR-4: Detection and analysis - investigate an incident

For more information, see Incident Response: IR-4: Detection and analysis - investigate an incident.

Name	Description	Effect(s)	Version
Network Watcher should be enabled	Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose problems at an end to end network level view. It is required to have a network watcher resource group to be created in every region where a virtual network is present. An alert is enabled if a network watcher resource group is not available in a particular region.	AuditIfNotExists; Disabled	3.0.0

IR-5: Detection and analysis - prioritize incidents

For more information, see Incident Response: IR-5: Detection and analysis - prioritize incidents.

Name	Description	Effect(s)	Version
Azure Defender for App Service should be enabled	Azure Defender for App Service leverages the scale of the cloud, and the visibility that Azure has as a cloud provider, to monitor for common web app attacks.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Azure SQL Database servers should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for Key Vault should be enabled	Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Resource Manager should be enabled	Azure Defender for Resource Manager automatically monitors the resource management operations in your organization. Azure Defender detects threats and alerts you about suspicious activity. Learn more about the capabilities of Azure Defender for Resource Manager at Microsoft Defender for Resource Manager - Benefits and Features . Enabling this Azure Defender plan results in charges. Learn about the pricing details per region on Security Center's pricing page: Pricing - Microsoft Defender for Cloud .	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL servers on machines should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL should be enabled for unprotected Azure SQL servers	Audit SQL servers without Advanced Data Security	AuditIfNotExists; Disabled	2.0.1
Azure Defender for SQL should be enabled for unprotected MySQL flexible servers	Audit MySQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected PostgreSQL flexible servers	Audit PostgreSQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for open-source relational databases should be enabled	Azure Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more about the capabilities of Azure Defender for open-source relational databases at Overview of Defender for Open-Source Relational Databases. Important: Enabling this plan will result in charges for protecting your open-source relational databases. Learn about the pricing on Security Center's pricing page: Pricing - Microsoft Defender for Cloud	AuditIfNotExists; Disabled	1.0.0
Azure Defender for servers should be enabled	Azure Defender for servers provides real-time threat protection for server workloads and generates hardening recommendations as well as alerts about suspicious activities.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender CSPM should be enabled	Defender Cloud Security Posture Management (CSPM) provides enhanced posture capabilities and a new intelligent cloud security graph to help identify, prioritize, and reduce risk. Defender CSPM is available in addition to the free foundational security posture capabilities turned on by default in Defender for Cloud.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for APIs should be enabled	Microsoft Defender for APIs brings new discovery, protection, detection, & response coverage to monitor for common API based attacks & security misconfigurations.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender for Containers should be enabled	Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multi-cloud Kubernetes environments.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for SQL should be enabled for unprotected Synapse workspaces	Enable Defender for SQL to protect your Synapse workspaces. Defender for SQL monitors your Synapse SQL to detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for Storage should be enabled	Microsoft Defender for Storage detects potential threats to your storage accounts. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption. The new Defender for Storage plan includes Malware Scanning and Sensitive Data Threat Detection. This plan also provides a predictable pricing structure (per storage account) for control over coverage and costs.	AuditIfNotExists; Disabled	1.0.0
SQL server-targeted autoprovisioning should be enabled for SQL servers on machines plan	To ensure your SQL VMs and Arc-enabled SQL Servers are protected, ensure the SQL-targeted Azure Monitoring Agent is configured to automatically deploy. This is also necessary if you've previously configured autoprovisioning of the Microsoft Monitoring Agent, as that component is being deprecated. Learn more: Migrate to Defender for SQL on machines using AMA	AuditIfNotExists; Disabled	1.0.0

LT-1: Enable threat detection capabilities

For more information, see Logging and Threat Detection: LT-1: Enable threat detection capabilities.

Name	Description	Effect(s)	Version
[Preview]: Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed	Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in Secure score in Defender for Cloud.	AuditIfNotExists; Disabled	6.0.0-preview
Azure Defender for App Service should be enabled	Azure Defender for App Service leverages the scale of the cloud, and the visibility that Azure has as a cloud provider, to monitor for common web app attacks.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Azure SQL Database servers should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for Key Vault should be enabled	Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for open-source relational databases should be enabled	Azure Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more about the capabilities of Azure Defender for open-source relational databases at Overview of Defender for Open-Source Relational Databases. Important: Enabling this plan will result in charges for protecting your open-source relational databases. Learn about the pricing on Security Center's pricing page: Pricing - Microsoft Defender for Cloud	AuditIfNotExists; Disabled	1.0.0
Azure Defender for Resource Manager should be enabled	Azure Defender for Resource Manager automatically monitors the resource management operations in your organization. Azure Defender detects threats and alerts you about suspicious activity. Learn more about the capabilities of Azure Defender for Resource Manager at Microsoft Defender for Resource Manager - Benefits and Features . Enabling this Azure Defender plan results in charges. Learn about the pricing details per region on Security Center's pricing page: Pricing - Microsoft Defender for Cloud .	AuditIfNotExists; Disabled	1.0.0
Azure Defender for servers should be enabled	Azure Defender for servers provides real-time threat protection for server workloads and generates hardening recommendations as well as alerts about suspicious activities.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for SQL servers on machines should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL should be enabled for unprotected Azure SQL servers	Audit SQL servers without Advanced Data Security	AuditIfNotExists; Disabled	2.0.1
Azure Defender for SQL should be enabled for unprotected MySQL flexible servers	Audit MySQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected PostgreSQL flexible servers	Audit PostgreSQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists; Disabled	1.0.2
Azure Kubernetes Service clusters should have Defender profile enabled	Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers in Manage MCSB recommendations in Defender for Cloud	Audit; Disabled	2.0.1
[Preview]: ChangeTracking extension should be installed on your Linux Arc machine	Install ChangeTracking Extension on Linux Arc machines to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	1.0.0-preview
[Preview]: ChangeTracking extension should be installed on your Linux virtual machine	Install ChangeTracking Extension on Linux virtual machines to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	2.0.0-preview
ChangeTracking extension should be installed on your Linux virtual machine scale sets	Install ChangeTracking Extension on Linux virtual machine scale sets to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	2.0.1
[Preview]: ChangeTracking extension should be installed on your Windows Arc machine	Install ChangeTracking Extension on Windows Arc machines to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	1.0.0-preview
[Preview]: ChangeTracking extension should be installed on your Windows virtual machine	Install ChangeTracking Extension on Windows virtual machines to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	2.0.0-preview
ChangeTracking extension should be installed on your Windows virtual machine scale sets	Install ChangeTracking Extension on Windows virtual machine scale sets to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. The extension can be installed in virtual machines and locations supported by Azure Monitoring Agent.	AuditIfNotExists; Disabled	2.0.1
Microsoft Defender CSPM should be enabled	Defender Cloud Security Posture Management (CSPM) provides enhanced posture capabilities and a new intelligent cloud security graph to help identify, prioritize, and reduce risk. Defender CSPM is available in addition to the free foundational security posture capabilities turned on by default in Defender for Cloud.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for APIs should be enabled	Microsoft Defender for APIs brings new discovery, protection, detection, & response coverage to monitor for common API based attacks & security misconfigurations.	AuditIfNotExists; Disabled	1.0.3
Microsoft Defender for Azure Cosmos DB should be enabled	Microsoft Defender for Azure Cosmos DB is an Azure-native layer of security that detects attempts to exploit databases in your Azure Cosmos DB accounts. Defender for Azure Cosmos DB detects potential SQL injections, known bad actors based on Microsoft Threat Intelligence, suspicious access patterns, and potential exploitations of your database through compromised identities or malicious insiders.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for Containers should be enabled	Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multi-cloud Kubernetes environments.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for SQL should be enabled for unprotected Synapse workspaces	Enable Defender for SQL to protect your Synapse workspaces. Defender for SQL monitors your Synapse SQL to detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for Storage should be enabled	Microsoft Defender for Storage detects potential threats to your storage accounts. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption. The new Defender for Storage plan includes Malware Scanning and Sensitive Data Threat Detection. This plan also provides a predictable pricing structure (per storage account) for control over coverage and costs.	AuditIfNotExists; Disabled	1.0.0
Security Center standard pricing tier should be selected	The standard pricing tier enables threat detection for networks and virtual machines, providing threat intelligence, anomaly detection, and behavior analytics in Azure Security Center	Audit; Disabled	1.1.0
SQL server-targeted autoprovisioning should be enabled for SQL servers on machines plan	To ensure your SQL VMs and Arc-enabled SQL Servers are protected, ensure the SQL-targeted Azure Monitoring Agent is configured to automatically deploy. This is also necessary if you've previously configured autoprovisioning of the Microsoft Monitoring Agent, as that component is being deprecated. Learn more: Migrate to Defender for SQL on machines using AMA	AuditIfNotExists; Disabled	1.0.0
Windows Defender Exploit Guard should be enabled on your machines	Windows Defender Exploit Guard uses the Azure Policy Guest Configuration agent. Exploit Guard has four components that are designed to lock down devices against a wide variety of attack vectors and block behaviors commonly used in malware attacks while enabling enterprises to balance their security risk and productivity requirements (Windows only).	AuditIfNotExists; Disabled	2.0.0

LT-2: Enable threat detection for identity and access management

For more information, see Logging and Threat Detection: LT-2: Enable threat detection for identity and access management.

Name	Description	Effect(s)	Version
Azure Defender for App Service should be enabled	Azure Defender for App Service leverages the scale of the cloud, and the visibility that Azure has as a cloud provider, to monitor for common web app attacks.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Azure SQL Database servers should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for Key Vault should be enabled	Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts.	AuditIfNotExists; Disabled	1.0.3
Azure Defender for Resource Manager should be enabled	Azure Defender for Resource Manager automatically monitors the resource management operations in your organization. Azure Defender detects threats and alerts you about suspicious activity. Learn more about the capabilities of Azure Defender for Resource Manager at Microsoft Defender for Resource Manager - Benefits and Features . Enabling this Azure Defender plan results in charges. Learn about the pricing details per region on Security Center's pricing page: Pricing - Microsoft Defender for Cloud .	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL servers on machines should be enabled	Azure Defender for SQL provides functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate threats to SQL databases, and discovering and classifying sensitive data.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for SQL should be enabled for unprotected Azure SQL servers	Audit SQL servers without Advanced Data Security	AuditIfNotExists; Disabled	2.0.1
Azure Defender for SQL should be enabled for unprotected MySQL flexible servers	Audit MySQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected PostgreSQL flexible servers	Audit PostgreSQL flexible servers without Advanced Data Security	AuditIfNotExists; Disabled	1.0.0
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists; Disabled	1.0.2
Azure Defender for open-source relational databases should be enabled	Azure Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more about the capabilities of Azure Defender for open-source relational databases at Overview of Defender for Open-Source Relational Databases. Important: Enabling this plan will result in charges for protecting your open-source relational databases. Learn about the pricing on Security Center's pricing page: Pricing - Microsoft Defender for Cloud	AuditIfNotExists; Disabled	1.0.0
Azure Defender for servers should be enabled	Azure Defender for servers provides real-time threat protection for server workloads and generates hardening recommendations as well as alerts about suspicious activities.	AuditIfNotExists; Disabled	1.0.3
Azure Kubernetes Service clusters should have Defender profile enabled	Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers in Manage MCSB recommendations in Defender for Cloud	Audit; Disabled	2.0.1
Microsoft Defender CSPM should be enabled	Defender Cloud Security Posture Management (CSPM) provides enhanced posture capabilities and a new intelligent cloud security graph to help identify, prioritize, and reduce risk. Defender CSPM is available in addition to the free foundational security posture capabilities turned on by default in Defender for Cloud.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for Containers should be enabled	Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multi-cloud Kubernetes environments.	AuditIfNotExists; Disabled	1.0.0
Microsoft Defender for SQL should be enabled for unprotected Synapse workspaces	Enable Defender for SQL to protect your Synapse workspaces. Defender for SQL monitors your Synapse SQL to detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.	AuditIfNotExists; Disabled	1.0.0
SQL server-targeted autoprovisioning should be enabled for SQL servers on machines plan	To ensure your SQL VMs and Arc-enabled SQL Servers are protected, ensure the SQL-targeted Azure Monitoring Agent is configured to automatically deploy. This is also necessary if you've previously configured autoprovisioning of the Microsoft Monitoring Agent, as that component is being deprecated. Learn more: Migrate to Defender for SQL on machines using AMA	AuditIfNotExists; Disabled	1.0.0
Windows Defender Exploit Guard should be enabled on your machines	Windows Defender Exploit Guard uses the Azure Policy Guest Configuration agent. Exploit Guard has four components that are designed to lock down devices against a wide variety of attack vectors and block behaviors commonly used in malware attacks while enabling enterprises to balance their security risk and productivity requirements (Windows only).	AuditIfNotExists; Disabled	2.0.0
[Preview]: Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed	Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in Secure score in Defender for Cloud.	AuditIfNotExists; Disabled	6.0.0-preview

LT-3: Enable logging for security investigation

For more information, see Logging and Threat Detection: LT-3: Enable logging for security investigation.

Name	Description	Effect(s)	Version
Activity log should be retained for at least one year	This policy audits the activity log if the retention is not set for 365 days or forever (retention days set to 0).	AuditIfNotExists; Disabled	1.0.0
An activity log alert should exist for specific Administrative operations	This policy audits specific Administrative operations with no activity log alerts configured.	AuditIfNotExists; Disabled	1.0.0
An activity log alert should exist for specific Policy operations	This policy audits specific Policy operations with no activity log alerts configured.	AuditIfNotExists; Disabled	3.0.0
An activity log alert should exist for specific Security operations	This policy audits specific Security operations with no activity log alerts configured.	AuditIfNotExists; Disabled	1.1.0
App Service app slots should have resource logs enabled	Audit enabling of resource logs on the app. This enables you to recreate activity trails for investigation purposes if a security incident occurs or your network is compromised.	AuditIfNotExists; Disabled	1.0.0
App Service apps should have resource logs enabled	Audit enabling of resource logs on the app. This enables you to recreate activity trails for investigation purposes if a security incident occurs or your network is compromised.	AuditIfNotExists; Disabled	2.0.1
Auditing on SQL server should be enabled	Auditing on your SQL Server should be enabled to track database activities across all databases on the server and save them in an audit log.	AuditIfNotExists; Disabled	2.0.0
Azure Application Gateway should have Resource logs enabled	Enable Resource logs for Azure Application Gateway (plus WAF) and stream to a Log Analytics workspace. Get detailed visibility into inbound web traffic and actions taken to mitigate attacks.	AuditIfNotExists; Disabled	1.0.0
Azure Front Door should have Resource logs enabled	Enable Resource logs for Azure Front Door (plus WAF) and stream to a Log Analytics workspace. Get detailed visibility into inbound web traffic and actions taken to mitigate attacks.	AuditIfNotExists; Disabled	1.0.0
Azure Monitor log profile should collect logs for categories 'write,' 'delete,' and 'action'	This policy ensures that a log profile collects logs for categories 'write,' 'delete,' and 'action'	AuditIfNotExists; Disabled	1.0.0
Azure Monitor Logs for Application Insights should be linked to a Log Analytics workspace	Link the Application Insights component to a Log Analytics workspace for logs encryption. Customer-managed keys are commonly required to meet regulatory compliance and for more control over the access to your data in Azure Monitor. Linking your component to a Log Analytics workspace that's enabled with a customer-managed key, ensures that your Application Insights logs meet this compliance requirement, see /azure/azure-monitor/platform/customer-managed-keys.	Audit; Deny; Disabled	1.1.0
Azure Monitor should collect activity logs from all regions	This policy audits the Azure Monitor log profile which does not export activities from all Azure supported regions including global.	AuditIfNotExists; Disabled	2.0.0
Azure Monitor solution 'Security and Audit' must be deployed	This policy ensures that Security and Audit is deployed.	AuditIfNotExists; Disabled	1.0.0
Azure SignalR Service should enable diagnostic logs	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	1.0.0
Azure subscriptions should have a log profile for Activity Log	This policy ensures if a log profile is enabled for exporting activity logs. It audits if there is no log profile created to export the logs either to a storage account or to an event hub.	AuditIfNotExists; Disabled	1.0.0
Azure Web PubSub Service should enable diagnostic logs	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	1.0.0
[Preview]: Configure subscriptions to enable service health alert monitoring rule	Assignable at the subscription or management group level, this policy ensures that each subscription has a service health alert rule configured with alert conditions and mapping to action groups as specified in the policy parameters. By default creates a resource group, alert rule and action group configured to send emails to subscription owners for all service health events.	DeployIfNotExists; AuditIfNotExists; Disabled	1.4.0-preview
Diagnostic logs in Azure AI services resources should be enabled	Enable logs for Azure AI services resources. This enables you to recreate activity trails for investigation purposes, when a security incident occurs or your network is compromised	AuditIfNotExists; Disabled	1.0.0
Resource logs in Azure Data Lake Store 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
Resource logs in Azure Databricks Workspaces should be enabled	Resource logs enable recreating activity trails to use for investigation purposes when a security incident occurs or when your network is compromised.	AuditIfNotExists; 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: /azure/key-vault/managed-hsm/logging.	AuditIfNotExists; Disabled	1.1.0
Resource logs in Azure Kubernetes Service should be enabled	Azure Kubernetes Service's resource logs can help recreate activity trails when investigating security incidents. Enable it to make sure the logs will exist when needed	AuditIfNotExists; Disabled	1.0.0
Resource logs in Azure Machine Learning Workspaces should be enabled	Resource logs enable recreating activity trails to use for investigation purposes when a security incident occurs or when your network is compromised.	AuditIfNotExists; Disabled	1.0.1
Resource logs in Azure Stream Analytics 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
Resource logs in Batch accounts 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
Resource logs in Data Lake Analytics 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
Resource logs in Event Hub 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
Resource logs in IoT Hub 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	3.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
Resource logs in Logic Apps 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.1.0
Resource logs in Search services 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
Resource logs in Service Bus 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

LT-4: Enable network logging for security investigation

For more information, see Logging and Threat Detection: LT-4: Enable network logging for security investigation.

Name	Description	Effect(s)	Version
All flow log resources should be in enabled state	Audit for flow log resources to verify if flow log status is enabled. Enabling flow logs allows to log information about IP traffic flowing. It can be used for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more.	Audit; Disabled	1.0.1
Audit flow logs configuration for every virtual network	Audit for virtual network to verify if flow logs are configured. Enabling flow logs allows to log information about IP traffic flowing through virtual network. It can be used for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more.	Audit; Disabled	1.0.1
Enable logging by category group for Application gateways (microsoft.network/applicationgateways) 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 Application gateways (microsoft.network/applicationgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Application gateways (microsoft.network/applicationgateways) 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 Application gateways (microsoft.network/applicationgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Application gateways (microsoft.network/applicationgateways) 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 Application gateways (microsoft.network/applicationgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Bastions (microsoft.network/bastionhosts) 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 Bastions (microsoft.network/bastionhosts).	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for Bastions (microsoft.network/bastionhosts) 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 Bastions (microsoft.network/bastionhosts).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Bastions (microsoft.network/bastionhosts) 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 Bastions (microsoft.network/bastionhosts).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Endpoints (microsoft.cdn/profiles/endpoints) 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 Endpoints (microsoft.cdn/profiles/endpoints).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Endpoints (microsoft.cdn/profiles/endpoints) 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 Endpoints (microsoft.cdn/profiles/endpoints).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Endpoints (microsoft.cdn/profiles/endpoints) 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 Endpoints (microsoft.cdn/profiles/endpoints).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for ExpressRoute circuits (microsoft.network/expressroutecircuits) 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 ExpressRoute circuits (microsoft.network/expressroutecircuits).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for ExpressRoute circuits (microsoft.network/expressroutecircuits) 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 ExpressRoute circuits (microsoft.network/expressroutecircuits).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for ExpressRoute circuits (microsoft.network/expressroutecircuits) 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 ExpressRoute circuits (microsoft.network/expressroutecircuits).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Firewall (microsoft.network/azurefirewalls) 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 Firewall (microsoft.network/azurefirewalls).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Firewalls (microsoft.network/azurefirewalls) 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 Firewalls (microsoft.network/azurefirewalls).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Firewalls (microsoft.network/azurefirewalls) 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 Firewalls (microsoft.network/azurefirewalls).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Firewalls (microsoft.network/azurefirewalls) 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 Firewalls (microsoft.network/azurefirewalls).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Front Door and CDN profiles (microsoft.cdn/profiles) 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 Front Door and CDN profiles (microsoft.cdn/profiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for Front Door and CDN profiles (microsoft.cdn/profiles) 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 Front Door and CDN profiles (microsoft.cdn/profiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Front Door and CDN profiles (microsoft.cdn/profiles) 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 Front Door and CDN profiles (microsoft.cdn/profiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Front Door and CDN profiles (microsoft.network/frontdoors) 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 Front Door and CDN profiles (microsoft.network/frontdoors).	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for Front Door and CDN profiles (microsoft.network/frontdoors) 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 Front Door and CDN profiles (microsoft.network/frontdoors).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Front Door and CDN profiles (microsoft.network/frontdoors) 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 Front Door and CDN profiles (microsoft.network/frontdoors).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Load balancers (microsoft.network/loadbalancers) 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 Load balancers (microsoft.network/loadbalancers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Load balancers (microsoft.network/loadbalancers) 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 Load balancers (microsoft.network/loadbalancers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Load balancers (microsoft.network/loadbalancers) 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 Load balancers (microsoft.network/loadbalancers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.cdn/cdnwebapplicationfirewallpolicies 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 microsoft.cdn/cdnwebapplicationfirewallpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.cdn/cdnwebapplicationfirewallpolicies 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 microsoft.cdn/cdnwebapplicationfirewallpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.cdn/cdnwebapplicationfirewallpolicies 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 microsoft.cdn/cdnwebapplicationfirewallpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/dnsresolverpolicies 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 microsoft.network/dnsresolverpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/dnsresolverpolicies 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 microsoft.network/dnsresolverpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/dnsresolverpolicies 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 microsoft.network/dnsresolverpolicies.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networkmanagers/ipampools 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 microsoft.network/networkmanagers/ipampools.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networkmanagers/ipampools 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 microsoft.network/networkmanagers/ipampools.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networkmanagers/ipampools 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 microsoft.network/networkmanagers/ipampools.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networksecurityperimeters 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 microsoft.network/networksecurityperimeters.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networksecurityperimeters 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 microsoft.network/networksecurityperimeters.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/networksecurityperimeters 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 microsoft.network/networksecurityperimeters.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/p2svpngateways 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 microsoft.network/p2svpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for microsoft.network/p2svpngateways 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 microsoft.network/p2svpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for microsoft.network/p2svpngateways 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 microsoft.network/p2svpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for microsoft.network/vpngateways 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 microsoft.network/vpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/vpngateways 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 microsoft.network/vpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.network/vpngateways 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 microsoft.network/vpngateways.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.networkfunction/azuretrafficcollectors 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 microsoft.networkfunction/azuretrafficcollectors.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.networkfunction/azuretrafficcollectors 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 microsoft.networkfunction/azuretrafficcollectors.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for microsoft.networkfunction/azuretrafficcollectors 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 microsoft.networkfunction/azuretrafficcollectors.	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network Managers (microsoft.network/networkmanagers) 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 Network Managers (microsoft.network/networkmanagers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network Managers (microsoft.network/networkmanagers) 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 Network Managers (microsoft.network/networkmanagers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network Managers (microsoft.network/networkmanagers) 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 Network Managers (microsoft.network/networkmanagers).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network security groups (microsoft.network/networksecuritygroups) 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 Network security groups (microsoft.network/networksecuritygroups).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network security groups (microsoft.network/networksecuritygroups) 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 Network security groups (microsoft.network/networksecuritygroups).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Network security groups (microsoft.network/networksecuritygroups) 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 Network security groups (microsoft.network/networksecuritygroups).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) 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 Public IP addresses (microsoft.network/publicipaddresses).	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) 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 Public IP addresses (microsoft.network/publicipaddresses).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) 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 Public IP addresses (microsoft.network/publicipaddresses).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Public IP Prefixes (microsoft.network/publicipprefixes) 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 Public IP Prefixes (microsoft.network/publicipprefixes).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Public IP Prefixes (microsoft.network/publicipprefixes) 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 Public IP Prefixes (microsoft.network/publicipprefixes).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Public IP Prefixes (microsoft.network/publicipprefixes) 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 Public IP Prefixes (microsoft.network/publicipprefixes).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Traffic Manager profiles (microsoft.network/trafficmanagerprofiles) 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 Traffic Manager profiles (microsoft.network/trafficmanagerprofiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Traffic Manager profiles (microsoft.network/trafficmanagerprofiles) 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 Traffic Manager profiles (microsoft.network/trafficmanagerprofiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Traffic Manager profiles (microsoft.network/trafficmanagerprofiles) 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 Traffic Manager profiles (microsoft.network/trafficmanagerprofiles).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Virtual network gateways (microsoft.network/virtualnetworkgateways) 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 Virtual network gateways (microsoft.network/virtualnetworkgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.2.0
Enable logging by category group for Virtual network gateways (microsoft.network/virtualnetworkgateways) 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 Virtual network gateways (microsoft.network/virtualnetworkgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Virtual network gateways (microsoft.network/virtualnetworkgateways) 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 Virtual network gateways (microsoft.network/virtualnetworkgateways).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Virtual networks (microsoft.network/virtualnetworks) 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 Virtual networks (microsoft.network/virtualnetworks).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Enable logging by category group for Virtual networks (microsoft.network/virtualnetworks) 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 Virtual networks (microsoft.network/virtualnetworks).	DeployIfNotExists; AuditIfNotExists; Disabled	1.1.0
Enable logging by category group for Virtual networks (microsoft.network/virtualnetworks) 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 Virtual networks (microsoft.network/virtualnetworks).	DeployIfNotExists; AuditIfNotExists; Disabled	1.0.0
Flow logs should be configured for every network security group	Audit for network security groups to verify if flow logs are configured. Enabling flow logs allows to log information about IP traffic flowing through network security group. It can be used for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more.	Audit; Disabled	1.1.0
[Preview]: Network traffic data collection agent should be installed on Linux virtual machines	Security Center uses the Microsoft Dependency agent to collect network traffic data from your Azure virtual machines to enable advanced network protection features such as traffic visualization on the network map, network hardening recommendations and specific network threats.	AuditIfNotExists; Disabled	1.0.2-preview
[Preview]: Network traffic data collection agent should be installed on Windows virtual machines	Security Center uses the Microsoft Dependency agent to collect network traffic data from your Azure virtual machines to enable advanced network protection features such as traffic visualization on the network map, network hardening recommendations and specific network threats.	AuditIfNotExists; Disabled	1.0.2-preview
Network Watcher flow logs should have traffic analytics enabled	Traffic analytics analyzes flow logs to provide insights into traffic flow in your Azure cloud. It can be used to visualize network activity across your Azure subscriptions and identify hot spots, identify security threats, understand traffic flow patterns, pinpoint network misconfigurations and more.	Audit; Disabled	1.0.1
Public IP addresses should have resource logs enabled for Azure DDoS Protection	Enable resource logs for public IP addressess in diagnostic settings to stream to a Log Analytics workspace. Get detailed visibility into attack traffic and actions taken to mitigate DDoS attacks via notifications, reports and flow logs.	AuditIfNotExists; DeployIfNotExists; Disabled	1.0.1

LT-5: Centralize security log management and analysis

For more information, see Logging and Threat Detection: LT-5: Centralize security log management and analysis.

Name	Description	Effect(s)	Version
Linux Arc-enabled machines should have Azure Monitor Agent installed	Linux Arc-enabled machines should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. This policy will audit Arc-enabled machines in supported regions. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	1.2.0
Linux virtual machine scale sets should have Azure Monitor Agent installed	Linux virtual machine scale sets should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. This policy will audit virtual machine scale sets with supported OS images in supported regions. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	3.6.0
Linux virtual machines should have Azure Monitor Agent installed	Linux virtual machines should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. This policy will audit virtual machines with supported OS images in supported regions. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	3.6.0
Log Analytics agent should be installed on your Cloud Services (extended support) role instances	Security Center collects data from your Cloud Services (extended support) role instances to monitor for security vulnerabilities and threats.	AuditIfNotExists; Disabled	2.0.0
Saved-queries in Azure Monitor should be saved in customer storage account for logs encryption	Link storage account to Log Analytics workspace to protect saved-queries with storage account encryption. Customer-managed keys are commonly required to meet regulatory compliance and for more control over the access to your saved-queries in Azure Monitor. For more details on the above, see Customer-managed key for saved queries in Azure Monitor.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Windows Arc-enabled machines should have Azure Monitor Agent installed	Windows Arc-enabled machines should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. Windows Arc-enabled machines in supported regions are monitored for Azure Monitor Agent deployment. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	1.4.0
Windows virtual machine scale sets should have Azure Monitor Agent installed	Windows virtual machine scale sets should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. Virtual machine scale sets with supported OS and in supported regions are monitored for Azure Monitor Agent deployment. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	3.5.0
Windows virtual machines should have Azure Monitor Agent installed	Windows virtual machines should be monitored and secured through the deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry data from the guest OS. Windows virtual machines with supported OS and in supported regions are monitored for Azure Monitor Agent deployment. Learn more: https://aka.ms/AMAOverview.	AuditIfNotExists; Disabled	3.5.0

LT-6: Configure log storage retention

For more information, see Logging and Threat Detection: LT-6: Configure log storage retention.

Name	Description	Effect(s)	Version
SQL servers with auditing to storage account destination should be configured with 90 days retention or higher	For incident investigation purposes, we recommend setting the data retention for your SQL Server' auditing to storage account destination to at least 90 days. Confirm that you are meeting the necessary retention rules for the regions in which you are operating. This is sometimes required for compliance with regulatory standards.	AuditIfNotExists; Disabled	3.0.0

NS-1: Establish network segmentation boundaries

For more information, see Network Security: NS-1: Establish network segmentation boundaries.

Name	Description	Effect(s)	Version
All network ports should be restricted on network security groups associated to your virtual machine	Azure Security Center has identified some of your network security groups' inbound rules to be too permissive. Inbound rules should not allow access from 'Any' or 'Internet' ranges. This can potentially enable attackers to target your resources.	AuditIfNotExists; Disabled	3.0.0
Azure Kubernetes Clusters should use Azure CNI	Azure CNI is a prerequisite for some Azure Kubernetes Service features, including Azure network policies, Windows node pools and virtual nodes add-on. Learn more at: https://aka.ms/aks-azure-cni	Audit; Disabled	1.0.1
Internet-facing virtual machines should be protected with network security groups	Protect your virtual machines from potential threats by restricting access to them with network security groups (NSG). Learn more about controlling traffic with NSGs at Azure network security groups overview	AuditIfNotExists; Disabled	3.0.0
[Preview]: Machines should have ports closed that might expose attack vectors	Azure's Terms Of Use prohibit the use of Azure services in ways that could damage, disable, overburden, or impair any Microsoft server, or the network. The exposed ports identified by this recommendation need to be closed for your continued security. For each identified port, the recommendation also provides an explanation of the potential threat.	AuditIfNotExists; Disabled	1.0.0-preview
Non-internet-facing virtual machines should be protected with network security groups	Protect your non-internet-facing virtual machines from potential threats by restricting access with network security groups (NSG). Learn more about controlling traffic with NSGs at Azure network security groups overview	AuditIfNotExists; Disabled	3.0.0
Subnets should be associated with a Network Security Group	Protect your subnet from potential threats by restricting access to it with a Network Security Group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your subnet.	AuditIfNotExists; Disabled	3.0.0
Virtual machines should be connected to an approved virtual network	This policy audits any virtual machine connected to a virtual network that is not approved.	Audit; Deny; Disabled	1.0.0
Virtual networks should use specified virtual network gateway	This policy audits any virtual network if the default route does not point to the specified virtual network gateway.	AuditIfNotExists; Disabled	1.0.0

NS-2: Secure cloud-native services with network controls

For more information, see Network Security: NS-2: Secure cloud-native services with network controls.

Name	Description	Effect(s)	Version
API Management services should use a virtual network	Azure Virtual Network deployment provides enhanced security, isolation and allows you to place your API Management service in a non-internet routable network that you control access to. These networks can then be connected to your on-premises networks using various VPN technologies, which enables access to your backend services within the network and/or on-premises. The developer portal and API gateway, can be configured to be accessible either from the Internet or only within the virtual network.	Audit; Deny; Disabled	1.0.2
API Management should disable public network access to the service configuration endpoints	To improve the security of API Management services, restrict connectivity to service configuration endpoints, like direct access management API, Git configuration management endpoint, or self-hosted gateways configuration endpoint.	AuditIfNotExists; Disabled	1.0.1
App Configuration should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Use Private Endpoints for Azure App Configuration.	Audit; Deny; Disabled	1.0.0
App Configuration should use a SKU that supports private link	When using a supported SKU, Azure Private Link lets you connect your virtual network 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 your app configuration instances instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Use Private Endpoints for Azure App Configuration.	Audit; Deny; Disabled	1.0.0
App Configuration should use private link	Azure Private Link lets you connect your virtual network 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 your app configuration instances instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Use Private Endpoints for Azure App Configuration.	AuditIfNotExists; Disabled	1.0.2
App Service app slots should be injected into a virtual network	Injecting App Service Apps in a virtual network unlocks advanced App Service networking and security features and provides you with greater control over your network security configuration. Learn more at: /azure/app-service/web-sites-integrate-with-vnet.	Audit; Deny; Disabled	1.2.0
App Service app slots should disable public network access	Disabling public network access improves security by ensuring that the App Service is not exposed on the public internet. Creating private endpoints can limit exposure of an App Service. Learn more at: Use Private Endpoints for Apps.	Audit; Disabled; Deny	1.0.0
App Service app slots should enable configuration routing to Azure Virtual Network	By default, app configuration like pulling container images and mounting content storage is not routed through regional VNET integration. For API versions before 2024-11-01, set 'vnetImagePullEnabled' and 'vnetContentShareEnabled' to true. For 2024-11-01+, set 'outboundVnetRouting.imagePullTraffic' and 'outboundVnetRouting.contentShareTraffic' to true. Learn more at https://aka.ms/appservice-vnet-configuration-routing.	Audit; Deny; Disabled	1.1.0
App Service app slots should enable outbound non-RFC 1918 traffic to Azure Virtual Network	By default, regional VNET integration only routes RFC1918 traffic into the virtual network. For API versions before 2024-11-01, set 'vnetRouteAllEnabled' to true to enable all outbound traffic into the Azure Virtual Network. For 2024-11-01+, set 'outboundVnetRouting.applicationTraffic' to true. This enables network security groups and user defined routes for all outbound traffic.	Audit; Deny; Disabled	1.1.0
App Service apps should be injected into a virtual network	Injecting App Service Apps in a virtual network unlocks advanced App Service networking and security features and provides you with greater control over your network security configuration. Learn more at: /azure/app-service/web-sites-integrate-with-vnet.	Audit; Deny; Disabled	3.2.0
App Service apps should disable public network access	Disabling public network access improves security by ensuring that the App Service is not exposed on the public internet. Creating private endpoints can limit exposure of an App Service. Learn more at: Use Private Endpoints for Apps.	Audit; Disabled; Deny	1.1.0
App Service apps should enable configuration routing to Azure Virtual Network	By default, app configuration like pulling container images and mounting content storage is not routed through regional VNET integration. For API versions before 2024-11-01, set 'vnetImagePullEnabled' and 'vnetContentShareEnabled' to true. For 2024-11-01+, set 'outboundVnetRouting.imagePullTraffic' and 'outboundVnetRouting.contentShareTraffic' to true. Learn more at https://aka.ms/appservice-vnet-configuration-routing.	Audit; Deny; Disabled	1.1.0
App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network	By default, regional VNET integration only routes RFC1918 traffic into the virtual network. For API versions before 2024-11-01, set 'vnetRouteAllEnabled' to true to enable all outbound traffic into the Azure Virtual Network. For 2024-11-01+, set 'outboundVnetRouting.applicationTraffic' to true. This enables network security groups and user defined routes for all outbound traffic.	Audit; Deny; Disabled	1.1.0
App Service apps should use a SKU that supports private link	With supported SKUs, Azure Private Link lets you connect your virtual network 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 apps, you can reduce data leakage risks. Learn more about private links at: Use Private Endpoints for Apps.	Audit; Deny; Disabled	4.3.0
App Service apps should use a virtual network service endpoint	Use virtual network service endpoints to restrict access to your app from selected subnets from an Azure virtual network. To learn more about App Service service endpoints, visit https://aka.ms/appservice-vnet-service-endpoint.	AuditIfNotExists; Disabled	2.0.1
App Service apps 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 App Service, you can reduce data leakage risks. Learn more about private links at: Use Private Endpoints for Apps.	AuditIfNotExists; Disabled	1.0.1
App Service Environment apps should not be reachable over public internet	To ensure apps deployed in an App Service Environment are not accessible over public internet, one should deploy App Service Environment with an IP address in virtual network. To set the IP address to a virtual network IP, the App Service Environment must be deployed with an internal load balancer.	Audit; Deny; Disabled	3.0.0
Application Insights components should block log ingestion and querying from public networks	Improve Application Insights security by blocking log ingestion and querying from public networks. Only private-link connected networks will be able to ingest and query logs of this component. Learn more at Use Azure Private Link to connect networks to Azure Monitor.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Application Insights components with Private Link enabled should use Bring Your Own Storage accounts for profiler and debugger.	To support private link and customer-managed key policies, create your own storage account for profiler and debugger. Learn more in /azure/azure-monitor/app/profiler-bring-your-own-storage	Deny; Audit; Disabled	1.0.0
Authorized IP ranges should be defined on Kubernetes Services	Restrict access to the Kubernetes Service Management API by granting API access only to IP addresses in specific ranges. It is recommended to limit access to authorized IP ranges to ensure that only applications from allowed networks can access the cluster.	Audit; Disabled	2.0.1
Automation accounts should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your Automation account resources by creating private endpoints instead. Learn more at: Use Azure Private Link to securely connect networks to Azure Automation.	Audit; Deny; Disabled	1.0.0
Azure AI Search service should use a SKU that supports private link	With supported SKUs of Azure AI Search, Azure Private Link lets you connect your virtual network 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 your Search service, data leakage risks are reduced. Learn more at: Create a private endpoint for a secure connection.	Audit; Deny; Disabled	1.0.1
Azure AI Search services should disable public network access	Disabling public network access improves security by ensuring that your Azure AI Search service is not exposed on the public internet. Creating private endpoints can limit exposure of your Search service. Learn more at: Create a private endpoint for a secure connection.	Audit; Deny; Disabled	1.0.1
Azure AI Services resources should restrict network access	By restricting network access, you can ensure that only allowed networks can access the service. This can be achieved by configuring network rules so that only applications from allowed networks can access the Microsoft Foundry tool.	Audit; Deny; Disabled	3.3.0
Azure AI Services resources should use Azure Private Link	Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform reduces data leakage risks by handling the connectivity between the consumer and services over the Azure backbone network. Learn more about private links at: What is Azure Private Link?	Audit; Disabled	1.0.0
Azure API for FHIR should use private link	Azure API for FHIR should have at least one approved private endpoint connection. Clients in a virtual network can securely access resources that have private endpoint connections through private links. For more information, visit: Configure Private Link for Azure Health Data Services.	Audit; Disabled	1.0.0
Azure Arc Private Link Scopes should be configured with a private endpoint	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 Azure Arc Private Link Scopes, data leakage risks are reduced. Learn more about private links at: Use Azure Private Link to Connect Servers to Azure Arc by Using a Private Endpoint.	Audit; Disabled	1.0.0
Azure Arc Private Link Scopes should disable public network access	Disabling public network access improves security by ensuring that Azure Arc resources cannot connect via the public internet. Creating private endpoints can limit exposure of Azure Arc resources. Learn more at: Use Azure Private Link to Connect Servers to Azure Arc by Using a Private Endpoint.	Audit; Deny; Disabled	1.0.0
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope	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 Azure Arc-enabled servers to an Azure Arc Private Link Scope that is configured with a private endpoint, data leakage risks are reduced. Learn more about private links at: Use Azure Private Link to Connect Servers to Azure Arc by Using a Private Endpoint.	Audit; Deny; Disabled	1.0.0
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope	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 Azure Arc-enabled servers to an Azure Arc Private Link Scope that is configured with a private endpoint, data leakage risks are reduced. Learn more about private links at: Use Azure Private Link to Connect Servers to Azure Arc by Using a Private Endpoint.	Audit; Deny; Disabled	1.0.0
Azure Attestation providers should disable public network access	To improve the security of Azure Attestation Service, ensure that it isn't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in aka.ms/azureattestation. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks.	Audit; Deny; Disabled	1.0.0
Azure Cache for Redis Enterprise should use private link	Private endpoints lets you connect your virtual network to Azure services without a public IP address at the source or destination. By mapping private endpoints to your Azure Cache for Redis Enterprise instances, data leakage risks are reduced. Learn more at: What is Azure Cache for Redis with Azure Private Link?.	AuditIfNotExists; Disabled	1.0.0
Azure Cache for Redis should disable public network access	Disabling public network access improves security by ensuring that the Azure Cache for Redis isn't exposed on the public internet. You can limit exposure of your Azure Cache for Redis by creating private endpoints instead. Learn more at: What is Azure Cache for Redis with Azure Private Link?.	Audit; Deny; Disabled	1.0.0
Azure Cache for Redis should use private link	Private endpoints lets you connect your virtual network to Azure services without a public IP address at the source or destination. By mapping private endpoints to your Azure Cache for Redis instances, data leakage risks are reduced. Learn more at: What is Azure Cache for Redis with Azure Private Link?.	AuditIfNotExists; Disabled	1.0.0
Azure Container Instance container group should deploy into a virtual network	Secure communication between your containers with Azure Virtual Networks. When you specify a virtual network, resources within the virtual network can securely and privately communicate with each other.	Audit; Disabled; Deny	2.0.0
Azure Cosmos DB accounts should have firewall rules	Firewall rules should be defined on your Azure Cosmos DB accounts to prevent traffic from unauthorized sources. Accounts that have at least one IP rule defined with the virtual network filter enabled are deemed compliant. Accounts disabling public access are also deemed compliant.	Audit; Deny; Disabled	2.1.0
Azure Cosmos DB should disable public network access	Disabling public network access improves security by ensuring that your CosmosDB account isn't exposed on the public internet. Creating private endpoints can limit exposure of your CosmosDB account. Learn more at: Blocking public network access during Azure Cosmos DB account creation.	Audit; Deny; Disabled	1.0.0
Azure Data Explorer cluster should use private link	Azure Private Link lets you connect your virtual network 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 your Azure Data Explorer cluster, data leakage risks are reduced. Learn more about private links at: Private endpoints for Azure Data Explorer.	Audit; Disabled	1.0.0
Azure Data Explorer should use a SKU that supports private link	With supported SKUs, Azure Private Link lets you connect your virtual network 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 apps, you can reduce data leakage risks. Learn more about private links at: Use Private Endpoints for Apps.	Audit; Deny; Disabled	1.0.0
Azure Data Factory should use private link	Azure Private Link lets you connect your virtual network 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 Azure Data Factory, data leakage risks are reduced. Learn more about private links at: Azure Private Link for Azure Data Factory.	AuditIfNotExists; Disabled	1.0.0
Azure Databricks Clusters should disable public IP	Disabling public IP of clusters in Azure Databricks Workspaces improves security by ensuring that the clusters aren't exposed on the public internet. Learn more at: Enable secure cluster connectivity.	Audit; Deny; Disabled	1.0.1
Azure Databricks Workspaces should be in a virtual network	Azure Virtual Networks provide enhanced security and isolation for your Azure Databricks Workspaces, as well as subnets, access control policies, and other features to further restrict access. Learn more at: Deploy Azure Databricks in your Azure virtual network (VNet injection).	Audit; Deny; Disabled	1.0.2
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption	Only allow Databricks workspace with Premium Sku that your organization can deploy to support features like Private Link, customer-managed key for encryption. Learn more at: Configure back-end private connectivity to Azure Databricks.	Audit; Deny; Disabled	1.0.1
Azure Databricks Workspaces should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: Azure Private Link concepts.	Audit; Deny; Disabled	1.0.1
Azure Databricks Workspaces 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 Azure Databricks workspaces, you can reduce data leakage risks. Learn more about private links at: Configure back-end private connectivity to Azure Databricks.	Audit; Disabled	1.0.2
Azure Device Update for IoT Hub accounts should use private link	Azure Private Link lets you connect your virtual network 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 Azure Device Update for IoT Hub accounts, data leakage risks are reduced.	AuditIfNotExists; Disabled	1.0.0
Azure Event Grid domains should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Configure private endpoints for topics or domains.	Audit; Deny; Disabled	1.0.0
Azure Event Grid domains should use private link	Azure Private Link lets you connect your virtual network 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 your Event Grid domain instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Configure private endpoints for topics or domains.	Audit; Disabled	1.0.2
Azure Event Grid namespace MQTT broker should use private link	Azure Private Link lets you connect your virtual network 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 your Event Grid namespace instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Configure private endpoints for topics or domains.	Audit; Disabled	1.0.0
Azure Event Grid namespace topic broker should use private link	Azure Private Link lets you connect your virtual network 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 your Event Grid namespace instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Configure private endpoints for topics or domains.	Audit; Disabled	1.0.0
Azure Event Grid namespaces should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Configure private endpoints for topics or domains.	Audit; Deny; Disabled	1.0.0
Azure Event Grid topics should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Configure private endpoints for topics or domains.	Audit; Deny; Disabled	1.0.0
Azure Event Grid topics should use private link	Azure Private Link lets you connect your virtual network 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 your Event Grid topic instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Configure private endpoints for topics or domains.	Audit; Disabled	1.0.2
Azure File Sync should use private link	Creating a private endpoint for the indicated Storage Sync Service resource allows you to address your Storage Sync Service resource from within the private IP address space of your organization's network, rather than through the internet-accessible public endpoint. Creating a private endpoint by itself does not disable the public endpoint.	AuditIfNotExists; Disabled	1.0.0
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link	Azure Front Door Premium supports Azure managed WAF rules and private link to supported Azure origins.	Audit; Deny; Disabled	1.0.0
Azure HDInsight 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 Azure HDInsight clusters, you can reduce data leakage risks. Learn more about private links at: Enable Private Link on an Azure HDInsight cluster.	AuditIfNotExists; Disabled	1.0.0
Azure Health Data Services de-identification service should disable public network access	Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead.	Audit; Disabled	1.0.0
Azure Health Data Services de-identification service should use private link	Azure Health Data Services de-identification service should have at least one approved private endpoint connection. Clients in a virtual network can securely access resources that have private endpoint connections through private links.	Audit; Disabled	1.0.0
Azure Health Data Services workspace should use private link	Health Data Services workspace should have at least one approved private endpoint connection. Clients in a virtual network can securely access resources that have private endpoint connections through private links. For more information, visit: Configure Private Link for Azure Health Data Services.	Audit; Disabled	1.0.0
[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: 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: Integrate Managed HSM with Azure Private Link	Audit; Disabled	1.0.0-preview
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: Integrate Key Vault with Azure Private Link.	Audit; Deny; Disabled	1.1.0
Azure Key Vault should have firewall enabled or public network access disabled	Enable the key vault firewall so that the key vault is not accessible by default to any public IPs or disable public network access for your key vault so that it's not accessible over the public internet. Optionally, you can configure specific IP ranges to limit access to those networks. Learn more at: Network security for Azure Key Vault and Integrate Key Vault with Azure Private Link	Audit; Deny; Disabled	3.3.0
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: Integrate Key Vault with Azure Private Link.	Audit; Deny; Disabled	1.2.1
Azure Kubernetes Service Private Clusters should be enabled	Enable the private cluster feature for your Azure Kubernetes Service cluster to ensure network traffic between your API server and your node pools remains on the private network only. This is a common requirement in many regulatory and industry compliance standards.	Audit; Deny; Disabled	1.0.1
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode	Managed VNet isolation streamlines and automates your network isolation configuration with a built-in, workspace-level Azure Machine Learning managed VNet. The managed VNet secures your managed Azure Machine Learning resources, such as compute instances, compute clusters, serverless compute, and managed online endpoints.	Audit; Deny; Disabled	1.0.0
Azure Machine Learning Computes should be in a virtual network	Azure Virtual Networks provide enhanced security and isolation for your Azure Machine Learning Compute Clusters and Instances, as well as subnets, access control policies, and other features to further restrict access. When a compute is configured with a virtual network, it is not publicly addressable and can only be accessed from virtual machines and applications within the virtual network.	Audit; Disabled	1.0.1
Azure Machine Learning Workspaces should disable public network access	Disabling public network access improves security by ensuring that the Machine Learning Workspaces aren't exposed on the public internet. You can control exposure of your workspaces by creating private endpoints instead. Learn more at: Configure a private endpoint for an Azure Machine Learning workspace.	Audit; Deny; Disabled	2.0.1
Azure Machine Learning workspaces should use private link	Azure Private Link lets you connect your virtual network 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 Azure Machine Learning workspaces, data leakage risks are reduced. Learn more about private links at: Configure a private endpoint for an Azure Machine Learning workspace.	Audit; Disabled	1.0.0
Azure Managed Grafana workspaces should disable public network access	Disabling public network access improves security by ensuring that your Azure Managed Grafana workspace isn't exposed on the public internet. Creating private endpoints can limit exposure of your workspaces.	Audit; Deny; Disabled	1.0.0
Azure Managed Grafana workspaces 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 Managed Grafana, you can reduce data leakage risks.	Audit; Disabled	1.0.1
Azure Monitor Private Link Scope should block access to non private link resources	Azure Private Link lets you connect your virtual networks to Azure resources through a private endpoint to an Azure Monitor Private Link scope (AMPLS). Private Link Access modes are set on your AMPLS to control whether ingestion and query requests from your networks can reach all resources, or only Private Link resources (to prevent data exfiltration). Learn more about private links at: Azure Private Link access modes (private-only vs. open).	Audit; Deny; Disabled	1.0.0
Azure Monitor Private Link Scope 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 Azure Monitor Private Links Scope, you can reduce data leakage risks. Learn more about private links at: Use Azure Private Link to connect networks to Azure Monitor.	AuditIfNotExists; Disabled	1.0.0
Azure Purview accounts should use private link	Azure Private Link lets you connect your virtual network 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 your Azure Purview accounts instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Use private endpoints in the classic Microsoft Purview governance portal.	Audit; Disabled	1.0.0
[Preview]: Azure Recovery Services vaults should disable public network access	Disabling public network access improves security by ensuring that recovery services vault is not exposed on the public internet. Creating private endpoints can limit exposure of recovery services vault. Learn more at: https://aka.ms/AB-PublicNetworkAccess-Deny.	Audit; Deny; Disabled	1.0.0-preview
[Preview]: Azure Recovery Services vaults should use private link for backup	Azure Private Link lets you connect your virtual network 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 Azure Recovery Services vaults, data leakage risks are reduced. Learn more about private links at: Create and use private endpoints for Azure Backup.	Audit; Disabled	2.0.0-preview
Azure Service Bus namespaces should use private link	Azure Private Link lets you connect your virtual network 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 Service Bus namespaces, data leakage risks are reduced. Learn more at: Allow access to Azure Service Bus namespaces via private endpoints.	AuditIfNotExists; Disabled	1.0.0
Azure SignalR Service should disable public network access	To improve the security of Azure SignalR Service resource, ensure that it isn't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in Configure network access control. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks.	Audit; Deny; Disabled	1.2.0
Azure SignalR Service should use a Private Link enabled SKU	Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination which protect your resources against public data leakage risks. The policy limits you to Private Link enabled SKUs for Azure SignalR Service. Learn more about private link at: Use private endpoints.	Audit; Deny; Disabled	1.0.0
Azure SignalR Service should use private link	Azure Private Link lets you connect your virtual network 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 your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: Use private endpoints.	Audit; Disabled	1.0.0
Azure Spring Cloud should use network injection	Azure Spring Cloud instances should use virtual network injection for the following purposes: 1. Isolate Azure Spring Cloud from Internet. 2. Enable Azure Spring Cloud to interact with systems in either on premises data centers or Azure service in other virtual networks. 3. Empower customers to control inbound and outbound network communications for Azure Spring Cloud.	Audit; Disabled; Deny	1.2.0
Azure SQL Managed Instances should disable public network access	Disabling public network access (public endpoint) on Azure SQL Managed Instances improves security by ensuring that they can only be accessed from inside their virtual networks or via Private Endpoints. To learn more about public network access, visit Configure Public Endpoint.	Audit; Deny; Disabled	1.0.0
Azure Synapse workspaces should allow outbound data traffic only to approved targets	Increase security of your Synapse workspace by allowing outbound data traffic only to approved targets. This helps prevention against data exfiltration by validating the target before sending data.	Audit; Disabled; Deny	1.0.0
Azure Synapse workspaces should disable public network access	Disabling public network access improves security by ensuring that the Synapse workspace isn't exposed on the public internet. Creating private endpoints can limit exposure of your Synapse workspaces. Learn more at: Azure Synapse Analytics connectivity settings.	Audit; Deny; Disabled	1.0.0
Azure Synapse workspaces should use private link	Azure Private Link lets you connect your virtual network 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 Azure Synapse workspace, data leakage risks are reduced. Learn more about private links at: Connect to your Azure Synapse workspace using private links.	Audit; Disabled	1.0.1
Azure Virtual Desktop hostpools should disable public network access	Disabling public network access improves security and keeps your data safe by ensuring that access to the Azure Virtual Desktop service is not exposed to the public internet. Learn more at: Set up Private Link with Azure Virtual Desktop.	Audit; Deny; Disabled	1.0.0
Azure Virtual Desktop hostpools should disable public network access only on session hosts	Disabling public network access for your Azure Virtual Desktop hostpool session hosts, but allowing public access for end users improves security by limiting exposure to the public internet. Learn more at: Set up Private Link with Azure Virtual Desktop.	Audit; Deny; Disabled	1.0.0
Azure Virtual Desktop service should use private link	Using Azure Private Link with your Azure Virtual Desktop resources can improve security and keep your data safe. Learn more about private links at: Set up Private Link with Azure Virtual Desktop.	Audit; Disabled	1.0.0
Azure Virtual Desktop workspaces should disable public network access	Disabling public network access for your Azure Virtual Desktop workspace resource prevents the feed from being accessible over the public internet. Allowing only private network access improves security and keeps your data safe. Learn more at: Set up Private Link with Azure Virtual Desktop.	Audit; Deny; Disabled	1.0.0
Azure Web PubSub Service should disable public network access	Disabling public network access improves security by ensuring that Azure Web PubSub service isn't exposed on the public internet. Creating private endpoints can limit exposure of Azure Web PubSub service. Learn more at: Azure Web PubSub network access control.	Audit; Deny; Disabled	1.0.0
Azure Web PubSub Service should use a SKU that supports private link	With supported SKU, Azure Private Link lets you connect your virtual network 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 Azure Web PubSub service, you can reduce data leakage risks. Learn more about private links at: Azure Web PubSub service private endpoint.	Audit; Deny; Disabled	1.0.0
Azure Web PubSub Service 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 your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: Azure Web PubSub service private endpoint.	Audit; Disabled	1.0.0
Bot Service should have isolated mode enabled	Bots should be set to 'isolated only' mode. This setting configures Bot Service channels that require traffic over the public internet to be disabled.	Audit; Deny; Disabled	2.1.0
Bot Service should have public network access disabled	Bots should be set to 'isolated only' mode. This setting configures Bot Service channels that require traffic over the public internet to be disabled.	Audit; Deny; Disabled	1.0.0
BotService resources should use private link	Azure Private Link lets you connect your virtual network 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 your BotService resource, data leakage risks are reduced.	Audit; Disabled	1.0.0
Container App environments should use network injection	Container Apps environments should use virtual network injection to: 1.Isolate Container Apps from the public internet 2.Enable network integration with resources on-premises or in other Azure virtual networks 3.Achieve more granular control over network traffic flowing to and from the environment.	Audit; Disabled; Deny	1.0.2
Container Apps environment should disable public network access	Disable public network access to improve security by exposing the Container Apps environment through an internal load balancer. This removes the need for a public IP address and prevents internet access to all Container Apps within the environment.	Audit; Deny; Disabled	1.1.0
Container Apps should disable external network access	Disable external network access to your Container Apps by enforcing internal-only ingress. This will ensure inbound communication for Container Apps is limited to callers within the Container Apps environment.	Audit; Deny; Disabled	1.1.0
Container registries should have SKUs that support Private Links	Azure Private Link lets you connect your virtual network 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 your container registries instead of the entire service, data leakage risks are reduced. Learn more at: Set Up Private Endpoint with Private Link for ACR.	Audit; Deny; Disabled	1.0.0
Container registries should not allow unrestricted network access	Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: Set Up Private Endpoint with Private Link for ACR, Configure Public Registry Access in Azure and Restrict Access to Azure Container Registry Using Service Endpoints.	Audit; Deny; Disabled	2.0.0
Container registries should use private link	Azure Private Link lets you connect your virtual network 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 your container registries instead of the entire service, you'll also be protected against data leakage risks. Learn more at: Set Up Private Endpoint with Private Link for ACR.	Audit; Disabled	1.0.1
[Preview]: Container Registry should use a virtual network service endpoint	This policy audits any Container Registry not configured to use a virtual network service endpoint.	Audit; Disabled	1.0.0-preview
Cosmos DB should use a virtual network service endpoint	This policy audits any Cosmos DB not configured to use a virtual network service endpoint.	Audit; Disabled	1.0.0
CosmosDB accounts should use private link	Azure Private Link lets you connect your virtual network 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 your CosmosDB account, data leakage risks are reduced. Learn more about private links at: Configure Azure Private Link for an Azure Cosmos DB account.	Audit; Disabled	1.0.0
Disk access resources should use private link	Azure Private Link lets you connect your virtual network 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 diskAccesses, data leakage risks are reduced. Learn more about private links at: Restrict import/export access to managed disks.	AuditIfNotExists; Disabled	1.0.0
ElasticSan should disable public network access	Disable public network access for your ElasticSan so that it's not accessible over the public internet. This can reduce data leakage risks.	Audit; Deny; Disabled	1.0.0
Event Hub Namespaces should disable public network access	Azure Event Hub should have public network access disabled. Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Allow access to Azure Event Hubs namespaces via private endpoints	Audit; Deny; Disabled	1.0.0
Event Hub namespaces should use private link	Azure Private Link lets you connect your virtual network 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 Event Hub namespaces, data leakage risks are reduced. Learn more at: Allow access to Azure Event Hubs namespaces via private endpoints.	AuditIfNotExists; Disabled	1.0.0
Event Hub should use a virtual network service endpoint	This policy audits any Event Hub not configured to use a virtual network service endpoint.	AuditIfNotExists; Disabled	1.0.0
Function app slots should disable public network access	Disabling public network access improves security by ensuring that the Function app is not exposed on the public internet. Creating private endpoints can limit exposure of a Function App. Learn more at: Use Private Endpoints for Apps.	Audit; Disabled; Deny	1.1.0
Function apps should disable public network access	Disabling public network access improves security by ensuring that the Function app is not exposed on the public internet. Creating private endpoints can limit exposure of a Function App. Learn more at: Use Private Endpoints for Apps.	Audit; Disabled; Deny	1.1.0
IoT Central should use private link	Azure Private Link lets you connect your virtual network 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 your IoT Central application instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: Network security using private endpoints in IoT Central.	Audit; Deny; Disabled	1.0.0
IoT Hub device provisioning service instances should disable public network access	Disabling public network access improves security by ensuring that IoT Hub device provisioning service instance isn't exposed on the public internet. Creating private endpoints can limit exposure of the IoT Hub device provisioning instances. Learn more at: Virtual network connections for DPS.	Audit; Deny; Disabled	1.0.0
IoT Hub device provisioning service instances should use private link	Azure Private Link lets you connect your virtual network 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 the IoT Hub device provisioning service, data leakage risks are reduced. Learn more about private links at: Virtual network connections for DPS.	Audit; Disabled	1.0.0
IP firewall rules on Azure Synapse workspaces should be removed	Removing all IP firewall rules improves security by ensuring your Azure Synapse workspace can only be accessed from a private endpoint. This configuration audits creation of firewall rules that allow public network access on the workspace.	Audit; Disabled	1.0.0
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
Log Analytics workspaces should block log ingestion and querying from public networks	Improve workspace security by blocking log ingestion and querying from public networks. Only private-link connected networks will be able to ingest and query logs on this workspace. Learn more at Use Azure Private Link to connect networks to Azure Monitor.	audit; Audit; deny; Deny; disabled; Disabled	1.1.0
Managed disks should disable public network access	Disabling public network access improves security by ensuring that a managed disk isn't exposed on the public internet. Creating private endpoints can limit exposure of managed disks. Learn more at: Restrict import/export access to managed disks.	Audit; Deny; Disabled	2.1.0
Managed workspace virtual network on Azure Synapse workspaces should be enabled	Enabling a managed workspace virtual network ensures that your workspace is network isolated from other workspaces. Data integration and Spark resources deployed in this virtual network also provides user level isolation for Spark activities.	Audit; Deny; Disabled	1.0.0
MariaDB server should use a virtual network service endpoint	Virtual network based firewall rules are used to enable traffic from a specific subnet to Azure Database for MariaDB while ensuring the traffic stays within the Azure boundary. This policy provides a way to audit if the Azure Database for MariaDB has virtual network service endpoint being used.	AuditIfNotExists; Disabled	1.0.2
MySQL server should use a virtual network service endpoint	Virtual network based firewall rules are used to enable traffic from a specific subnet to Azure Database for MySQL while ensuring the traffic stays within the Azure boundary. This policy provides a way to audit if the Azure Database for MySQL has virtual network service endpoint being used.	AuditIfNotExists; Disabled	1.0.2
PostgreSQL server should use a virtual network service endpoint	Virtual network based firewall rules are used to enable traffic from a specific subnet to Azure Database for PostgreSQL while ensuring the traffic stays within the Azure boundary. This policy provides a way to audit if the Azure Database for PostgreSQL has virtual network service endpoint being used.	AuditIfNotExists; Disabled	1.0.2
Private endpoint connections on Automation Accounts should be enabled	Private endpoint connections allow secure communication by enabling private connectivity to Automation accounts without a need for public IP addresses at the source or destination. Learn more about private endpoints in Azure Automation at /azure/automation/how-to/private-link-security	AuditIfNotExists; Disabled	1.0.0
Private endpoint connections on Azure SQL Database should be enabled	Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database.	Audit; Disabled	1.1.0
Private endpoint connections on Batch accounts should be enabled	Private endpoint connections allow secure communication by enabling private connectivity to Batch accounts without a need for public IP addresses at the source or destination. Learn more about private endpoints in Batch at /azure/batch/private-connectivity.	AuditIfNotExists; Disabled	1.0.0
Private endpoint should be enabled for IoT Hub	Private endpoint connections enforce secure communication by enabling private connectivity to IoT Hub. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure.	Audit; Disabled	1.0.0
Private endpoint should be enabled for MariaDB servers	Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MariaDB. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure.	AuditIfNotExists; Disabled	1.0.2
Private endpoint should be enabled for MySQL servers	Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MySQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure.	AuditIfNotExists; Disabled	1.0.2
Private endpoint should be enabled for PostgreSQL servers	Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for PostgreSQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure.	AuditIfNotExists; Disabled	1.0.2
Public network access for Azure Device Update for IoT Hub accounts should be disabled	Disabling the public network access property improves security by ensuring your Azure Device Update for IoT Hub accounts can only be accessed from a private endpoint.	Audit; Deny; Disabled	1.0.0
Public network access on Azure Data Explorer should be disabled	Disabling the public network access property improves security by ensuring Azure Data Explorer can only be accessed from a private endpoint. This configuration denies all logins that match IP or virtual network based firewall rules.	Audit; Deny; Disabled	1.0.0
Public network access on Azure Data Factory should be disabled	Disabling the public network access property improves security by ensuring your Azure Data Factory can only be accessed from a private endpoint.	Audit; Deny; Disabled	1.0.0
Public network access on Azure IoT Hub should be disabled	Disabling the public network access property improves security by ensuring your Azure IoT Hub can only be accessed from a private endpoint.	Audit; Deny; Disabled	1.0.0
Public network access on Azure SQL Database should be disabled	Disabling the public network access property improves security by ensuring your Azure SQL Database can only be accessed from a private endpoint. This configuration denies all logins that match IP or virtual network based firewall rules.	Audit; Deny; Disabled	1.1.0
Public network access should be disabled for Azure File Sync	Disabling the public endpoint allows you to restrict access to your Storage Sync Service resource to requests destined to approved private endpoints on your organization's network. There is nothing inherently insecure about allowing requests to the public endpoint, however, you may wish to disable it to meet regulatory, legal, or organizational policy requirements. You can disable the public endpoint for a Storage Sync Service by setting the incomingTrafficPolicy of the resource to AllowVirtualNetworksOnly.	Audit; Deny; Disabled	1.0.0
Public network access should be disabled for Batch accounts	Disabling public network access on a Batch account improves security by ensuring your Batch account can only be accessed from a private endpoint. Learn more about disabling public network access at Use private endpoints with Azure Batch accounts.	Audit; Deny; Disabled	1.0.0
Public network access should be disabled for Container registries	Disabling public network access improves security by ensuring that container registries are not exposed on the public internet. Creating private endpoints can limit exposure of container registry resources. Learn more at: Configure Public Registry Access in Azure and Set Up Private Endpoint with Private Link for ACR.	Audit; Deny; Disabled	1.0.0
Public network access should be disabled for IoT Central	To improve the security of IoT Central, ensure that it isn't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in Create a private endpoint for Azure IoT Central. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks.	Audit; Deny; Disabled	1.0.0
Public network access should be disabled for MariaDB servers	Disable the public network access property to improve security and ensure your Azure Database for MariaDB can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules.	Audit; Deny; Disabled	2.0.0
Public network access should be disabled for MySQL flexible servers	Disabling the public network access property improves security by ensuring your Azure Database for MySQL flexible servers can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range and denies all logins that match IP or virtual network-based firewall rules.	Audit; Deny; Disabled	2.3.0
Public network access should be disabled for MySQL servers	Disable the public network access property to improve security and ensure your Azure Database for MySQL can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules.	Audit; Deny; Disabled	2.0.0
Public network access should be disabled for PostgreSQL flexible servers	Disabling the public network access property improves security by ensuring your Azure Database for PostgreSQL flexible servers can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range and denies all logins that match IP based firewall rules.	Audit; Deny; Disabled	3.1.0
Public network access should be disabled for PostgreSQL servers	Disable the public network access property to improve security and ensure your Azure Database for PostgreSQL can only be accessed from a private endpoint. This configuration disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules.	Audit; Deny; Disabled	2.0.1
[Preview]: Recovery Services vaults should use private link	Azure Private Link lets you connect your virtual network 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 Azure Recovery Services vaults, data leakage risks are reduced. Learn more about private links for Azure Site Recovery at: Enable replication for on-premises machines with private endpoints and Enable replication for private endpoints in Azure Site Recovery.	Audit; Disabled	1.0.0-preview
Service Bus Namespaces should disable public network access	Azure Service Bus should have public network access disabled. Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can limit exposure of your resources by creating private endpoints instead. Learn more at: Allow access to Azure Service Bus namespaces via private endpoints	Audit; Deny; Disabled	1.1.0
SQL Server Integration Services integration runtimes on Azure Data Factory should be joined to a virtual network	Azure Virtual Network deployment provides enhanced security and isolation for your SQL Server Integration Services integration runtimes on Azure Data Factory, as well as subnets, access control policies, and other features to further restrict access.	Audit; Deny; Disabled	2.3.0
SQL Server should use a virtual network service endpoint	This policy audits any SQL Server not configured to use a virtual network service endpoint.	AuditIfNotExists; Disabled	1.0.0
Storage account public access should be disallowed	Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it.	audit; Audit; deny; Deny; disabled; Disabled	3.1.1
Storage accounts should allow access from trusted Microsoft services	Some Microsoft services that interact with storage accounts operate from networks that can't be granted access through network rules. To help this type of service work as intended, allow the set of trusted Microsoft services to bypass the network rules. These services will then use strong authentication to access the storage account.	Audit; Deny; Disabled	1.0.0
Storage accounts should disable public network access	To improve the security of Storage Accounts, ensure that they aren't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in Storage account public network access. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks.	Audit; Deny; Disabled	1.0.1
Storage accounts should restrict network access	Network access to storage accounts should be restricted. Configure network rules so only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges	Audit; Deny; Disabled	1.1.1
Storage Accounts should restrict network access through network ACL bypass configuration only.	To improve the security of Storage Accounts, enable access only through network ACL bypass. This policy should be used in combination with a private endpoint for storage account access.	Audit; Deny; Disabled	1.0.0
Storage accounts should restrict network access using virtual network rules	Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts.	Audit; Deny; Disabled	1.0.1
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)	Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts.	Audit; Deny; Disabled	1.0.0
Storage Accounts should use a virtual network service endpoint	This policy audits any Storage Account not configured to use a virtual network service endpoint.	Audit; Disabled	1.0.0
Storage accounts should use private link	Azure Private Link lets you connect your virtual network 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 your storage account, data leakage risks are reduced. Learn more about private links at - What is Azure Private Link?	AuditIfNotExists; Disabled	2.0.0
Storage accounts should use private link (excluding storage accounts created by Databricks)	Azure Private Link lets you connect your virtual network 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 your storage account, data leakage risks are reduced. Learn more about private links at - What is Azure Private Link?	AuditIfNotExists; Disabled	1.0.0
Synapse managed private endpoints should only connect to resources in approved Azure Active Directory tenants	Protect your Synapse workspace by only allowing connections to resources in approved Azure Active Directory (Azure AD) tenants. The approved Azure AD tenants can be defined during policy assignment.	Audit; Disabled; Deny	1.0.0
VM Image Builder templates should use private link	Azure Private Link lets you connect your virtual network 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 your VM Image Builder building resources, data leakage risks are reduced. Learn more about private links at: Azure VM Image Builder networking options - Deploy using an existing VNET.	Audit; Disabled; Deny	1.1.0

NS-3: Deploy firewall at the edge of enterprise network

For more information, see Network Security: NS-3: Deploy firewall at the edge of enterprise network.

Name	Description	Effect(s)	Version
IP Forwarding on your virtual machine should be disabled	Enabling IP forwarding on a virtual machine's NIC allows the machine to receive traffic addressed to other destinations. IP forwarding is rarely required (e.g., when using the VM as a network virtual appliance), and therefore, this should be reviewed by the network security team.	AuditIfNotExists; Disabled	3.0.0
Management ports of virtual machines should be protected with just-in-time network access control	Possible network Just In Time (JIT) access will be monitored by Azure Security Center as recommendations	AuditIfNotExists; Disabled	3.0.0
Management ports should be closed on your virtual machines	Open remote management ports are exposing your VM to a high level of risk from Internet-based attacks. These attacks attempt to brute force credentials to gain admin access to the machine.	AuditIfNotExists; Disabled	3.0.0
[Preview]: All Internet traffic should be routed via your deployed Azure Firewall	Azure Security Center has identified that some of your subnets aren't protected with a next generation firewall. Protect your subnets from potential threats by restricting access to them with Azure Firewall or a supported next generation firewall	AuditIfNotExists; Disabled	3.0.0-preview

NS-5: Deploy DDOS protection

For more information, see Network Security: NS-5: Deploy DDOS protection.

Name	Description	Effect(s)	Version
Azure DDoS Protection should be enabled	DDoS protection should be enabled for all virtual networks with a subnet that is part of an application gateway with a public IP.	AuditIfNotExists; Disabled	3.0.1
Enable Rate Limit rule to protect against DDoS attacks on Azure Front Door WAF	The Azure Web Application Firewall (WAF) rate limit rule for Azure Front Door controls the number of requests allowed from a particular client IP address to the application during a rate limit duration.	Audit; Deny; Disabled	1.0.0
Virtual networks should be protected by Azure DDoS Protection	Protect your virtual networks against volumetric and protocol attacks with Azure DDoS Protection. For more information, visit Azure DDoS Protection Overview.	Modify; Audit; Disabled	1.0.1

NS-6: Deploy web application firewall

For more information, see Network Security: NS-6: Deploy web application firewall.

Name	Description	Effect(s)	Version
Azure Front Door Standard or Premium (Plus WAF) should have resource logs enabled	Enable Resource logs for Azure Front Door Standard or Premium (plus WAF) and stream to a Log Analytics workspace. Get detailed visibility into inbound web traffic and actions taken to mitigate attacks.	AuditIfNotExists; Disabled	1.0.0
Azure Web Application Firewall on Azure Application Gateway should have request body inspection enabled	Ensure that Web Application Firewalls associated to Azure Application Gateways have Request body inspection enabled. This allows the WAF to inspect properties within the HTTP body that may not be evaluated in the HTTP headers, cookies, or URI.	Audit; Deny; Disabled	1.0.0
Azure Web Application Firewall on Azure Front Door should have request body inspection enabled	Ensure that Web Application Firewalls associated to Azure Front Doors have request body inspection enabled. This allows the WAF to inspect properties within the HTTP body that may not be evaluated in the HTTP headers, cookies, or URI.	Audit; Deny; Disabled	1.0.0
Azure Web Application Firewall should be enabled for Azure Front Door entry-points	Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries/regions, IP address ranges, and other http(s) parameters via custom rules.	Audit; Deny; Disabled	1.0.2
Enable Rate Limit rule to protect against DDoS attacks on Azure Front Door WAF	The Azure Web Application Firewall (WAF) rate limit rule for Azure Front Door controls the number of requests allowed from a particular client IP address to the application during a rate limit duration.	Audit; Deny; Disabled	1.0.0
Migrate WAF from WAF Config to WAF Policy on Application Gateway	If you have WAF Config instead of WAF Policy, then you may want to move to the new WAF Policy. Going forward, the firewall policy will support WAF policy settings, managed rulesets, exclusions, and disabled rule-groups.	Audit; Deny; Disabled	1.0.0
Web Application Firewall (WAF) should be enabled for Application Gateway	Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries/regions, IP address ranges, and other http(s) parameters via custom rules.	Audit; Deny; Disabled	2.0.0
Web Application Firewall (WAF) should use the specified mode for Application Gateway	Mandates the use of 'Detection' or 'Prevention' mode to be active on all Web Application Firewall policies for Application Gateway.	Audit; Deny; Disabled	1.0.0
Web Application Firewall (WAF) should use the specified mode for Azure Front Door Service	Mandates the use of 'Detection' or 'Prevention' mode to be active on all Web Application Firewall policies for Azure Front Door Service.	Audit; Deny; Disabled	1.0.0

NS-8: Detect and disable insecure services and protocols

For more information, see Network Security: NS-8: Detect and disable insecure services and protocols.

Name	Description	Effect(s)	Version
App Service apps should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	2.2.0
Azure VPN gateways should not use 'basic' SKU	This policy ensures that VPN gateways do not use 'basic' SKU.	Audit; Disabled	1.0.0
Function apps should use the latest TLS version	Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.	AuditIfNotExists; Disabled	2.3.0

PA-1: Separate and limit highly privileged/administrative users

For more information, see Privileged Access: PA-1: Separate and limit highly privileged/administrative users.

Name	Description	Effect(s)	Version
A maximum of 3 owners should be designated for your subscription	It is recommended to designate up to 3 subscription owners in order to reduce the potential for breach by a compromised owner.	AuditIfNotExists; Disabled	3.0.0
Blocked accounts with owner permissions on Azure resources should be removed	Deprecated accounts with owner permissions should be removed from your subscription. Deprecated accounts are accounts that have been blocked from signing in.	AuditIfNotExists; Disabled	1.0.0
Guest accounts with owner permissions on Azure resources should be removed	External accounts with owner permissions should be removed from your subscription in order to prevent unmonitored access.	AuditIfNotExists; Disabled	1.0.0
[Preview]: Multi-User Authorization (MUA) must be enabled for Recovery Services Vaults.	This policy audits if Multi-User Authorization (MUA) is enabled for Recovery Services Vaults. MUA helps in securing your Recovery Services Vaults by adding an additional layer of protection to critical operations. To learn more, visit https://aka.ms/MUAforRSV.	Audit; Disabled	1.0.0-preview
There should be more than one owner assigned to your subscription	It is recommended to designate more than one subscription owner in order to have administrator access redundancy.	AuditIfNotExists; Disabled	3.0.0

PA-2: Avoid standing access for user accounts and permissions

For more information, see Privileged Access: PA-2: Avoid standing access for user accounts and permissions.

Name	Description	Effect(s)	Version
Management ports of virtual machines should be protected with just-in-time network access control	Possible network Just In Time (JIT) access will be monitored by Azure Security Center as recommendations	AuditIfNotExists; Disabled	3.0.0

PA-4: Review and reconcile user access regularly

For more information, see Privileged Access: PA-4: Review and reconcile user access regularly.

Name	Description	Effect(s)	Version
Blocked accounts with owner permissions on Azure resources should be removed	Deprecated accounts with owner permissions should be removed from your subscription. Deprecated accounts are accounts that have been blocked from signing in.	AuditIfNotExists; Disabled	1.0.0
Blocked accounts with read and write permissions on Azure resources should be removed	Deprecated accounts should be removed from your subscriptions. Deprecated accounts are accounts that have been blocked from signing in.	AuditIfNotExists; Disabled	1.0.0
Guest accounts with owner permissions on Azure resources should be removed	External accounts with owner permissions should be removed from your subscription in order to prevent unmonitored access.	AuditIfNotExists; Disabled	1.0.0
Guest accounts with read permissions on Azure resources should be removed	External accounts with read privileges should be removed from your subscription in order to prevent unmonitored access.	AuditIfNotExists; Disabled	1.0.0
Guest accounts with write permissions on Azure resources should be removed	External accounts with write privileges should be removed from your subscription in order to prevent unmonitored access.	AuditIfNotExists; Disabled	1.0.0

PA-7: Follow just enough administration (least privilege) principle

For more information, see Privileged Access: PA-7: Follow just enough administration (least privilege) principle.

Name	Description	Effect(s)	Version
All authorization rules except RootManageSharedAccessKey should be removed from Event Hub namespace	Event Hub clients should not use a namespace level access policy that provides access to all queues and topics in a namespace. To align with the least privilege security model, you should create access policies at the entity level for queues and topics to provide access to only the specific entity	Audit; Deny; Disabled	1.0.1
All authorization rules except RootManageSharedAccessKey should be removed from Service Bus namespace	Service Bus clients should not use a namespace level access policy that provides access to all queues and topics in a namespace. To align with the least privilege security model, you should create access policies at the entity level for queues and topics to provide access to only the specific entity	Audit; Deny; Disabled	1.0.1
API Management subscriptions should not be scoped to all APIs	API Management subscriptions should be scoped to a product or an individual API instead of all APIs, which could result in an excessive data exposure.	Audit; Disabled; Deny	1.1.0
Audit usage of custom RBAC roles	Audit built-in roles such as 'Owner, Contributer, Reader' instead of custom RBAC roles, which are error prone. Using custom roles is treated as an exception and requires a rigorous review and threat modeling	Audit; Disabled	1.0.1
Authorization rules on the Event Hub instance should be defined	Audit existence of authorization rules on Event Hub entities to grant least-privileged access	AuditIfNotExists; Disabled	1.0.0
Azure Key Vault should use RBAC permission model	Enable RBAC permission model across Key Vaults. Learn more at: Migrate from vault access policy to an Azure role-based access control permission model	Audit; Deny; Disabled	1.0.1
Azure Kubernetes Service Clusters should disable Command Invoke	Disabling command invoke can enhance the security by avoiding bypass of restricted network access or Kubernetes role-based access control	Audit; Disabled	1.0.1
Kubernetes clusters should ensure that the cluster-admin role is only used where required	The role 'cluster-admin' provides wide-ranging powers over the environment and should be used only where and when needed.	Audit; Disabled	1.1.0
Kubernetes clusters should minimize wildcard use in role and cluster role	Using wildcards '*' can be a security risk because it grants broad permissions that may not be necessary for a specific role. If a role has too many permissions, it could potentially be abused by an attacker or compromised user to gain unauthorized access to resources in the cluster.	Audit; Disabled	1.1.0
Role-Based Access Control (RBAC) should be used on Kubernetes Services	To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies.	Audit; Disabled	1.1.0

PV-2: Audit and enforce secure configurations

For more information, see Posture and Vulnerability Management: PV-2: Audit and enforce secure configurations.

Name	Description	Effect(s)	Version
[Preview]: [Image Integrity] Kubernetes clusters should only use images signed by notation	Use images signed by notation to ensure that images come from trusted sources and will not be maliciously modified. For more info, visit https://aka.ms/aks/image-integrity	Audit; Disabled	1.1.0-preview
API Management direct management endpoint should not be enabled	The direct management REST API in Azure API Management bypasses Azure Resource Manager role-based access control, authorization, and throttling mechanisms, thus increasing the vulnerability of your service.	Audit; Disabled; Deny	1.0.2
App Service app slots should have remote debugging turned off	Remote debugging requires inbound ports to be opened on an App Service app. Remote debugging should be turned off.	AuditIfNotExists; Disabled	1.0.1
App Service app slots should not have CORS configured to allow every resource to access your apps	Cross-Origin Resource Sharing (CORS) should not allow all domains to access your app. Allow only required domains to interact with your app.	AuditIfNotExists; Disabled	1.0.0
App Service app slots should use latest 'HTTP Version'	Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version.	AuditIfNotExists; Disabled	1.0.0
App Service app slots that use PHP should use a specified 'PHP version'	Periodically, newer versions are released for PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for App Service apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a PHP version that meets your requirements.	AuditIfNotExists; Disabled	1.0.0
App Service app slots that use Python should use a specified 'Python version'	Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for App Service apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Python version that meets your requirements.	AuditIfNotExists; Disabled	1.0.0
App Service apps should have Client Certificates (Incoming client certificates) enabled	Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. This policy applies to apps with Http version set to 1.1.	AuditIfNotExists; Disabled	1.0.0
App Service apps should have remote debugging turned off	Remote debugging requires inbound ports to be opened on an App Service app. Remote debugging should be turned off.	AuditIfNotExists; Disabled	2.0.0
App Service apps should not have CORS configured to allow every resource to access your apps	Cross-Origin Resource Sharing (CORS) should not allow all domains to access your app. Allow only required domains to interact with your app.	AuditIfNotExists; Disabled	2.0.0
App Service apps should use latest 'HTTP Version'	Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version.	AuditIfNotExists; Disabled	4.0.0
App Service apps that use Java should use a specified 'Java version'	Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for App Service apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Java version that meets your requirements.	AuditIfNotExists; Disabled	3.1.0
App Service apps that use PHP should use a specified 'PHP version'	Periodically, newer versions are released for PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for App Service apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a PHP version that meets your requirements.	AuditIfNotExists; Disabled	3.2.0
App Service apps that use Python should use a specified 'Python version'	Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for App Service apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Python version that meets your requirements.	AuditIfNotExists; Disabled	4.1.0
[Preview]: Automanage Configuration Profile Assignment should be Conformant	Resources managed by Automanage should have a status of Conformant or ConformantCorrected.	AuditIfNotExists; Disabled	1.0.0-preview
Azure API Management platform version should be stv2	Azure API Management stv1 compute platform version will be retired effective 31 August 2024, and these instances should be migrated to stv2 compute platform for continued support. Learn more at API Management stv1 platform retirement - Global Azure cloud (August 2024)	Audit; Deny; Disabled	1.0.0
Azure Arc enabled Kubernetes clusters should have the Azure Policy extension installed	The Azure Policy extension for Azure Arc provides at-scale enforcements and safeguards on your Arc enabled Kubernetes clusters in a centralized, consistent manner. Learn more at Understand Azure Policy for Kubernetes clusters.	AuditIfNotExists; Disabled	1.1.0
Azure Data Factory should use a Git repository for source control	Configure only your development data factory with Git integration. Changes to test and production should be deployed via CI/CD and should NOT have Git integration. DO NOT apply this policy on your QA / Test / Production data factories.	Audit; Deny; Disabled	1.0.1
Azure Machine Learning Compute Instance should have idle shutdown.	Having an idle shutdown schedule reduces cost by shutting down computes that are idle after a pre-determined period of activity.	Audit; Deny; Disabled	1.0.0
Azure Machine Learning compute instances should be recreated to get the latest software updates	Ensure Azure Machine Learning compute instances run on the latest available operating system. Security is improved and vulnerabilities reduced by running with the latest security patches. For more information, visit https://aka.ms/azureml-ci-updates/.	Audit; Disabled	1.0.3
Azure Machine Learning workspaces should enable V1LegacyMode to support network isolation backward compatibility	Azure ML is making a transition to a new V2 API platform on Azure Resource Manager and you can control API platform version using V1LegacyMode parameter. Enabling the V1LegacyMode parameter will enable you to keep your workspaces in the same network isolation as V1, though you won't have use of the new V2 features. We recommend turning on V1 Legacy Mode only when you want to keep the AzureML control plane data inside your private networks. Learn more at: https://aka.ms/V1LegacyMode.	Audit; Deny; Disabled	1.0.0
Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters	Azure Policy Add-on for Kubernetes service (AKS) extends Gatekeeper v3, an admission controller webhook for Open Policy Agent (OPA), to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner.	Audit; Disabled	1.0.2
[Preview]: Boot Diagnostics should be enabled on virtual machines	Azure virtual machines should have boot diagniostics enabled.	Audit; Disabled	1.0.0-preview
Cannot Edit Individual Nodes	Cannot Edit Individual Nodes. Users should not edit individual nodes. Please edit node pools. Modifying individual nodes can lead to inconsistent settings, operational challenges, and potential security risks.	Audit; Deny; Disabled	1.3.1
Connection throttling should be enabled for PostgreSQL database servers	This policy helps audit any PostgreSQL databases in your environment without Connection throttling enabled. This setting enables temporary connection throttling per IP for too many invalid password login failures.	AuditIfNotExists; Disabled	1.0.0
Container registries should have exports disabled	Disabling exports improves security by ensuring data in a registry is accessed solely via the dataplane ('docker pull'). Data cannot be moved out of the registry via 'acr import' or via 'acr transfer'. In order to disable exports, public network access must be disabled. Learn more at: https://aka.ms/acr/export-policy.	Audit; Deny; Disabled	1.0.0
Ensure cluster containers have readiness or liveness probes configured	This policy enforces that all pods have a readiness and/or liveness probes configured. Probe Types can be any of tcpSocket, httpGet and exec. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For instructions on using this policy, visit https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	3.3.0
Function app slots should have remote debugging turned off	Remote debugging requires inbound ports to be opened on Function apps. Remote debugging should be turned off.	AuditIfNotExists; Disabled	1.1.0
Function app slots should not have CORS configured to allow every resource to access your apps	Cross-Origin Resource Sharing (CORS) should not allow all domains to access your Function app. Allow only required domains to interact with your Function app.	AuditIfNotExists; Disabled	1.1.0
Function app slots should use latest 'HTTP Version'	Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version.	AuditIfNotExists; Disabled	1.1.0
Function app slots that use Java should use a specified 'Java version'	Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for Function apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Java version that meets your requirements.	AuditIfNotExists; Disabled	1.0.0
Function apps should have Client Certificates (Incoming client certificates) enabled	Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. This policy applies to apps with Http version set to 1.1.	AuditIfNotExists; Disabled	1.1.0
Function apps should have remote debugging turned off	Remote debugging requires inbound ports to be opened on Function apps. Remote debugging should be turned off.	AuditIfNotExists; Disabled	2.1.0
Function apps should not have CORS configured to allow every resource to access your apps	Cross-Origin Resource Sharing (CORS) should not allow all domains to access your Function app. Allow only required domains to interact with your Function app.	AuditIfNotExists; Disabled	2.1.0
Function apps should use latest 'HTTP Version'	Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version.	AuditIfNotExists; Disabled	4.1.0
Function apps that use Java should use a specified 'Java version'	Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for Function apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Java version that meets your requirements.	AuditIfNotExists; Disabled	3.1.0
Function apps that use Python should use a specified 'Python version'	Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for Function apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the latest version. This policy only applies to Linux apps. This policy requires you to specify a Python version that meets your requirements.	AuditIfNotExists; Disabled	4.1.0
Kubernetes cluster container images should not include latest image tag	Requires that container images do not use the latest tag in Kubernetes, it is a best practice to ensure reproducibility, prevent unintended updates, and facilitate easier debugging and rollbacks by using explicit and versioned container images.	Audit; Deny; Disabled	2.0.1
Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits	Enforce container CPU and memory resource limits to prevent resource exhaustion attacks in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	9.3.0
Kubernetes cluster containers CPU and memory resource requests must be defined	Enforce container CPU and memory resource requests to ensure scheduled node has required resources.	Audit; Deny; Disabled	1.0.0-preview
Kubernetes cluster containers should not share host namespaces	Block pod containers from sharing the host process ID namespace, host IPC namespace, and host network namespace in a Kubernetes cluster. This recommendation aligns with the Kubernetes Pod Security Standards for host namespaces and is part of CIS 5.2.1, 5.2.2 and 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	Audit; Deny; Disabled	6.0.0
Kubernetes cluster containers should only use allowed AppArmor profiles	Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	6.2.1
Kubernetes cluster containers should only use allowed capabilities	Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	6.2.0
Kubernetes cluster containers should only use allowed images	Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	9.3.0
Kubernetes cluster containers should only use allowed ProcMountType	Pod containers can only use allowed ProcMountTypes in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	8.2.0
Kubernetes cluster containers should only use allowed pull policy	Restrict containers' pull policy to enforce containers to use only allowed images on deployments	Audit; Deny; Disabled	3.2.0
Kubernetes cluster containers should only use allowed seccomp profiles	Pod containers can only use allowed seccomp profiles in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	7.2.0
Kubernetes cluster containers should run with a read only root file system	Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	6.3.0
[Preview]: Kubernetes cluster containers should use only allowed sysctl interfaces	Containers should use only allowed sysctl interfaces in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	1.0.0-preview
Kubernetes cluster pod hostPath volumes should only use allowed host paths	Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This policy is generally available for Kubernetes Service (AKS), and Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	6.3.0
Kubernetes cluster pods and containers should follow SELinux security standards	This policy enforces Kubernetes Pod Security Standards for SELinux options. Under PSS mode, 'user' and 'role' fields must be empty, and 'type' field must be one of the allowed values. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	8.0.0
Kubernetes cluster pods and containers should only run with approved user and group IDs	Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	6.2.0
Kubernetes cluster pods should only use allowed volume types	Pods can only use allowed volume types in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	5.2.0
Kubernetes cluster pods should only use approved host network and port list	Restrict pod access to the host network and the allowable host ports in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments and aligns with Pod Security Standards (PSS) for hostPorts. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	Audit; Deny; Disabled	7.0.0
Kubernetes cluster services should listen only on allowed ports	Restrict services to listen only on allowed ports to secure access to the Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	8.2.0
Kubernetes cluster services should only use allowed external IPs	Use allowed external IPs to avoid the potential attack (CVE-2020-8554) in a Kubernetes cluster. For more information, see https://aka.ms/kubepolicydoc.	Audit; Deny; Disabled	5.2.0
Kubernetes cluster services should use unique selectors	Ensure Services in a Namespace Have Unique Selectors. A unique service selector ensures that each service within a namespace is uniquely identifiable based on specific criteria. This policy syncs service resources into OPA via Gatekeeper. Before applying, verify Gatekeeper pods memory capacity won't be exceeded. Parameters apply to specific namespaces, but it syncs all resources of that type across all namespaces. Currently in preview for Kubernetes Service (AKS).	Audit; Deny; Disabled	1.2.2
Kubernetes cluster should not allow privileged containers	Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	9.2.0
Kubernetes cluster should not use naked pods	Block usage of naked Pods. Naked Pods will not be rescheduled in the event of a node failure. Pods should be managed by Deployment, Replicset, Daemonset or Jobs	Audit; Deny; Disabled	2.3.1
Kubernetes cluster Windows containers should not run as ContainerAdministrator	Prevent usage of ContainerAdministrator as the user to execute the container processes for Windows pods or containers. This recommendation is intended to improve the security of Windows nodes. For more information, see https://kubernetes.io/docs/concepts/windows/intro/ .	Audit; Deny; Disabled	1.2.0
Kubernetes cluster Windows pods should not run HostProcess containers	Prevent prviledged access to the windows node. This recommendation is intended to improve the security of Windows nodes. For more information, see https://kubernetes.io/docs/concepts/windows/intro/ .	Audit; Deny; Disabled	1.0.0
Kubernetes clusters should disable automounting API credentials	Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	4.2.0
Kubernetes clusters should not allow container privilege escalation	Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes. For more information, see Understand Azure Policy for Kubernetes clusters.	Audit; Deny; Disabled	8.0.0
Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities	To reduce the attack surface of your containers, restrict CAP_SYS_ADMIN Linux capabilities. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	5.1.0
Kubernetes clusters should not use the default namespace	Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types. For more information, see Understand Azure Policy for Kubernetes clusters.	audit; Audit; deny; Deny; disabled; Disabled	4.2.0
Kubernetes clusters should use Container Storage Interface(CSI) driver StorageClass	The Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes. In-tree provisioner StorageClass should be deprecated since AKS version 1.21. To learn more, https://aka.ms/aks-csi-driver	Audit; Deny; Disabled	2.3.0
Must Have Anti Affinity Rules or Topology Spread Constraints Set	This policy ensures that pods are scheduled on different nodes within the cluster. By enforcing anti-affinity rules or pod topology spread constraints, availability is maintained even if one of the nodes becomes unavailable. Pods will continue to run on other nodes, enhancing resilience.	Audit; Deny; Disabled	1.2.2
Only approved VM extensions should be installed	This policy governs the virtual machine extensions that are not approved.	Audit; Deny; Disabled	1.0.0
Prints a message if a mutation is applied	Looks up the mutation annotations applied and prints a message if annotation exists.	Audit; Disabled	1.2.1
Storage accounts should prevent cross tenant object replication	Audit restriction of object replication for your storage account. By default, users can configure object replication with a source storage account in one Azure AD tenant and a destination account in a different tenant. It is a security concern because customer's data can be replicated to a storage account that is owned by the customer. By setting allowCrossTenantReplication to false, objects replication can be configured only if both source and destination accounts are in the same Azure AD tenant.	Audit; Deny; Disabled	1.0.0

PV-4: Audit and enforce secure configurations for compute resources

For more information, see Posture and Vulnerability Management: PV-4: Audit and enforce secure configurations for compute resources.

Name	Description	Effect(s)	Version
Audit Linux machines that allow remote connections from accounts without passwords	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Linux machines that allow remote connections from accounts without passwords	AuditIfNotExists; Disabled	3.1.0
Audit Linux machines that do not have the passwd file permissions set to 0644	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Linux machines that do not have the passwd file permissions set to 0644	AuditIfNotExists; Disabled	3.1.0
Audit Linux machines that have accounts without passwords	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Linux machines that have accounts without passwords	AuditIfNotExists; Disabled	3.1.0
Audit Windows machines that allow re-use of the passwords after the specified number of unique passwords	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that allow re-use of the passwords after the specified number of unique passwords. Default value for unique passwords is 24	AuditIfNotExists; Disabled	2.1.0
Audit Windows machines that do not have the maximum password age set to specified number of days	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that do not have the maximum password age set to specified number of days. Default value for maximum password age is 70 days	AuditIfNotExists; Disabled	2.1.0
Audit Windows machines that do not have the minimum password age set to specified number of days	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that do not have the minimum password age set to specified number of days. Default value for minimum password age is 1 day	AuditIfNotExists; Disabled	2.1.0
Audit Windows machines that do not have the password complexity setting enabled	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that do not have the password complexity setting enabled	AuditIfNotExists; Disabled	2.0.0
Audit Windows machines that do not restrict the minimum password length to specified number of characters	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that do not restrict the minimum password length to specified number of characters. Default value for minimum password length is 14 characters	AuditIfNotExists; Disabled	2.1.0
Audit Windows machines that do not store passwords using reversible encryption	Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if Windows machines that do not store passwords using reversible encryption	AuditIfNotExists; Disabled	2.0.0
[Preview]: Azure Stack HCI servers should have consistently enforced application control policies	At a minimum, apply the Microsoft WDAC base policy in enforced mode on all Azure Stack HCI servers. Applied Windows Defender Application Control (WDAC) policies must be consistent across servers in the same cluster.	Audit; Disabled; AuditIfNotExists	1.0.0-preview
[Preview]: Azure Stack HCI servers should meet Secured-core requirements	Ensure that all Azure Stack HCI servers meet the Secured-core requirements. To enable the Secured-core server requirements: 1. From the Azure Stack HCI clusters page, go to Windows Admin Center and select Connect. 2. Go to the Security extension and select Secured-core. 3. Select any setting that is not enabled and click Enable.	Audit; Disabled; AuditIfNotExists	1.0.0-preview
Cloud Services (extended support) role instances should be configured securely	Protect your Cloud Service (extended support) role instances from attacks by ensuring they are not expolosed to any OS vulnerabilities.	AuditIfNotExists; Disabled	1.0.0
Disks and OS image should support TrustedLaunch	TrustedLaunch improves security of a Virtual Machine which requires OS Disk & OS Image to support it (Gen 2). To learn more about TrustedLaunch, visit https://aka.ms/trustedlaunch	Audit; Disabled	1.0.0
[Preview]: Guest Attestation extension should be installed on supported Linux virtual machines	Install Guest Attestation extension on supported Linux virtual machines to allow Azure Security Center to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment applies to Trusted Launch and Confidential Linux virtual machines.	AuditIfNotExists; Disabled	6.0.0-preview
[Preview]: Guest Attestation extension should be installed on supported Linux virtual machines scale sets	Install Guest Attestation extension on supported Linux virtual machines scale sets to allow Azure Security Center to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment applies to Trusted Launch and Confidential Linux virtual machine scale sets.	AuditIfNotExists; Disabled	5.1.0-preview
[Preview]: Guest Attestation extension should be installed on supported Windows virtual machines	Install Guest Attestation extension on supported virtual machines to allow Azure Security Center to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment applies to Trusted Launch and Confidential Windows virtual machines.	AuditIfNotExists; Disabled	4.0.0-preview
[Preview]: Guest Attestation extension should be installed on supported Windows virtual machines scale sets	Install Guest Attestation extension on supported virtual machines scale sets to allow Azure Security Center to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment applies to Trusted Launch and Confidential Windows virtual machine scale sets.	AuditIfNotExists; Disabled	3.1.0-preview
Guest Configuration extension should be installed on your machines	To ensure secure configurations of in-guest settings of your machine, install the Guest Configuration extension. In-guest settings that the extension monitors include the configuration of the operating system, application configuration or presence, and environment settings. Once installed, in-guest policies will be available such as 'Windows Exploit guard should be enabled'. Learn more at Understand Azure Machine Configuration.	AuditIfNotExists; Disabled	1.0.3
Linux machines should meet requirements for the Azure compute security baseline	Requires that prerequisites are deployed to the policy assignment scope. For details, visit Understand Azure Machine Configuration. Machines are non-compliant if the machine is not configured correctly for one of the recommendations in the Azure compute security baseline.	AuditIfNotExists; Disabled	2.3.0
[Preview]: Linux virtual machines should use only signed and trusted boot components	All OS boot components (boot loader, kernel, kernel drivers) must be signed by trusted publishers. Defender for Cloud has identified untrusted OS boot components on one or more of your Linux machines. To protect your machines from potentially malicious components, add them to your allow list or remove the identified components.	AuditIfNotExists; Disabled	1.0.0-preview
[Preview]: Secure Boot should be enabled on supported Windows virtual machines	Enable Secure Boot on supported Windows virtual machines to mitigate against malicious and unauthorized changes to the boot chain. Once enabled, only trusted bootloaders, kernel and kernel drivers will be allowed to run. This assessment applies to Trusted Launch and Confidential Windows virtual machines.	Audit; Disabled	4.0.0-preview
Virtual Machine should have TrustedLaunch enabled	Enable TrustedLaunch on Virtual Machine for enhanced security, use VM SKU (Gen 2) that supports TrustedLaunch. To learn more about TrustedLaunch, visit /azure/virtual-machines/trusted-launch	Audit; Disabled	1.0.0
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity	The Guest Configuration extension requires a system assigned managed identity. Azure virtual machines in the scope of this policy will be non-compliant when they have the Guest Configuration extension installed but do not have a system assigned managed identity. Learn more at Understand Azure Machine Configuration	AuditIfNotExists; Disabled	1.0.1
[Preview]: vTPM should be enabled on supported virtual machines	Enable virtual TPM device on supported virtual machines to facilitate Measured Boot and other OS security features that require a TPM. Once enabled, vTPM can be used to attest boot integrity. This assessment only applies to trusted launch enabled virtual machines.	Audit; Disabled	2.0.0-preview
Windows machines should configure Windows Defender to update protection signatures within one day	To provide adequate protection against newly released malware, Windows Defender protection signatures need to be updated regularly to account for newly released malware. This policy is not applied to Arc connected servers and it requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For more information on Guest Configuration, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	1.0.1
Windows machines should enable Windows Defender Real-time protection	Windows machines should enable the Real-time protection in the Windows Defender to provide adequate protection against newly released malware. This policy is not applicable to arc connected servers and it requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For more information on Guest Configuration, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	1.0.1
Windows machines should meet requirements for 'Administrative Templates - Control Panel'	Windows machines should have the specified Group Policy settings in the category 'Administrative Templates - Control Panel' for input personalization and prevention of enabling lock screens. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Administrative Templates - MSS (Legacy)'	Windows machines should have the specified Group Policy settings in the category 'Administrative Templates - MSS (Legacy)' for automatic logon, screen saver, network behavior, safe DLL, and event log. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Administrative Templates - Network'	Windows machines should have the specified Group Policy settings in the category 'Administrative Templates - Network' for guest logons, simultaneous connections, network bridge, ICS, and multicast name resolution. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Administrative Templates - System'	Windows machines should have the specified Group Policy settings in the category 'Administrative Templates - System' for settings that control the administrative experience and Remote Assistance. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Accounts'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Accounts' for limiting local account use of blank passwords and guest account status. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Audit'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Audit' for forcing audit policy subcategory and shutting down if unable to log security audits. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Devices'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Devices' for undocking without logging on, installing print drivers, and formatting/ejecting media. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Interactive Logon'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Interactive Logon' for displaying last user name and requiring ctrl-alt-del. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Microsoft Network Client'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Microsoft Network Client' for Microsoft network client/server and SMB v1. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Microsoft Network Server'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Microsoft Network Server' for disabling SMB v1 server. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Network Access'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Network Access' for including access for anonymous users, local accounts, and remote access to the registry. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Network Security'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Network Security' for including Local System behavior, PKU2U, LAN Manager, LDAP client, and NTLM SSP. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Recovery console'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Recovery console' for allowing floppy copy and access to all drives and folders. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - Shutdown'	Windows machines should have the specified Group Policy settings in the category 'Security Options - Shutdown' for allowing shutdown without logon and clearing the virtual memory pagefile. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - System objects'	Windows machines should have the specified Group Policy settings in the category 'Security Options - System objects' for case insensitivity for non-Windows subsystems and permissions of internal system objects. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - System settings'	Windows machines should have the specified Group Policy settings in the category 'Security Options - System settings' for certificate rules on executables for SRP and optional subsystems. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Options - User Account Control'	Windows machines should have the specified Group Policy settings in the category 'Security Options - User Account Control' for mode for admins, behavior of elevation prompt, and virtualizing file and registry write failures. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Security Settings - Account Policies'	Windows machines should have the specified Group Policy settings in the category 'Security Settings - Account Policies' for password history, age, length, complexity, and storing passwords using reversible encryption. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Account Logon'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Account Logon' for auditing credential validation and other account logon events. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Account Management'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Account Management' for auditing application, security, and user group management, and other management events. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Detailed Tracking'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Detailed Tracking' for auditing DPAPI, process creation/termination, RPC events, and PNP activity. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Logon-Logoff'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Logon-Logoff' for auditing IPSec, network policy, claims, account lockout, group membership, and logon/logoff events. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Object Access'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Object Access' for auditing file, registry, SAM, storage, filtering, kernel, and other system types. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Policy Change'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Policy Change' for auditing changes to system audit policies. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - Privilege Use'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - Privilege Use' for auditing nonsensitive and other privilege use. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'System Audit Policies - System'	Windows machines should have the specified Group Policy settings in the category 'System Audit Policies - System' for auditing IPsec driver, system integrity, system extension, state change, and other system events. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'User Rights Assignment'	Windows machines should have the specified Group Policy settings in the category 'User Rights Assignment' for allowing log on locally, RDP, access from the network, and many other user activities. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Windows Components'	Windows machines should have the specified Group Policy settings in the category 'Windows Components' for basic authentication, unencrypted traffic, Microsoft accounts, telemetry, Cortana, and other Windows behaviors. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements for 'Windows Firewall Properties'	Windows machines should have the specified Group Policy settings in the category 'Windows Firewall Properties' for firewall state, connections, rule management, and notifications. This policy requires that the Guest Configuration prerequisites have been deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol.	AuditIfNotExists; Disabled	3.0.0
Windows machines should meet requirements of the Azure compute security baseline	Requires that prerequisites are deployed to the policy assignment scope. For details, visit Understand Azure Machine Configuration. Machines are non-compliant if the machine is not configured correctly for one of the recommendations in the Azure compute security baseline.	AuditIfNotExists; Disabled	2.1.0

PV-5: Perform vulnerability assessments

For more information, see Posture and Vulnerability Management: PV-5: Perform vulnerability assessments.

Name	Description	Effect(s)	Version
A vulnerability assessment solution should be enabled on your virtual machines	Audits virtual machines to detect whether they are running a supported vulnerability assessment solution. A core component of every cyber risk and security program is the identification and analysis of vulnerabilities. Azure Security Center's standard pricing tier includes vulnerability scanning for your virtual machines at no extra cost. Additionally, Security Center can automatically deploy this tool for you.	AuditIfNotExists; Disabled	3.0.0
Machines should have secret findings resolved	Audits virtual machines to detect whether they contain secret findings from the secret scanning solutions on your virtual machines.	AuditIfNotExists; Disabled	1.0.2
Vulnerability assessment should be enabled on SQL Managed Instance	Audit each SQL Managed Instance which doesn't have recurring vulnerability assessment scans enabled. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.	AuditIfNotExists; Disabled	1.0.1
Vulnerability assessment should be enabled on your SQL servers	Audit Azure SQL servers which do not have vulnerability assessment properly configured. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.	AuditIfNotExists; Disabled	3.0.0
Vulnerability assessment should be enabled on your Synapse workspaces	Discover, track, and remediate potential vulnerabilities by configuring recurring SQL vulnerability assessment scans on your Synapse workspaces.	AuditIfNotExists; Disabled	1.0.0

PV-6: Rapidly and automatically remediate vulnerabilities

For more information, see Posture and Vulnerability Management: PV-6: Rapidly and automatically remediate vulnerabilities.

Name	Description	Effect(s)	Version
Azure registry container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)	Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. Resolving vulnerabilities can greatly improve your security posture, ensuring images are safe to use prior to deployment.	AuditIfNotExists; Disabled	1.0.1
Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)	Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. This recommendation provides visibility to vulnerable images currently running in your Kubernetes clusters. Remediating vulnerabilities in container images that are currently running is key to improving your security posture, significantly reducing the attack surface for your containerized workloads.	AuditIfNotExists; Disabled	1.0.1
Cloud Services (extended support) role instances should have system updates installed	Secure your Cloud Services (extended support) role instances by ensuring the latest security and critical updates are installed on them.	AuditIfNotExists; Disabled	1.0.0
Hotpatch should be enabled for Windows Server Azure Edition VMs	Minimize reboots and install updates quickly with hotpatch. Learn more at /azure/automanage/automanage-hotpatch	Audit; Deny; Disabled	1.0.0
Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version	Upgrade your Kubernetes service cluster to a later Kubernetes version to protect against known vulnerabilities in your current Kubernetes version. Vulnerability CVE-2019-9946 has been patched in Kubernetes versions 1.11.9+, 1.12.7+, 1.13.5+, and 1.14.0+	Audit; Disabled	1.0.2
Machines should be configured to periodically check for missing system updates	To ensure periodic assessments for missing system updates are triggered automatically every 24 hours, the AssessmentMode property should be set to 'AutomaticByPlatform'. Learn more about AssessmentMode property for Windows: Windows patch assessment mode, for Linux: Linux patch assessment mode.	Audit; Deny; Disabled	3.9.0
SQL databases should have vulnerability findings resolved	Monitor vulnerability assessment scan results and recommendations for how to remediate database vulnerabilities.	AuditIfNotExists; Disabled	4.1.0
SQL servers on machines should have vulnerability findings resolved	SQL vulnerability assessment scans your database for security vulnerabilities, and exposes any deviations from best practices such as misconfigurations, excessive permissions, and unprotected sensitive data. Resolving the vulnerabilities found can greatly improve your database security posture.	AuditIfNotExists; Disabled	1.0.0
System updates should be installed on your machines (powered by Update Center)	Your machines are missing system, security, and critical updates. Software updates often include critical patches to security holes. Such holes are frequently exploited in malware attacks so it's vital to keep your software updated. To install all outstanding patches and secure your machines, follow the remediation steps.	AuditIfNotExists; Disabled	1.0.1

---

Next Steps

• Review the Microsoft cloud security benchmark for more information about control details.
• See the MCSB v2 to CIS Controls mapping for a consolidated view of CIS Controls v8.1 mappings
• Assign policies through the Azure portal
• Learn more about Azure Policy