CAPTCHA vs honeypot for signup forms

CAPTCHA covers several designs: Google’s reCAPTCHA v3 documentation, for example, describes a score returned without an interactive challenge. Its score and expected action still need server-side verification.

What each check establishes

A form honeypot is a decoy field that a normal submission should leave empty. The server checks that rule when the form arrives. It can catch scripts that fill every field, but an attacker can recognise the decoy and skip it. The Drupal Honeypot documentation describes both this limitation and an optional minimum-time check. A time threshold is a separate rule; it is not a property of every honeypot.

An interactive CAPTCHA asks the visitor to complete a task. The W3C Group Draft Note on CAPTCHA accessibility describes barriers these tasks can create for people with disabilities. When a task is part of your signup flow, test keyboard and assistive-technology access, recovery and an alternative route. A non-interactive assessment has different tradeoffs and still needs its own evaluation.

A passed check gives evidence about that interaction. It does not establish that the account belongs to a unique person. An empty honeypot does not establish that a submission is human.

Choose a combination for your registration flow

The following combinations address different checks in a signup flow. Choose according to the evidence you need and the cost of a mistaken decision:

• Honeypot and email confirmation. Use the decoy as an initial filter for scripts that fill it. Require a confirmation link before granting the permissions tied to mailbox control. Scripts that skip the decoy remain possible, and someone who controls many mailboxes can still create many accounts.
• CAPTCHA and email confirmation. Use a validated challenge or interaction assessment when you need that additional check. Keep confirmation for mailbox control. Decide how a genuine visitor can continue when the challenge cannot be completed, and measure both successful signups and abandonment.
• Visit signals and email confirmation. Use evidence about the visit and form submission to decide when confirmation is needed. This can avoid adding a solving task to your integration, but it does not establish equivalent protection to your chosen CAPTCHA. Evaluate it against your own registration traffic.

Confirmation establishes access to the mailbox used for the link. Email verification instead checks address and mail-system evidence without sending that confirmation message. The verification and confirmation comparison explains when you need each.

Handle incomplete checks separately

Keep a failed rule, an expired response and an unavailable check distinct in your server’s result handling. For example, Cloudflare’s Turnstile validation documentation separates expired or duplicate tokens from internal errors and requires server-side validation. Its widget alone does not protect a form. Follow the validation and retry rules of the specific component you use.

Choose an explicit fallback for unavailable checks: ask for a fresh challenge, hold the signup, or restrict permissions until another check completes. The appropriate choice depends on the account’s privileges and your application’s policy. Keep retries bounded, retain the visitor’s entered fields where appropriate, and explain the next step. A timeout is not evidence that the visitor failed a human test.

For a honeypot, define the server’s behaviour for an absent or malformed field as well as a filled one. Test that ordinary browsers, autofill and assistive technology can submit the form correctly before you use that rule to refuse accounts.

Where Emvero fits

Signup Protection combines email evidence and visit signals, or checks visit signals separately. Your server sends the visit token and available request details; Emvero returns a recommended action. Your application applies that recommendation. Emvero does not provide your honeypot or CAPTCHA, send your confirmation message, or grant account permissions.

Visit signals can raise an otherwise allowed email result to allow_with_email_confirmation. They do not recommend reject on their own; a combined response can reject because of the email result. Network findings such as VPN use are informational by default. An unavailable signals result is not evidence of a safe visit.

Keep the outer signup action, the nested email result and the signals outcome separate. You still own rate limits, confirmation state and access rules. Follow the signup protection setup guide for the form, token, server request and action sequence.