SOAR Is Dead. Long Live Custom Integration.

The Promise That Never Landed

In 2018, Security Orchestration, Automation, and Response was going to save us. Gartner put it in the magic quadrant. VCs poured hundreds of millions into platforms that would finally make the SOC efficient. The pitch was irresistible: connect everything, automate everything, respond to everything — all from one platform.

Eight years later, here's what actually happened: the average MSSP is running three to five security tools that still don't talk to each other. Analysts still copy-paste IOCs between dashboards. Tickets still go stale because status updates don't propagate. The SOAR platform sits in the corner, running the twelve playbooks that someone built during implementation — half of which broke six months ago when the SIEM updated its API.

SOAR didn't fail because orchestration is a bad idea. It failed because SOAR platforms tried to become the brain of your security operation instead of the nervous system.

The SOAR Timeline: Hype to Disillusionment

2016-2018: The gold rush. Demisto, Phantom, Swimlane, and a dozen others raised massive rounds. The thesis was sound: security teams are drowning in alerts, tooling is fragmented, manual processes don't scale. Automate the repetitive work and analysts can focus on real threats.

2019-2021: The acquisitions. Palo Alto bought Demisto (rebranded to XSOAR). Splunk acquired Phantom (rebranded to SOAR). Google bought Siemplify. The message from mega-vendors was clear: SOAR belongs inside our ecosystem. This was the first crack in the promise. SOAR was supposed to be vendor-agnostic. Now it was a feature of a larger platform.

2022-2024: The quiet stagnation. Deployments stalled. Organizations that bought SOAR licenses reported low utilization rates. The playbooks that worked on day one broke as APIs changed, staff turned over, and new tools entered the stack. SOAR became something teams maintained rather than something that maintained them.

2025-2026: The reckoning. Gartner itself retired the standalone SOAR market guide. The category absorbed into "Security Operations Platforms" and "SIEM." Not because the problems went away, but because SOAR as a category didn't solve them.

Why SOAR Platforms Actually Fail

1. Vendor Lock-in Disguised as Integration

Every SOAR platform advertises hundreds of "integrations." Open the hood and you'll find most are thin wrappers around REST APIs that the vendor built once and never updated. When CrowdStrike ships a new API version, your SOAR integration breaks. When ServiceNow changes a field schema, your ticket-creation playbook silently fails. You're not integrated — you're dependent on a third party to maintain connectors they have no incentive to prioritize.

2. Playbook Maintenance Is a Full-Time Job

The dirty secret of SOAR: maintaining playbooks requires the same engineering talent that could just build direct integrations. A mid-size MSSP running 30-50 playbooks needs at least one dedicated SOAR engineer. That engineer spends 60-70% of their time fixing broken playbooks, not building new automation. The ROI math collapses when you factor in the human cost of keeping the platform alive.

Industry data backs this up. A 2025 survey from the Ponemon Institute found that 62% of deployed SOAR playbooks become non-functional within 12 months due to API changes, staff departures, or undocumented edge cases. That's not automation. That's technical debt with a subscription fee.

3. Heterogeneous Environments Break the Model

SOAR works beautifully in a demo. The demo environment has one SIEM, one EDR, one ticketing system. Real enterprise security environments have three SIEMs (because of the acquisition last year), two EDR platforms (because the subsidiary runs something different), and ticketing workflows that span ServiceNow, Jira, and a homegrown system nobody wants to admit exists.

SOAR platforms assume a clean, rationalized stack. MSSPs managing 30-100 clients never have that luxury. Each client has their own combination of tools. A playbook built for Client A's CrowdStrike + Splunk + ServiceNow environment doesn't work for Client B's SentinelOne + Elastic + ConnectWise setup. You end up building custom playbooks per client anyway.

4. The "Single Pane of Glass" Myth

SOAR vendors love this phrase. The reality: you now have one more pane of glass. Your analysts still need to know CrowdStrike for deep-dive investigations. They still need the SIEM for complex queries. They still need the ticketing system for client communication. The SOAR platform adds a layer of abstraction that experienced analysts work around, not through.

