Stop fake SaaS sign-ups without adding friction for real users
Bot accounts pollute your funnel data, waste onboarding emails and, if you send SMS codes, can quietly run up a large bill. Here is a layered approach that keeps the door open for genuine customers.
By the Xuru Technologies team · 25 October 2026
Key takeaways
- Fake sign-ups are a recognised automated threat: OWASP lists bulk account creation as OAT-019.
- The biggest hidden cost is SMS pumping, where fraudsters trigger texts to numbers they profit from and you pay the bill.
- No single fix works. Layer an invisible bot check, rate limits, email and phone checks, and monitoring.
- Validate bot-check tokens on the server; a widget on the page alone does not protect anything.
- Measure the impact on real conversion so security does not quietly cost you customers.
Why fake sign-ups are more than a nuisance
Every SaaS startup with a public sign-up form eventually sees them: accounts with random names, throwaway email addresses, or bursts of registrations from the same network at 3am. The OWASP Automated Threats project classifies this as OAT-019, Account Creation: "bulk account creation, and sometimes profile population, by using the application's account sign-up processes", in order to "create multiple accounts for subsequent misuse".
The damage shows up in several places:
- Your metrics. Sign-up and activation rates become meaningless, which makes every product and marketing decision harder. Our guide to startup conversion tracking is only as useful as the data going in.
- Your email reputation. Welcome and onboarding emails sent to fake or mistyped addresses bounce, which can hurt deliverability for real users.
- Your costs. Compute, seats on third-party tools priced per contact, and above all SMS.
- Abuse of your product. Fake accounts can be used to send spam through your platform, scrape data or exploit trial limits.
The expensive one: SMS pumping
If your sign-up or login sends a verification code by text, you are a target for SMS pumping. Twilio's anti-fraud developer guide describes it as a form of toll fraud that causes inflated traffic, with fraudsters directing messages to high-cost destinations they own, such as premium rate numbers. Your application sends the texts; you pay the bill.
Twilio's recommended defences are a useful checklist whatever provider you use:
- Restrict SMS geographic permissions to the countries you actually serve, and turn them off entirely if you do not need SMS.
- Rate-limit how many messages your app can send.
- Do not let users send arbitrary content to arbitrary numbers, and validate phone number inputs.
- Set usage triggers that alert you when spend crosses a threshold.
- Use your provider's built-in fraud protection for verification flows where available.
A simple design question helps too: do you need SMS at sign-up at all? For many B2B products, email verification plus optional app-based MFA is enough, and it removes the SMS attack surface from the public form.
A layered defence for your sign-up form
| Layer | What it does | Friction for real users |
|---|---|---|
| Invisible or managed bot check | Scores the browser for automation before the form submits | Low; most people see nothing |
| Rate limiting | Caps sign-ups per IP, device or network over time | None, unless limits are too tight |
| Honeypot field | Hidden field that bots fill and humans do not | None (keep it hidden from screen readers too) |
| Email checks | Syntax, domain and MX validation; optional disposable-domain screening | Low |
| Email verification before full access | Confirms a reachable inbox | Moderate; design it well |
| Phone checks (only if you use SMS) | Validates number format and country, applies risk scoring | Low to moderate |
| Progressive limits | New accounts get reduced sending or export limits until verified or paid | Low for genuine users |
| Monitoring and alerts | Spots spikes by country, domain or network | None |
Choosing a bot check
Traditional image puzzles annoy people and can create accessibility barriers. Newer tools aim to stay invisible. Cloudflare's Turnstile, for example, runs non-interactive JavaScript checks in the browser and aims to avoid showing visual puzzles, with managed, non-interactive and invisible widget modes. Whatever you choose, the critical step is on the server. Cloudflare's server-side validation docs state that you must call its Siteverify API to complete the implementation, and that each token is valid for 300 seconds and can be used only once. A common mistake is adding the widget to the page but never checking the token, which stops nothing.
Email verification that does not hurt activation
Requiring email confirmation before anyone sees the product can cut activation. A common compromise is to let new users into a limited workspace immediately, then require verification before they invite teammates, send messages or connect integrations. Pair this with the onboarding patterns in our SaaS onboarding guide so the verification step feels like part of getting started rather than a hurdle.
Measure both sides
Anti-bot work can quietly block real customers, especially those on VPNs, corporate networks or assistive technology. Track:
- Sign-up form starts versus completions, before and after each change
- Bot-check failure rate by country and browser
- Share of new accounts that verify their email
- SMS spend per verified account, if you use SMS
- Support tickets mentioning sign-up problems
Provide a fallback, such as a "Having trouble signing up?" contact link, so a false positive becomes a conversation rather than a lost lead. Keep the form accessible; our accessibility service includes testing sign-up flows with keyboard and screen readers.
Sign-up protection checklist
- Bot check installed and its token validated on the server
- Rate limits on the sign-up and verification endpoints
- Honeypot field hidden visually and from assistive technology
- Email syntax and domain checks
- SMS geo permissions limited to countries you serve, with spend alerts
- Reduced limits for unverified new accounts
- Dashboard or alerts for unusual sign-up spikes
- Fallback contact route for blocked users
- Privacy policy updated if you use third-party risk scoring (ask a privacy adviser what is required)
Frequently asked questions
Will a CAPTCHA alone stop fake sign-ups?
Rarely. Determined attackers can get past many single checks. Combining a bot check with rate limits, verification and monitoring is far more effective.
Should we block all disposable email domains?
It depends on your product. Blocking them can reduce junk accounts, but some genuine users try products with secondary addresses. Many teams allow them with reduced limits until the user upgrades or verifies further.
How do we know if we are being hit by SMS pumping?
Watch for unexpected spikes in verification texts, especially to countries you do not normally serve, and low completion rates for those codes. Usage alerts from your SMS provider help you catch it early.
Can you add this to an existing sign-up flow?
Usually, yes. Most of these layers can be added without rebuilding your app; the main work is server-side validation, rate limits and monitoring.
A sign-up flow that is open to customers, closed to bots
We'll review your flow and design a sample of the improved sign-up before you commit, with a fixed written quote.
Websites, payments, digital marketing, AI automation, consultancy and practical technology training — for businesses and aspiring professionals worldwide.
Saturday – Sunday: closed