> 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/cortex-cloud-data-sources-and-connectors/what-are-cortex-cloud-data-sources.md).

# What are Cortex Cloud data sources and connectors?

Data sources and connectors are the foundational mechanisms used to ingest security and operational data into Cortex Cloud for analysis, correlation, and response. By consolidating data from cloud environments and third-party security tools, Cortex Cloud helps monitor identity risks and secure configurations across your multi-cloud and SaaS ecosystem.

### Customer availability by tenant type

The ingestion methods and configuration options available to you in the user interface depend on your tenant onboarding date:

* **New tenants (onboarded after July 26, 2026)**: You will primarily interact with the strategic Connector experience. Standalone Marketplace integrations that have been consolidated into connectors are hidden from the catalog to ensure a unified configuration flow.
* **Existing tenants (onboarded before July 26, 2026)**: You will continue to see both standalone Marketplace integrations and unified Connectors. Refer to the specific documentation for each vendor to determine the supported configuration method for your account.

### Clarifying terminology: Data sources and Connectors

In the Cortex Cloud user interface (UI), configuring ingestion involves different areas and terminologies depending on the type of connection and your tenant onboarding date. While Cortex Cloud is introducing connectors as a new, unified approach to ingestion, traditional Data Source methods remain supported.

In the current intermediate state, it is important to understand how these terms relate to each other:

* **Data sources**: Represents the traditional method for any integration that provides data to Cortex Cloud. In this documentation, Data Source is used as the category for these traditional ingestion methods, which include:
  * **Data collectors**: Built-in tools primarily focused on raw log ingestion. This includes generic logs ingested via XDR Collectors and core ingestion functionalities found using the Data Source Onboarder.
  * **Broker VM applets**: Specialized applications running on the Broker VM that function as collectors, such as the Syslog Collector.
  * **Marketplace (integrations)**: Content packs that include collection integrations. These are typically referred to as data sources in the UI, as integrations that fetch data are configured through the Data Source Onboarder on the **Data Sources & Integrations** page.

    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>This legacy implementation is primarily available to existing customers; new customers (onboarded after July 26, 2026) will use the new Connectors framework for these services (see <a href="#customer-availability-by-tenant-type">Customer availability by tenant type</a> above).</p></div>
* **Connectors**: The new, unified mechanism for data ingestion. For supported vendors, a Connector groups multiple security capabilities, such as Identity Posture and Data Security, into a single, uniquely named entry with a guided configuration wizard.

While specific components like Data Collectors, Broker VM applets, and Connectors are named explicitly when discussing their unique configuration workflows, they all fall under the foundational goal of ingesting data into Cortex Cloud.

### Why are different data sources and connectors necessary?

Cortex Cloud enables you to collect data across a vast and varied enterprise landscape. This necessitates distinct data source types and connectors designed for different environments and needs:

* **Connectors**: Streamline the onboarding of third-party SaaS services by grouping identity and data security capabilities into a single entry with a guided wizard.
* **Standard data collectors (API/Built-in)**: These are built-in functionalities primarily focused on ingesting raw logs and security events for core security analysis, parsing, and normalization.
* **Broker VM data collector applets**: These are modular applications installed on a local Broker VM virtual appliance, designed for on-premise data collection needs like the Syslog Collector or Database Collector.
* **XDR Collectors (XDRC)**: These are lightweight agents dedicated to on-premise log collection on Windows and Linux host machines.
* **Cloud Service Provider (CSP) Onboarding**: These are specialized wizards for integrating cloud environments, such as AWS, Azure, GCP, and OCI, enabling streamlined setup for asset discovery, cloud posture/runtime security, and log collection.
* **Marketplace content packs**: These packages offer specialized security functionality by bundling both a collection integration (for data ingestion) and automation components, such as playbooks and correlation rules.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>Standalone Marketplace integrations are primarily used by existing customers (onboarded before July 26, 2026). New customers will find these services consolidated within the new Connector framework.</p></div>
* **Palo Alto Networks Integrations**: Cortex Cloud provides both standard data sources and new unified connectors for Palo Alto Networks products to ensure deep telemetry ingestion.
* **Cloud Posture and Runtime Security data sources**: These data sources provide agentless visibility and real-time control over cloud risks by using cloud-native APIs to monitor misconfigurations and secure container environments.

### **Current UI and future direction**

Cortex Cloud is transitioning toward a unified ingestion experience. While different ingestion methods currently involve distinct workflows, the following table summarizes where to manage them:

<table data-header-hidden><thead><tr><th width="374"></th><th></th><th></th></tr></thead><tbody><tr><td>Data Source Type</td><td>Primary UI Location(s) for Configuration</td><td>Key Components</td></tr><tr><td>Connectors</td><td><strong>Data Sources &#x26; Integrations</strong> page (<strong>Settings</strong> → <strong>Data Sources &#x26; Integrations</strong> → <strong>+ Add New</strong>)</td><td>Unified wizard for multi-capability vendor integrations.</td></tr><tr><td>Standard data collectors</td><td><strong>Data Sources &#x26; Integrations</strong> page (<strong>Settings</strong> → <strong>Data Sources &#x26; Integrations</strong> → <strong>+ Add New</strong>)</td><td>Built-in functionalities primarily focused on ingesting raw logs and security events, such as Okta and Amazon S3.</td></tr><tr><td>Broker VM applets</td><td><strong>Broker VMs</strong> page (<strong>Settings</strong> → <strong>Configurations</strong> → <strong>Data Broker</strong> → <strong>Broker VMs</strong>)</td><td>Specialized applications running on a Broker VM, such as Syslog Collector.</td></tr><tr><td>XDR Collectors</td><td><strong>XDR Collectors</strong> page (<strong>Settings</strong> → <strong>Configurations</strong> → <strong>XDR Collectors</strong>)</td><td>Management of XDR Collectors dedicated for on-premise data collection on Windows and Linux machines.</td></tr><tr><td>CSP onboarding and standard collectors</td><td><strong>Data Sources &#x26; Integrations</strong> page (Settings → Data Sources &#x26; Integrations → <strong>+ Add New</strong>)</td><td>Specialized wizards for integrating cloud environments, such as AWS, Azure, and GCP.</td></tr><tr><td>Marketplace content packs</td><td><p><strong>Data Sources &#x26; Integrations</strong> page (<strong>Settings</strong> → <strong>Data Sources &#x26; Integrations</strong> via Data Source Onboarder, for packs with data ingestion or after a <strong>Marketplace</strong> install)</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>Some content packs provide parsing rules and data model rules for data sources ingested using a Syslog Collector applet of the Broker VM or for standard data sources, and won't be listed in the <strong>Data Sources &#x26; Integrations</strong> page.</p></div></td><td><p>Discovery and installation of integration-specific content packs.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>For new tenants from July 26, 2026, services consolidated into connectors are managed via the <strong>Data Sources &#x26; Integrations</strong> page.</p></div></td></tr><tr><td>Cloud Posture and Runtime Security data sources</td><td><ul><li><strong>Data Sources &#x26; Integrations</strong> page (Settings → Data Sources &#x26; Integrations → <strong>+ Add New</strong>)</li><li><strong>Broker VMs</strong> page (Settings → Configurations → Data Broker → <strong>Broker VMs</strong>)</li></ul></td><td>Direct API ingestion or Broker VM applets for monitoring misconfigurations and securing cloud workloads.</td></tr></tbody></table>


---

# 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/cortex-cloud-data-sources-and-connectors/what-are-cortex-cloud-data-sources.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.