QRadar SaaS alternatives: self-hosted SIEM

Why QRadar SaaS customers are looking at self-hosted SIEM options

If your QRadar SaaS tenant changed hands in September 2024, you were probably offered a move to Cortex XSIAM. A self-hosted stack built on Wazuh and OpenSearch is the other route: it keeps log data in your own cloud accounts, data centers or air-gapped network, operated by your team or a partner you choose. The ownership change is the trigger for most reviews, but the real question is who runs the platform, where events live and who decides how long they are kept. Palo Alto Networks completed its acquisition of IBM's QRadar SaaS assets on September 4, 2024, and offered eligible customers free migration to Cortex XSIAM with IBM Consulting. Under the SaaS model, the vendor operates the platform and the storage, and retention and access follow the service terms. Before you decide, confirm in writing with your account team and the vendor who now holds your contract: where your events are stored, which retention periods apply, how long an export takes, what support and data processing terms carry over, and what happens to your content if you leave.

The QRadar on-premises line is a different case. Palo Alto Networks' announcement states that QRadar on-premises customers continue to receive IBM features and support, so an on-premises deployment you already run is not forced into a migration by the sale. That gives you a choice of timing: stay on QRadar for now, move to a self-hosted stack, or move to XSIAM. A self-hosted option asks your team to take on platform operations, upgrades, storage sizing and detection content, so the decision depends on who will own those tasks after the move. Start by listing your log sources, daily event volume, retention obligations and any regulatory frameworks you must evidence. Those answers determine whether Wazuh's agents and server cover your endpoints and devices, and whether OpenSearch can hold the history you need. The sections that follow compare the three paths on those criteria.

What keeping security logs in your own infrastructure requires

Moving security logs from a vendor-run SaaS into your own infrastructure makes your team responsible for where events sit, who can read them and how the platform stays patched. The cards below cover the requirements that follow from that choice, and each one names what your organization must decide before a platform is chosen.

Storage location and residency

Decide which data centers, cloud accounts or on-premises racks will hold alerts, raw events and archives, and which events may leave a given jurisdiction. Wazuh stores alerts in its indexer and OpenSearch holds indexed events, so both need storage sized and placed inside your boundary. Confirm where backups, snapshots and vulnerability feed copies also land, since these often leave the primary cluster unnoticed.

Authentication and role separation

Analysts, detection engineers and administrators need different rights, and QRadar SaaS customers often inherited a broad shared role model from the vendor. The OpenSearch Security plugin provides role-based access control, document-level and field-level security and field masking, and it can connect to SAML, OpenID Connect, Active Directory or LDAP. Decide which groups may read personal data fields and who may change detection content.

Encryption in transit

Every hop between agents, the Wazuh server, the indexer, the dashboard and any OpenSearch node carries security events that may name users, hosts and internal addresses. OpenSearch Security supports TLS for node and client traffic, and you should confirm that certificates for agent enrollment and syslog sources are issued and rotated under your own certificate authority. Write down which links are encrypted and which legacy log sources cannot be.

Audit logging of access

A SIEM that holds investigation data must itself record who searched, exported and changed rules. OpenSearch Security includes audit logs, and you should decide which events are retained, where the audit trail is stored and who reviews it, separately from the analysts whose activity it records. Confirm that the audit store is outside the cluster it monitors so that an administrator cannot silently remove their own trail.

Offline and restricted-network installation

Some regulated networks cannot reach public update servers or threat intelligence feeds. Wazuh documents an offline installation path for systems without internet connectivity and an offline vulnerability repository in place of its cloud threat intelligence platform. Decide who builds and transfers the installation media, how signed packages are verified and how vulnerability content is refreshed across an air gap.

Documented upgrade path

Self-hosting moves patching from the vendor to your team. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, and OpenSearch targets a new minor version about every eight weeks, with each version maintained for a limited window. Decide who tracks release notes, how a test cluster validates upgrades and which version your support contract or retainer covers before you commit.

