The Elephant in the Room: How Independent Can Splunk Remain Inside Cisco?

Two years after the acquisition, there is an elephant in the room: Cisco and Splunk are becoming increasingly difficult to view as separate technology strategies. Cisco Live 2026 and Splunk .conf26 demonstrated a shift from product-level integration toward architectural convergence, with the Splunk Platform serving as the data and intelligence layer beneath Cisco Data Fabric, Cloud Control and its emerging agentic operations model. The integration of Splunk is complete from a company perspective but the product integration is on-going. Splunk remains a distinct platform, product portfolio and business unit, but Cisco is increasingly building new capabilities on the assumption that Splunk data and intelligence are part of the underlying Cisco architecture. That raises an important question for Splunk customers: How independent can Splunk remain as it becomes more important to Cisco?

Cisco and Splunk anticipated this tension when the acquisition closed in March 2024. Splunk said the combined portfolio would remain “open and extensible” and described the desired architecture as “tightly integrated, but loosely coupled,” specifically so customers could continue operating multi-vendor environments and protect existing investments. I heard those words again at both Cisco Live and Splunk .conf26, but this is a challenging tightrope to walk.

There is still considerable evidence that Cisco is honoring the “open” side of the Splunk promise. Splunk continues to invest in OpenTelemetry as well as Open Cybersecurity Schema Framework (OCSF), a critical security standard, and in July 2026 explicitly characterized OTel as important for vendor neutrality. Cisco Data Fabric’s new Machine Data Lake also retains data in open formats, while Federated Search is designed to query data where it resides rather than requiring everything to be ingested into Splunk. But let’s double down on this point: technical openness is not necessarily the same thing as architectural neutrality.

Splunk can continue ingesting telemetry from Cisco, AWS, Microsoft, Palo Alto Networks, CrowdStrike, custom applications and countless other sources. It can support OpenTelemetry, OCSF, and federated data and remain an open platform in that sense. But Cisco is increasingly making Splunk the intelligence layer of Cisco’s own architecture. At Cisco Live 2026, Cisco Data Fabric, powered by Splunk, was described as the prospective “system of record and intelligence layer for the agentic enterprise.” Then at Splunk .conf26, Splunk appeared directly inside Cisco Cloud Control, connecting network, security and application data with Cisco’s AI operating environment.

This isn’t necessarily a Borg moment where Cisco consumes Splunk and Splunk disappears. The two can coexist. But what I heard from some customers at .conf26 was concern about a gravitational pull toward Cisco. For example, Jeetu Patel said during his opening keynote at .conf26, “You don’t have to buy everything from us all at once, but boy, when you do buy two things together, they work like that.” He used the phrasing to explain Cisco’s philosophy behind a “tightly integrated but loosely coupled” full stack: customers can adopt components modularly, but gain greater value and interoperability when Cisco and Splunk products are paired together.

That makes sense strategically, but having Cisco leadership so prominently on stage, combined with statements about the value customers gain when Cisco technologies are purchased together, does make a longtime Splunk customer wonder where this ultimately leads. I wouldn’t expect Cisco to make Splunk a closed, Cisco-only platform. That would risk damaging one of the primary assets it spent $28 billion to acquire: Splunk’s enormous installed base and its position as a relatively neutral repository and analytics platform across heterogeneous environments. The more realistic customer concern is more subtle: Does the best Splunk experience gradually become a Cisco experience? That, to me, is the elephant in the room.

The question for existing Splunk customers may therefore be shifting from whether Splunk remains technically open to whether it remains architecturally neutral, or whether the richest capabilities increasingly accrue to customers operating more broadly within the Cisco ecosystem. For Cisco customers, deeper integration demonstrates the strategic value of the acquisition. For long-standing Splunk customers, that same integration can create uncertainty about Splunk’s future independence. Those two groups can look at exactly the same product announcement and interpret it differently: Cisco customers see synergy; longtime Splunk customers may see dependency.

This is also what I heard in customer one-to-ones at .conf26. I heard both: “It’s great that Cisco is benefiting from Splunk in its architecture. I like the convergence.” And I heard, “I’m concerned that Cisco is absorbing Splunk too deeply into its architecture and Splunk will no longer be vendor agnostic.” Neither interpretation necessarily means Cisco is doing anything problematic today. But it does give customers a useful set of things to watch:

1. Whether non-Cisco integrations retain functional parity.

2. Whether Cisco-native telemetry begins to receive privileged context or functionality.

3. Whether agentic remediation remains equally capable across third-party infrastructure.

4. Whether OpenTelemetry and OCSF continue receiving first-class investment.

5. Whether licensing and bundling begin economically favoring the Cisco stack.

My advice to Cisco and Splunk is to navigate this tension consciously and with great intention. The more deeply Splunk becomes embedded in Cisco’s architecture, the more important it becomes to demonstrate to existing Splunk customers that openness is not simply an architectural talking point. That matters both for reducing potential customer attrition and for providing a natural migration path if Cisco ultimately intends to bring more Splunk customers into the broader Cisco fold.

There is another possibility, however: rather than making Splunk more Cisco-centric, Cisco may be using Splunk to make Cisco itself more open. One indication came in my session with Raja Mukhopadhyay, VP of Product for Splunk Observability Cloud. He highlighted what he described as a “new Cisco” approach to openness, moving away from traditional walled gardens to support third-party telemetry, ecosystem partners and open data ingestion alongside Splunk.

So perhaps the question isn’t simply whether Cisco will pull Splunk deeper into a Cisco-centered architecture. It may also be whether Splunk’s heritage as an open, heterogeneous data platform pulls Cisco in the opposite direction. After Cisco Live 2026 and Splunk .conf26, I think we are watching both forces at work, and which one ultimately wins out is still the elephant in the room.