New Features

The following new features are categorized by product component.

High Availability

Cortex XSOAR 6.1 introduces High Availability for both single-instance and multi-tenant deployments. In a High Availability architecture, you have both data and application server redundancy. You can install multiple app servers that all work with an Elasticsearch database.
Maximum times to recover a Playbook
In a HA environment, to protect the server from a rogue playbook which keeps crashing it, the playbook will not be recovered when reaching the maximum number of attempts to recover.
Supports custom installation path
When installing Cortex XSOAR by default, some data files are saved in
. When deploying HA app servers, these files are required to be shared between them. To achieve this, the user must create/mount a shared folder in the
path on all app servers before installation. If you would like to use a different path, you can specify the custom path using the
installer flag.
Temp folder flag
When installing Cortex XSOAR, data from the Cortex XSOAR service (such as Content Packs for accounts, configuration for hosts, etc) is added to the
folder, located in
. Due to permission or security issues the temp folder may not be accessible.
Add the
flag at installation which replaces the
demisto temp
folder with
. Useful for HA, so the new directory is accessible outside the shared folder system.
Block starting a host until upgrade
When a database has already been upgraded by an app server, another app server is prevented from starting until the host/app server is upgraded.


As of version 6.1, if you are using Elasticsearch as your database, all of your data is stored in Elasticsearch. In addition, you can use the inherent Elasticsearch features to provide data redundancy and backup your information. Also, as of this version, any XSOAR service that is using Elasticsearch database will no longer run automatic backups.
When downloading the Elasticsearch migration tool, make sure to add the
Show previous results in an elastic migration
When migrating to Elasticsearch, if the migration is partially completed, you can now see a breakdown of completed, partially migrated and not completed items.
Support migration of a specific partition Database
When migrating to Elasticsearch, you can add a partitions flag so specific database partitions can be migrated.
For example,
go run ./cmd/elasticMigrator -config-path ./conf_for_systemtests_elasticsearch --migrate-all -y -partitions 122020,092020
Data is no longer automatically purged when uninstalling Cortex XSOAR
When using Elasticsearch as your database and uninstalling Cortex XSOAR, data is no longer automatically purged from the /var/lib/data directory. This can be useful when the data is part of a shared drive and automatically removing the data would affect the other servers using the directory.
To remove the data, when uninstalling, you have to include a
flag to explicitly indicate that you want to delete the data.
The migration to Elasticsearch includes the following limitations:
  • You no longer have the option to use Elasticsearch to only manage your indicators. If you were using Cortex XSOAR with Elasticsearch before version 6.1, you must migrate your entire database as part of the upgrade. For more information, see the section about migrating an existing Elasticsearch deployment in the Administrator’s Guide.
  • Once you migrate to Elasticsearch, you cannot roll back and use BoltDB.
  • Objects, such as incidents, indicators, evidence, custom fields, etc. that includes an invalid data value, for example, a field that is defined as text but the field contains an object, the invalid value will not be migrated.
  • As the messages feature was deprecated in Cortex XSOAR version 6.0, existing messages will not be migrated.

Indicator Extraction

The new indicator extraction feature enables you to extract indicators from incident fields for each incident type.
Extracting indicators can adversely affect system performance. In each incident type, you can now select when to extract an indicator (on incident creation and upon a field change) and which indicator types to extract from each incident field. For each incident field, you can select which indicator types to extract according to one of the following rules:
  • None.
  • All indicator types with regex.
  • One or more indicator types with regex.
  • Any indicator based on the field value.
For example:


Cortex XSOAR Marketplace is the central location for installing, exchanging, contributing, and managing all of your content, including playbooks, integrations, automations, fields, layouts, and more. Cortex XSOAR 6.1 introduces the following features to the Marketplace.
  • You can update multiple content packs in a single update operation. From the Content Pack library, select all of the packs that you want to update (and for which there is an available update), and click
    . The content packs and any required dependencies are displayed for you to review before confirming the installation (update).
    While the updates are installing, you can continue working in other parts of the Cortex XSOAR platform.

Threat Intel Management

These features do not require a threat intel management license, they are available to all Cortex XSOAR users.
Helpful message when a feed takes a long time to fetch indicators
The error message that displays when a feed indicator ingestion takes a long time, clearly explains that this occurs either because there are many indicators, or because there is a problem with the integration instance configuration.

Case Management