Which self-hosted platforms meet the constraint, and what each gives up

This table compares the QRadar SaaS migration paths and the self-hosted candidates on the points that matter after the Palo Alto Networks sale: licensing, deployment, compliance views, authentication and content transfer. Read each row as a trade-off, not a verdict, and use the gap notes to scope what your team must rebuild or confirm with vendors.

Option	What it gives you	What it gives up or leaves open
Wazuh (GPLv2)	Free SIEM and XDR under GPLv2 with four components: indexer, server, dashboard and agents. Agents cover Linux, Windows and macOS, and agentless syslog collection covers firewalls. Dashboards include PCI DSS, GDPR, HIPAA and NIST 800-53 views. Offline installation is documented.	QRadar DSMs and offense rules do not transfer automatically. Every log source needs a decoder or rule you validate. Vulnerability data needs the CTI platform or an offline repository, so confirm which your environment allows.
OpenSearch (Apache 2.0)	Search and analytics layer under Apache 2.0 with no paid edition described in the FAQ. Security plugin supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT, plus RBAC, field-level security and audit logs.	Security Analytics detection content is not QRadar's correlation library. Evaluate its detectors against your use cases, and plan to tune them yourself. Confirm the plugin's rule coverage before committing.
Stay on QRadar on premises	IBM continues to provide features and support to QRadar on-premises customers, according to the Palo Alto Networks press release. Existing DSMs, content and analyst workflows remain in place.	Licensing stays tied to EPS, FPM or Managed Virtual Server terms and appliance refresh. Confirm with IBM the end-of-support dates for your version and the renewal terms.
Cortex XSIAM (vendor path)	Palo Alto Networks offered eligible QRadar SaaS customers free migration to Cortex XSIAM with IBM Consulting, per its September 2024 announcement.	This is a commercial platform, not self-hosted, so data stays in a vendor-operated environment. Confirm with Palo Alto Networks the eligibility criteria, data residency, and what the migration offer covers after the offer period.
Rebuilding QRadar content	Wazuh and OpenSearch let you rewrite detections as code and keep rules in your own repository under your control.	QRadar's packaged content and DSM library do not transfer automatically. Expect analyst time to map offenses, building blocks and reports, and budget for that work in your scope.
Authentication and access control	OpenSearch Security offers RBAC, document and field-level security, field masking and TLS. Wazuh supports single sign-on through its documented configuration.	Confirm which SSO protocol and role mapping your identity provider needs. Test access separation for analysts, auditors and administrators before cutover.

Staying on QRadar, moving to XSIAM, or self-hosting: which path fits which situation

Some organizations must keep security logs inside their own network, either for data residency rules, contractual terms or a policy that forbids sending telemetry to a vendor cloud. For this group, the question is less about features and more about where every component runs. A self-hosted stack built on Wazuh and OpenSearch keeps event storage, search and alert data on infrastructure you control, including air-gapped networks. Confirm the following before choosing:

Data location: List every system that receives logs, alerts or agent data, including vendor support access and telemetry, and confirm whether any of it leaves your network.
Team skills: Identify who will operate the indexer cluster, the Wazuh server and the agents, and whether you have Linux, search engine and detection engineering experience.
Existing content: Inventory the QRadar rules, building blocks and reports you rely on, since these must be rebuilt as Wazuh rules or OpenSearch detectors.
Offline needs: The Wazuh offline installation guide and the offline vulnerability repository cover disconnected systems, so test whether your update process fits that model.
Contract dates: Note your current QRadar term so the rebuild does not depend on a rushed cutover.

The supplied facts establish that Wazuh and OpenSearch are self-hostable and documented for offline use. They do not establish that either matches every QRadar detection, so confirm coverage with a pilot.

How to deploy Wazuh and OpenSearch inside your own network

This sequence takes a team from a documented log source and retention scope to a Wazuh and OpenSearch deployment inside its own network, with access controls, agent coverage, validated detections and a patch cadence in place.

