XDR vs. SOAR: Is Your Tech Stack Redundant or Resilient?

By Manny Fernandez

July 23, 2026

XDR vs. SOAR: Is Your Tech Stack Redundant or Resilient?

The short answer. XDR and SOAR overlap on automated response and enrichment. They do not overlap on scope. XDR automates inside its own telemetry. SOAR automates across everything else, including systems that will never have an agent on them.

If you own both and you cannot draw the line between them on a whiteboard in under a minute, you are paying twice for one capability and leaving the other half unbuilt.

What XDR Actually Does

Strip the marketing off and XDR is three things bolted together: a telemetry pipeline, a vendor-authored correlation engine, and a set of response actions that are native to the sensors the platform already owns.

Telemetry it collects itself. Endpoint process trees, network session metadata, identity events, mail flow, cloud workload activity. Raw, high fidelity, and structurally consistent because one vendor defined the schema.
Detection logic you did not write. The correlation rules ship with the product and get updated by the vendor’s research team. That is the actual product. You are buying somebody else’s detection engineering.
Response scoped to its own blast radius. Isolate the host, kill the process, block the hash, quarantine the mailbox, revoke the session. Sub-second, because the enforcement point is the agent it already controls.

The constraint is the part vendors gloss over: XDR stops at the edge of its own telemetry. It cannot open a change record in your ITSM. It cannot disable an account in a directory it does not integrate with. It cannot page the on-call rotation, collect a manager approval, or produce the audit artifact your compliance team needs six months later. Those are not detection problems. They are workflow problems.

What SOAR Actually Does

SOAR is an API broker, a workflow engine, and a case management system in one box. It generally detects nothing. It consumes alerts that something else produced and then does the parts a detection platform structurally cannot do.

Cross-domain action. Firewall, IAM, ITSM, EDR, cloud provider, DNS, email gateway, HR system. Anything with an API is in scope, including systems from vendors who compete with each other.
Human-in-the-loop control. Approval gates, escalation paths, and the ability to stop a playbook before it does something expensive at 3 a.m.
The record of truth. One case, one timeline, every action attributed and timestamped. This is the artifact that survives an audit or a lawsuit.
Process measurement. You cannot improve an incident response process you have never instrumented. SOAR instruments it.

The constraint here is equally unglamorous: SOAR is software you have to build and then keep alive. Connectors break when a vendor bumps an API version. Playbooks rot when a process changes and nobody updates the logic. It needs a named owner with real hours allocated. Teams that buy SOAR without funding that role end up with a very expensive alert forwarder.

Where the Overlap Is Real

Anyone telling you there is zero overlap is selling one of the two. Here is the honest map.

Capability	XDR	SOAR	Verdict
Cross-source correlation	Native, vendor-maintained	Possible, you maintain it	XDR wins
Endpoint containment	Sub-second at the agent	API round trip, seconds to minutes	Redundant
IOC and asset enrichment	Built in, limited sources	Any source with an API	Overlaps, tier it
Third-party tool action	Only where integrated	Anything with an API	SOAR wins
Approval gates and escalation	Rare, shallow	Core function	SOAR wins
Case management	Incident queue	Full case lifecycle	Redundant
Log retention for compliance	Short, detection focused	Not its job	Neither, that is SIEM

Two rows in that table say Redundant. That is where money leaks. Not because both tools can do the thing, but because most teams never decide which one is allowed to.

The Redundancy Test

Five questions. Answer them honestly with your actual team, not the architecture diagram from the procurement cycle.

Which system owns the incident record? If an analyst has to update status in two consoles, you have redundancy, and you also have a reporting number that is quietly wrong.
When a host gets isolated, which system pulled the trigger and where is that written down? If the answer is “depends who was on shift,” you have a process gap wearing a technology costume.
What percentage of your SOAR playbooks act only on endpoint data? If it is over half, you built a slower copy of your XDR.
How many SOAR connectors have not executed successfully in the last 30 days? Pull the number. It is almost always higher than the team believes.
Can your XDR reach the systems your playbooks touch? ITSM, IAM, edge firewall, cloud provider, HR offboarding. If yes, you may not need SOAR yet. If no, SOAR is the only thing that closes those loops.

Rule of thumb. Three or more uncomfortable answers means redundant. Zero or one means resilient. Two means you are mid-migration and should finish the migration instead of buying a third thing.

