Authenticity challenge policies enable you to configure the Cequence Unified API Protection (UAP) platform  to configure the Challenge action in mitigation policies. Instead of blocking potentially suspicious requests, the Challenge action redirects users to complete biometric verification, enabling legitimate users to prove authenticity.

Use cases

Use authenticity challenge policies to reduce false positives by giving blocked users a path to prove legitimacy. Apply the Challenge action to protect high-value endpoints such as checkout or payment flows that require human verification. During rule tuning and new detection rule rollout, use Challenge instead of Block to validate rules before blocking. Challenge provides a more user-friendly security experience than showing error pages.

Prerequisites

Cequence Defender must be deployed with authenticity challenge policies enabled. The sidecar auth service must be deployed alongside Defender (this is handled by deployment). Biometric authentication requires secure connections, making HTTPS a requirement.

Enabling the Challenge action on a policy

1. Log in to the Cequence UAP platform dashboard.
2. Navigate to Policies > Mitigation Policies.
3. Select an existing policy or create a new one.
4. In the policy configuration, locate the Action field.
5. From the dropdown, select Challenge.
6. Configure any additional policy conditions such as rules or endpoints.
7. Save the policy.

Configuration examples

Challenge on bot detection

Create a policy that challenges users flagged as potential bots.

Challenge on high-value endpoints

Require human verification for checkout or payment endpoints.

Challenge during rule validation

When testing a new detection rule, use Challenge to validate behavior before blocking.

Dashboard and monitoring

Viewing Challenge metrics

1. Log in to the Cequence UAP platform.
2. Navigate to Dashboards > Mitigation.
3. The traffic chart includes Challenge actions alongside Block, Allow, and Redirect.
4. Filter by policy to view Challenge volume for specific rules.

Available metrics

Technical requirements

Deployment requirements

Network requirements

Policy design recommendations

Begin with high-confidence rules and apply Challenge to rules you are confident about. Monitor Challenge pass rates to identify rules with high false positive rates. Combine Challenge with other actions by using Challenge for borderline cases and Block for definite bots. Consider user journey and apply Challenge early in user flows, before forms or shopping carts where blocked access creates friction.

Limitations and considerations

Current limitations

Authenticity challenge policies currently support GET requests only. POST, PUT, PATCH, and DELETE requests are not supported because the Challenge action uses redirect, which loses request body data. Use Block or Redirect actions instead for state-changing HTTP methods. By design, users without biometric capability are blocked with no fallback option in order to maintain bot protection. Windows Hello or Touch ID must be enabled on desktop devices; users with disabled biometrics cannot complete verification.

Known compatibility issues

Verification may not work in private or incognito browsing mode in some browsers. Enterprise-managed devices may have IT policies that disable biometrics. Virtual machines typically lack biometric hardware. Embedded web views may have limited WebAuthn support. WebAuthn may not function when embedded in cross-origin iframes.

Device and browser support

Session management

Session duration is determined by the JWT token expiration, typically one hour. Users do not need to re-verify until the session expires. Each device requires independent verification; sessions are device-specific, not user-specific. Users can complete verification from multiple devices, but each device maintains its own session.