Scope log sources and retention with security
The security team, the QRadar owners and the compliance lead list every log source that feeds QRadar today, including syslog devices, cloud audit feeds, endpoints and any flow data, then mark which ones must be kept, which can be retired and which need a compliance-driven retention period. Confirm how each source reaches Wazuh: a Wazuh agent, syslog collection or periodic API probing for agentless devices. Done when the team signs off a written source inventory and retention table that the rest of the steps reference.
Choose an installation method for the environment
The platform or infrastructure lead picks one of the documented Wazuh deployment options that fits the hosting model: step-by-step installation, the prebuilt OVA virtual machine, the Amazon Machine Image, Docker, Kubernetes, Ansible or Puppet. Networks without internet access use the offline installation guide, with an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Confirm the chosen method against the current Wazuh documentation and the OpenSearch install options, then record the decision and the reason. Done when the method and its prerequisites are approved in the change record.
Size the indexer and server cluster
The architect works with the security team to size the Wazuh indexer, which stores alerts and runs search, and the Wazuh server, which can run as a cluster for horizontal scaling. Inputs are the agent count, the event rate taken from the existing QRadar licensing report, retention periods and the storage needed for alert history. Ask the vendor or your partner to confirm sizing guidance for your event profile before purchasing hardware. Done when a sizing document shows node counts, storage and the growth assumptions, and the team accepts it.
Configure OpenSearch Security for SSO, roles and TLS
The identity team connects the OpenSearch Security plugin to the corporate directory using one of its supported backends, such as SAML, OpenID Connect or LDAP, then maps directory groups to roles that limit analysts to the indices they need. The administrator enables TLS for node and client traffic and turns on audit logging for administrative actions. Field-level or document-level security is applied where analysts should not see certain data. Done when a test analyst can log in through SSO, sees only permitted indices, and the audit log records the test activity.
Connect agents and syslog sources
The operations team installs Wazuh agents on the endpoints and servers in the inventory, using the configuration and upgrade functions the server manages remotely, and points syslog sources and agentless devices at the Wazuh server. Each source is checked against the inventory so that missing sources are visible. Decoders are confirmed for each device type that does not decode out of the box. Done when every in-scope source shows as reporting in the dashboard and the coverage gap list is empty or documented with an owner.
Validate detections and compliance views
The detection engineers replay known test events and run controlled simulations against the rules rebuilt from the QRadar offense logic, confirming that each expected alert fires and that noisy rules are tuned. Vulnerability detection is checked against the software inventory the agents collect. The compliance lead then confirms that the prebuilt dashboard views for the frameworks in scope, such as PCI DSS, GDPR, HIPAA or NIST 800-53, show the evidence the auditors expect. Done when test results, tuning decisions and the compliance view checks are recorded and signed off.
Set an upgrade cadence and maintenance calendar
The platform owner sets a recurring patch review that tracks the Wazuh 4.14 patch line, which has shipped roughly every one to two months, and the OpenSearch maintenance windows, since each minor release follows a published schedule and maintained versions receive security patches only. Each cycle includes a staging upgrade, a rollback plan and a check of the release notes for changed decoders or rules. Confirm the support and end-of-life dates for the exact versions you run before fixing the calendar. Done when the cadence is documented, the first patch cycle is scheduled and the owner is named.

Moving rules, history and SaaS-held data out of QRadar

The first question for any QRadar SaaS tenant is what you can take out, in what form, and by when. The facts available to us do not describe the export tooling for SaaS-held data after the sale, so treat the export path as something to confirm in writing with IBM and Palo Alto Networks before any cutover is scheduled. Ask for the export formats for raw events and normalized events, whether exports include the parsing and custom property context needed to read them later, and whether rule, reference data and offense exports come with the events or separately. Ask how much of the retained history is complete, which time ranges are archived, and whether any data is held in a form that only the vendor can query. Get the answers attached to the contract, not in a call summary.

