AC-7 on Splunk

What this finds

An account exceeded the defined consecutive-failure threshold within the counting window, and no lockout was recorded during the burst or in the hour following it.

The requirement

The organization must enforce a limit of consecutive invalid logon attempts by a user during an organization-defined time period, and automatically lock the account, delay the next prompt, or take another organization-defined action when that limit is exceeded.

NIST SP 800-53 Rev. 5 — AC-7 (Unsuccessful Logon Attempts).

NIST requires that a limit exist and that exceeding it triggers a response. The attempt threshold, the counting window, and what happens on breach are all organization-defined — NIST prescribes no numbers. This pack reports accounts whose failures passed your stated threshold with no lockout recorded afterwards, which evidences whether the limit you defined is actually being enforced.

How this maps to the CISA performance goals

The Cross-Sector Cybersecurity Performance Goals are a voluntary baseline published by CISA — the U.S. federal agency for critical-infrastructure cybersecurity — written for organizations too small to employ security staff. This control speaks to:

• 3.E — Monitor unsuccessful (automated) login attempts
  The goal is monitoring unsuccessful login attempts; the pack finds accounts that passed the defined attempt limit with no lockout recorded while it happened.
• 3.B — Establish minimum password strength (partial — see note)
  An unenforced attempt limit weakens whatever password strength is set, but the pack checks lockout enforcement rather than the strength policy itself.

See the full coverage map, including the goals no query can answer →

Evidence this query needs

None. This query runs on platform telemetry alone — there is no file to prepare and nothing to export.

The query

Published as ac-7-failed-signins.splunk.spl. Reads index=identity sourcetype=authentication:events. Requires: Search access to the identity index.

Before this returns anything, index=identity sourcetype=authentication:events has to be reaching Splunk Enterprise / Enterprise Security. If not, the query reports nothing found — which looks exactly like nothing wrong. What has to be switched on first →

index=identity sourcetype=authentication:events action=failure
| eval user_key=lower(user)
| bin _time span=1h AS window_start
| stats count AS failure_count,
        dc(src_ip) AS distinct_ips,
        min(_time) AS first_failure,
        max(_time) AS last_failure
        BY user_key, window_start
| where failure_count >= 10
| join type=left user_key
    [ search index=identity sourcetype=authentication:events action=lockout
      | eval user_key=lower(user)
      | stats max(_time) AS lockout_time BY user_key ]
| eval lockout_observed=if(isnotnull(lockout_time)
        AND lockout_time>=first_failure AND lockout_time<=(last_failure+3600),"true","false")
| where lockout_observed="false"
| convert ctime(first_failure) ctime(last_failure)
| table user_key, window_start, failure_count, distinct_ips,
        first_failure, last_failure, lockout_observed
| sort - failure_count

Open this pack on Splunk to adjust the settings and download it →

The interactive version opens on Splunk — the platform on this page — even if your environment profile does not list it.

Settings you decide

NIST states the objective and leaves these to your organization. The interactive version of this pack applies them to the query for you.

Consecutive failure threshold (default 10)

How many failed authentications inside the counting window before the account is reported.

Counting window (hours) (default 1)

The span used to bucket failures before the threshold applies.

Limit to specific accounts (optional)

Paste account names, one per line.

What this query returned when it was run

Executed against Splunk Enterprise 10.4.2 on 2026-08-07 against purpose-built test data. The software examined 33 records and returned 1 result in 0.156 seconds.

Test data, not a real organization. It shows the query executes and returns the intended shape of result.

Running it continuously

Correlation search → notable event

Search type:      Correlation search (Enterprise Security)
Cron schedule:    0 * * * *   (hourly)
Time range:       -24h to now
Trigger:          Number of results > 0
Alert action:     Create notable event
Urgency:          High
Security domain:  Access
Drill-down:       index=identity sourcetype=authentication:events user="$user_key$"
Throttling:       Suppress 4h on user_key

authentication:events is a vendor-neutral sourcetype. Forward Okta, Duo, Active Directory, or any other authentication source with user, src_ip, and action fields and this published search covers it with no new query written.

Before you act on a result

• Is the lockout policy actually configured for this account population, or only for a subset?
• Do the failures come from one source address, which suggests a stuck client rather than an attack?
• Is a service account authenticating interactively and failing on a rotated secret?
• Was the account locked by a system this query does not read, such as an on-premises domain controller?
• Does a conditional-access or risk-based policy already block these attempts before lockout would apply?

Common questions

How do I check for repeated failed sign-ins without lockout in Splunk?

Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=identity sourcetype=authentication:events and reports: An account exceeded the defined consecutive-failure threshold within the counting window, and no lockout was recorded during the burst or in the hour following it.

What permissions are needed to run this Splunk query?

Search access to the identity index.

Does a result from this query mean the control has failed?

Failed sign-ins do not establish that an attack occurred or that any account was compromised. They establish that the organization's own attempt limit was not evidenced as enforced for that account in that window. A stuck client, an expired cached credential, or a misconfigured service can produce the same pattern.

The same control on other platforms

• AC-7 on Microsoft Sentinel — KQL
• AC-7 on AWS — SQL (Athena) + Lambda
• All platforms for AC-7