Welcome to Splunk Enterprise 10.6

Improved security of Splunk to Splunk connections for Federated Search

Federated Search for Splunk now verifies and validates connections between federated and remote search heads. This update activates an automated exchange of capabilities, allowing search heads to optimize performance and ensure searches run efficiently. By proactively confirming compatibility, this feature significantly increases the overall stability and reliability of your distributed search environment.

Note: With this change, federated searches will fail if any remote search head runs a version lower than Splunk Enterprise 10.4 after you upgrade. If you use Federated Search for Splunk, upgrade all remote search heads to Splunk Enterprise version 10.4 or higher before upgrading your deployment. See About upgrading to 10.6 READ THIS FIRST.

Mutually-authenticated transport layer security (mTLS) protocol support for Federated Search - Hybrid Model

Splunk now offers mTLS support for customers that use Federated Search - Hybrid Model. Customers can now install a client certificate on their Splunk Cloud Platform deployment for this feature to function. File a Splunk Support case to update this configuration.

Support for the $8$ encryption cipher format in Splunk Enterprise

Splunk is migrating to a new secret encryption cipher format, $8$, that is compliant with federal information processing standards (FIPS) and uses independently-derived, high-entropy keys such as keyed-hash message authentication code (HMAC)-based Key Derivation Function (HKDF)-Secure Hash Algorithm 256-bit (HKDF-SHA256). This updated password encryption method supersedes the existing $7$ encryption cipher format that the Splunk platform currently uses.

The Splunk CLI includes a migration tool to assist customers with migration to the $8$ format:

• splunk reencrypt secrets
• splunk reencrypt shcluster-secrets

These commands only operate on secrets that are based on non-$8$ values, so re-running it on previously-migrated keys does nothing. Splunk Enterprise continues to read secrets that it encrypted using the $7$ format.

Splunk Enterprise customers have access to these changes starting with Splunk Enterprise 10.6. An upgrade to Splunk Enterprise 10.6 only changes the secret-hashing algorithm that the Splunk platform uses for future encryptions; existing encryptions don't change unless you run the previously-described commands.

For more information about the commands, see Migrate encrypted configuration values to the $8$ cipher format.

In Splunk Enterprise 10.6, the KV store is now backed by PostgreSQL for supported Linux, Windows, and MacOS platforms. KV store provides app-scoped structured data used by Splunk Enterprise and Splunk applications. This update modernizes the underlying storage technology by establishing PostgreSQL as the foundation for KV store, while preserving supported KV store behavior, APIs, and application workflows.

Splunk Enterprise 10.6 is validated against Splunk's compatibility, data integrity, performance, and reliability criteria to support continuity for supported applications and operational workflows. To learn about the Splunk-supported path to migrate existing KV store data from the past MongoDB-backed implementation to PostgreSQL, along with upgrade and migration guidance, eligibility, prerequisites, and platform-specific requirements, see Upgrade to a cohosted KV store and the updated guidance in How to upgrade Splunk Enterprise.

Removal of versions 1.0 and 1.1 of the TLS network encrytion protocol for inter-Splunk connections

The Splunk platform no longer supports the use of the TLS 1.0 or TLS 1.1 network encryption protocols for connections between Splunk components. There is no longer a way to turn on this support temporarily. Ensure you have migrated to TLS versions 1.2 or 1.3 for Splunk component connections.

Removal of Client Authentication Extended Key Usage (EKU) from Public TLS Certificates

To enhance security and comply with industry changes, digital certificate authorities have begun removing the "Client Authentication" Extended Key Usage (EKU) from Public TLS Certificates that they issue.

While this change is not specific to Splunk Enterprise 10.6, Splunk uses this new release to remind customers to confirm that they have updated certificates for their deployments in place by March 1, 2027. Detailed guidance is available on Splunk Help.

Stateful aggregation and deduplication of events in Edge Processors

You can now configure Edge Processor pipelines to reduce data volume and noise by aggregating and removing duplicate events.

• Use the stats SPL2 command to aggregate the events that are processed by an Edge Processor instance within a given state window. See Aggregate event data using Edge Processor for more information.
• Use the dedup SPL2 command to remove events that contain identical values in specified fields. See Remove duplicate fields from pipelines for more information.

Edge Processor features including expanded SPL2 support and additional configuration options

Edge Processors now support the following features and workflows:

(Conditional Availability) Splunk Enterprise support for aarch64 (ARM64) processor architecture when run in FIPS 140-3 mode

_Conditional Availability_ - Splunk Enterprise now supports running on the aarch64 (ARM64) processor architecture, including Amazon Web Services (AWS) Graviton 4 virtual machines, when you run it in FIPS 140-3 mode.

