> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/microsoft-azure-cloud-onboarding/onboard-microsoft-azure.md).

# Onboard Microsoft Azure

Follow the Azure onboarding wizard, and Cortex creates a custom authentication template to be executed in Azure.

Use the cloud onboarding wizard to integrate a Microsoft Azure environment with Cortex Cloud. The onboarding wizard requires minimal configuration to set up the integration. To complete the minimum configuration, define the scope of the Microsoft Azure accounts and specify the scan mode. Alternatively, configure the advanced settings for full control of the onboarding process.

Cortex Cloud generates a Terraform or ARM authentication template based on the configuration settings. The authentication template establishes trust with Microsoft Azure. The authentication template also grants required permissions to Cortex Cloud. Execute the authentication template in Microsoft Azure to complete the onboarding process. Executing the authentication template notifies Cortex Cloud of the execution details. Cortex Cloud then creates a new cloud instance.

### Onboard Microsoft Entra ID only

You can onboard Microsoft Entra ID independently of a full tenant-level onboarding. When you select the Onboard Microsoft Entra ID only option during onboarding with Tenant scope, Cortex Cloud connects to Entra ID to unlock identity-based capabilities, including Cloud Infrastructure Entitlement Management (CIEM), identity posture assessment, and Entra ID sign-in log ingestion. This approach enables identity visibility without requiring Cortex Cloud to scan or manage the broader Azure tenant environment.

When you onboard Entra ID only, Cortex Cloud operates in collection-only mode. Scan mode selection and scope modification are not available for this configuration. Both Terraform and ARM authentication templates are supported, and manual onboarding is also available. Cortex Cloud generates the appropriate authentication template based on your selection, and you execute it in Microsoft Azure to complete the onboarding process.

If you enable audit log collection with Entra ID-only onboarding using automated collection, Cortex Cloud ingests sign-in and activity log categories including: SignInLogs, AuditLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, ProvisioningLogs, ADFSSignInLogs, and MicrosoftGraphActivityLogs. Administrative category logs are excluded from automated collection. If you configure custom diagnostic settings, log ingestion follows your specified configuration.

You can later expand an Entra ID-only configuration to full tenant scope by editing the onboarding configuration. This approach lets you to begin with identity-focused onboarding and transition to comprehensive tenant coverage as requirements evolve.

### About the Cortex Cloud service principal

A service principal is an identity that an application uses to authenticate and interact with Azure resources. When Cortex Cloud connects to your Azure tenant, Cortex Cloud uses a service principal as its runtime identity in that tenant.

Cortex Cloud uses the service principal to:

* Authenticate to your Azure tenant without requiring interactive user sign-in during ongoing operations.
* Perform the role assignments and resource provisioning defined in the authentication template you execute during onboarding.
* Operate within the custom roles and scoped permissions you grant, following the principle of least privilege.

When you onboard an Azure tenant for the first time, Cortex Cloud checks automatically whether the Cortex service principal already exists in your tenant when you enter your tenant ID in the onboarding wizard. If the Cortex service principal does not yet exist in your tenant, you must create it before you can proceed with onboarding. Cortex Cloud displays the Azure CLI command to run in the onboarding wizard. The user who runs this command must have the Application Administrator built-in Entra ID role. The Application Administrator role is required only to create the Cortex service principal. After the service principal exists in your tenant, you do not need this role to complete the rest of the onboarding process.

### Automated deployment per subscription with Azure policy

When you onboard an Azure Management Group or Tenant, Cortex Cloud uses a native Azure Policy with the `deployIfNotExists` effect to keep every subscription under that scope covered automatically, including subscriptions created after onboarding.

#### Why Cortex Cloud deploys into each subscription

Cortex Cloud creates a dedicated resource group (`cortex-{suffix}`) in every in-scope subscription. Two Azure constraints drive this:

* **Ephemeral scan resource containment:** Capabilities like DSPM and Agentless Disk Scanning (ADS) generate short-lived artifacts during scans. A dedicated resource group limits write/delete permissions to that group rather than the whole subscription, and gives you a single container for auditing, cost attribution, and cleanup.
* **Scoped role placement:** Some permissions (such as data actions for reading blob or file data) cannot be assigned at the Management Group level due to Azure RBAC constraints. They must be granted at the subscription level, scoped to the Cortex Cloud resource group where possible.

#### How it works

Cortex Cloud uses Azure Policy with the `deployIfNotExists` (DINE) effect, a standard first-party Azure capability. During onboarding, Cortex Cloud creates one custom policy definition and assigns it to your selected Management Group (or Tenant Root Management Group). Azure then evaluates all current and future subscriptions under that scope on its own schedule and deploys any missing Cortex Cloud resources through its own control plane.

The deployment flow:

1. Azure Policy detects a non-compliant subscription.
2. Azure's Policy control plane launches the embedded deployment using the managed identity (`cortex-mi-{suffix}`) in Incremental mode, adding or updating only Cortex Cloud resources.
3. The managed identity creates the `cortex-{suffix}` resource group and any per-subscription resources for the enabled capabilities.

`cortex-mi-{suffix}` is a User-Assigned Managed Identity attached only to the policy. It holds the privileged write/delete permissions needed for deployment and is used exclusively by Azure's Policy control plane. Cortex Cloud has no access to it.

On first onboarding, Cortex Cloud uses the Service Principal's `remediations/write` permission to trigger an initial re-evaluation. This re-runs the existing remediation logic only and cannot change what gets deployed.

**Microsoft reference documentation:**

* [Azure Policy deployIfNotExists effect](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deploy-if-not-exists)
* [Remediate non-compliant resources with Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources)
* [Get Azure Policy compliance data](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data)

#### What gets created, and when

* **Base onboarding (always):** An empty resource group named `cortex-{suffix}` is created in every in-scope subscription.
* **Agentless Disk Scanning (when ADS is enabled):** In addition to the ADS roles and permissions, Cortex Cloud creates a Compute Gallery named `cortex_ads_{suffix}` inside the `cortex-{suffix}` resource group. This is an empty, no-cost container to hold temporary image versions during scans.

#### Roles and permissions reference <a href="#roles-and-permissions-reference" id="roles-and-permissions-reference"></a>

For the complete list of permissions and roles created for each capability, see the [Cortex Cloud Azure Permissions documentation](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/cloud-service-provider-permissions/microsoft-azure-provider-permissions#data-security-posture-management-dspm).<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/microsoft-azure-cloud-onboarding/onboard-microsoft-azure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.