Choose to deploy and manage your own outpost:
In these cases, you might prefer to keep your data within your own network boundary.
| | Most of the cloud resources involved are charged to Palo Alto Networks instead of to you, so scan costs are reduced. | This mode requires additional cloud provider permissions and may incur additional cloud costs. | | Cortex-managed outposts require zero management from you. | Outposts incur some additional maintenance overhead. This includes securing the outpost, managing the necessary IAM roles and permissions, upgrading versions, and adjusting cloud provider quotas to meet workload demands. Actively manage your capacity and quotas to meet the workload requirements. | | For DSPM, your actual data is accessible to Palo Alto Networks, not just metadata. Rest assured, your data are deleted after scanners have completed. Zero trust security is used to secure your data in Palo Alto Networks-owned accounts. | For DSPM, only metadata is accessible to Palo Alto Networks, not your actual data. | | DSPM on SaaS (such as for Snowflake and Office 365) is currently supported only for cloud scan. | DSPM on SaaS (such as for Snowflake and Office 365) is not supported for outpost scan. | | Organizations cannot enforce strict Entra ID governance on outposts using the BYOA deployment model. | Organizations with strict Entra ID governance requirements can deploy outposts using the BYOA model. | ## Outpost security concepts and component handling This section presents outpost-related concepts and a high-level overview of how outposts perform scanning on your resources and data without putting them at risk. For a deeper understanding, contact your Palo Alto Networks representative. | Concept | Description | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Trust model | Cortex Cloud interacts with your environment via dedicated IAM roles within the outpost. This establishes a secure trust relationship that adheres to the principle of least privilege. | | Data security and residency | Outposts utilize a regionally symmetric architecture, processing data locally within the same cloud region and provider where it resides. Only metadata is ever sent back to Cortex Cloud. | | Scan operations | Scanning is performed by task-specific, ephemeral VMs built from hardened and continuously patched images. These instances are automatically terminated and all temporary resources are purged immediately after a scan completes. | | Secure orchestration storage (such as buckets) | Scanner VMs operate in isolated private subnets without direct internet or Cortex Cloud access. They communicate exclusively through encrypted, cloud-native storage used for operational data and scan results, never raw customer data. | | Temporary processing storage (such as artifact buckets) | For specific scans where direct data sharing is restricted, data is temporarily placed in encrypted regional storage for analysis. Cortex Cloud has no read permissions on this storage, and all data is deleted immediately after the job finishes. | | Scanner isolation | Each scanner VM is purpose-built with a strictly defined set of permissions and network access tailored to its specific job. This ensures complete compartmentalization between different scan types. | | Data encryption | Security is enforced through universal encryption at rest and in transit. Advanced egress filtering locks down external traffic to verified destinations, and secrets are managed via your own cloud-native secret management service. | ### Deployment criteria for a standard outpost A basic, standard outpost is suitable for your organization if the following conditions apply to your environment: * Your organization is comfortable running Cortex-generated Terraform in your CSP account. * Default naming conventions, network topology, and resource configurations meet your governance requirements. * You do not need to pre-create tenant-level identities, use your own VPC or VNet, or route egress through your own proxy. {% hint style="info" %} **Notes**: * Azure Entra ID app registration is supported. * For custom outpost configurations, contact your Palo Alto Network representative for available options. {% endhint %} ## Outpost planning Before creating outposts, we recommend you become familiar with how outposts work and then plan accordingly. For example, some points to consider include: * A dedicated account is required for the outpost account. Make sure the dedicated account is free from other resources. * Each cloud account (AWS account, Azure subscription, GCP project) can host only one outpost. * An individual outpost instance is strictly bound to a single Cortex Cloud tenant and cannot be used to scan resources belonging to a different tenant or organization. * Using an outpost requires additional cloud provider permissions and may incur additional cloud costs. * Familiarize yourself with the needed permissions and resources expected to be added to the outpost during creation. For exact implementation details, contact your Palo Alto Networks representative. {% hint style="info" %} **Notes:** * Before you create your outpost, verify that your internet connection is active. An active internet connection is necessary for the notification to be sent to Cortex Cloud to create the new outpost. * (Azure) Due to limitations in Terraform, the Azure subscription name cannot contain blanks. Take this into account while onboarding. {% endhint %} ## What's next? * [Create your outpost](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/outpost-creation-workflow.md) * View and manage existing outposts by navigating to **Settings → Data Sources & Integrations → Outposts** --- # 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/outpost-onboarding/outpost-fundamentals-and-planning.md?ask=