Layered, Not Stacked

A resilient stack has one authority per layer and a documented handoff between layers. A redundant stack has two systems fighting over the same layer while nobody owns the layer above it.

Layer 1 / Telemetry

Agents, sensors, taps, cloud audit logs, identity providers. Owned by the platform that collects it.

Layer 2 / Detection

XDR is authoritative for anything inside its telemetry. SIEM covers the sources XDR does not ingest. Do not write duplicate rules in both.

Layer 3 / First Response

XDR is authoritative. Native containment inside its own blast radius, executed in seconds without waiting for a workflow engine. Speed lives here.

Layer 4 / Orchestration

SOAR is authoritative. Everything XDR cannot touch. Ticketing, IAM, edge policy, cloud, notification, approval, third-party enrichment.

Layer 5 / Case and Metrics

One system, and only one. Usually SOAR or your ITSM. The XDR incident ID becomes a field on that case, not a competing record.

Notice what is missing from that stack: a layer where both tools do the same job. If you can point at one, that is your redundancy.

The Automation You Already Paid For

Before you sign a SOAR quote, inventory what your existing platforms already automate. Most modern security fabrics ship an event-driven automation engine that covers a meaningful slice of the easy playbooks at no additional license cost.

On FortiOS, that engine is the automation stitch: a trigger, one or more actions, and a binding between them. Here is auto-quarantine of a compromised host on a high-confidence IOC, which is the single most common “we need SOAR for this” request I hear in the field.

config system automation-trigger
    edit "trig-ioc-high"
        set event-type ioc
        set ioc-level high
    next
end

config system automation-action
    edit "act-quarantine-host"
        set action-type quarantine
        set required enable
    next
end

config system automation-stitch
    edit "stitch-auto-quarantine-ioc"
        set status enable
        set trigger "trig-ioc-high"
        config actions
            edit 1
                set action "act-quarantine-host"
                set required enable
            next
        end
    next
end

That is a containment playbook with zero orchestration licensing and zero connector maintenance. It runs at the enforcement point. It will still be running in three years when half your SOAR connectors have drifted.

Now the honest counterpoint. That stitch cannot open a ticket, cannot notify the asset owner, cannot check whether the host is a production database server before it cuts it off, and cannot produce an audit trail your GRC team will accept. For that you need to hand off. A webhook action is the cleanest seam between the two worlds.

config system automation-action
    edit "act-notify-soar"
        set action-type webhook
        set protocol https
        set method post
        set uri "soar.example.com/api/triggers/1/fabric-ioc"
        set port 443
        set http-body "{\"src\":\"%%log.srcip%%\",\"dev\":\"%%log.devname%%\",\"sev\":\"%%log.level%%\"}"
        config http-headers
            edit 1
                set key "Content-Type"
                set value "application/json"
            next
            edit 2
                set key "Authorization"
                set value "Bearer REPLACE_WITH_TOKEN"
            next
        end
    next
end

Add that action to the same stitch and you get the pattern that actually works: the fabric contains, the orchestrator coordinates. Containment does not wait on the workflow engine, and the workflow engine still gets an authoritative event to build a case around.

Validate the receiver before you wire it into production. If this returns anything other than a 2xx, your stitch will fail silently and you will not find out until the incident that mattered.

curl -sS -o /dev/null -w "%{http_code}\n" \
  -X POST "https://soar.example.com/api/triggers/1/fabric-ioc" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer REPLACE_WITH_TOKEN" \
  -d '{"src":"10.20.30.40","dev":"FGT-EDGE-01","sev":"critical"}'

# Then confirm the stitch fired at all:
#   diagnose test application autod 2
#   execute log filter category event
#   execute log display

Where SIEM Fits

Skipping this section would be dishonest, because a lot of “XDR vs. SOAR” arguments are really unresolved SIEM arguments in disguise.

XDR does not replace SIEM. It replaces a subset of SIEM’s detection workload for the sources it happens to ingest. It does not replace multi-year retention, it does not replace correlation across the mainframe and the badge reader and the custom app your finance team wrote in 2009, and it does not replace the compliance evidence chain. If your XDR business case included “we can decommission the SIEM,” go re-read the retention requirement in your audit scope before that renewal lands.

The clean split: SIEM for breadth and retention, XDR for depth and speed, SOAR for reach and record. Three jobs, three tools, and the moment two of them are doing the same job you should be killing one.