Universal Forwarder Certification on Splunk 10.6

Universal Forwarder is certified on Splunk Enterprise 10.6 and Splunk Cloud 10.6.

Fewer app management operations require Splunk platform restarts.

Due to internal improvements in our app management tooling, app uninstall operations are ~50% less likely to require Splunk platform restarts. After upgrading to Splunk platform version 10.6, Splunk Cloud customers will have this feature incrementally enabled or can reach out to Splunk Support for scheduling. Splunk Enterprise customers can enable this feature by updating the limits.conf stanza [reload_on_delete] to disabled = false. Note that the feature can be rolled back by setting disabled = true. Enabling or disabling this feature requires a Splunk platform restart.

Configuration change tracking in audit logs

In Splunk Enterprise, you can use audit logs to track configuration changes made through Splunk Web or the REST API in the _audit index. This capability provides visibility into who made a change, what changed, and when. Previously available in Splunk Cloud Platform, configuration change tracking is now available in Splunk Enterprise.

See Tracking configuration changes with audit logs.

System for Cross-domain Identity Management (SCIM)-based user de-provisioning for Entra ID Customers - CA

This feature lets customers that use Microsoft Entra ID for Security Assertion Markup Language (SAML) authentication configure their Splunk search head to use SCIM to automatically remove SAML users when the user is deleted from Entra ID or loses Splunk access.

Integrated Enterprise Value

Deliver Integrated Enterprise Value reporting that gives customers clear visibility into Cisco data consumption, weighted usage, and remaining entitlement across Ingest in CMC and MC.

Monitoring Console KVStore Dashboards Update

Monitoring Console KVStore Dashboards Update

Splunk Enterprise Versioning Change

Starting with Splunk Enterprise and Splunk Cloud Platform release 10.6, Splunk introduces a unified four-segment version format (Major.Minor.Maintenance.Patch, e.g., 10.6.0.5) across Splunk Cloud and customer-managed platform builds to provide consistent and transparent release tracking. This update does not alter standard Splunk Cloud operations, service consumption, or deployment schedules. Customers utilizing custom scripts, CMDB integrations, or automated tooling that parse Splunk version strings should verify compatibility with the four-segment format.

Data Management APIs for Splunk Enterprise​

Providing API support for CMP customers. This involves API support for Edge Processor on Splunk Enterprise. This introduces the public methods needed to configure and operate Edge Processors, pipelines, pipeline deployments, destinations, sourcetype synchronization, shared settings, administrative first-time setup, bootstrap, and offboarding in Splunk Enterprise deployments.

Updates to Splunk AI Assistant on Search page

The Splunk AI Assistant is seamlessly integrated into the Search & Reporting experience and brings the latest AI-agentic-powered capabilities directly into your search workflow, including support for SPL2 search authoring. The AI Assistant also helps you create SPL2 searches for Federated Search and MDL datasets.

Ingest Tier Scaling (Physical Separation)

With Ingest-Tier Scaling for Splunk Enterprise, you can deploy a dedicated ingest tier that is physically separated from indexers and managed through Splunk Operator for Kubernetes (SOK). You can scale ingestion independently from indexing, improve resilience during data spikes, and operate more efficiently in large on-premises environments.

See Physical separation of indexing and ingestion.

GA feature: Field filters for the Splunk platform are now generally available and on by default to protect sensitive fields in search time results

To protect your personal identifiable information (PII) and protected health information (PHI) data, and meet data privacy requirements such as General Data Protection Regulation (GDPR) or other privacy regulations, you can use field filters in the Splunk platform to limit access to your sensitive data. Field filters let you limit access to confidential information by redacting or obfuscating fields in events within searches, with optional role-based exemptions. For more information about field filters, see Protect PII, PHI, and other sensitive data with field filters and Plan for field filters in your organization.

READ THIS FIRST: Should you deploy field filters in your organization? Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but field filters might not be a good fit for every deployment.

If your organization uses downstream configurations, such as accelerated data models, Splunk Enterprise Security (ES) detections using those data models, or user-level search-time field extractions, ensure you sufficiently plan for your field filter use cases on those configurations before deploying field filters in your environment. See READ THIS: Downstream impact of field filters.

If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.

Remote configuration of OpenTelemetry Collectors

Centrally manage OpenTelemetry Collector configurations from agent management to reduce manual configuration work and apply consistent settings across multiple collectors. Create configuration sets from one or more files, assign them to supported collectors, update configurations by replacing or changing configuration sets, and monitor delivery status from a central interface. Collectors must report the OpAMP AcceptsRemoteConfig capability to receive configurations and the ReportsRemoteConfig capability to report configuration status.

See Remote configuration of OpenTelemetry Collectors