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
- Log in to the Cequence UAP platform dashboard.
- Navigate to Policies > Mitigation Policies.
- Select an existing policy or create a new one.
- In the policy configuration, locate the Action field.
- From the dropdown, select Challenge.
- Configure any additional policy conditions such as rules or endpoints.
- Save the policy.
Configuration examples
Challenge on bot detection
Create a policy that challenges users flagged as potential bots.
| Field | Value |
|---|---|
| Policy name | Bot Score Challenge |
| Condition | Bot Score 70 |
| Action | Challenge |
| Endpoints | All |
Challenge on high-value endpoints
Require human verification for checkout or payment endpoints.
| Field | Value |
|---|---|
| Policy name | Checkout Protection |
| Condition | Endpoint matches /checkout/* or /payment/* |
| Action | Challenge |
Challenge during rule validation
When testing a new detection rule, use Challenge to validate behavior before blocking.
| Field | Value |
|---|---|
| Policy name | New Rule Validation |
| Condition | Custom rule match |
| Action | Challenge (instead of Block) |
Dashboard and monitoring
Viewing Challenge metrics
- Log in to the Cequence UAP platform.
- Navigate to Dashboards > Mitigation.
- The traffic chart includes Challenge actions alongside Block, Allow, and Redirect.
- Filter by policy to view Challenge volume for specific rules.
Available metrics
| Metric | Description |
|---|---|
| Challenge count | Number of Challenge actions issued. |
| Challenge over time | Line chart showing Challenge volume trends. |
| Challenge pass rate | Percentage of users who successfully completed verification. High pass rates may indicate false positives in the associated rule. |
Technical requirements
Deployment requirements
| Requirement | Details |
|---|---|
| HTTPS | Required. Biometric authentication only works over secure connections. |
| Defender version | Requires the 6.0 release or later of Defender. |
| Auth service | Deployed as sidecar container (automatic with feature enablement). |
Network requirements
| Connection | Purpose |
|---|---|
| Outbound HTTPS | Auth service connects to WebAuthn provider for credential verification. |
| Internal (localhost) | Defender communicates with auth service on localhost. |
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
| Platform | Status |
|---|---|
| Mobile Safari (iOS) | Supported with Face ID or Touch ID. |
| Chrome Mobile (Android) | Supported with device biometrics. |
| Native mobile apps | May require additional integration. |
| Hybrid apps (React Native, Flutter) | Compatibility varies. |
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.