Which attacks does Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) help stop?

What CAPTCHA is actually good at stopping

CAPTCHA is designed to make high-volume automation more expensive and less reliable, so it is most useful against abuse patterns that depend on scale rather than stealth. That includes mass credential guessing, fake account creation, scripted submissions, ticket buying bots, scraping and other repetitive actions that abuse public web forms or login flows.

Its value is strongest when the attacker needs to repeat the same action many times and can tolerate some friction. A well-placed challenge can reduce throughput, raise solver cost and expose unsophisticated bot traffic, but it is not a substitute for access control or abuse monitoring.

Which attack patterns are most affected

CAPTCHA helps most when the attack is automated, predictable and exposed at the edge of a public workflow. Credential stuffing is a common example because the attacker needs to try many username and password pairs, and registration spam or scripted form submission also depend on cheap repetition.

It can also slow ticket scalping and similar inventory abuse where speed and volume matter. For those cases, the challenge is less about proving the user is human in an absolute sense and more about forcing the attacker to spend time, money or infrastructure to continue.

CAPTCHA is less useful when the abuse comes from a human operator, a low-and-slow bot, or an attacker using a solving service. In those cases, the control may still filter noise, but it should not be treated as the primary defence for the workflow.

Why CAPTCHA fails if you rely on it alone

CAPTCHA is only one signal in an abuse control stack, and attackers routinely adapt to it. Weak challenges can be bypassed, outsourced or solved with automation that mimics normal browser behaviour, so the control can create a false sense of safety if it is deployed without rate limits, anomaly detection and workflow-specific rules.

It is most effective when paired with controls that react to suspicious patterns, such as repeated failures, impossible request velocity, geographic anomalies or signs of scripted browser activity. In other words, CAPTCHA should slow abuse, while other controls decide whether the traffic should be blocked, stepped up or investigated.

For practitioners, the key design point is to protect the business action, not just the form. Login, signup, checkout, search and ticketing flows each fail differently, so the same challenge policy should not be applied everywhere without considering conversion impact and attacker behaviour.

Risk and Threat Considerations

CAPTCHA reduces opportunistic automation, but it also creates a control assumption that can be overstated. If teams treat it as a proof of humanity rather than a friction layer, they may miss credential attacks, account abuse or bot-driven inventory theft that continues at lower volume or through outsourced solving.

Failure mechanism: Attackers bypass the challenge through solver farms, browser automation, token reuse or human-assisted solving, then continue the same abuse path with enough success to stay economical.

Impact: The organisation keeps seeing “successful” challenge deployment while still absorbing account takeover attempts, fake registrations, scraped data or business-flow abuse.

Practitioner Guidance

What to verify: Test the control against the specific abuse you expect, not against generic bot traffic. A challenge that stops simple form spam may do little against credential stuffing or ticket scalping tooling that already handles common CAPTCHA variants.

Decision rule: If the protected action can be monetised at scale, pair CAPTCHA with rate limiting, device or session risk scoring, and logging that makes repeated abuse visible. If the action is high-value or account-related, require a second control to make the outcome measurable and enforceable.

Common mistake: Placing CAPTCHA too early in the journey, where it hurts legitimate users more than attackers, or too late, where the attacker has already consumed expensive backend resources. The best placement is where the abuse has to become economically visible.

Practitioner takeaway: CAPTCHA is a friction control, not an assurance control. Use it to raise attacker cost and reduce volume, then rely on detection and enforcement controls to decide whether the traffic is malicious.

Related resources from NHI Mgmt Group

• Guide: Bot Management Guide
• Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA)
• How should security teams stop help desk based MFA bypass attacks?
• How can help desks stop becoming the weak link in vishing attacks?
• How should security teams stop help desk impersonation attacks?