What do security teams get wrong about low-and-slow login attacks?

Why This Matters for Security Teams

Low-and-slow login attacks are dangerous because they are engineered to look ordinary while they probe for weak accounts, reused infrastructure, and inconsistent device posture. Teams that only alert on bursty volume miss the attacker’s real advantage: persistence across time. The better lens is identity behaviour, not just request rate, which is why NHI-focused research such as the 52 NHI Breaches Analysis matters even for human login abuse patterns.

Security teams also underestimate how often these attacks are credential-adjacent. Attackers rarely need to win quickly if they can reuse infrastructure, rotate proxies, and test a small set of compromised usernames until one path succeeds. Guidance from CISA cyber threat advisories consistently points to layered detection, but the practical failure mode is treating authentication as a single-event control rather than a campaign.

That distinction matters because low-and-slow activity often blends into normal travel, remote work, and vendor access patterns. In practice, many security teams encounter the compromise only after an account is used successfully from a different infrastructure path, rather than through intentional detection of the reconnaissance phase.

How It Works in Practice

Attackers keep login attempts below common thresholds by spreading them across accounts, timestamps, geographies, and source IPs. The goal is not immediate access, but to map which identities respond to password spraying, MFA fatigue, credential stuffing, or token replay. This is why raw velocity is a weak primary indicator. Behavioural consistency, infrastructure reuse, and device trust drift are stronger signals, especially when correlated across longer windows.

A workable detection model usually combines multiple layers:

• Account-level baselines for time-of-day, device, ASN, and geographic pattern changes.
• Infrastructure correlation that links shared VPNs, hosting providers, or proxy exits across many usernames.
• Repeated failure sequences that are individually low risk but collectively reveal campaign behaviour.
• Risk scoring that updates as the same device fingerprint or browser profile reappears across accounts.
• Policy response that increases friction only when the identity context changes materially.

For teams managing sensitive identities, NHIMG guidance on the Top 10 NHI Issues is useful because the same logic applies to persistent access: the control problem is often provenance and reuse, not volume alone. On the standards side, the MITRE ATLAS adversarial AI threat matrix is a useful reminder that adversaries iterate through many small actions before they succeed.

Teams often improve outcomes by feeding login telemetry into a broader identity graph rather than isolated SIEM rules. The most reliable detections tend to join failed logins, password reset attempts, device changes, and session anomalies into one timeline. These controls tend to break down when organisations lack stable device signals, because shared workstations, consumer VPNs, and remote contractor access blur the behavioural baseline.

Common Variations and Edge Cases

Tighter login controls often increase friction for legitimate users, so organisations must balance detection sensitivity against support burden and lockout risk. That tradeoff is especially visible in global workforces, service desks, and vendor-heavy environments where login behaviour is naturally noisy.

There is no universal standard for this yet, but current guidance suggests the detection model should change by environment. For high-risk admin portals, aggressive step-up authentication and short session lifetimes are justified. For lower-risk collaboration tools, the better answer may be alerting and progressive verification rather than immediate blocking. The key is to tune responses to identity confidence, not to a single failed-login count.

Low-and-slow attacks also blur into legitimate automation when shared browsers, RPA tools, or scripted access are involved. That is why NHIs deserve separate treatment: infrastructure reuse is not always malicious, but it still deserves provenance tracking. The Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference when teams need to separate normal machine behaviour from suspicious campaign reuse.

Where teams still go wrong is assuming that a quiet attack is a weak attack. Low-and-slow login activity is often the prelude to privilege escalation, token theft, or long dwell time after a single successful guess.

Related resources from NHI Mgmt Group

• What do security teams get wrong about low-and-slow application probing?
• What do security teams get wrong about cloud directory visibility?
• What do security teams get wrong about detecting malicious packages?
• What do security teams get wrong about dependency scanning?