TL;DR: Credential stuffing can still succeed when stolen username and password pairs are tested at scale, according to Impart. Login controls need identity context at the blocking point, or valid sessions can still form.
Editorial analysis by NHI Mgmt Group, based on content published by Impart: “What Your WAF Misses: Credential Stuffing”.
Key questions
Q: Why do reused credentials still create account takeover risk even when bots are detected?
A: Because detection alone does not stop authentication from succeeding.
Q: How do organisations know whether credential stuffing controls are working?
A: Look for fewer reused secrets in code and configuration, lower volumes of anomalous login attempts, faster secret rotation after exposure, and clear ownership for every service credential.
Q: What breaks when credential stuffing detection is separated from enforcement?
A: The control loses the identity context needed to block the attack reliably.
Practitioner guidance
- Align detection and blocking in the same runtime layer Move credential stuffing decisions into the application request path so the system that sees the login context can also block the attempt without a tool handoff.
- Correlate login attempts across accounts and sessions Use aggregate signals such as credential velocity, IP rotation, and session history to identify campaigns that look normal one request at a time.
- Run login policies in shadow mode first Evaluate every decision against live traffic, log the evidence chain, and only promote to enforcement after the policy matches expected outcomes.
Bottom line: Credential stuffing succeeds when stolen credentials are tested at scale and reused passwords still open a valid session.
Glossary terms: Credential Stuffing, Cross-Request Correlation, Request-Path Enforcement, Shadow Mode
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Detection without enforcement is a governance failure, not a tooling gap. Credential stuffing shows that teams can identify suspicious authentication behaviour and still fail to stop it if the block decision lives outside the layer that understands account and session context. That is why the real control issue is not whether the alert is accurate, but whether the enforcement path can consume the same evidence. Practitioners should treat this as an identity-control design problem, not a tuning problem.
A question worth separating out:
Q: Should organisations rely on WAF rules or identity-aware controls for login abuse?
A: 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.
👉 Read our full editorial: Credential stuffing exposes the gap between detection and enforcement