Many CAPTCHA implementations share the client IP, browser fingerprint, header set and behavioral telemetry with third-party services at the moment of verification. That model is acceptable in some sectors, but for public-sector, financial, healthcare and air-gapped environments it creates serious data residency and compliance exposure.
For compliance-sensitive organizations, even a single CAPTCHA call on a login screen can trigger a personal-data-transfer discussion. Explicit consent requirements, cross-border transfer rules, contractual safeguards and vendor dependency can turn a simple bot-protection decision into a lengthy compliance project.
Relying on external CAPTCHA services also creates operational risk. When a third-party verification service slows down or becomes unreachable, the login, registration or payment flow of every protected application is affected. Bot protection becomes a critical external dependency for the application.
The correct model is to perform challenge generation, delivery and verification inside the organization's own ADC layer. Client data stays local, the verification process is self-contained, difficulty scales with service risk, and failed attempts can feed quarantine escalation.
TR7 Self-Hosted CAPTCHA delivers exactly this model: it makes bot verification self-hosted, reduces data residency risk and integrates directly with the WAAP decision pipeline.
TR7 implements CAPTCHA through local generation, tunable difficulty, visible and invisible verification modes, and quarantine escalation.
The CAPTCHA image, HTML/JS content, token signature and solution verification all run on TR7. No outbound HTTP call to an external service is made during the verification process.
Difficulty is evaluated together with character length, visual noise, PoW workload and minimum solve time. The operator strikes the right balance between user experience and bot resistance with a single setting.
Visual verification can be shown to high-risk clients. For medium-risk clients, PoW validation can run silently in the background without presenting an additional screen to the user.
CAPTCHA is triggered only when a risk threshold is crossed. Wrong answers are tracked; once the threshold is exceeded, quarantine actions such as deny, redirect, custom content or a custom status code can be applied.
Self-Hosted CAPTCHA combines self-hosted challenge generation with bot scoring, PoW, cookie security and quarantine flows.
TR7 generates the CAPTCHA image internally, serves the challenge page from its own service and verifies solutions through a local helper process. The client IP, user agent and verification result are never sent to an external service. This model provides a critical advantage for organizations with data residency requirements. CAPTCHA protection is applied without any dependency on external services.
In TR7, difficulty is selected on a scale of 1–5. This value maps to PoW bit depth (16–20 bits), CAPTCHA character length (4–7 characters), visual line and dot density, and a server-enforced minimum solve time. The operator manages both the human experience and the bot cost with a single slider. Higher-risk services can be configured with higher difficulty.
PoW validation is applied as part of CAPTCHA verification. The browser must complete a defined computation before the solution is accepted. A server-side minimum solve time is also enforced — even if a bot produces the correct answer instantly, a solution that arrives too quickly is treated as suspicious. This approach raises automation cost while adding minimal burden to genuine users.
The token produced after successful verification is carried in an encrypted cookie. The token can be bound to the client's IP address and user agent context, making it significantly harder to reuse a verification token obtained by one client in a different context. During the verifiedTtl window, the genuine user does not have to solve CAPTCHA on every request.
TR7 can assign a dedicated helper process and a dedicated socket path to each CAPTCHA rule. This isolation reduces the impact of a fault or load spike in one rule on other rules. Pool-based separation means CAPTCHA flows for different services are managed independently. scalingCount allows multiple processes to run for the same rule.
When type is set to text, the user encounters a visual CAPTCHA. In invisible mode, PoW-based verification runs without presenting a full challenge screen. Medium-risk clients are verified with less friction, while higher-risk clients receive visual CAPTCHA to increase bot cost.
Background color, text color, theme and size can be defined per service. Small, medium and large CAPTCHA sizes adapt to different user interfaces. The verification screen does not appear disconnected from the organization's brand experience. In white-label B2B SaaS scenarios, each tenant can offer an experience that matches its own visual identity.
CAPTCHA titles, description text and error messages can be tied to a multilingual structure. Language can be selected per service or based on client context. This provides a clearer verification flow in public-sector, financial and multi-region services. Adding a new language does not require changing verification logic.
CAPTCHA does not have to be shown to every user by default. TR7 bot scoring, IP reputation, behavioral signals and DDoS conditions can restrict challenge presentation to risky clients only. This reduces friction for genuine users. Trusted traffic continues on the normal path while suspicious traffic is routed to verification.
Wrong CAPTCHA answers can be tracked, and once a defined threshold is exceeded the client is quarantined. The quarantine action can be configured as deny, redirect, customContent or customStatusCode. This prevents bots from repeatedly consuming challenges to exhaust the system. As failure accumulates, a harder action replaces the challenge.
When a user passes CAPTCHA successfully, they can be treated as verified for a configured period. The same user is not shown CAPTCHA again until verifiedTtl expires. This preserves the genuine user experience while maintaining the initial verification barrier against bots. IP+UA binding makes it harder for the verification state to be stolen and replayed in a different context.
CAPTCHA is not a standalone screen — it is one of the actions in the TR7 decision pipeline. DDoS protection, bot protection, IP reputation and account-takeover policies can all trigger the showCaptcha action. Each security module can connect its own risk signal to the CAPTCHA verification flow. The operator uses a single self-hosted challenge infrastructure across different risk scenarios.
Self-hosted CAPTCHA is operated together with helper processes, secret management, token binding, a quarantine state machine, multilingual support and audit records.
Each CAPTCHA rule can run with a dedicated helper process. If the process terminates unexpectedly, it can be restarted automatically. A fault in one rule does not affect CAPTCHA verification in other services.
A dedicated socket path can be created for each pool and CAPTCHA rule. This structure separates challenge verification traffic between services. When configuration is replayed, the mapping between the same logical rule and the same physical socket structure is preserved.
A distinct secret can be generated for each rule, and verification tokens are signed against that secret. When a secret is rotated, existing verified tokens may be invalidated. This behavior can be leveraged for planned security renewals.
PoW solving can use more efficient APIs in modern browsers. In environments without support, a slower but compatible JavaScript fallback is applied. On mobile clients, the solving process runs asynchronously so the user interface does not freeze.
Failed challenge responses are tracked separately. When the threshold is exceeded, the client is directed to a quarantine action for a configured period. During that period, deny, redirect or custom content is applied directly instead of presenting another CAPTCHA.
For each challenge, timestamp, source IP, user agent, rule ID, difficulty level, challenge type and outcome can be logged. PoW solve time also produces a valuable signal for incident investigation. These records support bot analysis and fraud forensics workflows.
Banks may be required to avoid transmitting user IP or browser information to external services during CAPTCHA verification. With TR7 self-hosted CAPTCHA, the challenge process stays inside the ADC and login protection is operated in line with data residency requirements.
Government agencies operating in environments without access to external verification services can still apply bot protection. TR7 CAPTCHA generation and verification work without requiring external DNS resolution or outbound HTTP calls.
For coupon fraud, fake account creation or automated registration attacks, the signup endpoint can be placed behind CAPTCHA based on bot score. Failed attempts are linked to quarantine, preventing bots from continuously consuming challenges.
Healthcare portals can verify users on appointment booking or patient access flows that involve sensitive data without relying on an external CAPTCHA service. The user verification process remains under organizational control.
During a DDoS or bot wave, TR7 can apply CAPTCHA or invisible PoW only to clients with a high risk score. The majority of genuine users continue without additional friction while bot cost is raised.
B2B SaaS providers can configure color, theme and size settings separately for each tenant. The CAPTCHA screen carries no third-party logo and appears closer to the customer's own user experience.
Self-hosted CAPTCHA that keeps data local — integrated with WAAP, DDoS and ATO flows. Let's walk through a live setup in your own environment.