QRadar 7.6.0 Upgrade Guide: EOS Dates & Migration Plan
QRadar 7.6.0 is GA, the legacy Auto Update server retires 21 August 2026, and several QRadar products hit end of support. A practitioner's upgrade plan.
There is a hard deadline in your QRadar estate on 21 August 2026, and most teams have not scheduled the maintenance window for it.
Executive Summary
Three things happened to the IBM QRadar portfolio in 2026, and they interact badly if you handle them in the wrong order.
First, IBM shipped QRadar 7.6.0. It reached general availability on 30 June 2026 under PID 5737-B52, with a Support Cycle-5 lifecycle policy — five years of support, a one-year critical fix extension, and three further years of usage and existing fixes (5+1+3). This is the first new QRadar version stream since 7.5.0 went GA in January 2022.
Second, IBM is moving the QRadar Auto Update infrastructure. The new server went live on 21 July 2026; the legacy server is decommissioned on 21 August 2026. Connectivity to the new server is by hostname only — there is no static IP. If your firewall team wrote IP-based egress rules for QRadar (and in most Indian BFSI environments they did), your daily and weekly content updates stop on that date.
Third, a set of QRadar products reached end of support on 30 April 2026, and one of them — QRadar Incident Forensics — is not available in the 7.6.x release stream at all. That single fact splits QRadar estates into two groups with different upgrade paths.
None of this is a crisis. All of it is schedulable work that becomes a crisis when it surfaces during an audit or an incident rather than during planning. What follows is what changed, what breaks on upgrade, what you gain, and how to sequence the work without violating CERT-In's log retention direction along the way — written for SOC leads, SIEM engineers and CISOs running QRadar on-premises in India.
1. What Actually Changed in the QRadar Portfolio
QRadar 7.6.0 is a real version boundary
7.6.0 is not an update package. It is a new version stream, built as 2026.4.0.20260621205226 and delivered as the SFS file 760-QRADAR-QRSIEM-2026.4.0.20260621205226.sfs. IBM's release notes enumerate exactly which source versions it accepts, and the list starts at 7.5.0 Update Package 10.
The platform work matters more than the feature list: 7.6.0 replaces QRadar's older custom network configuration scripts with Red Hat NetworkManager, which IBM explicitly frames as alignment with "Red Hat's roadmap for RHEL 9 and RHEL 10." Read that as groundwork for the operating system transition that follows. If you plan appliance refreshes on a three-year cycle, this is the release where the OS floor starts moving.
The 30 April 2026 end-of-support group
Per IBM's QRadar Support Lifecycle page (last modified 14 May 2026):
| Product | PID | End of Support | Extended/sustained support complete |
|---|---|---|---|
| QRadar Incident Forensics | 5725-Q41 | 30 April 2026 | 30 April 2030 |
| QRadar Incident Forensics Software | 5725-Q42 | 30 April 2026 | 30 April 2030 |
| QRadar Network Packet Capture Software | 5737-B29 | 30 April 2026 | 30 April 2026 |
| QRadar Log Manager | 5737-C13 | 30 April 2026 | 30 April 2030 |
| QRadar Log Manager High Availability | 5737-C14 | 30 April 2026 | 30 April 2030 |
| QRadar Log Manager Disaster Recovery | 5737-C15 | 30 April 2026 | 30 April 2030 |
| QRadar Vulnerability Manager | 5725-M15 | 30 April 2023 | 30 April 2023 |
Note the asymmetry. Most of these have sustained support running to 2030, which buys planning time. QRadar Network Packet Capture Software does not — its extended support window closed on the same day as its EOS. If packet capture is part of your forensic evidence chain, that gap is already open.
On the software version side, the same page records 7.4.x reaching EOS on 28 April 2023 and 7.3.x on 30 September 2022. Both 7.5.0 and 7.6.0 are listed as current patched releases. If you are still on 7.4.x, you have been running without defect or security fixes for over three years — and, as section 2 explains, you are about to lose content updates as well.
What the Palo Alto divestiture did and did not change
This is the most commonly misread item in the portfolio, so it is worth stating precisely.
IBM divested the SaaS assets only. Per IBM's own divestiture notifications, QRadar Suite – EDR SaaS (PID 5900-AOI) and QRadar Suite – SOAR SaaS (PID 5900-AX0) were divested to Palo Alto Networks on 5 September 2024, with end of marketing on the same date under announcement AD24-0738. Palo Alto Networks subsequently announced end of life for the acquired Threat Management QRadar SaaS products on 14 April 2025.
Two clarifications that follow directly from those pages:
- IBM continues to provide QRadar product support for both SaaS and on-premises customers. SaaS customers with a corresponding entitlement are instructed to continue opening IBM QRadar support cases as usual.
- On-premises QRadar SIEM was not part of the divestiture. IBM published 7.6.x on 30 June 2026 with a full 5+1+3 support cycle, which is not the behaviour of a product being wound down.
The practical consequence: "QRadar is end of life" is wrong as a blanket statement, and any vendor telling you otherwise is selling you something. The accurate statement is that the SaaS line is gone, several sub-products hit EOS in April 2026, and the on-premises SIEM has a fresh version stream with a published lifecycle.
If you are on the SaaS side of that line rather than on-premises, this guide is not the one you need — see our QRadar SaaS end-of-life migration guide for Indian SOC teams, which covers the Cortex XSIAM path, the alternative-SIEM options and the data residency questions that apply to the divested products.
2. The 21 August 2026 Auto Update Cutover
Do this one first. It is the smallest piece of work on this list and the only one with a fixed external deadline.
What changes
| Legacy server | New server | |
|---|---|---|
| Hostname | https://auto-update.qradar.ibmcloud.com/ | https://au.ibm.qradar.com/ |
| Static IP | 169.47.251.244:443 | None — FQDN only |
| Status | Decommissioned 21 August 2026 | Live since 21 July 2026 |
IBM states that all QRadar products and versions are impacted. QRadar on Cloud customers need do nothing — the SRE team handles it. Everyone running on-premises owns this change.
The critical detail is the absence of a static IP on the new server. Any firewall rule, proxy ACL or egress policy that permits QRadar to reach 169.47.251.244 and nothing else stops working silently. DSM updates, protocol updates and content packs simply stop arriving, and the first symptom is usually a parsing failure on a device type someone updated three months later.
The 7.4.x trap
IBM's notice is explicit: QRadar 7.4.x may fail to connect to the new Auto Update server due to TLS version requirements. The signature IBM documents in the auto update logs is:
Could not retrieve "manifest_list_512": 500 error while setting up ssl connection
(SSL connect attempt failed because of handshake problems
error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error)
The documented workaround is to pull the weekly auto update (WAU) bundle from Fix Central and install it locally while planning an upgrade to a supported version. That is a stopgap, not a plan. A 7.4.x console in an Indian BFSI environment in August 2026 is a finding waiting to be written up.
The change itself
The procedure IBM documents is short:
- Log in to the QRadar Console as an administrator.
- Admin tab → System Configuration → Auto Update → Change Settings.
- Advanced tab → set Web Server to
https://au.ibm.qradar.com/. - Click Yes if prompted to reload settings. This reloads configuration only; it does not stop services.
- Check for Updates, then Get New Updates, then confirm completion in View Update History.
One trap worth flagging to whoever does the work: the Web Server field must end with a trailing forward slash, or QRadar returns an "Invalid format for server" error.
Sequence it as: firewall team adds the FQDN allow rule → verify egress from the console → change the setting in a maintenance window → confirm a successful update cycle. Not the other way round.
3. The 7.6.0 Upgrade Path — Who Can Upgrade and Who Cannot
Supported source versions
The 7.6.0 SFS will upgrade only these versions:
| Source version (base UP supported) | Interim fixes also supported |
|---|---|
| 7.5.0 Update Package 10 | IF01 to IF02 |
| 7.5.0 Update Package 11 | IF01 to IF04 |
| 7.5.0 Update Package 12 | IF01 to IF03 |
| 7.5.0 Update Package 13 | IF01 to IF02 |
| 7.5.0 Update Package 14 | IF01 to IF05 |
| 7.5.0 Update Package 15 | IF01 to IF04 |
Anything below 7.5.0 UP10 requires an intermediate hop first. Budget for that — it is a second maintenance window, a second backup, and a second regression pass on your custom content.
Standard preconditions from the release notes apply and are routinely missed:
- Every appliance in the deployment must be at the same software version as the Console. The update will not install on a managed host at a different revision.
- All changes must be deployed. The update refuses hosts with undeployed changes.
- At least 10 GB free in a staging directory. IBM recommends
/storetmp; in 7.6.0,/store/tmpis a symlink to the/storetmppartition. - Verify the SFS sha256sum against Fix Central, and use code signing utility 1.0.2 to confirm the package is IBM-signed.
- The Console is patched first, always. Managed hosts do not even appear in the installer menu until the Console is done.
The Incident Forensics fork
This is the decision point that determines your whole roadmap. From the 7.6.0 release notes, verbatim:
QRadar Incident Forensics is not available in the QRadar 7.6.x release stream. Customers currently using QRadar Incident Forensics should remain on, or upgrade to, QRadar version 7.5.0 Update Package 15 (UP15) to maintain support.
If you run QIF, your supported ceiling is 7.5.0 UP15 — and QIF itself reached EOS on 30 April 2026, with sustained support to 30 April 2030. The choice is between keeping a forensics capability on a frozen version stream or replacing it and moving the SIEM forward. Decide deliberately and document it, because an auditor will eventually ask why the SIEM version is pinned.
Appliance hardware
Hardware lifecycle runs separately from software. Per the lifecycle page, the current M8 series (machine type 5840) and D7 series (4893) follow the standard IBM appliance policy — five years from the end-of-marketing date — while legacy series appliances follow a custom lifecycle of five years from the date of original purchase, fixed to each individual serial number. Several widely deployed legacy PIDs (5737-B26, B27, B28, C39, C42, D35) reached hardware EOS on 31 December 2025; the M7-generation parts (5900-AVJ, AVK, AVL, AVS, AVQ, AVO, AVP) run to 31 December 2030.
After hardware EOS, no remote or on-site hardware support is available. Software support continues if S&S is current, but you source hardware fixes from the vendor yourself. Pull your serial numbers before you scope the upgrade, not after.
4. Breaking Changes That Will Bite You
| Change | Who is affected | What to do |
|---|---|---|
| HA hosts route app traffic via the shared VIP | Any HA deployment where a firewall, VPN or proxy allows egress by the HA host's physical IP | Reconfigure third-party devices to expect the VIP. IBM states the change is by design and does not support third-party software. |
| WinCollect 7.3.1 Patch 4 required | Estates with managed WinCollect 7 agents | Upgrade the agent version on the Console; depending on your path this may be required before the SIEM upgrade |
| Red Hat NetworkManager adoption | All | Network config now flows through NetworkManager (CLI, API, message bus). Re-validate any bonding, VLAN or static route automation. |
| MaxMind database refresh | Anyone using geographic AQL functions or country flags on Log Activity | Update the MaxMind database after upgrading, or geo queries return stale or empty results |
| Browser cache | All analysts | Clear cache before first login post-upgrade; tell the SOC before the window, not after |
The HA VIP change deserves emphasis: it is the one most likely to produce a confusing post-upgrade outage, and IBM flagged the same behaviour in 7.5.0 UP15. If your apps — threat intelligence feeds, X-Force integrations, app-store extensions — lose internet reachability after the upgrade, this is almost certainly why, and the fix is on the network device, not in QRadar.
Known issues shipped at GA
IBM published six known issues alongside the 7.6.0 release:
DT473994— Attack Timeline filter error for usernames with special charactersDT474000— report limits not applying on multi-value CEPsDT472949— editing bonds can disable the bond and its interfacesDT474010— CEP regex test returns incorrect resultsDT473913— EP/EFP/FP timebomb licence does not update to PERPETUAL after expiryDT474013— dashboard widget throws an exception while saving configuration
DT472949 is the one to respect during the change window: bond editing is exactly what a network engineer might attempt mid-upgrade on a multi-NIC appliance.
On the credit side, 7.6.0 resolves real operational defects, including DT446559 (backup archives over 512 MB could not be uploaded through the Admin tab), DT466765 (backups failing after UP15 IF01) and DT450797 (reports queuing indefinitely after UP12 with a NoClassDefFoundError). If you have been living with any of those, the upgrade pays for itself.
5. What You Actually Gain
A version upgrade needs a business case beyond "supported." Here is what 7.6.0 adds, per IBM's what's-new documentation.
Attack Timeline. A chronological view of offense progression showing the initial trigger, rule contributions, and the point at which new users, hosts or log sources entered the offense — each milestone carrying event names, IPs, hostnames and contributing rules, with a drill-down panel that does not navigate away. For L1 analysts, this collapses several manual pivots into one view.
Multi-value Custom Event Properties. The DSM editor can now capture repeated matches and persist them as a list, so events with repeating fields retain all values instead of one parsed instance. UI searches and AQL both evaluate every captured value. If you have ever written a regex that silently dropped the second and third entries in a list-shaped field — most cloud audit logs, most modern JSON telemetry — this is the fix.
CEP parsing order via API. You can retrieve and modify the execution order of custom event property parsing expressions programmatically, with changes reflected in the DSM editor and impact analysis flagging conflicts before they apply. That makes parsing configuration a version-controllable artefact rather than a UI ritual — which matters if you run dev and production consoles that must agree. Bulk asset create and delete APIs land in the same release, processed asynchronously with a status endpoint reporting per-operation failures.
QNI: RDP fingerprinting and TLS 1.3 decryption. QRadar Network Insights now analyses RDP at layer 7 — identifying insecure encryption, inspecting payloads, and detecting non-standard ports and suspicious authentication attempts — with fingerprints stored in Ariel for correlation and search. Given how much lateral movement in Indian enterprise environments transits RDP, that is useful detection surface. TLS 1.3 decryption is supported where an approved SSL proxy or key-based setup exists, with policy and audit controls.
Performance. Searches over events and flows using reference set filters are up to 5× faster, building on improvements in 7.5.0 UP15. The maximum rate at which CRE rule responses add data to reference data structures is 2× higher. If your detection content leans on reference sets — and if you have built anything like the identity-correlation rules in our SIEM and IAM integration playbook, it does — this is the most tangible operational gain in the release.
Resilience tooling. A DC-DR health-check dashboard API (Phase 1), invoked by Data Synchronization app 4.0.0, provides scheduled or on-demand failover and failback validation across network connectivity, backup and storage, deployment topology and system configuration. For regulated entities carrying recovery objectives, that is evidence rather than assertion.
6. Doing This Without Breaking Your Indian Regulatory Obligations
A SIEM upgrade is a period during which logging is degraded, and Indian regulation is specific about logging. Three obligations constrain how you schedule the work.
CERT-In Directions under Section 70B(6)
The directions dated 28 April 2022 (No. 20(3)/2022-CERT-In) impose three requirements that intersect directly with an upgrade window:
- Clause (i) — time synchronisation. All ICT system clocks must be synchronised to NIC or NPL NTP servers, or to servers traceable to them. Entities spanning multiple geographies may use another accurate standard source, provided it does not deviate from NPL and NIC. An upgrade that resets or re-images NTP configuration on collectors puts correlation accuracy — and this clause — at risk.
- Clause (ii) — six-hour reporting. Listed cyber incidents must be reported to CERT-In within six hours of noticing them. Your detection and escalation capability cannot be dark for longer than your incident response process can tolerate.
- Clause (iv) — 180-day rolling retention. Logs of all ICT systems must be enabled, maintained securely for a rolling period of 180 days, and maintained within Indian jurisdiction, and provided to CERT-In alongside incident reporting or on direction.
The directions state that failure to furnish the information or non-compliance "may invite punitive action under sub-section (7) of the section 70B of the IT Act, 2000 and other laws as applicable."
The operational reading: your upgrade plan needs a documented answer to "where did events go during the window, and can we still produce 180 days of history afterwards." A verified backup, a collector-side queueing strategy, and an explicit restore test are not optional extras here — they are the compliance artefact.
SEBI CSCRF
For SEBI-regulated entities, the governing instrument is the Cybersecurity and Cyber Resilience Framework, circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated 20 August 2024. Treat a major SIEM version change as a change-management event with a rollback plan and evidence trail, and schedule it away from your audit submission window. Our SEBI CSCRF checklist covers the control set auditors actually test.
Detection coverage
The upgrade is also an opportunity. As CERT-In's own threat reporting makes clear — see our breakdown of the Digital Threat Report 2025-26 — the attacks that matter in Indian BFSI now present as legitimate sessions rather than obvious intrusions. Multi-value CEP support and RDP fingerprinting are both relevant to that class of detection. Fold a content review into the project rather than treating it as a pure platform exercise.
7. Upgrade, or Migrate Off QRadar?
The honest answer depends on your estate, not on vendor positioning.
| Factor | Favours upgrading to 7.6.0 | Favours evaluating alternatives |
|---|---|---|
| Detection content | Large investment in custom rules, building blocks, reference sets and DSM extensions | Thin content; mostly out-of-the-box rules |
| Team skills | Existing QRadar-certified engineers and AQL fluency in-house | No QRadar skills; hiring has repeatedly failed |
| Deployment shape | On-premises or data-residency-constrained; appliances within hardware lifecycle | Cloud-first estate; appliances past or near hardware EOS |
| Sub-products in use | SIEM, QNI, Log Manager consolidation | Heavy dependence on Incident Forensics or QRadar Vulnerability Manager |
| Cost trajectory | EPS volumes stable and predictable | Volumes growing faster than the licence model absorbs |
| Timeline | Need a supported platform this quarter | Have 9–12 months and executive appetite for a platform change |
Two observations from doing this work in Indian enterprises. Migration is almost always more expensive than the licence comparison suggests, because the cost sits in re-authoring detection content and re-onboarding log sources, not in the platform — a rule set built over five years does not port, it gets rewritten and re-tuned, and the tuning is the expensive part. And the strongest case for migration is rarely price; it is staffing. If you cannot hire or retain people who can operate the platform, the platform is wrong for you regardless of its feature matrix. We covered the cost and capability comparison in QRadar vs Splunk, and the staffing side in our guide to SOC as a Service in India.
If the answer is "upgrade" — which for most estates with real content investment it is — do it now, while 7.5.0 UP15 is still a supported fallback.
8. A Practical Sequence
| Phase | Work | Gate before proceeding |
|---|---|---|
| Week 0 | Auto Update cutover: firewall FQDN rule, console setting change, verify update cycle completes | A successful entry in View Update History |
| Week 1 | Inventory: software version and UP/IF level per host, appliance serial numbers and hardware EOS dates, sub-products in use (QIF, Log Manager, NPC, QVM) | Documented estate map, QIF decision made |
| Week 2 | Remediate the floor: bring any host below 7.5.0 UP10 up to a supported source version; align all managed hosts to the Console revision; deploy all pending changes | Every host at the same revision, zero undeployed changes |
| Week 3 | Pre-flight: verified configuration backup with a tested restore, df -h disk check on every host, sha256 and code-signature verification, WinCollect agent plan, HA VIP firewall changes staged | Restore test passes |
| Week 4 | Upgrade Console, then managed hosts. Clear browser caches. Update MaxMind. Validate log source health, parsing, offense generation, reports and app internet reachability | 24-hour clean run on EPS, parsing errors and offense counts |
| Week 5 | Content review: migrate list-shaped CEPs to multi-value, enable Attack Timeline, evaluate QNI RDP fingerprinting, baseline the reference-set search improvement | Detection coverage report |
The gates matter more than the weeks. Compress the calendar if you can staff it; do not skip the gates.
FAQ
Is IBM QRadar end of life?
No — but parts of it are. IBM divested QRadar's SaaS assets (EDR and SOAR SaaS) to Palo Alto Networks on 5 September 2024, and Palo Alto announced end of life for those acquired SaaS products on 14 April 2025. On-premises QRadar SIEM was not divested: IBM released version 7.6.x on 30 June 2026 with a 5+1+3 support lifecycle, and continues to provide QRadar support to both SaaS and on-premises customers. Separately, QRadar Incident Forensics, Log Manager, Network Packet Capture Software and Vulnerability Manager have reached end of support.
What happens if I miss the 21 August 2026 Auto Update deadline?
Your QRadar deployment stops receiving daily and weekly Auto Update packages — DSM updates, protocol updates and content. Existing detection continues to run, so the failure is quiet. It surfaces later as parsing failures against updated device types and stale content. The fix is the same after the deadline as before: allow au.ibm.qradar.com by FQDN through the firewall and repoint the console's Auto Update Web Server setting.
Can I upgrade to 7.6.0 directly from QRadar 7.4.x?
No. The 7.6.0 SFS accepts only 7.5.0 Update Package 10 through Update Package 15 IF04. A 7.4.x deployment needs an intermediate upgrade first — and 7.4.x has been out of support since 28 April 2023, and may not connect to the new Auto Update server at all because of TLS version requirements.
We use QRadar Incident Forensics. What are our options?
QIF is not available in the 7.6.x stream. IBM's guidance is to remain on or upgrade to 7.5.0 UP15 to maintain support. QIF itself reached end of support on 30 April 2026, with sustained support to 30 April 2030. That gives you a planning window, not a solution — you will eventually choose between replacing the forensics capability or leaving the SIEM pinned to 7.5.0.
How long does a QRadar 7.6.0 upgrade take?
Installer runtime scales with appliance count and data volume, but runtime is rarely the constraint. The schedule is driven by prerequisites: bringing hosts to a common revision, clearing undeployed changes, freeing 10 GB of staging space per host, and completing a verified backup with a tested restore. Estates already on 7.5.0 UP14 or UP15 with a clean deployment state move quickly; estates below UP10 need two windows.
Does upgrading the SIEM affect our CERT-In log retention compliance?
It can. CERT-In's 28 April 2022 directions require logs of all ICT systems to be maintained securely for a rolling 180 days, within Indian jurisdiction. An upgrade window during which events are dropped, or a restore that loses historical data, puts that obligation at risk. Plan collector-side queueing, verify the backup with an actual restore test, and document event continuity across the window as part of the change record.
Should we move to a managed SOC instead of running QRadar ourselves?
That is a staffing question more than a platform one. If the upgrade is stalled because nobody in-house can own it, the platform decision is downstream of the capability gap. A co-managed model — your team retains the console, an external team carries 24/7 monitoring and platform engineering — is usually a better first step than a full migration, because it does not force you to rewrite detection content under time pressure.
Planning This With Cyberaube
QRadar upgrades that go badly go badly for the same three reasons: the estate inventory was incomplete, the backup was never restore-tested, or nobody checked what the firewall was doing to egress traffic.
Cyberaube works with Indian enterprises on QRadar platform engineering — version upgrades, appliance refresh planning, Auto Update and connectivity remediation, detection content migration, and DSM and log source onboarding. Where the constraint is people rather than plan, we place certified QRadar and SIEM engineers on contract or permanent terms through our cybersecurity staffing practice, and run 24/7 managed security operations for organisations that would rather not carry the platform in-house. Where DPDP obligations sit alongside the SIEM work, our DPDP audit and compliance service covers the data-protection assessment.
Talk to us about your QRadar upgrade or migration
Conclusion
The 21 August 2026 Auto Update decommission is the item to action this week. It takes a firewall rule and a settings change, and missing it degrades your SIEM silently rather than loudly — the worst failure mode a compliance-relevant system can have.
Everything else is planning work with real deadlines attached. QRadar 7.6.0 gives you a supported platform on a published 5+1+3 lifecycle, meaningful search performance gains, and the first analyst-facing triage improvement in years. It also draws a hard line: 7.5.0 UP10 is the floor, Incident Forensics does not cross it, and several appliance generations are already past hardware end of support.
Pull your version list and your serial numbers this week. Most of the difficulty here is discovery, and discovery is free.
Request a QRadar estate and upgrade readiness assessment
About the Author
Saurabh Pande is Co-Founder of Cyberaube Technologies with 13+ years of experience across enterprise security platforms including IBM Security, CyberArk, and QRadar. He has interviewed and placed 2,500+ cybersecurity professionals across SIEM, PAM, and IAM disciplines, and advises BFSI organizations on security operations strategy and compliance readiness.
About Cyberaube
Cyberaube provides cybersecurity staffing, 24/7 managed security services, and expert consulting for SIEM, IAM, and data protection platforms. Our certified specialists implement and operate QRadar, Splunk, ArcSight, CyberArk, Okta, SailPoint, and integrated security stacks for enterprises across India and globally.