Trust at Every Hop: How mTLS in Splunk Enterprise 10.0 Makes Security Simpler

For years, many of us in the Splunk community have relied on transport layer security (TLS) to secure traffic between Splunk components—forwarders, indexers, search heads, and more. TLS did the job: encrypt traffic, authenticate the server, and move on. But as the world shifted—toward a Zero Trust framework, tighter compliance, and more aggressive cyber threats—the age-old question resurfaced: "How do I really know who’s on the other end of that connection?"

Enter Mutual TLS (mTLS). In a world where verifying the server alone isn't enough, mTLS takes things up a notch. It requires both the server and the client to prove their identity. Think of it as cryptographically enforced mutual trust.

From Idea to Implementation: Why Splunk Built mTLS into Splunk Enterprise 10.0

mTLS wasn’t just a checkbox feature. It was a response to what customers were asking for—and what regulators were starting to expect.

Here's what we heard:

• Enterprises wanted to protect internal Splunk traffic from lateral movement and spoofed services.
• Government contracts required mutual authentication by default, especially on sensitive deployments.
• Teams moving toward Zero Trust needed strong identity validation at the network layer.
• And of course…auditors started asking, “Can you prove that the client connecting to your indexer is really who it claims to be?”

So, we went to work. As of Splunk Enterprise 10.0, mTLS is now supported across 10 essential communication paths in your deployment—from forwarders and HTTP Event Collector (HEC) to clustered search heads and indexers.

The Certificate Conundrum (and How We Solved It)

We get it. When someone says “mTLS,” most admins think: "Ah, great…double the certificates, double the complexity." And yes, mTLS does need both sides to have certificates. That used to mean:

• You had to manually rotate certs every few months
• Restart services just to load new certs
• Risk downtime if a cert expired unexpectedly
• Maintain complex trust models across clusters

So, we tackled those, too:

• Auto-rotation of Indexer and Forwarder certificates (introduced in 9.3 and 9.4) automates certificate updates, removing manual work
• Hot-Reload Support lets you update certs without restarts
• Federated search between Search Heads in different Splunk deployments is now secured with mTLS, requiring both sides to authenticate with certificates
• All of this is backed by public documentation that breaks it down clearly

In short, we're making mTLS secure and operationally manageable, even at an enterprise scale. This isn’t just a security feature—it’s a business enabler.

What’s Actually Supported?

With Splunk Enterprise 10.0, you can now turn mTLS on for these connections:

• Forwarders to Indexers (S2S over TCP port 9997)
• HTTP Event Collector (HEC on TCP port 8088)
• Search Head and Indexer REST APIs
• Search Head Cluster Replication
• Indexer Clusters
• KV Store and Federated Search
• And more...

What's Out of Scope?

• Splunk does not enforce mTLS for localhost connections that originate and terminate on the local machine due to implicit trust boundaries. Examples of such connections include the CLI on localhost and other internal localhost-style connections between Splunk components.
• mTLS support on Splunk Cloud Platform is pending customer collaboration to mitigate impact on existing unidirectional TLS connections and validation by our internal SkyNet stack.

How mTLS Helps You Meet Regulatory and Security Goals

Whether you’re preparing for an audit, adopting Zero Trust, or securing traffic between different regions (e.g. EMEA and APAC) — mTLS is a smart move. And it aligns with major frameworks:

• National Institute of Standards and Technology (NIST) Special Publication #800-207 (Zero Trust): Mandates mutual authentication
• Payment Card Industry Data Security Standard (PCI DSS) v4.0: Requires secure, verified communication channels
• Federal Risk and Authorization Management Program (FedRAMP): Demands strong identity controls in cloud-based systems
• International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Publication #27001 A.13: Emphasizes secured service-to-service communications

With mTLS built into Splunk Enterprise 10.0, you’re a big step closer to meeting all of these—without needing extra tooling or agents.

Getting Started Is Easier Than You Think

Here’s how to begin:

1. Upgrade to Splunk 10.0 (available now)
2. Identify your key traffic paths—forwarders, indexers, HEC endpoints
3. Follow the public mTLS guide to test and secure your first channel
4. Reach out to your Splunk rep if you want help with validating the applicability of mTLS in your current architecture.

You don’t have to turn everything on at once. Start with the most security-critical paths, validate, and expand from there.

What’s Next?

mTLS is just the beginning. Here’s what else is coming:

• TLS version 1.3 support, which is already mandated in some regions
• Certificate Revocation List (CRL) support for better compromise response
• Unique certificates for any new forwarder
• Administrator-controlled certificate lifespans for better certificate management

We're building toward a world where security is both strong and seamless.

The Bottom Line

You asked us for stronger, smarter security.

You asked us for easier certificate management.

You asked us for Zero Trust readiness, without turning the Splunk platform into a full-time cert babysitting job.

mTLS in Splunk Enterprise 10.0 is the answer.

You now have the power to verify every connection, reduce attack surfaces, and meet the bar that your regulators set—without the pain of legacy Public Key Infrastructure (PKI) operations.

Ready to explore more?

• Configure mutually authenticated transport layer security (mTLS) on the Splunk platform
• NIST 800-207: Zero Trust Architecture
• PCI DSS v4.0 Summary
• FedRAMP High Baseline Controls
• Ask your Customer Success Manager for our mTLS documentation and rollout checklist

Let’s raise the bar—together.

Welcome to a more trusted Splunk.