Attestation-ready

Private Access Tokens, read as a trust signal.

The industry is building cryptographic attestation tokens that prove a request comes from a real device without identifying the user. CaptchaLa ingests these tokens so verified visitors pass without a challenge, and falls back to risk-based verification for everyone else. We are complementary to attestation, not replaced by it.

What attestation tokens are

An attestation token is a signed statement that a request comes from a genuine browser or device. The device proves itself to its platform, the platform issues a token, and your site receives the token instead of asking the person to solve a CAPTCHA. The token carries no identity, so it does not track the user across sites.

On the web this is built on Private Access Tokens and Privacy Pass (RFC 9576). A newer extension, PACT — Private Access Control Tokens — was proposed in June 2026 by Cloudflare, Chrome, Firefox, Edge and Shopify to broaden how these tokens are issued and used.

The goal is to let real users skip challenges more often, while keeping verification private by design.

PACT is an early proposal and is years from broad deployment. CaptchaLa supports the existing Private Access Tokens / Privacy Pass mechanism today and follows the proposal as it develops. None of this requires you to wait.

How CaptchaLa uses them

We treat an attestation token as one trust signal among several, not as the whole decision. The flow is simple:

Token present

Verified token, skip the challenge

If a valid attestation token is present, we verify it against the issuer's public key. A low-risk visitor with a verified token passes without an interactive challenge.

No token

Fall back to risk-based verification

If there is no token, or it cannot be verified, CaptchaLa uses its own risk engine — device, network and behavioral signals — and shows a challenge only when the request looks suspicious.

Where it works: web vs native

Attestation is not the same everywhere. Here is the accurate picture of what works automatically and what needs your configuration.

Web — Private Access Tokens / Privacy Pass

Automatic

On the web, CaptchaLa verifies Private Access Tokens against the issuer's public key. There is nothing for you to set up — supported browsers and devices produce the token, and we read it.

iOS App Attest / Android Play Integrity

Optional, you configure

These native attestations are bound to your app's own developer identity, not to a public issuer. They can only work as an optional signal that you configure for your own app, so they are not automatic for everyone.

Native apps otherwise

Our own risk signals

Where platform attestation is not configured, native apps rely on CaptchaLa's own device and behavioral risk signals — the same engine that protects the web fallback.

Attestation says "real device." We add "real and not abusing."

Attestation can confirm a request comes from a genuine device. It cannot tell you whether that device is being used to abuse your service. That gap is where CaptchaLa's durable value lives — and it does not go away when attestation ships.

Credential stuffing

Real devices running stolen username and password lists still look like real devices to an attestation token. Our risk engine catches the pattern.

Proxy and bot farms

Distributed abuse from many genuine devices passes attestation but fails behavioral and network scoring.

OTP and signup abuse

Mass account creation and one-time-password farming come from real phones. We score intent, not just device authenticity.

Fraud and content abuse

Payment fraud, spam and harmful uploads are about behavior, which attestation does not measure — and which our risk engine and content moderation do.

Ready when attestation is — and protecting you now.

Free tier included. No credit card required.