Retention and custody need equal attention. Ask how long archived data remains available after the SaaS subscription ends, who holds copies, whether deletion is scheduled and how you confirm it, and what happens to logs that arrive during a transition period. Your legal and compliance owners should set the retention period your framework requires before the vendor answer is accepted. Record who keeps the final export, where it is stored, and who may restore it, because that record becomes evidence if an auditor asks how history was preserved.

Once you have a usable export, keep history queryable by loading it into OpenSearch as an index that your analysts can search and that your dashboards can read. The OpenSearch migration guidance and the migration assistant overview describe the supported paths for moving data between versions. The rolling upgrade facts apply to Elasticsearch 6.0 through 7.10 indices only, so they matter only if your export is already sitting in an Elasticsearch index from a legacy deployment. Otherwise, plan a fresh ingest, check field mappings against a sample, and keep the original export read-only. Re-creating detection rules is a manual task owned by your own team: translate each rule by hand, test it against the migrated history and retire the QRadar version only after the replacement behaves as expected.

Evidence that auditors and regulators ask for from the SIEM

Auditors assessing a SIEM rarely accept a description of the platform alone. They ask for records that show where logs live, who can reach them, how traffic is protected and how the platform has been kept current. DeployOpen prepares these artifacts, but independent auditors and certification bodies decide whether they meet the framework in scope.

Data-flow and storage record

A current diagram and register showing each log source, the collectors that carry events, where the Wazuh indexer and OpenSearch nodes store them, how long they are kept and which backups hold copies. Auditors use it to confirm that logs stay in the organization's own infrastructure and that no unknown copy exists. Check that the record is updated whenever a QRadar log source is migrated, since source mapping changes during the move.

OpenSearch role and access exports

Exports of roles, role mappings and users from the OpenSearch Security plugin, showing which teams can search indices, which fields are masked and which document-level restrictions apply. Pair them with the identity provider configuration for SAML, OpenID Connect, LDAP or Kerberos. Review them on a fixed schedule and keep the export history, because a point-in-time export alone shows nothing about changes.

Audit log samples

Samples of the OpenSearch audit log and Wazuh alert records that show authentication events, configuration changes and administrative actions with timestamps and user identities. Auditors read them to test whether privileged activity on the SIEM is itself recorded. Confirm which audit categories are enabled in your build, since the defaults you inherit from a QRadar appliance do not carry over.

TLS and certificate configuration

Evidence that traffic between agents, the Wazuh server, the indexer, the dashboard and OpenSearch nodes is encrypted, including certificate issuers, validity periods, key lengths and renewal procedures. Keep the node and client TLS settings and a list of certificates with owners. Ask your assessor which certificate authority and rotation process they accept before you generate the set.

Wazuh compliance dashboard outputs

Exports from the Wazuh dashboard views for the framework in scope, such as PCI DSS, GDPR, HIPAA or NIST 800-53, with the rules and agents behind each result. A dashboard screenshot is weak evidence on its own, so keep the underlying rule mapping and the date of each export. Confirm with your assessor that the prebuilt mapping covers the controls they will test, because gaps in that mapping must be documented by you.

Upgrade and patch records

A dated log of every Wazuh and OpenSearch upgrade, the versions moved between, the change ticket, test results and rollback steps. Wazuh 4.14 patch releases and OpenSearch minor versions arrive on a regular cadence, and auditors look for evidence that security patches were applied within your own timeline. Record which versions are still in maintenance so you can show that the platform is supported.

Questions buyers ask before moving off QRadar SaaS

What does a move off QRadar SaaS cost, and which costs recur?

The cost splits into one-time work and recurring spend. One-time work covers design, log source mapping, rule rebuilding, data export, testing and cutover. Recurring costs include the infrastructure to run the stack, storage that grows with retention, staff time for tuning and content, and any outside support retainer. Wazuh and OpenSearch carry no license fee for the core products, so the recurring line is mostly hardware or cloud capacity and people. Ask any vendor or partner for a written quote that lists each component separately, with the event rate, retention period and storage assumptions stated. No public figures for QRadar SaaS or Cortex XSIAM pricing were supplied for this page, so confirm those numbers directly with the vendors.

