Home > Azure Security Management > Supported Risk Rules
Download this articleSupported Risk Rules
The following table lists the supported risk rules by Elements.
| Scope | Rule Name | Description | Reference | Last Update |
|---|---|---|---|---|
| Azure SQL Database | Database users shouldn't share the same name as a server login for Model SQL database | Database users might share the same name as a server login. This rule validates that there are no such users. | Defender for Cloud | June 2026 |
| Azure SQL Database | The Trustworthy bit should be disabled on all databases except MSDB for SQL Databases | The TRUSTWORTHY database property is used to indicate whether the instance of SQL Server trusts the database and the contents within it. If this option is enabled database modules (for example user-defined functions or stored procedures) that use an impersonation context can access resources outside the database. This rule verifies that the TRUSTWORTHY bit is disabled on all databases except MSDB. | Defender for Cloud | June 2026 |
| Azure SQL Database | Orphan database roles should be removed from SQL databases | Orphan roles are user-defined roles that have no members. Eliminate orphaned roles as they are not needed on the system. This rule checks whether there are any orphan roles. | Defender for Cloud | June 2026 |
| Azure SQL Database | Database-level firewall rules should not grant excessive access for SQL Servers | The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see Azure SQL Database and Azure Synapse Analytics IP firewall rules. This check verifies that database-level firewall rules do not grant access to more than 255 IP addresses. | Defender for Cloud | June 2026 |
| Azure SQL Database | Database-level firewall rules should be tracked and maintained at a strict minimum for SQL Servers | The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see Azure SQL Database and Azure Synapse Analytics IP firewall rules. This check enumerates all the database-level firewall rules so that any changes made to them can be identified and addressed. | Defender for Cloud | June 2026 |
| Azure SQL Database | Minimal set of principals should be members of fixed Azure SQL Database master database roles | SQL Database provides two restricted administrative roles in the master database to which user accounts can be added that grant permissions to either create databases or manage logins. This rule check that a minimal set of principals are members of these administrative roles. | Defender for Cloud | June 2026 |
| Azure SQL Database | Track all users with access to the database for SQL Databases | This check tracks all users with access to a database. Make sure that these users are authorized according to their current role in the organization. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Principal GUEST should not be granted permissions in SQL databases | Each database includes a user called GUEST. Permissions granted to GUEST are inherited by users who have access to the database but who do not have a user account in the database. This rule checks that all permissions have been revoked from the GUEST user. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Principal GUEST should not be granted permissions on objects or columns in SQL databases | Each database includes a user called GUEST. Permissions granted to GUEST are inherited by users who have access to the database but who do not have a user account in the database. This rule checks that all permissions have been revoked from the GUEST user | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Transparent data encryption should be enabled for SQL databases | Transparent data encryption (TDE) helps to protect the database files against information disclosure by performing real-time encryption and decryption of the database, associated backups, and transaction log files 'at rest', without requiring changes to the application. This rule checks that TDE is enabled on the database. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | User-defined database roles should not be members of fixed roles in SQL databases | To easily manage the permissions in your databases SQL Server provides several roles, which are security principals that group other principals. They are like groups in the Microsoft Windows operating system. Database accounts and other SQL Server roles can be added into database-level roles. Each member of a fixed-database role can add other users to that same role. This rule checks that no user-defined roles are members of fixed roles. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Database owners should be as expected for SQL databases | Database owners can perform all configuration and maintenance activities on the database and can also drop databases in SQL Server. Tracking database owners is important to avoid having excessive permission for some principals. Create a baseline that defines the expected database owners for the database. This rule checks whether the database owners are as defined in the baseline. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | All memberships for user-defined roles should be intended in SQL databases | User-defined roles are security principals defined by the user to group principals to easily manage permissions. Monitoring these roles is important to avoid having excessive permissions. Create a baseline that defines expected membership for each user-defined role. This rule checks whether all memberships for user-defined roles are as defined in the baseline. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Minimal set of principals should be granted ALTER or ALTER ANY USER database-scoped permissions in SQL databases | Every SQL Server securable has permissions associated with it that can be granted to principals. Permissions can be scoped at the server level (assigned to logins and server roles) or at the database level (assigned to database users and database roles). These rules check that only a minimal set of principals are granted ALTER or ALTER ANY USER database-scoped permissions. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Minimal set of principals should be granted EXECUTE permission on objects or columns in SQL databases | This rule checks which principals are granted EXECUTE permission on objects or columns to ensure this permission is granted to a minimal set of principals. Every SQL Server securable has permissions associated with it that can be granted to principals. Permissions can be scoped at the server level (assigned to logins and server roles) or at the database level (assigned to database users, database roles, or application roles). The EXECUTE permission applies to both stored procedures and scalar functions, which can be used in computed columns. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Minimal set of principals should be members of fixed high impact database roles in SQL databases | SQL Server provides roles to help manage the permissions. Roles are security principals that group other principals. Database-level roles are database-wide in their permission scope. This rule checks that a minimal set of principals are members of the fixed database roles. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Minimal set of principals should be members of fixed low impact database roles in SQL databases | SQL Server provides roles to help manage the permissions. Roles are security principals that group other principals. Database-level roles are database-wide in their permission scope. This rule checks that a minimal set of principals are members of the fixed database roles. | Defender for Cloud | June 2026 |
| Azure SQL Database;SQL virtual machine | Changes to signed modules should be authorized for SQL databases | You can sign a stored procedure, function, or trigger with a certificate or an asymmetric key. This is designed for scenarios when permissions cannot be inherited through ownership chaining or when the ownership chain is broken, such as dynamic SQL. This rule checks for changes made to signed modules, which could be an indication of malicious use. | Defender for Cloud | June 2026 |
| Azure SQL Server | Maximum number of error logs should be 12 or more for SQL Servers | Each SQL Server Error log will have all the information related to failures / errors that have occurred since SQL Server was last restarted or since the last time you have recycled the error logs. This rule checks that the maximum number of error logs is 12 or more. | Defender for Cloud | June 2026 |
| Azure SQL Server | Server-level firewall rules should be tracked and maintained at a strict minimum on SQL Servers | The Azure SQL server-level firewall helps protect your data by preventing all access to your databases until you specify which IP addresses have permission. Server-level firewall rules grant access to all databases that belong to the server based on the originating IP address of each request. Server-level firewall rules can be created and managed through Transact-SQL as well as through the Azure portal or PowerShell. For more information, see Azure SQL Database and Azure Synapse Analytics IP firewall rules. This check enumerates all the server-level firewall rules so that any changes made to them can be identified and addressed. | Defender for Cloud | June 2026 |
| Container App | Authentication should be enabled on Azure Container Apps | This recommendation checks whether authentication is enabled for Azure Container Apps. When authentication is not configured, publicly accessible container app endpoints may allow anonymous HTTP requests. Enabling authentication ensures that requests are validated using identity providers before reaching the container app, reducing the risk of unauthorized access and misuse. | Defender for Cloud | June 2026 |
| Container App | Azure Container Apps should not be exposed to the public internet unless required | This recommendation checks whether Azure Container Apps are exposed to the public internet. Public exposure increases the attack surface and may allow unauthorized access if additional controls are not in place. Unless business requirements explicitly demand public ingress, container apps should be deployed in internal environments or configured with private network access to reduce internet‑based threats. | Defender for Cloud | June 2026 |
| Container App | Managed identities assigned to Azure Container Apps should follow least privilege | This recommendation checks whether managed identities assigned to Azure Container Apps are granted only the minimum permissions required to perform their intended functions. Over‑privileged managed identities can increase the impact of a compromised application by allowing broader access to Azure resources. Following the principle of least privilege reduces the risk of unauthorized actions and limits potential blast radius. | Defender for Cloud | June 2026 |
| Container Instance | Azure Container Instances should not be publicly exposed | This recommendation checks whether Azure Container Instances are publicly exposed by using a public IP address. Publicly exposed container instances can be accessed directly from the internet, increasing the risk of unauthorized access and attacks. Container instances should be deployed with private network access unless public exposure is explicitly required. | Defender for Cloud | June 2026 |
| Container Instance | Managed identities assigned to Azure Container Instances should follow least privilege | This recommendation checks whether managed identities assigned to Azure Container Instances are granted only the minimum permissions required for their operation. Over‑privileged managed identities increase the potential impact of a compromised container instance by allowing broader access to Azure resources. Applying the principle of least privilege helps reduce attack surface and limits the blast radius of security incidents. | Defender for Cloud | June 2026 |
| Function App | Authentication should be enabled on Azure Functions | This recommendation checks whether authentication is enabled for Azure Functions. When authentication is not configured, function endpoints may be publicly accessible without identity verification. Enabling authentication ensures that only authorized users or applications can invoke functions, reducing the risk of unauthorized access, data exposure, or abuse. | Defender for Cloud | June 2026 |
| Function App | Restricted network access should be configured on Internet exposed Function app | This recommendation checks whether restricted network access is configured for Azure Function Apps that are exposed to the internet. When a Function App is publicly accessible without network restrictions, it can be reached by any external client, increasing the risk of unauthorized access and abuse. Configuring restricted network access—such as IP restrictions, virtual network integration, or private endpoints—limits who can reach the Function App and reduces its public attack surface. | Defender for Cloud | June 2026 |
| Kubernetes services | CNI plugins should be configured on Azure Kubernetes Services (AKS) clusters | This recommendation is issued by Microsoft Defender for Cloud as part of Kubernetes security posture management. It is based on AKS official networking requirements, which state that clusters created with --network-plugin none must have a Container Network Interface (CNI) plugin explicitly configured. Failure to deploy a CNI results in non-functional pod and node networking and represents a misconfiguration against Microsoft Cloud Security Benchmark (Network Security controls). | Defender for Cloud | June 2026 |
| Kubernetes services | Private endpoint access should be enabled for the control plane in Azure Kubernetes Service (AKS) clusters | This recommendation promotes enabling Private Endpoint for the AKS control plane, based on AKS private cluster architecture and the built‑in Azure Policy “Azure Kubernetes Service Private Clusters should be enabled”. | Defender for Cloud | June 2026 |
| Kubernetes services | Private nodes should be configured on Azure Kubernetes Service (AKS) clusters | This recommendation checks whether AKS cluster nodes are configured as private nodes without public IP addresses. When nodes are assigned public IPs, they can be directly reachable from the internet, increasing the attack surface of the cluster. Configuring private nodes ensures that cluster nodes are only accessible through internal virtual network connectivity, reducing exposure and supporting a more secure network isolation model. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | Allow access to Azure services' should be disabled for PostgreSQL Servers | This recommendation checks whether the “Allow access to Azure services” firewall setting is enabled on Azure Database for PostgreSQL servers. When this option is enabled, the PostgreSQL server can be accessed by any Azure service without explicit network rules. Disabling this setting enforces stricter network access control and ensures that only explicitly allowed networks or private endpoints can connect to the database. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | Private endpoint should be configured for Azure Database for PostgreSQL Servers | This recommendation checks whether Azure Database for PostgreSQL servers are configured to use a private endpoint. When a private endpoint is not enabled, database access may rely on public network exposure or broad firewall rules. Configuring a private endpoint ensures that database connectivity is restricted to a virtual network, reducing exposure to the public internet and improving overall network isolation for sensitive data workloads. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | Public IP access should be disabled for Azure Database for PostgreSQL Servers | This recommendation checks whether public IP access is enabled for Azure Database for PostgreSQL servers. Allowing public IP access exposes the database to potential internet-based threats, even when firewall rules are configured. Disabling public IP access reduces the attack surface and ensures that database connectivity relies on private network access, such as private endpoints and virtual networks. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | require_secure_transport should be set to 'on' for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter require_secure_transport is set to on. When this setting is disabled, client connections to the database can occur without transport-level encryption. Enabling require_secure_transport enforces TLS encryption for all connections, helping protect sensitive data and credentials from interception during network transmission. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | shared_preload_libraries should include pgaudit for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server configuration parameter shared_preload_libraries includes pgaudit. The pgAudit extension provides detailed logging of database activities such as SQL statements, schema changes, and access patterns. If pgaudit is not preloaded at server startup, database activity auditing is not available. Enabling pgAudit strengthens monitoring, compliance, and forensic investigation capabilities. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | pgaudit.log should include role, ddl, and misc for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL pgAudit configuration includes auditing for role changes, DDL operations, and miscellaneous administrative actions by ensuring that pgaudit.log includes role, ddl, and misc. Without these settings, critical security‑relevant database activities may not be logged, reducing visibility into privileged actions and weakening auditing and compliance capabilities. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | pgaudit.log_level should be set to 'log' for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL pgAudit configuration parameter pgaudit.log_level is set to log. If the log level is set to a less restrictive value, audit events may not be consistently captured or forwarded to centralized logging systems. Setting pgaudit.log_level to log ensures that audit records are reliably written to PostgreSQL logs and available for security monitoring, compliance, and forensic analysis. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | pgaudit.log_statement should be set to 'on' for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL pgAudit parameter pgaudit.log_statement is set to on. When this setting is disabled, audit logs may omit the actual SQL statements associated with audited events. Enabling pgaudit.log_statement ensures that audited database activities include statement details, strengthening monitoring, investigation, and compliance capabilities. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | pgaudit.log_statement_once should be set to 'on' for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL pgAudit parameter pgaudit.log_statement_once is set to on. When this setting is disabled, the same SQL statement may be logged multiple times for a single audited event, leading to excessive and noisy audit logs. Enabling pgaudit.log_statement_once ensures that each audited SQL statement is logged only once, improving audit log clarity while maintaining full audit coverage. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | password_encryption should be set to 'scram-sha-256' for Azure Database for PostgreSQL servers | This recommendation checks whether the PostgreSQL server parameter password_encryption is set to scram-sha-256. When weaker encryption methods such as MD5 are used, stored credentials may be more susceptible to brute-force or compromise. Configuring password_encryption to scram-sha-256 ensures stronger password hashing and improves protection of database user credentials. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | log_checkpoints should be set to on for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter log_checkpoints is enabled. When checkpoint logging is disabled, critical information about checkpoint activity is not recorded, reducing visibility into database behavior and performance. Enabling log_checkpoints helps administrators monitor checkpoint activity, detect abnormal patterns, and support troubleshooting and forensic analysis. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | log_connections should be set to 'on' for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter log_connections is enabled. When connection logging is disabled, successful database connection attempts are not recorded, reducing visibility into access patterns and potentially hiding unauthorized or suspicious activity. Enabling log_connections helps administrators monitor database access, detect anomalies, and support security investigations. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | log_disconnections should be set to 'on' for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter log_disconnections is enabled. When disconnection logging is disabled, information about when and how database sessions end is not recorded. Enabling log_disconnections improves visibility into session behavior, supports security investigations, and helps diagnose abnormal or unexpected disconnections. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | log_line_prefix should include key identifiers for auditing and troubleshooting for Azure Database for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter log_line_prefix is configured to include key identifiers such as user, database name, process ID, or session information. When log entries lack sufficient contextual identifiers, auditing, troubleshooting, and security investigations become difficult. Including key identifiers in the log line prefix improves traceability and helps correlate log events with specific users and sessions. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | logfiles.retention_days should be greater than 3 for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server log retention period, defined by logfiles.retention_days, is configured to retain logs for more than three days. When log retention is too short, important security, audit, and troubleshooting information may be lost before it can be reviewed or investigated. Increasing log retention improves the ability to perform security investigations, compliance audits, and root‑cause analysis. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | Geo-redundant backups should be enabled for PostgreSQL Servers | This recommendation checks whether geo‑redundant backups are enabled for Azure Database for PostgreSQL servers. Without geo‑redundant backups, backups are stored in a single region, which may result in data unavailability or loss in the event of a regional outage. Enabling geo‑redundant backups improves data resilience and ensures database recovery is possible even during region‑wide failures. | Defender for Cloud | June 2026 |
| PostgreSQL flexible server;PostgreSQL server | Connection_throttle should be set to 'on' for PostgreSQL Servers | This recommendation checks whether the PostgreSQL server parameter connection_throttle is enabled. When connection throttling is disabled, the database may allow an excessive number of rapid connection attempts, increasing the risk of brute‑force attacks, credential abuse, or resource exhaustion. Enabling connection_throttle helps limit abnormal connection behavior and protects the database from abuse and denial‑of‑service scenarios. | Defender for Cloud | June 2026 |
| SQL virtual machine | Latest updates should be installed for SQL Servers | Microsoft periodically releases Cumulative Updates (CUs) for each version of SQL Server. This rule checks whether the latest CU has been installed for the particular version of SQL Server being used, by passing in a string for execution. This rule checks that all users (except dbo) do not have permission to execute the xp_cmdshell extended stored procedure. | Defender for Cloud | June 2026 |
| SQL virtual machine | Untracked trusted assemblies should be removed for SQL Servers | Assemblies marked as UNSAFE are required to be signed by a certificate or asymmetric key with a corresponding login that has been granted UNSAFE ASSEMBLY permission in the master database. Trusted assemblies might bypass this requirement. | Defender for Cloud | June 2026 |
| SQL virtual machine | Remote Admin Connections should be disabled unless specifically required for SQL databases | This rule checks that remote dedicated admin connections are disabled if they are not being used for clustering to reduce attack surface area. SQL Server provides a dedicated administrator connection (DAC). The DAC lets an administrator access a running server to execute diagnostic functions or Transact-SQL statements, or to troubleshoot problems on the server and it becomes an attractive target to attack when it is enabled remotely. | Defender for Cloud | June 2026 |
| SQL virtual machine | Password expiration check should be enabled for all SQL logins on SQL Servers | Password expiration policies are used to manage the lifespan of a password. When SQL Server enforces password expiration policy, users are reminded to change old passwords, and accounts that have expired passwords are disabled. This rule checks that password expiration policy is enabled for all SQL logins. | Defender for Cloud | June 2026 |
| SQL virtual machine | sa' login should be disabled for SQL Servers | sa is a well-known account with principal ID 1. This rule verifies that the sa account is disabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | xp_cmdshell should be disabled for SQL Servers | xp_cmdshell spawns a Windows command shell and passes it a string for execution. This rule checks that xp_cmdshell is disabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | Unused service broker endpoints should be removed for SQL Servers | Service Broker provides queuing and reliable messaging for SQL Server. Service Broker is used both for applications that use a single SQL Server instance and applications that distribute work across multiple instances. Service Broker endpoints provide options for transport security and message forwarding. This rule enumerates all the service broker endpoints. Remove those that are not used. | Defender for Cloud | June 2026 |
| SQL virtual machine | Server permissions shouldn't be granted directly to principals for SQL Servers | Server level permissions are associated with a server level object to regulate which users can gain access to the object. This rule checks that there are no server level permissions granted directly to logins. | Defender for Cloud | June 2026 |
| SQL virtual machine | Scan for startup stored procedures' option should be disabled for SQL Servers | When 'Scan for startup procs' is enabled SQL Server scans for and runs all automatically run stored procedures defined on the server. If this option is enabled SQL Server scans for and runs all automatically run stored procedures defined on the server. This rule checks that this option is disabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | Authentication mode should be Windows Authentication for SQL Servers | There are two possible authentication modes: Windows Authentication mode and mixed mode. Mixed mode means that SQL Server enables both Windows authentication and SQL Server authentication. This rule checks that the authentication mode is set to Windows Authentication. | Defender for Cloud | June 2026 |
| SQL virtual machine | Auditing of both successful and failed login attempts (default trace) should be enabled when 'Login auditing' is set up to track logins for SQL Servers | SQL Server Login auditing configuration enables administrators to track the users logging into SQL Server instances. If the user chooses to count on 'Login auditing' to track users logging into SQL Server instances, then it is important to enable it for both successful and failed login attempts. | Defender for Cloud | June 2026 |
| SQL virtual machine | AES encryption should be required for any Existing Mirroring or SSB endpoint on SQL Databases | Service Broker and Mirroring endpoints support different encryption algorithms including no-encryption. This rule checks that any existing endpoint requires AES encryption. | Defender for Cloud | June 2026 |
| SQL virtual machine | Model database should only be accessible by Only 'dbo' should have access to Model SQL database | The Model database is used as the template for all databases created on the instance of SQL Server. Modifications made to the model database such as database size recovery model and other database options are applied to any databases created afterward. This rule checks that dbo is the only account allowed to access the model database. | Defender for Cloud | June 2026 |
| SQL virtual machine | Server configuration 'Replication XPs' should be disabled for SQL Servers | Disable the deprecated server configuration 'Replication XPs' to limit the attack surface area. This is an internal only configuration setting. | Defender for Cloud | June 2026 |
| SQL virtual machine | Orphaned users should be removed from SQL server databases | A database user that exists on a database but has no corresponding login in the master database or as an external resource (for example, a Windows user) is referred to as an orphaned user and it should either be removed or remapped to a valid login. This rule checks that there are no orphaned users. | Defender for Cloud | June 2026 |
| SQL virtual machine | The database owner information in the database should match the respective database owner information in the master database for SQL databases | There is redundant information about the dbo identity for any database: metadata stored in the database itself and metadata stored in master DB. This rule checks that this information is consistent between the target DB and master. | Defender for Cloud | June 2026 |
| SQL virtual machine | There should be no SPs marked as auto-start for SQL Servers | When SQL Server has been configured to 'scan for startup procs' the server will scan master DB for stored procedures marked as auto-start. This rule checks that there are no SPs marked as auto-start. | Defender for Cloud | June 2026 |
| SQL virtual machine | User CLR assemblies should not be defined in SQL databases | CLR assemblies can be used to execute arbitrary code on SQL Server process. This rule checks that there are no user-defined CLR assemblies in the database. | Defender for Cloud | June 2026 |
| SQL virtual machine | Auditing of both successful and failed login attempts should be enabled for SQL Servers | SQL Server auditing configuration enables administrators to track the users logging into SQL Server instances that they're responsible for. This rule checks that auditing is enabled for both successful and failed login attempts. | Defender for Cloud | June 2026 |
| SQL virtual machine | Auditing of both successful and failed login attempts for contained DB authentication should be enabled for SQL databases | SQL Server auditing configuration enables administrators to track users logging to SQL Server instances that they're responsible for. This rule checks that auditing is enabled for both successful and failed login attempts for contained DB authentication. | Defender for Cloud | June 2026 |
| SQL virtual machine | Polybase network encryption should be enabled for SQL databases | PolyBase is a technology that accesses and combines both non-relational and relational data all from within SQL Server. Polybase network encryption option configures SQL Server to encrypt control and data channels when using Polybase. This rule verifies that this option is enabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | Create a baseline of External Key Management Providers for SQL Servers | The SQL Server Extensible Key Management (EKM) enables third-party EKM / Hardware Security Modules (HSM) vendors to register their modules in SQL Server. When registered SQL Server users can use the encryption keys stored on EKM modules, this rule displays a list of EKM providers being used in the system. | Defender for Cloud | June 2026 |
| SQL virtual machine | Server Permissions granted to public should be minimized for SQL Servers | Every SQL Server login belongs to the public server role. When a server principal has not been granted or denied specific permissions on a securable object the user inherits the permissions granted to public on that object. This rule checks that server permissions granted to public are minimized. | Defender for Cloud | June 2026 |
| SQL virtual machine | Unnecessary execute permissions on extended stored procedures should be revoked for SQL Servers | Extended stored procedures are DLLs that an instance of SQL Server can dynamically load and run. SQL Server is packaged with many extended stored procedures that allow for interaction with the system DLLs. This rule checks that unnecessary execute permissions on extended stored procedures have been revoked. | Defender for Cloud | June 2026 |
| SQL virtual machine | Execute permissions to access the registry should be restricted for SQL Servers | Registry extended stored procedures allow Microsoft SQL Server to read write and enumerate values and keys in the registry. They are used by Enterprise Manager to configure the server. This rule checks that the permissions to execute registry extended stored procedures have been revoked from all users (other than dbo). | Defender for Cloud | June 2026 |
| SQL virtual machine | Sample databases should be removed for SQL Servers | Microsoft SQL Server comes shipped with several sample databases. This rule checks whether the sample databases have been removed. | Defender for Cloud | June 2026 |
| SQL virtual machine | Data Transformation Services (DTS) permissions should only be granted to SSIS roles in MSDB SQL database | Data Transformation Services (DTS), is a set of objects and utilities that allow the automation of extract, transform, and load operations to or from a database. The objects are DTS packages and their components, and the utilities are called DTS tools. This rule checks that only the SSIS roles are granted permissions to use the DTS system stored procedures and the permissions for the PUBLIC role to use the DTS system stored procedures have been revoked. | Defender for Cloud | June 2026 |
| SQL virtual machine | Minimal set of principals should be members of fixed server roles for SQL Servers | SQL Server provides roles to help manage permissions. Roles are security principals that group other principals. Server-level roles are server-wide in their permission scope. This rule checks that a minimal set of principals are members of the fixed server roles. | Defender for Cloud | June 2026 |
| SQL virtual machine | Features that may affect security should be disabled for SQL Servers | SQL Server is capable of providing a wide range of features and services. Some of the features and services provided by default might not be necessary and enabling them could adversely affect the security of the system. This rule checks that these features are disabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | Extensibility-features that may affect security should be disabled if not needed for SQL Servers | SQL Server provides a wide range of features and services. Some of the features and services, provided by default, might not be necessary, and enabling them could adversely affect the security of the system. This rule checks that configurations that allow extraction of data to an external data source and the execution of scripts with certain remote language extensions are disabled. | Defender for Cloud | June 2026 |
| SQL virtual machine | SQL logins with commonly used names should be disabled for SQL Servers | This rule checks the accounts with database owner permission for commonly used names. Assigning commonly used names to accounts with database owner permission increases the likelihood of successful brute force attacks. | Defender for Cloud | June 2026 |
| All resources | Identify guest users with Azure RBAC role assignments | This rule audits all guest accounts that have Azure RBAC role assignments at any scope (subscription, resource group, or resource). Guest accounts often represent external collaborators and should be reviewed regularly to ensure least privilege and compliance. | AvePoint Best Practices | April 2026 |
| All resources | Identify risky users with Azure RBAC role assignments | This rule Identify Entra ID users who are flagged as risky by Microsoft Entra ID Identity Protection and have Azure RBAC role assignments at any scope (subscription, resource group, or resource). Risky users are identified based on risk detections from user management. | AvePoint Best Practices | April 2026 |
| All resources | Identify users with direct (non-group) RBAC role assignments | This rule Identify Entra ID users who have Azure RBAC role assignments directly assigned to the user, rather than via group membership. Direct assignments are flagged as unique permissions that bypass normal group-based access controls. | AvePoint Best Practices | April 2026 |
| All resources | Identify inactive users with Azure RBAC assignments | This rule Identify all Entra ID principals (users and service principals) that have Azure RBAC role assignments at subscription, resource group, or resource scope. It flags principals that have no interactive sign-in activity in the last 30 days or have never signed in. | AvePoint Best Practices | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | Identify users with temporary privileged access in Azure RBAC | This rule Identify Entra ID users who currently have active temporary RBAC role assignments through Microsoft Entra Privileged Identity Management (PIM). Temporary access is typically granted via eligible roles activated for a limited time. | AvePoint Best Practices | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | Azure overprovisioned identities should have only the necessary permissions | A policy that identifies identities (users, service principals, managed identities) which have more permissions than necessary across Azure subscriptions. Overprovisioned identities increase attack surface and risk of accidental or malicious misuse. | Defender for Cloud | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| All resources | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| AI Search | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| API Management service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| App Configuration | 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: https://aka.ms/appconfig/private-endpoint. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | App Service apps should use managed identity | Use a managed identity for enhanced authentication security | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | App Service apps should require FTPS only | Enable FTPS enforcement for enhanced security. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Automation Account | Automation account variables should be encrypted | It is important to enable encryption of Automation account variable assets when storing sensitive data | Microsoft cloud security benchmark v1 | April 2026 |
| Azure AI Video Indexer; Document intelligence; Immersive reader; Azure OpenAI; Speech service; AI Search; Computer vision; Custom vision; Face API; Language; Translator | 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: https://aka.ms/AI/auth. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cache for Redis | 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: https://docs.microsoft.com/azure/azure-cache-for-redis/cache-private-link. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cache for Redis | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cosmos DB account | 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: https://docs.microsoft.com/azure/cosmos-db/how-to-configure-private-endpoints. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cosmos DB account | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cosmos DB account | 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: https://docs.microsoft.com/azure/cosmos-db/how-to-setup-rbac#disable-local-auth. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cosmos DB account | 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 https://aka.ms/cosmosdb-cmk. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Cosmos DB account | 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: https://docs.microsoft.com/azure/cosmos-db/how-to-configure-private-endpoints#blocking-public-network-access-during-account-creation. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL flexible server | Azure MySQL flexible server should restrict public access ranges | This policy ensures Azure Database for MySQL flexible servers do not allow overly permissive public access ranges. Public access should be limited to required IP ranges or disabled to reduce exposure. | Defender for Cloud | April 2026 |
| Azure Database for MySQL flexible server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL server | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for MySQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL flexible server | Azure PostgreSQL flexible server should restrict public access ranges | This policy ensures Azure Database for PostgreSQL flexible servers do not allow overly permissive public access ranges. Public access should be limited to required IP ranges or disabled to reduce exposure. | Defender for Cloud | April 2026 |
| Azure Database for PostgreSQL flexible server | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL server | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Database for PostgreSQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Databricks Service | 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: https://learn.microsoft.com/azure/databricks/security/secure-cluster-connectivity. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Databricks Service | 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: https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Databricks Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Databricks Service | 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: https://docs.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/vnet-inject. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Databricks Service | 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: https://aka.ms/adbpe. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure file share | Ensure 'SMB protocol version' is set to 'SMB 3.1.1' or higher for SMB file shares | Ensure that SMB file shares are configured to use the latest supported SMB protocol version. Keeping the SMB protocol updated helps mitigate risks associated with older SMB versions, which may contain vulnerabilities and lack essential security controls. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Azure Firewall | Azure Firewall Premium should be enabled | Use network intrusion detection and intrusion prevention systems (IDS/IPS) to inspect the network and payload traffic to or from your workload. Ensure that IDS/IPS is always tuned to provide high-quality alerts to your SIEM solution.For more in-depth host level detection and prevention capability, use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with the network IDS/IPS. | Azure security benchmark | April 2026 |
| Azure Machine Learning workspace | 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: https://aka.ms/azure-ml-aad-policy. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | 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/. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | Network connections should be limited on Azure AI Foundry | This security policy ensures that Azure AI Foundry workspaces have appropriate network security controls in place to limit and control network connections. This includes configuring private endpoints, disabling public network access when appropriate, implementing network access control lists, and ensuring secure network connectivity for AI/ML workloads. | Defender for Cloud | April 2026 |
| Azure Machine Learning workspace | 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: https://docs.microsoft.com/azure/machine-learning/how-to-configure-private-link. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | 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 https://aka.ms/azureml-workspaces-cmk. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | 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: https://learn.microsoft.com/azure/machine-learning/how-to-configure-private-link?view=azureml-api-2&tabs=azure-portal. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace; AI Search; Azure OpenAI; Speech service; Language; Face API | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace; Azure OpenAI; AI Search; Speech service; Language; Face API; Computer vision; Custom vision; Translator | 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 Azure AI service. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace; Azure OpenAI; AI Search; Speech service; Language; Face API; Computer vision; Custom vision; Translator | 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: https://aka.ms/AzurePrivateLink/Overview | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Machine Learning workspace; Azure OpenAI; AI Search; Speech service; Language; Face API; Computer vision; Custom vision; Translator | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Synapse Analytics | 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: https://aka.ms/Synapse. | Microsoft cloud security benchmark v1 | April 2026 |
| Azure Synapse Analytics | 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: https://aka.ms/Synapse. | Microsoft cloud security benchmark v1 | April 2026 |
| Batch account | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Container registry | 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: https://aka.ms/acr/private-link. | Microsoft cloud security benchmark v1 | April 2026 |
| Container registry | 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 https://aka.ms/acr/CMK. | Microsoft cloud security benchmark v1 | April 2026 |
| Container registry | 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: https://aka.ms/acr/privatelink, https://aka.ms/acr/portal/public-network and https://aka.ms/acr/vnet. | Microsoft cloud security benchmark v1 | April 2026 |
| Event Grid | 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: https://aka.ms/privateendpoints. | Microsoft cloud security benchmark v1 | April 2026 |
| Event Grid | 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: https://aka.ms/privateendpoints. | Microsoft cloud security benchmark v1 | April 2026 |
| Event Hub | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | Function apps should use managed identity | Use a managed identity for enhanced authentication security | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | Function apps should require FTPS only | Enable FTPS enforcement for enhanced security. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App | Authentication should be enabled on API endpoints hosted in Function Apps | This policy ensures that authentication is properly configured on API endpoints hosted in Azure Function Apps to prevent unauthorized access and protect sensitive data and functionality from being exposed to unauthenticated users. | Defender for Cloud | April 2026 |
| Function App | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App; App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Function App; App Service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| IoT Hub | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | Azure Key Vault should use RBAC permission model | Enable RBAC permission model across Key Vaults. Learn more at: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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: https://docs.microsoft.com/azure/key-vault/general/network-security and https://aka.ms/akvprivatelink | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | Azure Key Vaults should use private link | Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to key vault, you can reduce data leakage risks. Learn more about private links at: https://aka.ms/akvprivatelink. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | Public network access must be explicitly Disabled | Disable public network access for your key vault so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/akvprivatelink. | Microsoft cloud security benchmark v1 | April 2026 |
| Key vault | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | Ensure clusters are created with Private Nodes | Disable public IP addresses for cluster nodes, so that they only have private IP addresses. Private Nodes are nodes with no public IP addresses. | CIS Azure Kubernetes Service (AKS) Benchmark v1.5.0 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | Public endpoints should be disabled on private Azure Kubernetes Service (AKS) clusters | This policy ensures that Azure Kubernetes Service (AKS) clusters configured as private clusters have their public endpoints properly disabled. When an AKS cluster is configured as private, all public access should be restricted to maintain network isolation and security. | Defender for Cloud | April 2026 |
| Kubernetes service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | [Preview]: Sets Privilege escalation in the Pod spec to false. | Setting Privilege escalation to false increases security by preventing containers from allowing privilege escalation such as via set-user-ID or set-group-ID file mode. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | Mutate K8s Container to drop all capabilities | Mutates securityContext.capabilities.drop to add in "ALL". This drops all capabilities for k8s linux containers | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | Sets automountServiceAccountToken in the Pod spec in containers to false. | Setting automountServiceAccountToken to false increases security by avoiding the default auto-mounting of service account tokens | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | Network policy should be enabled for Azure Kubernetes Service (AKS) clusters | This policy ensures that Azure Kubernetes Service (AKS) clusters have network policies enabled at the cluster level to provide network-level security and traffic control between pods and namespaces. Network policy enablement is fundamental for implementing microsegmentation and controlling network traffic flow within Kubernetes clusters. | Defender for Cloud | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Kubernetes service | 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 https://aka.ms/kubepolicydoc. | Microsoft cloud security benchmark v1 | April 2026 |
| Logic app | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Logic app | Authentication should be enabled on API endpoints hosted in Logic Apps | This policy ensures that authentication is properly configured on API endpoints hosted in Azure Logic Apps to prevent unauthorized access and protect sensitive data and functionality from being exposed to unauthenticated users. | Defender for Cloud | April 2026 |
| Network security group | Ensure that HTTP(S) access from the Internet is evaluated and restricted | This policy audit Network Security Group rules that allow inbound HTTP/HTTPS (TCP 80/443 or any port) from public networks (Internet). | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Network security group | Ensure that SSH access from the Internet is evaluated and restricted | This policy is deprecated. This policy audits any network security rule that allows SSH access from Internet | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Network security group | Ensure Network Access Rules are set to Deny-by-default | Restricting default network access provides a foundational level of security to networked resources. To limit access to selected networks, the default action must be changed. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Network security group | Ensure that RDP access from the Internet is evaluated and restricted | This policy is deprecated. This policy audits any network security rule that allows RDP access from Internet | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Network security group | Ensure that UDP access from the Internet is evaluated and restricted | This policy audits Network Security Group rules that allow inbound UDP access from the Internet (any port). | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Service Bus | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Service Fabric cluster | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Service Fabric cluster | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| SignalR | 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: https://aka.ms/asrs/privatelink. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Private endpoint connections on Azure SQL Database should be enabled | Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Transparent Data Encryption on SQL databases should be enabled | Transparent data encryption should be enabled to protect data-at-rest and meet compliance requirements | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | GUEST user should not be granted permissions on SQL database securables | SQL Server securables (schemas, objects, assemblies, types, etc.) define access boundaries within a database. Granting permissions on any securable to the guest user in user databases can expose data, code, or extended capabilities to identities that are not explicitly provisioned, undermining least privilege. This policy ensures the guest user (database principal guest) has no explicit permissions on securables in Azure SQL Databases or SQL Server databases. | Defender for Cloud | April 2026 |
| SQL database | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Certificate keys should use at least 2048 bits for SQL Databases | This security policy ensures that certificate keys used in SQL databases maintain a minimum key length of 2048 bits. Certificates with shorter key lengths are vulnerable to cryptographic attacks and do not meet current security best practices and compliance standards. | Defender for Cloud | April 2026 |
| SQL database | Principal GUEST should not have access to any user SQL database | The SQL Server GUEST user allows access to a database without an explicit user mapping. If enabled in user databases, it can permit broader or unintended access. This policy detects user SQL databases (excluding system DBs) where the GUEST principal has CONNECT or other permissions. | Defender for Cloud | April 2026 |
| SQL database | 'dbo' user should not be used for normal service operation in SQL databases | The dbo user (database owner) has broad implicit privileges within a SQL Server database. Using dbo for routine application service operations bypasses least privilege controls and increases blast radius in the event of credential compromise or injection vulnerabilities. This policy discourages using the dbo principal for normal application workloads and checks for impersonation grants that could enable privilege escalation. | Defender for Cloud | April 2026 |
| SQL database | Database user GUEST should not be a member of any role in SQL databases | This policy ensures the built-in GUEST database user is not a member of any database role in user databases. The GUEST user can allow access to users without individual database accounts and can unintentionally broaden access when granted role memberships. | Defender for Cloud | April 2026 |
| SQL database | Cell-Level Encryption keys should use AES algorithm in SQL databases | Cell-level encryption (including Always Encrypted column encryption keys) protects specific columns containing sensitive data. Weak algorithms reduce protection strength and may allow ciphertext attacks. This policy validates that column encryption keys (CEKs) and other cell-level symmetric keys use AES-based algorithms. | Defender for Cloud | April 2026 |
| SQL database | Excessive permissions should not be granted to PUBLIC role on objects or columns in SQL databases | The PUBLIC role exists in every SQL Server database and all users inherit its permissions. Granting explicit object or column-level permissions to PUBLIC can unintentionally expose data or functionality broadly. This policy detects object or column permissions explicitly granted to PUBLIC. | Defender for Cloud | April 2026 |
| SQL database | AUTO_CLOSE should be disabled for SQL databases | The AUTO_CLOSE option shuts down a database and releases resources when the last connection closes. In modern workloads this introduces performance overhead (frequent open/close cycles) and can impact availability or monitoring. This policy flags user databases with AUTO_CLOSE ON. | Defender for Cloud | April 2026 |
| SQL database | Excessive permissions should not be granted to PUBLIC role in SQL databases | The PUBLIC role is automatically granted to all users in a database. Any explicit database-level permission (e.g., ALTER ANY USER, VIEW DEFINITION, CONNECT, CONTROL) granted to PUBLIC broadens access for every principal, often unnecessarily. This policy detects excessive database-level grants (class=0) to PUBLIC. | Defender for Cloud | April 2026 |
| SQL database | 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: https://aka.ms/adonlycreate. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Application roles should not be used in SQL databases | This security policy ensures that application roles are not used in SQL Server databases. Application roles are a legacy security mechanism that can introduce security risks and complexity. Modern authentication and authorization approaches provide better security controls and auditing capabilities. | Defender for Cloud | April 2026 |
| SQL database | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | 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: https://aka.ms/adonlycreate. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Asymmetric keys' length should be at least 2048 bits in SQL databases | This security policy ensures that asymmetric keys used in SQL databases maintain a minimum key length of 2048 bits. Asymmetric keys with shorter key lengths (512 or 1024 bits) are vulnerable to cryptographic attacks and do not meet current security best practices. | Defender for Cloud | April 2026 |
| SQL database | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL database | Ensure no Azure SQL Databases allow ingress from 0.0.0.0/0 (ANY IP) | Ensure no Azure SQL Databases allow ingress from 0.0.0.0/0 (ANY IP). | CIS Microsoft Azure Database Services Benchmark v1.0.0 | April 2026 |
| SQL managed instance | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL managed instance | 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 https://aka.ms/mi-public-endpoint. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL server | CLR should be disabled for SQL Servers | The SQL Server "clr enabled" configuration option permits execution of user-defined CLR assemblies within the database engine. When enabled unnecessarily, it expands the attack surface by allowing managed code execution, which can perform complex operations, access external resources, or escalate privileges if unsafe assemblies are loaded. This policy detects SQL Server instances where CLR is enabled and should be disabled per hardening guidance unless a justified business need exists."clr enabled" configuration option permits execution of user-defined CLR assemblies within the database engine. When enabled unnecessarily, it expands the attack surface by allowing managed code execution, which can perform complex operations, access external resources, or escalate privileges if unsafe assemblies are loaded. This policy detects SQL Server instances where CLR is enabled and should be disabled per hardening guidance unless a justified business need exists. | Defender for Cloud | April 2026 |
| SQL server | Execute permissions on xp_cmdshell from all users (except dbo) should be revoked for SQL Servers | This policy checks for the presence of execute permissions on the xp_cmdshell extended stored procedure for principals other than the database owner (dbo) on SQL Servers. xp_cmdshell allows execution of shell commands and is high risk when available to non-DBA principals. | Defender for Cloud | April 2026 |
| SQL server | Database ownership chaining should be disabled for all databases except for 'master', 'msdb' and 'tempdb' on SQL Servers | Ownership chaining in SQL Server allows permissions to cascade across objects with the same owner, bypassing explicit permission checks. Leaving ownership chaining enabled for user databases can inadvertently grant broader data access than intended. This policy detects SQL Server instances where user databases (excluding system databases: master, msdb, tempdb) have ownership chaining enabled. | Defender for Cloud | April 2026 |
| SQL server | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| SQL server | Force encryption should be enabled for TDS for SQL Servers | This security policy ensures that SQL Server instances are configured to force encryption for all Tabular Data Stream (TDS) connections. TDS is the protocol used by SQL Server for client-server communication, and forcing encryption ensures that all data transmitted between clients and the server is encrypted, protecting against network-based attacks and data interception. | Defender for Cloud | April 2026 |
| SQL server | Database communication using TDS should be protected through TLS for SQL Servers | Tabular Data Stream (TDS) is the protocol used by SQL Server for client-server communication. Without TLS protection enforced, TDS traffic can be intercepted or altered. This policy validates that server-level "Force Encryption" is enabled for SQL Server instances and that connections observed are encrypted."Force Encryption" is enabled for SQL Server instances and that connections observed are encrypted. | Defender for Cloud | April 2026 |
| SQL server | Default trace should be enabled for SQL Servers | The SQL Server default trace provides lightweight auditing of key server events (configuration changes, security modifications, object alterations). If disabled, forensic and compliance visibility may be reduced. This policy detects whether the default trace is enabled and flags servers where it is off. | Defender for Cloud | April 2026 |
| SQL server | Account with default name 'sa' should be renamed and disabled on SQL Servers | The built-in SQL Server system administrator login 'sa' is a common target for brute-force attacks. Best practice is to rename and disable this login when not required for legacy operations, reducing attack surface and credential guessing success likelihood. | Defender for Cloud | April 2026 |
| SQL server | CHECK_POLICY should be enabled for all SQL logins for SQL Servers | SQL Server login password policies (CHECK_POLICY) integrate with Windows password policy enforcement (complexity, lockout) for SQL logins. Disabling CHECK_POLICY weakens defenses against brute force and weak password usage. This policy detects SQL Server instances with SQL logins where CHECK_POLICY is OFF. | Defender for Cloud | April 2026 |
| SQL server | Server-level firewall rules should not grant excessive access for SQL Servers | This security policy ensures that server-level firewall rules for Azure SQL Servers do not grant excessive access by restricting overly permissive IP address ranges. Server-level firewall rules control access to the entire SQL server and should follow the principle of least privilege to minimize security exposure across all databases on the server. | Defender for Cloud | April 2026 |
| SQL server | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| SQL server | 'User Options' feature should be disabled for SQL Servers | This security policy ensures that the 'User Options' server configuration option is disabled (set to 0) on SQL Servers. The User Options setting controls default session settings for all user connections and can impact security by allowing potentially unsafe default behaviors across all user sessions. | Defender for Cloud | April 2026 |
| SQL server | Database permissions shouldn't be granted directly to principals for SQL Servers | Granting database-scoped permissions (e.g., ALTER, CONTROL, VIEW DEFINITION) directly to individual logins or users complicates access governance and makes auditing harder. Preferred practice is to assign permissions through database roles (built-in or custom) so membership changes can be managed centrally without enumerating scattered GRANT statements. | Defender for Cloud | April 2026 |
| SQL server | Database Encryption Symmetric Keys should use AES algorithm in SQL databases | Symmetric keys in SQL Server are used to encrypt data at rest (e.g., via EncryptByKey) and to protect other keys. Using weaker or deprecated algorithms (such as RC4, 3DES) increases risk of cryptographic compromise. This policy ensures all user-defined symmetric keys in user databases use an AES-based algorithm (AES_128/192/256) and flags any keys created with non-AES algorithms. | Defender for Cloud | April 2026 |
| SQL server | Vulnerability Assessment should be configured on SQL Server 2012 and higher only | This security policy ensures that Vulnerability Assessment is properly configured and available only on SQL Server 2012 and higher versions. SQL Server Vulnerability Assessment is a security feature that helps discover, track, and remediate potential database vulnerabilities, but it requires SQL Server 2012 (version 11.x) or later to function properly. | Defender for Cloud | April 2026 |
| SQL server | 'OLE Automation Procedures' feature should be disabled for SQL Servers | This security policy ensures that the OLE Automation Procedures feature is disabled on SQL Servers. OLE Automation Procedures allow Transact-SQL batches to instantiate OLE Automation objects, which can introduce security vulnerabilities and expand the attack surface of SQL Server instances. | Defender for Cloud | April 2026 |
| SQL server | BUILTIN Administrators should be removed as a server login for SQL Servers | Historically, the Windows group BUILTIN\Administrators could be provisioned as a SQL Server login, implicitly granting elevated database privileges to all machine administrators. Retaining this login increases risk of broad, unintended database access. This policy detects SQL Server instances where a server principal exists for BUILTIN\Administrators. | Defender for Cloud | April 2026 |
| SQL server | Filestream should be disabled for SQL Servers | This security policy ensures that FILESTREAM is disabled on SQL Servers unless specifically required for business operations. FILESTREAM allows storing unstructured data (BLOBs) as files on the file system, which introduces additional security risks including file system access vulnerabilities, encryption limitations, and expanded attack surface. | Defender for Cloud | April 2026 |
| SQL server | Ad-hoc distributed queries should be disabled for SQL Servers | The SQL Server configuration option "Ad Hoc Distributed Queries" enables the use of OPENROWSET and OPENDATASOURCE to access remote data sources without a linked server definition. Leaving this option enabled increases surface area and can allow unapproved data exfiltration or inbound access paths. This policy ensures that ad-hoc distributed queries are disabled (value_in_use = 0) on managed Azure SQL Servers (IaaS SQL on VM or PaaS SQL Managed Instance / Azure SQL Database servers where applicable) to reduce attack surface."Ad Hoc Distributed Queries" enables the use of OPENROWSET and OPENDATASOURCE to access remote data sources without a linked server definition. Leaving this option enabled increases surface area and can allow unapproved data exfiltration or inbound access paths. This policy ensures that ad-hoc distributed queries are disabled (value_in_use = 0) on managed Azure SQL Servers (IaaS SQL on VM or PaaS SQL Managed Instance / Azure SQL Database servers where applicable) to reduce attack surface. | Defender for Cloud | April 2026 |
| SQL server | Database Mail XPs should be disabled when it is not in use on SQL Servers | The 'Database Mail XPs' configuration option enables extended stored procedures that support Database Mail. If enabled without active mail profiles or legitimate operational need, it increases surface area for misuse and may expose SMTP configuration details. | Defender for Cloud | April 2026 |
| SQL virtual machine | Contained users should use Windows Authentication in SQL Server databases | This security policy ensures that contained database users utilize Windows Authentication rather than SQL Server authentication. Windows Authentication provides stronger security through integrated authentication mechanisms, centralized identity management, and elimination of password storage within the database. | Defender for Cloud | April 2026 |
| SQL virtual machine | Database principals should not be mapped to the sa account in SQL databases | Mapping database principals (users) to the high-privilege server login sa can circumvent intended least-privilege controls and auditing boundaries. This policy detects user databases containing principals mapped to sa or where ownership context implies sa usage. | Defender for Cloud | April 2026 |
| Storage account | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | Ensure that 'Allow Blob Anonymous Access' is set to 'Disabled' | To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | Ensure that soft delete for blobs on Azure Blob Storage storage accounts is Enabled | Blobs in Azure storage accounts may contain sensitive or personal data, such as ePHI or financial information. Data that is erroneously modified or deleted by an application or a user can lead to data loss or unavailability.It is recommended that soft delete be enabled on Azure storage accounts with blob storage to allow for the preservation and recovery of data when blobs or blob snapshots are deleted. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | 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 - https://aka.ms/azureprivatelinkoverview | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | Ensure 'Cross Tenant Replication' is not enabled | Cross Tenant Replication in Azure allows data to be replicated across multiple Azure tenants. While this feature can be beneficial for data sharing and availability, it also poses a significant security risk if not properly managed. Unauthorized data access, data leakage, and compliance violations are potential risks. Disabling Cross Tenant Replication ensures that data is not inadvertently replicated across different tenant boundaries without explicit authorization. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | Ensure that 'Default to Microsoft Entra authorization in the Azure portal' is set to 'Enabled' | When this property is enabled, the Azure portal authorizes requests to blobs, files, queues, and tables with Microsoft Entra ID by default. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | Ensure the 'Minimum TLS version' for storage accounts is set to 'Version 1.2' | 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. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | Ensure that 'Public Network Access' is 'Disabled' for storage accounts | Disallowing public network access for a storage account overrides the public access settings for individual containers in that storage account for Azure Resource Manager Deployment Model storage accounts. Azure Storage accounts that use the classic deployment model will be retired on August 31, 2024. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | Ensure Soft Delete is Enabled for Azure Containers and Blob Storage | The Azure Storage blobs contain data like ePHI or Financial, which can be secret or personal. Data that is erroneously modified or deleted by an application or other storage account user will cause data loss or unavailability.It is recommended that both Azure Containers with attached Blob Storage and standalone containers with Blob Storage be made recoverable by enabling the soft delete configuration. This is to save and recover data when blobs or blob snapshots are deleted. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | Ensure soft delete for Azure File Shares is Enabled | Azure Files offers soft delete for file shares, allowing you to easily recover your data when it is mistakenly deleted by an application or another storage account user. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Storage account | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Storage account | 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 - https://aka.ms/azureprivatelinkoverview | Microsoft cloud security benchmark v1 | April 2026 |
| Stream Analytics job | 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 | Microsoft cloud security benchmark v1 | April 2026 |
| Subscription | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Subscription; Resource group | Service Principals should not be assigned with administrative roles at the subscription and resource group level | This policy detects service principals that have been assigned built-in administrative roles (for example Owner, Contributor, or User Access Administrator) at subscription or resource group scope. Assigning administrative roles to service principals increases risk if the principal is compromised or over-privileged. | Defender for Cloud | April 2026 |
| Virtual machine | Ensure that 'Disk Network Access' is NOT set to 'Enable public access from all networks' | Virtual Machine Disks and snapshots can be configured to allow access from different network resources. | CIS Microsoft Azure Compute Services Benchmark v2.0.0 | April 2026 |
| Virtual machine | 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: https://aka.ms/computevm-windowspatchassessmentmode, for Linux: https://aka.ms/computevm-linuxpatchassessmentmode. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | 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 https://aka.ms/gcpol. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | 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 https://aka.ms/gcpol. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | The Azure Machine should be configured service combines features of DSC Extension, Azure Automation State Configuration. | Define the secure configuration baselines for your compute resources, such as VMs and containers. Use configuration management tools to establish the configuration baseline automatically before or during the compute resource deployment so the environment can be compliant by default after the deployment. Alternatively, use a pre-configured image to build the desired configuration baseline into the compute resource image template. | Azure security benchmark | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | VM system time should use approved time synchronization source | Microsoft maintains time sources for most Azure PaaS and SaaS services. For your compute resources operating systems, use a Microsoft default NTP server for time synchronization unless you have a specific requirement. If you need to stand up your own network time protocol (NTP) server, ensure you secure the UDP service port 123.All logs generated by resources within Azure provide time stamps with the time zone specified by default. | Azure security benchmark | April 2026 |
| Virtual machine | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine | Ensure that 'Enable Data Access Authentication Mode' is 'Checked' | Data Access Authentication Mode provides a method of uploading or exporting Virtual Machine Disks. | CIS Microsoft Azure Compute Services Benchmark v2.0.0 | April 2026 |
| Virtual machine | Ensure Trusted Launch is enabled on Virtual Machines | When Secure Boot and vTPM are enabled together, they provide a strong foundation for protecting your VM from boot attacks. For example, if an attacker attempts to replace the bootloader with a malicious version, Secure Boot will prevent the VM from booting. If the attacker is able to bypass Secure Boot and install a malicious bootloader, vTPM can be used to detect the intrusion and alert you. | CIS Microsoft Azure Compute Services Benchmark v2.0.0 | April 2026 |
| Virtual machine scale set | Enable Trusted Launch security features (Secure Boot vTPM) | Azure security baseline for Virtual Machine Scale Sets | April 2026 | |
| Virtual machine scale set | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine scale set | [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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual machine scale set | Avoid public IP assignments to individual instances | Audits Virtual Machine Scale Sets that have public IP configurations on instance NICs. | Azure security baseline for Virtual Machine Scale Sets | April 2026 |
| Virtual machine scale set | Configure multi-zone deployment for high availability | Azure security baseline for Virtual Machine Scale Sets | April 2026 | |
| Virtual machine scale set | Configure automatic guest patching | Azure security baseline for Virtual Machine Scale Sets | April 2026 | |
| Virtual machine scale set | Enable automatic OS image upgrades | This policy audits any Virtual Machine Scale Set that does not have automatic OS upgrade enabled. | Azure security baseline for Virtual Machine Scale Sets | April 2026 |
| Virtual machine; Virtual machine scale set | 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 https://aka.ms/vm-hbe. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual network | [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 | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual network | Ensure public network access is Disabled | Disable public network access to prevent exposure to the internet and reduce the risk of unauthorized access. Use private endpoints to securely manage access within trusted networks. | CIS Microsoft Azure Foundations Benchmark v4.0.0 | April 2026 |
| Virtual network | 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. | Microsoft cloud security benchmark v1 | April 2026 |
| Virtual network gateway | 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 https://docs.microsoft.com/azure/vpn-gateway/openvpn-azure-ad-tenant. | Microsoft cloud security benchmark v1 | April 2026 |
On this page