Palo Alto Networks Cortex XSIAM: Secure Roles, API Keys, Data Onboarding and Playbooks

A Cortex XSIAM tenant holds the organisation's security telemetry, its response automation and the credentials those automations use, so the people, API keys and playbooks that can act inside it need the same care as domain admin. Cortex XSIAM from Palo Alto Networks combines data onboarding, a data lake queried with XQL, analytics, case management and playbook-driven automation in one tenant. That concentration is what makes it useful, and it also means one over-privileged role or long-lived API key can read every log source and run actions across endpoints, identity systems and cloud accounts. This guide explains, from Palo Alto Networks' documentation, how sign-in, roles, scope, API keys, data sources, playbooks and audit logs work, and how to configure them securely. It is for SOC platform owners, detection engineers and identity teams running XSIAM. Vendor-neutral SIEM design is covered in the SIEM Guide.

This is an independent guide from NHI Mgmt Group, based on Palo Alto Networks' public Cortex XSIAM documentation as of November 2026. It is not sponsored or reviewed by Palo Alto Networks. Product features change, so confirm settings against Palo Alto Networks' current documentation.

Key takeaways

• Put MFA at the identity provider. XSIAM SSO uses SAML 2.0 with group mapping, and corporate MFA is enforced by the IdP, so the IdP policy is the real sign-in control.
• Turn on scope and dataset controls. Scope-Based Access Control and dataset access management are both off by default; switch them on before onboarding sensitive data.
• Prefer Advanced API keys with expiry. Advanced keys hash the key with a nonce and timestamp against replay, and every key can carry an expiration date with reminders before it lapses.
• Automated playbooks run as "system". Playbooks triggered by rules and jobs are bounded by the integrations' permissions, not the author's, so scope each integration instance tightly.
• Forward the Management Audit Log. XSIAM keeps it for 365 days and can send it to syslog, email or Slack; send it somewhere XSIAM admins cannot edit.

How identity and access work in Cortex XSIAM

A tenant is activated and licensed from the Cortex Gateway, and users reach it through the Customer Support Portal or SAML single sign-on. Inside the tenant, access is the combination of a role (what components a user may use), a scope (which rows and assets they may see) and object-level sharing for playbooks and scripts.

Accounts are created just in time on first SSO login, and a user disabled in the IdP is blocked at the next sign-in. SSO is configured per tenant, so production, development and any MSSP-managed tenants each need their own IdP application and review. See the SAML Security Guide.

Admin roles and privileged access

Account Admin and Instance Administrator carry Access Management rights by default and can change SSO, roles, scope and API keys. Everything else should be a custom role built under Settings > Configurations > Access Management > Roles (New Role, or Save As New Role from an existing one).

• Roles through groups: Palo Alto Networks' onboarding checklist recommends assigning roles through user groups. Combine that with IdP group membership that is itself governed by access reviews and approvals.
• Indirect data paths: the documentation warns that users can still reach restricted rows through dataset views and correlation rules. Limit who can create those objects and who they can be shared with.
• Gateway versus tenant roles: dataset access settings are available only in the tenant's Access Management, not for roles created in the Cortex Gateway, so build sensitive roles in the tenant.
• Admin account protection: keep a documented emergency path if SSO fails. See SaaS Admin Account Protection.

Integrations, API tokens and service accounts

XSIAM is full of non-human identities: API keys used by scripts and SOAR pipelines, credentials stored in integration instances so playbooks can act on firewalls, identity providers and ticketing systems, and cloud onboarding roles for AWS, Azure, GCP and OCI. Each is a standing credential that an attacker inside the tenant could reuse (ATT&CK T1078, Valid Accounts).

API keys

• Create: Settings > Configurations > Integrations > API Keys > New Key. The key is shown once; put it straight into a secrets manager.
• Security level: choose Advanced, which hashes the key with a nonce and timestamp to resist replay. Standard keys suit only tools that cannot compute the hash (the documentation notes cURL cannot use Advanced keys).
• Role and scope: give each key a custom role with only the components its job needs, and set the Scope tab. Non-administrators can assign only roles they already hold, which keeps delegation in bounds.
• Credentials permission: leave it None for keys that do not need stored secrets; credential calls then fail with 403.
• Expiry: select Enable Expiration Date on every key. XSIAM sends an API Key Expiration notification one week and one day before expiry; route those to the owning team.
• Visibility: administrators and Access Management users see all keys; review that list quarterly against a register of owners. See the API Key Management Guide.

Integration instances and stored credentials

Running a playbook does not depend on the user's access to the secrets it uses, and automated runs act through the integration's own permissions. That makes the account behind each integration instance the effective privilege of every automation that calls it. Give each integration a dedicated service account with only the actions the playbooks need (for example, disable user rather than full directory admin), prefer read-only integrations for enrichment, and keep secrets in an external vault where the integration supports it. See the Secrets Management Guide and the Non-Human Identity (NHI) Guide.

Logging and detection

Data onboarding