The Numbers Don't Lie

• 6-12 months: Average SOAR deployment timeline from purchase to full production (source: multiple vendor case studies)
• 60%+: Playbooks that go stale within one year of deployment
• $150K-$400K: Annual total cost of ownership for a mid-market SOAR deployment (license + engineer + maintenance)
• 12-20: Average number of actively maintained playbooks per deployment, despite platforms advertising hundreds of templates
• 2.1 FTEs: Average human resources dedicated to SOAR maintenance in organizations with 50+ playbooks

For a growth MSSP doing $10M in revenue, that $300K+ annual SOAR investment represents a significant margin hit for something that automates a fraction of the workflow it promised.

What Replaces SOAR: Purpose-Built Integration Layers

The industry isn't abandoning orchestration. It's abandoning the idea that one platform should own the orchestration logic for your entire operation. The replacement isn't another product category. It's an architectural pattern: purpose-built integration layers that connect your existing tools without becoming another tool to maintain.

The Integration Layer vs. The Orchestration Platform

Here's the fundamental difference in philosophy:

SOAR says: "Route everything through us. We'll be the brain. Your tools are the limbs."

Integration layers say: "Your tools already have brains. We connect the nervous system so they can coordinate."

An integration layer doesn't replace your SIEM's detection logic or your EDR's response capabilities. It ensures that when your SIEM detects something, the right data flows to the right systems with the right context — without a human copying and pasting between six tabs.

What This Looks Like in Practice

Instead of a monolithic playbook that tries to handle an entire incident lifecycle, you get focused integrations:

• Alert enrichment: SIEM alert fires → integration layer pulls context from EDR, identity provider, and asset inventory → enriched alert lands in the analyst's queue with full context. No playbook. No workflow builder. Just data flowing where it needs to go.
• Bidirectional sync: Analyst updates ticket status → SIEM case status updates → client portal reflects current state. All in real-time, all without manual intervention.
• Escalation routing: Alert meets threshold criteria → the right team gets notified through the right channel with the right context. Not a 47-step workflow diagram — a simple, maintainable routing rule.

Why This Works Where SOAR Doesn't

• Smaller surface area: Each integration does one thing well. When an API changes, you update one connector, not a cascade of dependent playbooks.
• No vendor lock-in: The integration layer talks to whatever tools you run. Swap your EDR? Update one connector. The rest of your automation continues uninterrupted.
• Lower maintenance burden: Purpose-built integrations are designed for resilience — idempotent operations, graceful degradation, automatic retry. They don't silently fail and require a SOAR engineer to debug.
• Environment-agnostic: For MSSPs, integration patterns can be templated across clients even when the specific tools differ. The pattern stays the same; the connectors swap.

When SOAR Still Makes Sense

Intellectual honesty matters. SOAR isn't universally wrong — it's wrong for most environments. If you meet all of the following criteria, a SOAR platform might still serve you well:

• You run a single-vendor security stack (e.g., all Palo Alto or all Microsoft)
• Your SOAR platform is from the same vendor as your primary tools
• You have a stable, low-churn environment where APIs don't change frequently
• You have dedicated SOAR engineering staff with no competing priorities
• Your use cases are well-defined and don't evolve rapidly

That describes maybe 15% of enterprise security teams. For the rest — especially for MSSPs managing diverse client environments — the monolithic SOAR model is a liability masquerading as automation.

The Path Forward

The security operations market is moving toward composability. Best-of-breed tools connected by lightweight, purpose-built integration layers. This isn't a prediction — it's already happening. The teams that abandoned their SOAR platforms in 2024 and 2025 aren't less automated. They're more automated, with less overhead, because they stopped trying to force everything through a single orchestration layer that was never designed for their environment.

The question isn't "which SOAR platform should we buy?" The question is: "What are the three to five integration gaps causing the most pain in our operation, and what's the most maintainable way to close them?"

That's a very different question. And it leads to very different solutions.