✅ Feature availability: This integration is now available for Vanta Government customers.
Overview
If your team runs infrastructure in Azure and manages employee identities through Microsoft Entra ID, this integration brings that data into Vanta automatically. Your team keeps working in Azure. Vanta handles evidence collection, access reviews, and compliance monitoring using the cloud resources, user directory, role assignments, security configurations, and vulnerability findings it reads directly from your environment.
Want the fastest way to get connected? Go to Azure: Quickstart.
⚠️Note on Azure and Entra ID: The Azure integration in Vanta connects to two Microsoft systems: Azure Resource Manager for cloud infrastructure data (VMs, databases, networking, storage) and Microsoft Entra ID for identity data (users, groups, roles, MFA). Both are accessed through a single integration tile in Vanta called "Azure." When this guide refers to Entra ID, it means the identity system that the Azure integration reads from — not a separate integration.
What you can do with this integration
Automatically collect evidence across SOC 2, ISO 27001, NIST 800-53, FedRAMP, HITRUST, CIS v8, CJIS, NIS2, TISAX, and 23 NYCRR 500.
Track whether Azure users have MFA enforced via Conditional Access.
Verify that terminated employees have had their Entra ID accounts deactivated.
Bring users, groups, and role assignments into access review workflows.
Collect vulnerability findings from Microsoft Defender for Cloud.
Monitor cloud resource configurations across compute, networking, storage, databases, and containers.
Two Azure integrations | one Entra tenant
Vanta supports two distinct Azure integrations, each configured independently:
Integration | What it does | Setup method |
Azure (this guide) | Reads cloud resource configurations from Azure Resource Manager and identity data (users, groups, roles, MFA) from Entra ID | App registration via Cloud Shell or Azure Portal |
Azure SCIM | Provisions and deprovisions Vanta user accounts based on Entra ID assignments. Does not read cloud resources. | Entra enterprise app provisioning configuration |
Setting up one does not configure the other. If users are syncing but provisioning isn't working, or if you're seeing unexpected user counts after enabling SCIM, the cause is almost always a misconfiguration in the SCIM layer specifically. See How the Azure connection and SCIM work together for details.
Connection details
ℹ️ Note on multiple Vanta workspaces: The same Azure tenant can be connected to more than one Vanta workspace. There is no restriction enforcing a one-to-one relationship between Azure tenants and Vanta workspaces.
Detail | Value |
Connection type | Service principal (app registration) with client secret |
API surfaces | Azure Resource Manager (ARM) for cloud infrastructure; Microsoft Graph API for directory and identity data |
Access level | Read-only. Vanta never writes to your Azure environment. |
Resource types collected | ~45 across compute, databases, networking, storage, identity, monitoring, containers, and vulnerabilities |
Service variants | Commercial Azure and Azure for Government (including DoD IL5) |
Who should connect | A Global Administrator or Privileged Role Administrator in Microsoft Entra ID |
Client secret expiry | 1 year from connection date |
What Vanta collects and why
This section covers the data Vanta reads from Azure and why each category is collected. For how this data powers specific Vanta workflows, see Use cases and capabilities.
This section covers the data Vanta reads from Azure and why each category is collected. For how this data powers specific Vanta workflows, see Use cases and capabilities.
Identity and directory data (Microsoft Graph)
Data | What Vanta collects | Why it's collected |
Users | ID, email, display name, account status, creation time, last sign-in | Powers personnel records, access reviews, deprovisioning tests |
MFA status | Whether MFA is enabled per account, Conditional Access policy enforcement | Powers MFA compliance tests |
Groups | Group ID, name, member list | Access reviews, IdP group imports, scoping |
Role assignments | Role type, assignment target, assignment method (direct or via group) | Surfaces privileged access; powers access reviews |
Service principals | App ID, display name, assigned permissions | Vendor and application visibility |
ℹ️ Note: Vanta detects MFA enforcement via Conditional Access policies, which requires a Microsoft Entra ID P1 license (not included with M365 Business Standard).
Cloud resources (Azure Resource Manager)
Category | What Vanta collects |
Compute | Virtual machines, scale sets, Azure Functions |
Databases | Azure SQL, Cosmos DB, PostgreSQL, MySQL, and others |
Networking | Network security groups, firewalls, load balancers, Front Door, Application Gateway, Traffic Manager |
Storage | Blob storage, file shares, managed disks |
Containers | AKS clusters, container registries |
Monitoring | Activity logs, diagnostic settings, alert rules |
Security | Defender for Cloud findings (requires Defender plans enabled in Azure) |
Key management | Key Vault secrets and access policies (requires Key Vault Reader role) |
What Vanta does not collect or do
What | Detail |
User credentials or passwords | Never read |
Authentication tokens | Not accessed |
Write access to Azure | Vanta does not create, modify, or delete any data in your Azure environment |
Real-time data | Data is synced on a scheduled cadence, not in real time |
Prerequisites and readiness checklist
Complete all items in this checklist before starting setup.
Complete all items in this checklist before starting setup.
Confirm your Azure role
The connecting account must have Global Administrator or Privileged Role Administrator in Microsoft Entra ID. These are Entra ID directory-level roles, not Azure subscription-level roles. The Azure integration requires directory-level permissions because it reads identity data from Entra ID in addition to cloud resources. Subscription-level roles (Owner, Contributor) are not sufficient.
ℹ️ Note: Admin consent is a directory-level grant that allows the Vanta app registration to read data across your tenant. App assignment controls which users can sign in to an application. These are different things. The integration requires admin consent. App assignment alone will not resolve permission errors.
Configure required permissions
Permission | Type | Required for |
Reader | Azure role on subscription or tenant | Collecting cloud resource data |
Directory.Read.All | Microsoft Graph application permission (admin consent required) | Collecting Entra identity data |
Key Vault Reader | Azure role on each Key Vault | Key Vault monitoring (optional) |
Policy.Read.All | Microsoft Graph application permission | CIS Benchmark policy data (optional) |
⚠️ Note: Directory.Read.All must be granted as Application type with admin consent. Delegated type will not work and is the most common cause of user data not appearing in Vanta.
Confirm license requirements
Basic Azure connection: no Entra license required.
Microsoft Entra ID P1 required for: group-based scoping, Conditional Access MFA detection. P1 is included with M365 Business Premium, E3, E5, or available as a standalone add-on. M365 Business Standard does not include P1. Entra P2 is only required for risk-based Conditional Access policies.
Decide which integrations you need
Cloud resource monitoring + identity data only? Azure API integration (this guide).
Cloud resource monitoring + user/group provisioning into Vanta? Azure API integration + Azure SCIM.
Choose your connection type
Type | Use when |
Subscription | You have one subscription, or a small number to connect individually |
Tenant | You have many subscriptions under a single tenant and want to connect them all at once |
Plan for client secret expiry
The client secret created during setup expires in 1 year. Set a calendar reminder at connection time. An expired secret is the most common cause of integration errors.
Readiness checklist — quick reference
You have Global Administrator or Privileged Role Administrator in Entra ID.
You have Vanta admin access.
You've decided between Subscription and Tenant connection type.
You've confirmed which optional products you want to enable (Defender, AKS, Key Vault).
You've set a reminder for client secret renewal in 1 year.
If using SCIM: SSO is fully configured and working before you proceed. See How the Azure connection and SCIM work together.
Setup guide
Connect using Cloud Shell (recommended)
Cloud Shell is the fastest and least error-prone path. Full step-by-step instructions are in the Azure: Quickstart.
Connect using the Azure Portal (manual)
Use this method if you cannot use Cloud Shell, or if your organization requires manually reviewing each step of the app registration process.
Use this method if you cannot use Cloud Shell, or if your organization requires manually reviewing each step of the app registration process.
From the left-hand navigation panel in Vanta, select Integrations.
Click Add Integration and search for Azure.
In the right panel that slides out, select Connect.
Choose your connection type
Supported connection patterns
Before connecting, review what Vanta supports for Azure:
You can connect multiple subscriptions to a single Vanta workspace (each linked individually).
You can connect multiple tenants to a single Vanta workspace (each set up using the Tenant connection flow).
You can connect individual subscriptions that belong to the same or different tenants.
The same Azure tenant can be connected to multiple Vanta workspaces — each workspace maintains its own independent connection and app registration.
You cannot mix tenant-level and subscription-level connections within a single Vanta workspace. If you previously connected subscriptions directly and want to switch to a tenant connection, you must unlink those subscription connections first.
For step-by-step instructions on adding multiple connections, see:
If you don't see the option to add additional tenants, contact Vanta Support.
Select the connection type:
Subscription - Choose this option if you have one or a few subscriptions. Each subscription must be linked individually.
Tenant - Choose this option if you manage multiple subscriptions under a single tenant.
Select Azure Portal, then click Next.
Select Products
Microsoft Azure is enabled by default and cannot be disabled.
If you use Microsoft Azure Kubernetes Monitoring and/or Microsoft Defender for Cloud for vulnerability scanning, enable these options to populate the Vulnerabilities page in Vanta. Hover over the tooltip for more information.
Click Next.
Select your Azure subscription
ℹ️ Note: These steps assume you have at least one Azure subscription. If you do not see any subscriptions, verify that your account has access to a subscription in Azure.
Click the Subscriptions hyperlink on this page, or navigate directly to Subscriptions in the Azure portal.
Copy the subscription ID.
Paste the subscription ID into the corresponding field in Vanta.
Register the Vanta application
In the Azure Portal, navigate to App Registrations.
Click + New registration.
Enter vanta-scanner as the application name and keep all default settings.
Click Register.
Copy the Application (client) ID and the Directory (tenant) ID to paste into Vanta.
Paste the values into their respective fields on the Register the Vanta Application page in Vanta.
Create a client secret
In the Azure portal, open the newly created app registration.
Navigate to Certificates & secrets.
Under Client secrets, click + New client secret.
Click Add.
Copy the Client Secret Value immediately.
⚠️ Note: The Client Secret Value is only visible at the time it is created. Once you leave the Certificates & secrets page, you will not be able to retrieve it again. Be sure to copy and store it securely before proceeding.
Paste the Client Secret Value on the Create a Client Secret page in Vanta and click Next.
Configure app access
In the Azure Portal, open the same app registration and navigate to API permissions.
Click + Add a permission.
Select Microsoft Graph.
Choose application permissions.
Search for and select
Directory.Read.All.Click Add permissions.
Click Grant admin consent for Your Organization.
Confirm by selecting Yes.
Return to Vanta and click Next.
Assign the reader role
In the Azure Portal, navigate to your Subscription.
Select Access control (IAM).
Click + Add, then select Add role assignment.
Under Role, select Reader, then click Next.
Click + Select members.
Search for the vanta-scanner application you created earlier and select it.
Click Select.
Review the configuration and click Review + assign.
Return to Vanta and click Next.
Check connection
If the setup was completed successfully, Vanta will display a confirmation screen indicating that the connection was established.
Optional configurations
Enables node-level security tests for AKS clusters. Enable in Integrations > Azure > Configure.
ℹ️ Note: Private clusters are not supported for node-level scanning. Vanta will list private clusters in inventory, but node security tests will not apply to them.
Microsoft Defender for Cloud
Required for vulnerability data to appear on the Vanta Vulnerabilities page. Enable in Integrations > Azure > Configure, then confirm the following in Azure:
The appropriate Defender plan is enabled (Defender for Containers or Defender for Servers).
Monitoring coverage is set to Full.
At least one scan has been completed.
If Vanta shows "No vulnerability data received," see No vulnerability data received (Azure).
Azure Key Vault
Enables monitoring of Key Vault keys and secrets for security best practices including expiration, rotation, and access controls.
If you connected via Cloud Shell and toggled on Azure Key Vault during setup, the Key Vault Reader role was assigned automatically by the script. No additional action is needed.
If you connected via the Azure Portal, manually assign the Key Vault Reader role to the Vanta app registration on each Key Vault you want monitored. Navigate to each Key Vault > Access control (IAM) > Add role assignment > select Key Vault Reader > assign to the Vanta app registration.
How the Azure connection and SCIM work together
This section covers one of the most common sources of configuration problems in the Azure integration. Read it before enabling SCIM.
This section covers one of the most common sources of configuration problems in the Azure integration. Read it before enabling SCIM.
The standard Azure connection is the foundation
When you connect Azure through the standard setup flow, Vanta uses the Microsoft Graph API with Directory.Read.All permission to read user and group data from Entra ID. This is the foundation of the integration. It handles identity data, access reviews, MFA detection, and group visibility in Vanta.
SCIM is a separate, optional layer
SCIM (System for Cross-domain Identity Management) handles the provisioning and deprovisioning of users into Vanta. It is not the same as the standard Azure connection and is not interchangeable with it.
ℹ️ Note: Both integrations connect to Entra ID. The standard Azure integration reads data from it, while SCIM writes provisioning changes based on it.
| Azure connection (standard) | SCIM |
Purpose | Read identity and cloud data for compliance | Provision and deprovision users in Vanta |
Required | Yes, for the integration to function | No — optional |
Configured in | Azure app registration + Vanta integration settings | Entra enterprise app + Vanta integration settings |
Scoping behavior | Controlled by scoping settings in Vanta | Overrides Vanta scoping settings entirely |
Required setup order
Required setup order
SSO must be fully configured and working before you enable SCIM.
Enabling SCIM before SSO setup is complete can result in a partially broken authentication state that locks users out of Vanta. Complete SSO setup first, confirm it is working, then enable SCIM.
SCIM overrides scoping settings — and does so silently
If SCIM is enabled, the Entra scoping settings in Vanta (for example, "sync only users in these groups") no longer take effect. SCIM becomes the sole source of truth for which users are synced into Vanta.
This means:
Users you excluded via scoping settings may reappear in Vanta after SCIM is enabled.
Scoping changes made in Vanta after enabling SCIM will have no effect.
There is no in-product warning when SCIM overrides your scoping configuration.
When SCIM is enabled, manage user scoping through Entra's enterprise app assignment in Azure, not through Vanta's integration scoping settings.
Enabling SCIM requires configuration on both sides
Enabling SCIM requires configuration on both sides
Toggling SCIM on in Vanta is not sufficient. You must also:
Assign users or groups to the Vanta enterprise app in Entra. Users must be explicitly assigned before SCIM will provision them.
Configure provisioning mappings in Entra. Navigate to the Vanta enterprise app → Provisioning → configure attribute mappings. See Azure SCIM attribute instructions for details on the
rbac_role_idcustom attribute, which does not appear natively in Entra's UI and must be added manually.Enable provisioning in Entra. Set provisioning status to On in the Entra portal. Toggling SCIM on in Vanta does not start provisioning.
Three named failure modes
Three named failure modes
⚠️ SSO lockout: Configuring SCIM before SSO setup is complete can lock users out of Vanta. Always confirm SSO is working before enabling SCIM.
⚠️ SCIM enabled, no users provisioned: If SCIM is toggled on in Vanta but no users are appearing or being deprovisioned, check: (1) users are assigned to the Vanta enterprise app in Entra, (2) provisioning mappings are configured, (3) provisioning is set to On in the Entra portal. Toggling on in Vanta alone is not enough.
⚠️ SCIM silently overrides scoping: If user counts changed unexpectedly after enabling SCIM, or if scoping settings stopped having any effect, SCIM is overriding them. To resolve: disable SCIM, reconfigure scoping via integration settings, then re-evaluate whether SCIM is needed and manage scoping through Entra's enterprise app assignment instead.
Configure user scoping
By default, Vanta imports all users from Entra ID. To limit which users appear in Vanta, use scoping.
By default, Vanta imports all users from Entra ID. To limit which users appear in Vanta, use scoping.
⚠️ Note: Scoping settings in Vanta do not apply when SCIM is enabled. If SCIM is enabled, manage scoping through Entra's enterprise app assignment. See How the Azure connection and SCIM work together.
How it works: When scoping is enabled, Vanta treats the configured scope as the source of truth. Only users matching your scope criteria will sync.
Setup:
In Vanta, go to Integrations > Azure > Configure scope.
Define your scope using users or Entra groups.
Service accounts and test accounts: Service accounts and test accounts in Entra will sync to Vanta by default and will appear in access reviews and user counts. To prevent this, exclude them via scoping, or use group-based scoping to define a group of human employees and scope to that group only.
⚠️ Note: Scoping interacts with offboarding. If your offboarding process removes users from the scoped group, those users will disappear from Vanta — including terminated employees you may still need for audit evidence. To preserve audit visibility, either keep terminated users in the scoped group (while deactivating them in Entra), or manage scope directly in Vanta.
Government cloud environments
⚠️ Note: Using Azure for Government? The Azure for Government integration is a separate tile available only in Vanta Government environments. The standard Azure setup flow covered in this guide is for commercial Azure only. If your organization is on a Vanta Government plan, search for Azure for Government in your integrations catalog instead of Azure. Follow the setup steps from that tile.
US Government and US Government DoD IL5
Vanta supports two US Government cloud variants:
US Government: standard government cloud
US Government DoD IL5: Department of Defense Impact Level 5
⚠️ Note: US Government DoD IL5 uses a different Microsoft Graph endpoint (dod-graph.microsoft.us) than standard US Government. Selecting the wrong variant will cause Graph API calls to fail silently or return no data. Confirm your environment before completing setup.
GCC High
GCC High environments have distinct endpoint and configuration requirements. Contact Vanta Support before proceeding.
Verification and validation
After setup, confirm the following to verify the integration is working and data is syncing.
Integration is active — Go to Integrations and confirm Azure shows Connected with a recent sync timestamp.
Resources are appearing — Go to Inventory. Azure resources should appear across the relevant categories.
Users are syncing — Go to People. Entra ID users should appear and be linked to personnel records.
Compliance tests are populating — Go to Tests. MFA, deprovisioning, and resource configuration tests should show data.
Role assignments are visible — Open a user's profile. Entra ID role assignments should appear. If they don't, confirm Directory.Read.All was granted as Application type with admin consent.
Vulnerability data is appearing (if Defender is enabled) — Go to Vulnerabilities. Data should appear after the first scan completes in Azure.
Use cases and capabilities
Quick reference
Resource / Capability | Supported | How it's used in Vanta |
Users | Yes | Personnel records, access reviews, deprovisioning tests, evidence |
Groups | Yes | Access reviews, scoping |
Role assignments | Yes | Surfaces privileged access; access reviews |
MFA enforcement | Yes (requires Entra P1/P2 + Conditional Access) | Automated compliance tests |
Cloud resource inventory | Yes | Compliance tests, evidence collection |
Vulnerability findings | Yes (requires Defender for Cloud) | Vulnerabilities page, compliance tests |
AKS node monitoring | Yes (private clusters not supported) | AKS security tests |
Key Vault monitoring | Yes (Cloud Shell assigns role automatically; Portal path requires manual role assignment) | Key management evidence |
User provisioning (Entra → Vanta) | Via SCIM only | Separate setup required |
Personnel management and lifecycle
Personnel management and lifecycle
Vanta uses Entra ID as a live source of identity data, syncing user profiles, account status, group memberships, role assignments, and MFA enrollment on a regular cadence.
What this powers in Vanta:
People section: Entra ID accounts are matched to Vanta user records by email address and appear on the People page with account status, role assignments, and MFA enrollment visible.
Access reviews: Synced users, groups, and roles surface in Vanta's access review workflows.
Automated tests: User data powers the core identity compliance tests.
⚠️ Note: Vanta's source of truth for employment status is your HRIS, not Entra ID. If a user is active in Entra but marked as terminated in your HRIS, Vanta will show them as terminated. If a user appears unexpectedly terminated in Vanta, check their status in your HRIS first.
Automated compliance tests
Automated compliance tests
Azure data powers several automated compliance tests in Vanta, depending on your framework and configuration. Tests run continuously and update as Vanta syncs new data.
MFA on Azure
Vanta checks whether every in-scope Entra user account has MFA enforced via Conditional Access.
Passes when all in-scope users have MFA enforced.
Fails when one or more users are not covered by an active Conditional Access policy requiring MFA.
Requires Entra P1 or P2. Per-user legacy MFA is not evaluated.
Azure accounts are associated with active users in Vanta
Vanta checks whether each active Entra account can be matched to a known, active user in Vanta.
Passes when every active Entra account is linked to an active Vanta user record.
Fails when an active account cannot be matched, or is matched to a user marked as terminated.
Matching is done by email address.
Troubleshooting and FAQs
"Insufficient permissions" or connection failure at setup
Likely cause: The account used does not have the required Entra ID role, or admin consent was not granted.
Fix: Re-run setup using an account with Global Administrator or Privileged Role Administrator role. Confirm
Directory.Read.Allshows Granted status (Application type) — not Pending.
Integration shows as broken or disconnected
Likely cause: The client secret has expired (expires after 1 year).
Fix: In the Azure Portal, navigate to your Vanta app registration > Certificates & secrets. Create a new client secret and copy the value. In Vanta, go to Integrations, select Azure, and update the secret.
Azure users or groups not appearing in Vanta
Likely cause:
Directory.Read.Allwas not granted with admin consent, or granted as Delegated rather than Application type.Fix: Confirm the permission is Application type with admin consent showing Granted. Allow up to a few hours for the initial sync to complete.
MFA not showing as enforced
Likely cause: MFA enforcement via Conditional Access requires a Microsoft Entra ID P1 license. P1 is included with M365 Business Premium, E3, and E5 — but not M365 Business Standard, which uses the Entra ID Free tier. Per-user legacy MFA and Security Defaults are not detectable by Vanta as Conditional Access policies.
Fix: Confirm your tenant has an Entra P1 or P2 license. Confirm MFA is enforced via Conditional Access policies.
SCIM enabled but no users provisioned
Likely cause: Provisioning was toggled on in Vanta only — configuration in the Entra portal is incomplete.
Fix: Confirm (1) users are assigned to the Vanta enterprise app in Entra, (2) provisioning mappings are configured, and (3) provisioning is set to On in the Entra portal. See How the Azure connection and SCIM work together.
A resource type isn't appearing in Vanta
Likely cause: The Azure resource provider is not registered in your subscription.
Fix: In the Azure Portal, go to Subscriptions > Resource providers and confirm the relevant provider is registered and not in a Failed state.
No vulnerability data received