Cortex Cloud Explained: Palo Alto Networks' Successor to Prisma Cloud, and How to Onboard and Use It

Palo Alto Networks has been assembling a cloud security platform through acquisitions since 2018: RedLock for posture, Twistlock for containers, Bridgecrew for infrastructure code. That platform was Prisma Cloud. In February 2025 Palo Alto announced Cortex Cloud, which rebuilds it on the Cortex security operations platform and merges it with Cortex's cloud detection and response. If you interview with a company that ran Prisma Cloud, this migration is probably something they are living through.

What it is

Cortex Cloud is a cloud-native application protection platform (CNAPP) that shares its data model with Palo Alto's security operations products, Cortex XDR and XSIAM. Palo Alto groups it into:

• Cloud Posture Security: CSPM, CIEM, DSPM, AI-SPM, Kubernetes posture, application security posture, workload protection and vulnerability management.
• Cloud Runtime Security: runtime agents and cloud detection and response.
• Application Security: code, dependency, secrets and IaC scanning, with an ASPM view.

Prisma AIRS, Palo Alto's AI runtime security line, is a separate product that still carries the Prisma name. Do not confuse it with Prisma Cloud.

How it works

Onboarding. For AWS you add a data source, pick a scope (Organization, Organizational Unit or Account) and a scan mode, then deploy the generated CloudFormation template from the management account (or Terraform for a single account). Cloud Scan uses Palo Alto-managed scanning infrastructure; Scan with Outpost runs scanning in a dedicated account you own. Optional capabilities include agentless disk scanning, data security posture, registry and serverless scanning, and CloudTrail log collection. Resources Cortex creates carry a managed_by = paloaltonetworks tag.

Runtime. The Kubernetes Connector enables posture management, including admission controller enforcement, and optionally real-time protection. You choose a cloud optimized agent (lighter, runtime and threat detection) or the full XDR agent (prevention and response), both deployed as a DaemonSet on every Linux node.

The data model. Cortex documentation separates four objects. Issues are problems to solve. Findings are informational context about assets. Events are logged activity. Cases group related Issues into one story. Each Issue card has Overview, Work Plan and War Room tabs. This is the main change for Prisma Cloud users: cloud posture problems and runtime detections land in the same case queue that the security operations centre already uses.

How to use it

Day one: onboard the organisation

1. Onboard the AWS organisation, Azure tenant and Google Cloud organisation at the top scope so new accounts are covered automatically.
2. Choose Cloud Scan or Outpost. Choose Outpost if policy forbids sharing disk snapshots with a vendor-managed account.
3. Turn on the capabilities you will actually triage: agentless disk scanning for vulnerabilities, data security posture only with the privacy team's agreement, and log collection if you want cloud detection.

Week one: runtime, code and the migration

1. Onboard Kubernetes clusters with the connector, starting in posture-only mode, and add runtime agents to the clusters that need detection and response.
2. Move pipelines to the Cortex CLI. Authenticate with CORTEX_API_KEY_ID, CORTEX_API_KEY and CORTEX_API_URL, then:

cortexcli code scan            # replaces checkov for IaC, secrets and SCA
cortexcli image scan myapp:1.4 # replaces twistcli images scan

The documentation notes that the Cortex CLI Docker image does not support dependency (SCA) scans, so use the binary for those.

3. If you are migrating from Prisma Cloud, run the Upgrade Helper. It maps Prisma roles to Cortex roles and user groups, Prisma policies to rules, custom configuration, attack path and data policies to detection rules, and runtime rules to policies and asset groups. It does not change the Prisma tenant and can be re-run, which lets the two run in parallel while you compare results.

Every day: work Cases, not alerts

Triage Cases, which group related Issues and attack paths, instead of individual Issues. Use the Work Plan to track remediation and the War Room for investigation notes. Tune rules where they generate Issues nobody acts on, and keep pipeline scans as gates for new problems.

Where it stops

• Migration is a project. Policies, exceptions, integrations and pipeline steps all need checking after the move; a clean Upgrade Helper run does not prove equivalent coverage.
• Agentless is periodic. Disk scanning shows what is installed; runtime evidence needs agents or logs.
• Agent choice matters. The cloud optimized agent detects; prevention and response need the XDR agent.
• Breadth is not coverage. As with any CNAPP, unconnected accounts and clusters without the connector are invisible.

How it comes up in interviews

• "You are migrating from Prisma Cloud to Cortex Cloud. How do you prove nothing was lost?" Run both in parallel, compare inventories, policies and alert volumes on the same accounts, and test with known-bad resources.
• "Why merge cloud posture with the SOC?" So a misconfiguration and the attack that uses it appear in the same case.
• "Outpost or vendor-managed scanning?" Data residency and snapshot sharing against cost and operational effort.

Sources

Checked on 13 November 2026: Palo Alto Networks press release introducing Cortex Cloud (13 February 2025) and launch blog; Cortex Cloud documentation on cloud onboarding (API overview and AWS onboarding steps), the Kubernetes Connector, Issues, Findings, Events and Cases, the Issue card, the Upgrade Helper and migrating to the Cortex CLI; Palo Alto press releases on completing the Twistlock (July 2019) and Bridgecrew (March 2021) acquisitions; Palo Alto end-of-life announcements page; Cortex Cloud open-source projects page.