When should organisations treat login failures as a password spraying event?

Why This Matters for Security Teams

password spraying is dangerous because it is designed to look boring: low and slow, spread across many identities, and often sourced through proxy networks or cloud-hosted infrastructure. That makes it easy to confuse with normal user error unless the team is watching for patterns across accounts, not just repeated failures on one login. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward continuous monitoring and access control discipline, which is exactly where spraying should be detected.

For NHI and AI-adjacent environments, the concern is broader than human logins. A sprayed account may be a service identity, API client, or admin account tied to secrets that unlock automation, data access, or delegated workflows. Once an attacker gets a foothold, they can test other secrets, pivot into toolchains, or abuse over-permissioned roles. NHIMG research on the DeepSeek breach shows how exposed credentials and backend access can quickly become operational risk, not just an authentication event.

In practice, many security teams only recognise spraying after an unusual spike in downstream account lockouts or help desk complaints, rather than through intentional pattern detection.

How It Works in Practice

The practical test is not whether login failures occurred, but whether they form a cross-account pattern that suggests one password is being tried against many identities. Security operations should look for the same password variant, shared source infrastructure, repeated failures against high-value roles, and attempts spread over time to avoid threshold-based alerts. A single account with 20 failures is often a user mistake or a brute-force attempt. Ten accounts with one or two failures each, especially from the same netblock or access path, is much more consistent with spraying.

Defenders should correlate authentication telemetry with IP reputation, geo-velocity, user-agent consistency, and identity sensitivity. Where available, identity providers and SIEM rules should flag attempts against multiple accounts with the same password pattern, not just repeated failures per principal. That matters even more when the target set includes NHI credentials, because secrets and API keys often have weaker human-style recovery signals. The NIST Cybersecurity Framework 2.0 supports this kind of event correlation through detect and respond practices, while NHIMG’s analysis in DeepSeek breach illustrates how exposed credentials can cascade into broader compromise when authentication hygiene is weak.

• Alert on low-frequency failures across many identities from the same source family.
• Weight failures against privileged, service, and high-value accounts more heavily.
• Correlate with impossible travel, proxy use, and new device or ASN patterns.
• Use risk-based step-up checks before lockout so attackers do not trigger noisy denial-of-service conditions.

These controls tend to break down in heavily remote, distributed environments because shared VPN exits and contractor access can make hostile traffic look operationally normal.

Common Variations and Edge Cases

Tighter detection often increases alert volume, requiring organisations to balance visibility against false positives and user friction. That tradeoff is especially real in environments with shared egress, regional proxies, or third-party access brokers, where geography and source range alone are weak signals. Best practice is evolving, but current guidance suggests treating correlation as a risk score rather than a single hard threshold.

There is no universal standard for exactly how many failures equals spraying. In some environments, five failures across five accounts may be enough if the accounts are privileged or tied to secrets management systems. In others, higher counts are needed to avoid noise. The decisive factor is intent: attackers are testing many identities with the same or similar password pattern to stay below detection. That becomes more serious when the exposed account unlocks privileged access management, automation tokens, or secret stores.

Teams should also distinguish spraying from credential stuffing. Stuffing usually involves known username and password pairs from prior leaks; spraying often uses a small set of common passwords against many accounts. NIST’s risk-based approach in the NIST Cybersecurity Framework 2.0 supports this distinction, but operationally the faster win is to force MFA, monitor for repeated low-and-slow failures, and review whether exposed credentials or leaked secrets are feeding the attempt set. When service identities are in scope, the same pattern can indicate an NHI compromise path rather than a simple user login attack.

Related resources from NHI Mgmt Group

• When should organisations treat a successful login as a security event?
• When should organisations treat a file share as a security incident?
• How should security teams defend against password spraying in hybrid identity environments?
• Why is password spraying so effective against Active Directory and Entra ID?