The Azure integration enables security, compliance, and IT administrators to streamline access reviews and automate evidence collection. It connects Drata to Azure so your team can monitor user access and demonstrate infrastructure security compliance.
Key Capabilities:
Access Reviews: Automatically pull user access data from Microsoft Entra into Drata for streamlined access certification.
User and Group Data: Syncs user and group information to support identity and access management controls.
Audit Evidence Automation: Collects and maintains audit-ready evidence for compliance monitoring and reporting.
Azure is an infrastructure connection in Drata and is used to review access to Azure resources. Identity management and personnel synchronization for Microsoft environments are handled through the Microsoft 365 / Microsoft 365 GCC High identity connection.
Prerequisites & Data Access
Account / Role Needed:
Microsoft Entra tenant with the Global Administrator role
To register the Drata app, create client secrets, and grant Graph API permissions.
Access to Azure subscription(s) to assign the Reader role (and Key Vault Reader role for GCC High).
To assign the Reader role (and Key Vault Reader role in GCC High) to the Drata app.
Additional Notes:
If you want to connect multiple Microsoft subscriptions, refer to Azure Management Groups connection.
You can limit or customize who is synced into Drata by specifying group object IDs. To learn more, go to Microsoft's Edit group settings.
Each member within the top level of a group is synced.
Nested groups sync as one individual; members of nested groups are not pulled individually. For complex scenarios, use Microsoft's dynamic group feature.
Permissions & Data Table
Drata requires the following Microsoft Graph API application permissions and Azure RBAC role assignments.
Permission / Scope | Why It’s Needed | Data Accessed (Read Only) |
User.Read.All | Used in access reviews to import personnel. | User directory data |
Reports.Read.All | Used in evidence collection (e.g., MFA checks). | Audit & usage reports |
Directory.Read.All | Used when syncing groups into Drata. | Group memberships, directory info |
Policy.Read.All | Used in monitoring to confirm policy configurations. | Policy objects |
AuditLog.Read.All | Used in infrastructure monitoring to detect changes (e.g., role or policy updates). | Audit log data |
Reader role | Provides subscription-wide read-only visibility. | Infrastructure configuration data |
Key Vault Reader role (GCC High) | Required only in Azure GCC High environments. Grants read-only access to Key Vault properties and metadata (not secrets/keys). | Key Vault metadata (properties only) |
Step-by-Step Setup
Step 1: Register a new Drata App in Microsoft
Log into the Microsoft Entra portal with Global Administrator role.
Within the Entra portal, navigate to App Registration > New Registration.
Application name:
Drata Entra AppSupported account types: Accounts in this organizational directory only
Redirect URL: Leave blank.
Copy the Application (client) ID and Directory (tenant) ID.
Enter these values in Drata:
Tenant ID: Entra’s Directory (tenant) ID.
Application ID: Entra’s Application (client) ID.
Step 2: Create a Client Secret
Follow Microsoft’s documentation on how to add a client secret.
Within the Drata Entra App created in Step1, navigate to “Certificates & secrets” and select “New client secret”
Description: Drata application secret
Expiration: 24 months
Note: The integration gets disconnected when the secret expires, so we recommend setting a reminder to ensure it stays active.
(❗Important Step) Copy the secret value (not the secret ID).
(❗Important Step) Refresh the Certificates & Secrets page to confirm activation.
Note: Microsoft holds the client secret in a pending state until the page is refreshed.
Paste the secret value into Drata’s Application Secret field.
Step 3: Add Permissions
To learn more about Microsoft's read-only permissions, refer to Microsoft’s documentation: Application permission to Microsoft Graph.
On your newly registered app overview page, in the left sidebar, under Manage and select API permissions.
Select + Add a permission.
Select Microsoft Graph API → Application permissions.
Add the following 5 permissions:
User.Read.AllReports.Read.AllDirectory.Read.AllPolicy.Read.AllAuditLog.Read.All
Select Add permissions, then Grant admin consent.
Note about User.Read permission:
When you register a new application in Microsoft Entra, Microsoft automatically assigns the delegated permission User.Read. This only allows a signed-in user to read their own profile. Drata does not use this permission.
Instead, Drata requires the application permission User.Read.All, which provides directory-wide read access needed for access reviews. You do not need to remove User.Read; it can remain in place but is unused by Drata.
Step 4: Assign Azure Roles
Find subscription ID:
In Azure Subscriptions, copy your Subscription ID and enter it into Drata. Refer to Microsoft’s documentation to find your Azure subscription ID.
Assign the Reader role to the Drata App:
In the Azure portal, go to your subscription → Access control (IAM).
Select + Add → Add role assignment. For more information, refer to Step 2: Open the Add role assignment page.
Choose the Reader role (built-in). For more information, refer to Step 3: Select the appropriate role.
Important (Azure GCC High only): In addition to the Reader role, you must also assign the Key Vault Reader role to the Drata Entra App in your subscription.
Under Assign access to, select User, group, or service principal.
Select + Select Members and choose your service principal Drata Entra App.
Select Review + assign to complete the role assignment. Refer to Microsoft’s documentation to learn how to select who needs access.
Save the assignment. Refer to Microsoft’s documentation to learn how to select who needs access ( Skip steps 5-9 since Drata does not manage identities).
Choose Who to Sync into Drata
In Drata, you can select who you would like to sync from Azure. Choose who you want to bring into Drata from this infrastructure provider
Everyone → Sync all members.
Specific Groups → Enter group object IDs.
To learn more about Microsoft's group settings and group object ID, go to Microsoft's Edit group settings.
Nested groups sync as one entity.
For complex scenarios, use dynamic groups.
Note: Each member within the top level of a group is synced. Nested groups are synced as one individual. Individual members of any nested group are not synced. For more complex group membership, refer to Microsoft's dynamic group feature.
Complete the Connection: Azure
When connecting, enter the following values from Azure:
Drata Field | Azure Value (Where to Find It) |
Tenant ID | Directory (tenant) ID from the app’s Overview page in Entra. |
Application ID | Application (client) ID from the app’s Overview page in Entra. |
Client Secret Value | Secret Value generated in Certificates & Secrets (not Secret ID). |
Subscription ID | Subscription ID from the Subscriptions page in the Azure portal. |
For steps on accessing and using the Connections page in Drata, refer to The Connections Page in Drata.
Important Notes
Expired secrets disconnect the integration — refresh regularly.
Integration enforces the principle of least privilege (read-only).
Edge Cases:
Nested groups sync as one entity only.
Expired/missing secrets cause failures.
Monitoring tests covered
Azure Resources
A table listing each Azure-related Drata test and the specific Azure resource it relies on, showing customers exactly what parts of Azure Drata reads to run each test.
Test Name | Azure Resource(s) |
Test 4: SSL/TLS on Admin Page of Infrastructure Console | N/A |
Test 69: Customer Data in Cloud Storage is Encrypted at Rest | Azure Storage Account |
Test 88: MFA on Infrastructure Console | Azure Users (Azure AD) |
Test 95: Infrastructure Accounts Properly Removed | N/A |
Test 98: Employees Have Unique Infrastructure Accounts | N/A |
Test 104: Cloud Data Storage Exposure | Azure Storage Accounts / Containers |
Test 107: Daily Database Backups | Azure Managed Databases (MySQL, Postgres, MSSQL, MariaDB, SQL Managed Instance) |
Test 108: Storage Data Versioned or Retained | Azure Storage Accounts (Blob Versioning) |
Test 112: Database CPU Monitored | Azure SQL / Azure MariaDB / MySQL / PostgreSQL / SQL Managed Instance |
Test 113: Database Free Storage Space Monitored | Azure SQL / Azure MariaDB / MySQL / PostgreSQL / SQL Managed Instance |
Test 114: Database Read I/O Monitored | Azure SQL / Azure MariaDB / MySQL / PostgreSQL / SQL Managed Instance |
Test 117: NoSQL Cluster Storage Utilization Monitored | Azure CosmosDB |
Test 118: Infrastructure Instance CPU Monitored | Azure Virtual Machines / Azure Kubernetes Service / Azure Container Instances |
Test 243: Azure Log Alert for Create Policy Assignment | Azure Monitor Activity Log Alert |
Test 244: Azure Log Alert for Delete Public IP Address | Azure Monitor Activity Log Alert |
Test 245: Azure Log Alert for Delete Policy Assignment | Azure Monitor Activity Log Alert |
Test 246: Azure Log Alert for Create or Update Network Security Group | Azure Monitor Activity Log Alert |
Test 247: Azure Log Alert for Delete Network Security Group | Azure Monitor Activity Log Alert |
Test 248: Azure Log Alert for Create or Update Security Solution | Azure Monitor Activity Log Alert |
Test 249: Azure Log Alert for Delete Security Solution | Azure Monitor Activity Log Alert |
Test 252: Azure Log Alert for Create or Update Public IP Address Rule | Azure Monitor Activity Log Alert |
Test 253: Azure Storage Accounts Accessed Via Private Endpoints | Azure Storage Account Private Endpoints |
Test 256: Azure SQL Servers Auditing | Azure SQL Server Auditing |
Test 257: Azure PostgreSQL Database Server Log Checkpoints | Azure PostgreSQL Server Parameters |
Test 263: Azure Storage Accounts Secure TLS Configuration | Azure Storage Account TLS Settings |
Test 268: Azure Network Security Group SSH Public Access Restricted | Azure Network Security Groups |
Test 269: Azure App Service Web App Redirects HTTP Traffic to HTTPS | Azure App Service Web Apps |
Test 250: Azure Log Alert for Create or Update SQL Server Firewall Rule | Activity Logs → SQL Server Firewall Rule events |
Test 251: Azure Log Alert for Delete SQL Server Firewall Rule | Activity Logs → SQL Server Firewall Rule events |
Test 254: Azure Key Vaults Key Expiration | Key Vault → Keys (expiration metadata) |
Test 270: Azure SQL Data Encryption | SQL Databases → Transparent Data Encryption (TDE) configuration |