Data reaches XSIAM through connectors and standard data collectors on the Data Sources and Integrations page, Broker VM applets such as the Syslog Collector and Database Collector, XDR Collectors on Windows and Linux hosts, cloud onboarding wizards and Marketplace content packs that bring parsing rules, data model rules, playbooks and correlation rules. The Broker VM is a closed, hardened appliance that updates itself from XSIAM and does not accept third-party agents.

Watching the platform itself

The Management Audit Log (Settings > Management Audit Logs) records administrative and investigative actions with user, type, subtype, result and timestamp, and is retained for 365 days. Configure notification forwarding to a syslog server outside XSIAM's administrative control, so a compromised admin cannot quietly remove the trail. Alert on:

• Changes to SSO settings, role definitions, user group mappings and SBAC.
• Creation of API keys, especially Standard keys, keys without expiry or keys with administrator roles.
• New or edited integration instances and changes to public playbooks and scripts.
• Response actions run outside a case, and spikes in authentication failures.
• Disabled or paused data sources, which reduce visibility without raising an obvious alarm.

Treat the audit trail as evidence. Agree in advance who reviews it, how often, and how an alert about an XSIAM administrator is escalated when the SOC team itself may be the subject, for example straight to the security lead or an internal audit contact. Keep the forwarded copy for at least as long as your incident response and regulatory retention requirements, which may exceed the 365 days held in the tenant. Reconcile API key, integration and role changes in the log against change tickets each month, so that undocumented changes stand out.

Detection logic in XQL correlation rules is best managed as code with peer review. See the Detection as Code Guide.

Metrics that show the platform is well governed: number of Instance Administrators (target three or fewer); percentage of API keys that are Advanced and have an expiry date (target 100%); integration instances with a named owner; data sources reporting in the last 24 hours versus onboarded; and audit log events reviewed within one business day.

Hardening baseline

1. Activate and set encryption. Activate in the Cortex Gateway and set up BYOK keys if your policy requires them, as listed in the onboarding checklist.
2. Configure SSO first. Enable SAML, enforce MFA and device posture at the IdP, map groups, and leave the Default Role empty or read-only.
3. Build custom roles. Define the personas above before inviting analysts, and give only administrators Access Management.
4. Enable SBAC and dataset access management before onboarding sensitive sources.
5. Set lifecycle controls. Enable Deactivate Inactive User and shorten the SSO User Removal period.
6. Onboard data with least-privilege collectors. Read-only cloud roles, dedicated collector accounts and a register of every data source and its credential.
7. Govern automation. Keep playbooks Restricted by default, review changes to public playbooks, scope integration accounts, and test new playbooks in a development tenant (Editor grants are treated as Viewer in production tenants).
8. Forward audit logs to external syslog and build the alerts above.
9. Review quarterly: admins, roles, API keys, integration accounts and object ownership, reassigning playbook ownership before people leave.

Common misconfigurations

• Broad Default Role: every new SSO user gets it on first login. Use read-only or none.
• Scope left off: without SBAC every analyst sees every business unit's data. Enable it before multi-team rollout.
• Keys without expiry: Standard, non-expiring keys with administrator roles outlive the scripts that created them. Make Advanced keys with expiry the rule.
• Over-privileged integration accounts: automated playbooks act with the integration's rights, so a directory integration with full admin rights hands that power to every rule-triggered playbook.
• Assuming object sharing limits execution: per-object access controls visibility and editing, but playbooks can still be run from the CLI (! in the Automation Playground or setPlaybook in the War Room). Control execution with role permissions and scope.
• Audit log only in the tenant: forward it, or an admin compromise can hide its own tracks.

Framework mapping

Practitioner checklist

• Enable SAML SSO with IdP-enforced phishing-resistant MFA and exact attribute mapping.
• Set the SSO Default Role to none or read-only.
• Limit Instance Administrator and Account Admin to a few named people.
• Build custom roles per persona and assign them through mapped user groups.
• Enable SBAC and dataset access management before onboarding sensitive data.
• Issue only Advanced API keys with custom roles, scope and expiration dates, stored in a vault.
• Give each integration instance a dedicated, least-privilege service account with an owner.
• Keep playbooks Restricted, review public playbook changes and test in a development tenant.
• Forward the Management Audit Log to external syslog and alert on admin, key and integration changes.
• Enable inactive user deactivation and run quarterly access, key and ownership reviews.

Standards and references

• Palo Alto Networks: Cortex XSIAM, manage API keys
• Palo Alto Networks: Cortex XSIAM, authenticate users using SSO
• Palo Alto Networks: Cortex XSIAM, manage user roles
• Palo Alto Networks: Cortex XSIAM, manage access to playbooks and scripts
• Palo Alto Networks: Cortex XSIAM, monitor administrative activity
• Palo Alto Networks: Cortex XSIAM data sources and connectors
• Palo Alto Networks: Cortex XSIAM onboarding checklist
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · Security Automation Maturity Model · API Key Management Guide · Cloud Detection Engineering Guide