wif.tax

Palo Alto Networks

F Cortex XSIAM / Cortex XDR (public APIs and data sources)

Scripts, SOAR tools and CI jobs call the Cortex XSIAM and XDR APIs with a static API key and key ID; there is no OIDC or workload federation. Keys are role-scoped and can be created and deleted by API, but the console lets a key never expire, and there is no last-used view or GitHub partner revocation. Cloud onboarding into AWS, Azure and GCP is keyless, but many log collectors still want pasted keys, connection strings or client secrets.

Docs: cortex-docs.paloaltonetworks.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static API key (Authorization header) plus its numeric key ID (x-xdr-auth-id), created under Settings > Integrations > API Keys or by the API Keys API, with an assigned role and optional SBAC scope. "Advanced" keys sign each call with a nonce and timestamp, but the key underneath is still a long-lived shared secret. No OIDC, cloud workload identity or token-exchange path exists.

Applies to Cortex XSIAM 3.x and Cortex XDR 5.x, which share the same tenant API, key model and docs (Cortex Cloud and AgentiX use the same API key scheme). The only federation-shaped feature in the Platform API is authentication-settings, which configures SAML SSO for human users. The Advanced key's nonce/timestamp hash stops replay of a captured request, not theft of the key. Grade moves to B or A only if the public API accepts a federated token (GitHub Actions OIDC, cloud workload identity or a bring-your-own issuer); to D with one more hygiene pass (an enforced maximum key lifetime would do it).

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Cloud service provider onboarding is keyless: AWS cross-account AssumeRole with a mandatory External ID plus OIDC web identity for audit logs, an Azure multi-tenant service principal with a federated credential on a managed identity for logs, and GCP service-account impersonation. The S3 collector offers Workload Federated Identity or an assumed role. But the GCP Pub/Sub and Google Workspace collectors want a service-account JSON key, Azure Event Hub wants connection strings, and Office 365, Okta, Salesforce, Box, Dropbox and Workday want client secrets, API tokens or passwords.

Checked: CSP onboarding for AWS (CloudFormation roles assumed by Cortex's AWS roles with an External ID; audit logs via Google-signed OIDC and AssumeRoleWithWebIdentity), Azure (`az ad sp create` for Cortex's multi-tenant app, audit logs via a user-assigned managed identity with a federated identity credential), GCP (roles/iam.serviceAccountTokenCreator granted to Cortex's service accounts) and OCI/Alibaba (Terraform templates; auth not inspected, not publicly detailed in what was fetched). Amazon S3 collectors (CloudTrail, flow, Route 53, generic): Workload Federated Identity (default), assumed role with External ID, or an IAM user's static access key. CloudWatch uses Firehose pushing to an XSIAM HTTP endpoint with an XSIAM-issued token (inbound). Static-credential collectors: GCP Pub/Sub (service-account JSON key), Google Workspace (service-account private key with domain-wide delegation), Azure Event Hub (Event Hub and storage connection strings), Office 365 and the newer Microsoft 365 connector (Entra app client secret), Okta (SSWS API token), Salesforce (client credentials secret), Box (client secret), Dropbox (app secret plus offline refresh token), Workday (integration user password). The Microsoft 365 email collector uses interactive admin consent to an authorized app. Keyless on all three big clouds for posture and audit logs, but at least one integration on each of them still wants a static key, so B. Marketplace content-pack integrations (XSOAR playbooks) were not graded.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Fails: keys generated through the API get a one-week default and a six-month cap, but the console marks expiration "(Optional)" and a key with no expiration never expires. No tenant setting that forces an expiry or caps console-created keys is documented (GitBook's own doc search found none). Same call as elastic-cloud-api: a changeable default is not an enforced expiry. Applying the API's six-month cap to console keys would flip this.
✓ Rotation via API
/public_api/v1/api_keys/generate, get_api_keys and delete exist in both the XSIAM 3.6 and XDR 5.2 Platform APIs (license note on XSIAM: Premium, Enterprise, NG SIEM or Enterprise Plus, i.e. every XSIAM tier).
✓ Scoped keys
Each key is its own principal with an explicitly chosen predefined or custom role, plus optional Scope-Based Access Control on assets, endpoints, cases and dataset rows (SBAC is off by default tenant-wide). It does not inherit its creator's access.
✗ Last-used visible
The get_api_keys response carries id, creation_time, created_by, user_name, roles, security_level, comment and expiration, with no last-used field, and the Manage API keys page describes no last-used column. Usage can only be reconstructed from management audit logs.
✗ Leak revocation
Palo Alto Networks and Cortex do not appear in GitHub's supported secret-scanning patterns table at all, so a leaked Cortex API key is neither detected nor reported to the vendor.

Notes

One card for Cortex XSIAM and Cortex XDR, which share the tenant public API, API key model and data-source collectors (XSIAM docs cited; XDR 5.x pages match). Two of five hygiene checks pass (API rotation, role scoping), so inbound is F. Inbound reaches D with an enforced expiry, a last-used timestamp or GitHub partner revocation, and B or A only with federated tokens. Outbound reaches A if the GCP Pub/Sub, Event Hub and Microsoft 365 collectors adopt the impersonation, managed-identity and federated-credential patterns already used by CSP onboarding. Prisma Cloud and Cortex Cloud are separate products not graded here.

Badge

wif.tax grade F

[![wif.tax grade](https://wif.tax/badge/paloalto-cortex-xsiam.svg)](https://wif.tax/p/paloalto-cortex-xsiam/)