What drives the length of a SIEM cutover?

The timeline depends on how many log sources you have, how many detections and dashboards must be rebuilt, how much historical data must be kept searchable, and whether both platforms run in parallel. Sources with custom parsing or compliance evidence needs usually take longer than standard endpoint or firewall feeds. Running in parallel lets analysts validate detections before the cutover, but it extends the period when you pay for two platforms. Ask for a dated plan from any provider that lists source onboarding, rule validation and sign-off as separate milestones, since no duration was supplied for this migration.

What does the internal team have to provide during the migration?

Your team needs to own the decisions that a packaged SIEM previously made for you. That includes log source inventory, owners who can confirm what each feed contains, analysts who can judge whether a rebuilt rule is correct, and an operations owner for upgrades, storage and agent rollout. Expect ongoing work on detection content, because open-source tools ship the engine and a baseline, not the tuned rules your SOC relies on. Name these people before the project starts and confirm their time commitment in writing.

Can our own team run this migration without an implementation partner?

Some teams can, particularly those with Linux, search cluster and detection engineering experience and time to learn Wazuh and OpenSearch. The common gaps are cluster sizing, secure configuration, source onboarding at scale and documenting controls for an assessment. A partner can take on a fixed scope, such as platform build, integration, hardening, backup and evidence preparation, with deliverables agreed in writing before work starts. DeployOpen implements, hardens and documents self-hosted platforms inside your own infrastructure and runs security testing, but it does not issue audit reports or certifications, so any compliance assessment still comes from an independent auditor.

Does using Wazuh under GPLv2 create obligations for our organization?

Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. Running Wazuh internally for your own security monitoring is generally a different situation from distributing modified copies to others, but the obligations depend on how you use and change the code. Have your legal or open-source compliance team review your specific use, especially if you plan to modify source code or embed components in a product you ship. Keep records of the versions you deploy and any changes you make.

Does OpenSearch's Apache 2.0 license require us to publish anything?

OpenSearch is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. Apache 2.0 is a permissive license, so you can run, modify and use OpenSearch internally without publishing your changes. You still need to retain license notices and attribution when you redistribute the software, and you should check any plugins or third-party components you add, since they may carry their own licenses. Confirm the license of each plugin in your build with the project before you rely on it.

What should a written quote for this migration include?

Ask for a fixed scope listing the log sources, detections, dashboards and reports in scope, plus the systems that remain out of scope. The quote should state deliverables, acceptance criteria, the environment the work runs in, and who operates the platform after handover. Request separate line items for design, build, source onboarding, rule rebuilding, data export, testing, documentation and training. Ask how the price changes if the event rate, retention or source count grows, and confirm what support, upgrades and continuous testing cost as a separate retainer.

How DeployOpen runs a QRadar SaaS exit inside your infrastructure

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a QRadar SaaS exit, that means scoping the move in writing first, building the replacement stack in your environment, and handing over the runbooks and evidence your team needs to run it.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists your QRadar SaaS log sources, retention needs, users and the detections you must keep.
We confirm where the new Wazuh and OpenSearch stack will run, including any air-gapped or offline requirements.

How we build

We deploy Wazuh agents, server, indexer and dashboard in your infrastructure using the installation method you choose.
We connect log sources, decoders and rules, then test detections against sample events from your environment.
We configure OpenSearch security settings such as single sign-on, role-based access control and TLS for node and client traffic.

How we hand over

We document architecture, configuration, data flows and the detection content mapped to your former QRadar rules.
We deliver runbooks for upgrades, backups and access reviews so your own team can operate the platform.
We prepare the controls and evidence your compliance assessors may ask for, while auditors remain the ones who assess.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer scope, response expectations and service terms should be confirmed in writing before you sign.
Security testing of the new stack, including applications, APIs and infrastructure, can be scoped separately.

QRadar SaaS after the Palo Alto Networks sale: self-hosted alternatives