| Cloud scan (Recommended) | Outpost scan |
| Configure a managed outpost when there is sufficient trust between you and Cortex Cloud. In this case, Cortex accesses your environment more extensively and with less mediation.For DSPM, a cloud scan means that your actual data is accessible to Palo Alto Networks—not just metadata. Customer data is deleted after scanners have completed. Their data is not kept and zero trust security is used to secure their data in Palo Alto Networks-owned accounts.Cortex-managed outposts require zero management from you. Most of the cloud resources involved are charged to Palo Alto Networks instead of to you, so scan costs are reduced.DSPM on SaaS (such as for Snowflake and Office 365) is currently supported only for cloud scan. | If you operate in a high-regulated market with a healthy “mistrust” of vendors, or for compliance with certain regulations for which we are not compliant “out of the box,” you might prefer to prevent access to your data from outside your network boundary. In this case, you can choose to deploy and manage your own outpost.For DSPM, only metadata is accessible to Palo Alto Networks—not your actual data.This mode requires additional cloud provider permissions and may incur additional cloud costs.For compliance with certain regulations, you might prefer keeping your data within your own boundaries. Because the outpost scan is customer-managed, the scan incurs some additional maintenance overhead. This includes securing the outpost, managing the necessary IAM roles and permissions, and adjusting cloud provider quotas to meet workload demands. Actively manage your capacity and quotas to meet the workload requirements. |
| State | Description | Cost implications |
| Idle state | The outpost is deployed but there is no active scanning workload. Resources like the communication buckets are provisioned but static. | An "idle" outpost, with no scanning activity, incurs almost no baseline billings for cloud infrastructure resources. |
| Active scanning state | Scanning jobs are running for ADS, Registry, or DSPM. Ephemeral VMs are actively spun up to perform security analysis on customer data. | Workload costs are calculated based on the consumption of dynamic resources, including VM execution time, storage IOPS, and API calls. The system attempts to use spot instances where available to reduce these costs. |
| Audit/cleanup state | Active scanning is complete, but the communication bucket still contains scan outputs (metadata, findings) for auditing purposes. The scan outputs remain for approximately 7 days, as this is the bucket’s configured retention policy. During this state, all dynamic resources (VMs, attached volumes) have been terminated. | A minimal storage cost is incurred for the low-volume storage of metadata in the communication bucket, which is retained for an auditing period of approximately 7 days, expiring according to the bucket’s configured retention policy. |
| Standard outpost | BYOA (Azure only) | BYON (AWS, Azure, GCP) | |
| What you provide | Nothing. The deployment creates all resources. | The Entra ID app registration and its service principal. | The virtual networks, subnets, and network security rules. |
| Permissions required at deployment | Broadest. On Azure, includes tenant-scoped Application.ReadWrite.All to create the app registration. | Narrower. The Terraform runner holds object-scoped ownership of one app registration and no tenant-wide permission. | Narrower on network resource creation. The deployment does not create network infrastructure. |
| Directory / tenant-level writes by Cortex Cloud | The deployment creates the app registration in your directory. | None beyond the single app registration you supply. | Unchanged from standard, unless combined with BYOA. |
| Network control | Cortex Cloud defines and manages the network, including CIDR ranges and security rules. | Cortex Cloud defines and manages the network. | You define and manage the network, and can apply your own egress inspection, logging, and private connectivity policies. |
| Setup effort | Lowest. Run the wizard and apply the Terraform. | Moderate. One app registration to create in advance, using a provided script or the Azure portal. | Highest. Requires network design, CIDR allocation, and coordination with your network team before deployment. |
| Ongoing responsibility | Cortex Cloud manages all outpost infrastructure. | You own the lifecycle of the app registration, including any credential rotation policy applied to it. | You own the network for the outpost's lifetime, including adding capacity when outpost regions are added and keeping scanner reachability intact. |
| Troubleshooting | Palo Alto Networks diagnoses infrastructure issues directly. | Largely unchanged. App registration misconfiguration is a distinct failure mode you resolve. | Network faults require joint diagnosis between your network team and Palo Alto Networks, which lengthens resolution time. |
| Time to deploy | Shortest. | Slightly longer than standard. | Longest. Plan for a network design cycle before deployment. |
| Best suited to | Most organizations. Recommended unless a specific governance constraint applies. | Organizations with strict governance over Entra ID tenant-level resources. | Organizations with a centrally governed network architecture or audit requirements covering scanning traffic paths. |
| Availability | Generally available. | Generally available. | Generally available (on request). |