Join our Newsletter — 33% off our NHI Course

Should organisations rely on WAF rules or identity-aware controls for login abuse?

Identity-aware controls should carry the blocking decision because they can evaluate account history, session state, and behavioural patterns that a WAF cannot see. A WAF can still help with coarse suppression, but it should not be the primary enforcement point for credential stuffing.

Why login abuse should be blocked closer to identity than to the edge

Login abuse is about deciding whether a specific account, session, or authentication path should be allowed to continue, and that is inherently an identity question. A WAF can slow noisy traffic and suppress some automated requests, but it sees the request pattern, not the account context. Identity-aware controls can use signals such as failed history, session age, device posture, and unusual access patterns to make a more defensible blocking decision.

That difference matters because credential stuffing is rarely just a volume problem. It is often a mix of valid usernames, recycled passwords, low-and-slow automation, and distributed source IPs, which makes coarse perimeter filtering easy to evade. Controls that sit closer to authentication can distinguish between a suspicious request stream and an account-level abuse condition.

When you compare the two control types, the key issue is not whether a WAF is useful, but where its visibility ends. WAF rules are still helpful for rate suppression, bot friction, and generic web abuse, yet they are a poor primary enforcement point when the decision depends on identity state. If the question is whether to stop a login, the control should be able to observe the login outcome, the account, and the session that follows.

Where WAF rules help, and where they break down

A WAF is strongest when the abuse pattern is visible at HTTP layer and can be reduced with coarse controls, such as request throttling, IP reputation, or challenge behaviour. That can be useful during spikes, scripted probing, or obvious spraying from a small set of sources. It becomes less reliable when attackers distribute attempts, rotate infrastructure, or keep request rates low enough to avoid simple threshold rules.

Identity-aware controls break down less often because they can evaluate conditions that are invisible to a network or application perimeter device. Account lockout policy, adaptive authentication, risk scoring, step-up challenges, session invalidation, and post-authentication anomaly detection all operate on the thing under attack, not just the traffic carrying the attack. For login abuse, that is usually the better enforcement model.

Seen another way, a WAF can reduce noise, but it cannot reliably answer whether a known account is being abused right now. An identity control can. That makes the identity layer the better place to make the blocking decision, with the WAF acting as a supporting control rather than the final arbiter.

What a defensible login-abuse control stack looks like

For most organisations, the practical model is layered: use the WAF for coarse suppression, then use identity-aware controls for the actual authorization to continue. That keeps perimeter rules simple and reduces the temptation to encode account-specific logic into a device that was not built for it. It also avoids breaking legitimate users when the traffic pattern looks odd but the account evidence is weak.

The stronger the account signal, the more the decision should move toward identity controls. If a login is tied to a known account with recent failures, impossible travel, new device signals, or suspicious session reuse, the enforcement action should happen in the authentication or session layer. Where possible, this should include challenge escalation, temporary denial, token revocation, or forced reauthentication rather than relying only on IP blocking.

For teams using an identity platform, the useful question is not “Can the WAF block it?” but “Which layer has the best evidence to decide?” That framing keeps engineering effort aligned to the control that can actually see the right signal. It also makes it easier to tune the WAF for early noise reduction without letting it become the single point of control for credential abuse.

Risk and Threat Considerations

Login abuse becomes materially more dangerous when organisations treat perimeter filtering as a substitute for account-level enforcement. Attackers can work around source-based rules with botnets, residential proxies, distributed retries, and low-and-slow credential stuffing, while still targeting the same accounts and sessions.

Failure mechanism: The WAF filters traffic patterns, but the abuse decision depends on identity state, so a distributed attack can keep reaching authentication even when the edge looks controlled. The gap is especially dangerous when reused passwords, stale accounts, or weak session controls let successful logins blend into normal traffic.

Impact: Organisations can miss active account takeover, overestimate their protection, and delay the response that should happen at the identity layer. That increases the chance of unauthorized access, session compromise, and follow-on fraud or data exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-04 — Insecure Authentication Login abuse hinges on weak or misapplied authentication decisions.
NHI-05 — Overprivileged NHI Abused logins can lead to excessive access once authentication succeeds.
Recommendation — Move abuse blocking into authentication controls that can assess account state and step up or deny access. Limit post-login privileges so a compromised account cannot immediately reach high-value actions.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Credential stuffing and login abuse depend on how authenticators are issued, rotated, and revoked.
AC-7 — Unsuccessful Logon Attempts Repeated failed logons are a core signal in credential-stuffing defence.
IA-2 — Identification and Authentication (Organizational Users) The question is about where to enforce login control for user accounts.
Recommendation — Harden authenticator lifecycle controls and invalidate exposed credentials quickly. Enforce retry limits and response actions for repeated failed logons. Base login enforcement on identity-aware authentication controls rather than perimeter filtering alone.
NIST Zero Trust (SP 800-207) Never Trust, Always Verify Identity-aware login decisions fit zero trust better than edge-only filtering.
Recommendation — Verify each login with contextual signals before allowing continued access.
CIS Controls v8 CIS-5 — Account Management Login abuse response depends on controlling account state and access paths.
Recommendation — Centralize account control, lockout, and review actions around identity data.

Practitioner Guidance

What to prioritise: Put the blocking decision where you can see account history, session state, and post-login behaviour. Use the WAF to reduce obvious spray noise, not to decide whether a specific account should be trusted.

What to verify: Confirm that your identity controls can trigger on failed-attempt patterns, device or session anomalies, and step-up or revoke actions without waiting for network-layer rules to fire. If they cannot, your login-abuse response is too edge-dependent.

Common mistake: Teams often tune WAF thresholds until legitimate users stop complaining, then assume the problem is solved. In practice, that can leave the authentication path intact for distributed attackers who never trip the perimeter thresholds.

Practitioner takeaway: Use the WAF as a pressure valve, but make the identity layer the authority for login abuse decisions, because only it can judge the account, the session, and the trust history that determine whether access should continue.