Anti-Patterns That Kill Programs

Rebuilding XDR correlation inside SOAR. You are now the detection engineering team for logic a vendor was already maintaining for you. This is the most expensive mistake on the list and it is almost always driven by a team that does not trust their XDR tuning.
Buying SOAR to solve a headcount problem. Automation multiplies capacity, it does not create it. A three-person SOC with no automation engineer will not have a functioning SOAR deployment in twelve months. They will have a shelf.
The playbook graveyard. Sixty playbooks built during the deployment sprint, six that have run this quarter. Kill the fifty-four. Dead playbooks are not neutral, they hide the live ones and inflate your perceived coverage.
Automating a broken process. If your escalation path is unclear when a human runs it, automating it produces confusion at machine speed. Fix the runbook first, then encode it.
Full auto-containment on day one. Ship in observe mode, then approval-gated, then automatic for a narrow and well-understood detection set. And build the rollback path before the first isolation, not after the first false positive takes out a payroll server on the 15th.
No connector owner. Every integration is a dependency on someone else’s API lifecycle. Unowned connectors do not throw errors, they just quietly stop mattering.

Metrics That Tell the Truth

Redundancy is measurable. These are the numbers that expose it, and most of them are not on a default dashboard because no vendor benefits from you seeing them.

Metric	What It Actually Proves
Console pivots per incident	The cleanest redundancy proxy there is. More than two means your layers are not cleanly owned.
Duplicate incident rate	One event producing two case records in two systems. Direct evidence of an undefined authority boundary.
Percent contained without analyst touch	Whether your XDR investment is actually returning anything at Layer 3.
Playbook execution success rate	Completed over attempted. Anything under 90 percent means your connectors are decaying faster than you are fixing them.
Playbooks executed in last 90 days	The graveyard count. Compare to total built. The gap is your real maintenance debt.
Detect to contain, split by layer	Measure XDR-native and SOAR-driven containment separately. Averaging them hides which one is slow.
Playbooks touching only endpoint data	Every one of these is a candidate to be deleted and re-implemented as a native XDR action.

Which One Do You Buy First?

Your Situation	Move
Under five analysts, mostly one vendor’s stack, drowning in alerts	XDR first. Native automation plus fabric stitches covers your top playbooks. SOAR would sit unmaintained.
Fifteen-plus security tools from six-plus vendors, heavy ticketing dependency	SOAR first. Your problem is connective tissue, not detection.
MSSP or MDR delivering detection for you	SOAR first, for the internal actions your provider contractually cannot take.
Regulated, audit-heavy, evidence chain is the pain	SOAR plus SIEM. XDR alone will not generate the artifacts you need.
You already own both and are not sure why	Buy nothing. Run the redundancy test, assign one authority per layer, delete the overlap.
No automation engineer and no plan to hire one	Not SOAR. Use native platform automation until the role exists.

What To Do Monday

Export every SOAR playbook. Tag each one with the systems it touches. Anything touching only endpoint or only your XDR API goes on the deletion candidate list.
Pull 90 days of playbook execution logs. Sort by last successful run. Everything untouched gets archived, not “reviewed later.”
Pick your last five real incidents. Walk each one and count console pivots. That number is your redundancy score.
Write one sentence per layer naming the authoritative system. If you cannot write it, that is the layer to fix first.
Inventory native automation you already own on your existing platforms. Move every playbook that fits down into it.
Define the handoff contract in writing. What XDR does natively, what triggers the webhook, what SOAR owns after that, and which system holds the case ID.

Bottom Line

XDR and SOAR are not competitors. They are adjacent layers that both happen to expose a button labeled “isolate host,” and that single overlap is why the debate exists at all.

Redundant stacks let both tools claim the same layer and hope it sorts itself out. Resilient stacks assign one authority per layer, document the handoff, and delete whatever is left over. The tools are not the variable. The boundary is.

XDR vs. SOAR: Is Your Tech Stack Redundant or Resilient?

What XDR Actually Does

What SOAR Actually Does

Where the Overlap Is Real

The Redundancy Test

Layered, Not Stacked

The Automation You Already Paid For

Where SIEM Fits

Anti-Patterns That Kill Programs

Metrics That Tell the Truth

Which One Do You Buy First?

What To Do Monday

Recent posts