Incident Read-Only Role
You can now grant read-only access to investigations, so roles that have read-only access cannot edit an incident or take part in the War Room. For example, when an incident is in triage (phase 1), you may want all Tier-2 analysts to have read-only access, so that Tier-1 can edit the incident. When the phase changes to phase 2, Tier-1 has read-only access.
Share engines and load-balancing groups between tenants (
In the main account, you can now share engines and load-balancing groups with tenants for integration instances.
Engine Login page removal
When using an engine in a communication task, if a user deleted the suffix in the link to the engine, a login page appeared. Although the user could not login, this page has now been deleted.
Account Creation Indication for Automatically Assigned Roles (
When creating a new account in the Main Account, by default, administrator roles (with read and write permissions) are automatically added to the account. You can change the default behavior when creating or editing an account by removing the administrator role.
Propagate configuration values upon host creation (
When creating an account or host in the Main Account all configuration parameters are now propagated from the Main Account to the host or tenant.
Block a tenant (
In the main account, you can now block/unblock a tenant account at proxy level (from the main server). You can still access the tenant account via the port, which enables you to fix any problems, without affecting the main account.
RBAC Control for Shared Dashboards
Added the ability to share and grant permissions to dashboards by user role. Permission level is either read-only or edit.
Exclusions Lists
It is now possible to add IPv6 CIDR ranges to exclusion lists.
Machine Learning improvements
When training a model using the machine learning feature, you now have the ability to view an advanced analysis of its evaluation, which enables you to decide whether, and how, to use the trained model. A detailed breakdown is provided, showing what is the expected performance of the model at each class, by displaying different metrics, such as precision, coverage, suggestions for applying a confidence threshold, etc.
Toggle for incident layout tabs (
In the Cortex XSOAR Web app, when customizing incident layout visibility settings, you can decide whether you want each tab to appear in the mobile app by selecting the
Show this tab on Cortex XSOAR mobile App if role allows
checkbox. Only mobile supported tabs have this checkbox (for example, Work Plan and the Evidence tabs do not have the checkbox and will not appear in the mobile app). By default, all mobile supported tabs have the checkbox selected and appear in the mobile app.
You can also create new tabs and add fields to them as required.
Scriptable buttons (
You can now run commands such as escalation or enrichment in the mobile app by adding a script button to the tab when customizing incident layouts in the web. It is useful to add a button when you are undertaking war room commands or other custom actions in the mobile app.
Enhanced Audit Trail
The Audit Trail
Audit Trail
information now contains:
  • Details about creating, updating and deleting users and roles
  • Details about password changes for users.
Support for the
argument in the
In the
command, while adding the
argument with values such as
machine-learning, top-user, less-busy-user
, etc, you can now assign according to role when adding the
Using Demisto REST API out of the box
You can now send read only requests using Demisto REST API without adding and enabling an instance. For example, if you run an API command in a Playbook (which is run by Dbot), it has read only permissions, and you cannot modify data.
Block starting a host until the Database is upgraded
) When a database has already been upgraded by an app server, another app server is prevented from starting until the database is upgraded to block data corruption.


Attach and Detach incident types
By default, when installing a Content Pack, incident types are attached (cannot be edited).
To customize the incident type, such as changing the layout, the default playbook, extract indicators, etc you need to detach it.
When detached, the incident type is not updated by the Content Pack, which may be useful when you want to update the playbook without breaking customization.
When upgrading to version 6.1, by default, all out of the box incident types (from a Content Pack) are detached. To receive content updates for detached incident types, reattach the incident type.
Multiple Load-Balancing Engine Groups
You can use separate load-balancing groups for different integrations and instances. Users can create load balancing groups for certain tasks, which can help segregate the infrastructure of critical integrations. This is useful for example:
  • For managed security service providers who may want to split internal engines and SaaS product engines.
  • If you have multiple AWS accounts that are not connected and do not want a single point of failure for AWS integrations that use STS.
  • For high availability, you may want multiple load-balancing groups of engines in different locations.
  • It can also help manage the load in a multi-tenant environment.
Deploy multiple engines on the same machine
Shell installation
) Install multiple engines on the same machine without having numerous engine installation files and manage those engines in different environments.
In a multi-tenant environment, users may want to deploy engines for different tenants on the same machine.
User Interface improvements
  • Cortex XSOAR 6.1 includes the following user interface improvements:
    • consistent look and feel for scroll bars.
    • pinned table headers so you can see the headers as you scroll.
    • improved spacing and page readability, including changes to the fonts and colors in the Light theme.
    • changes in the license flow, which enable you to upload a license even when there are warnings or errors.
    • borders around individual fields and drop-downs to clarify where values are selected.
    • After upgrading to v6.1, when going to
      Incident Types
      , pop-up screen appears explaining the new Indicator Extraction feature.
Report date range
In the Reports page, when viewing the reports list, you can now select the incident date range when generating a report. You no longer need to duplicate the report and then change the date range.
Setting up the Fetch Interval Field for integrations
You can now add the Incident Fetch Interval field to any incident fetching integration that is not included out of the box. This enables you to control the interval in which an integration instance reaches out to fetch incidents, from ingesting into the Cortex XSOAR platform and from 3rd party platforms.
Dependency Check for Remote Repositories
When pushing content from the development to production environments, you can now review and select dependencies before pushing the content. This level of granularity enables you to select only those dependencies that you want in your production environment.
UI improvements for remote repositories
General User interface improvements when pushing content to a remote repository, such as dependencies are expanded by default.
Inline edit for Reputation and Expiration Widgets
The Indicator Summary page now supports inline editing for reputation and expiration widgets, which makes the editing process simpler.
Updated data in incident table
When a user makes changes to the incident such as status, owner, etc, the changes immediately appear in the incident table for all users.
Marketplace improvements
  • Exclude installed Content Packs when browsing.
  • View the number of downloads for each Content Pack. Filter was added to hide installed Content Packs.
Exclude dependencies for a Contribution Pack
In the
Contribution Pack Editor
, you can now select which dependencies to include.
Limit indicator timeline content
In the Indicator timeline, content details are truncated where there are many changes, which makes it easier to view. You can configure the timelime for multi-value (multi-select and tags) field, HTML, markdown, long and short text fields.
Display an error when a script widget fails
When a script fails for a widget, an error message now appears which enables the user to fix the script rather than showing a spinning wheel.
Run actions after an incident is closed
When an incident is closed, if users click an action button there is now an option to reopen the incident.
Add installer log to the log bundle
For better debugging and analysis, there is now an installer log when installing Cortex XSOAR.
Support for Podman on CentOS v8 and RHEL v8
Cortex XSOAR now supports Podman. If running CentOS v8 and higher or RHEL v8 and higher, Cortex XSOAR now installs Podman packages automatically and configures the operating system to enable Podman in rootless mode.
Upgrades from a previous Cortex XSOAR version are not affected and continue to use Docker.
Clear/Reset integration context data
In the Instance settings dialog box, for some integrations, you can now clear old or unnecessary data from the integration context.

Recommended For You