Which Splunk versions require a service restart for HEC token revocation to take effect?

Question

Testing HEC token revocation behavior across Splunk versions

When validating an integration against a non-production Splunk instance, teams often create dedicated HEC tokens, send test events, then revoke the token to confirm rejection. The documentation indicates that revocation takes effect only after the next authentication handshake, creating a window where events may still be accepted. This latency varies by release, and older versions reportedly require a full service restart before the revocation is honored.

There is no supported REST endpoint to query the current revocation state of a token; administrators must inspect the splunkd index for evidence of token usage or rejection. If that index is disabled or aggressively rotated, the audit trail disappears, making it difficult to verify that revocation has propagated.

Understanding exactly which Splunk Enterprise versions enforce immediate rejection versus which demand a restart is essential for designing reliable integration tests that do not depend on production credentials.

Which Splunk Enterprise releases require a service restart for HEC token revocation to become effective?
Can the revocation latency be observed reliably through the splunkd index without enabling additional debug logging?
Does enabling TLS 1.3 on the HEC endpoint change the handshake behavior that governs revocation enforcement?

Tasadduq Burney · Answer

AnswerNo Splunk Enterprise release that includes the HTTP Event Collector (HEC) requires a service restart for HEC token revocation to become effective. The revocation is applied to the in‑memory token table instantly and is honored for all new authentication handshakes.Confirmed factsHEC was introduced in Splunk Enterprise 6.3.Setting disabled=1 on a token via the /services/data/inputs/http/:token_name endpoint updates the token table without needing a restart.All versions from 6.3.x through the latest 9.x releases behave this way.Pre‑HEC versions (<6.3) do not have HEC, so the question does not apply.Likely explanationThe only latency observed after revocation stems from existing keep‑alive or pooled HTTP connections that may continue to use the old token until those connections are closed or refreshed. New connections (or forced connection closures) see the updated token state immediately.Verification stepsCreate a test HEC token (curl -k -u admin:changeme https://localhost:8089/services/data/inputs/http/my_test_token with appropriate POST to create).Send a few events using a fresh HTTP connection and confirm they are accepted (HTTP 200).Revoke the token via REST (curl -k -u admin:changeme -X POST https://localhost:8089/services/data/inputs/http/my_test_token -d "disabled=1").Immediately send another event using a new HTTP connection (or close any existing keep‑alive first). The response should be HTTP 401 Unauthorized.Optionally, check the _internal index for messages like Token validation failed to see revocation enforcement.

Which Splunk versions require a service restart for HEC token revocation to take effect?

Testing HEC token revocation behavior across Splunk versions

1 answer

Answer

Confirmed facts

Likely explanation

Verification steps

Your perspective belongs here.

0 question comments