Authenticity challenge policies enable human verification through biometric authentication in Cequence Defender. When legitimate users are incorrectly flagged as bots, they can prove their humanity using Touch ID, Face ID, Windows Hello, or equivalent device biometrics instead of being blocked.

The problem with false positives

Bot detection systems occasionally misclassify legitimate users as bots, creating a frustrating experience where real customers are blocked from accessing services. Your current mitigation options each carry trade-offs. Blocking loses legitimate customers and damages brand reputation. Allowing through undermines bot protection. Redirecting sends users elsewhere without verifying humanity. Rate limiting may still block legitimate users during high activity.

Traditional verification methods also fall short. CAPTCHAs are solvable by modern machine learning with 99% or higher accuracy. Email and SMS one-time passwords can be automated or intercepted. OAuth still requires CAPTCHA during account creation. Authenticity challenge policies eliminate these weaknesses by using device-native biometrics that cannot be automated or scaled because they require interaction with hardware security modules that only legitimate devices possess.

Why authenticity challenge policies work

Biometric verification provides very high bot resistance because it is hardware-bound—impossible to solve without access to the actual device. Unlike CAPTCHAs or one-time passwords, biometrics cannot be machine-learned, intercepted, or scaled. Verification completes in under one second using a single biometric interaction—the same authentication method users employ to unlock their phones or laptops. No personal information is collected.

Overview

Authenticity challenge policies work best early in user flows before forms or carts, applied to bot detection rules you have high confidence in, and when users are primarily on devices with biometric capability. For borderline cases, use Challenge; for definite bots, use Block. Consider alternatives when protecting API endpoints called programmatically, when requests use POST, PUT, PATCH, or DELETE methods (not currently supported), or when users primarily access from non-biometric devices.

Stakeholder benefits

Biometrics offer a fast, familiar verification process that provides cryptographically proven human verification with hardware-backed assurance. Authenticity challenge policies also enable measurement of false positive rate for the first time. By tracking how many users successfully pass the challenge policy, you gain actionable data to tune detection thresholds and identify rules with high false positive rates.

What users see

The verification screen

When authenticity challenge policies are triggered, users see a verification page with a title explaining why verification is needed, brief explanatory text, and a prompt for biometric authentication from their device's operating system.

Completing verification on desktop

On Windows with Windows Hello or Mac with Touch ID, users are redirected to a verification page. The browser displays the biometric prompt. The user places a finger on the fingerprint reader, or looks at the camera for Windows Hello face recognition. Upon successful verification, the user is automatically redirected to their original destination.

Completing verification on mobile

On mobile devices, the verification page loads in the browser. The device prompts for biometric authentication. The user completes verification using Face ID, Touch ID, or their device's fingerprint sensor. Upon success, the user is redirected back to the application. Verification typically completes in under one second.

After successful verification

The user is automatically redirected to the page they were trying to access. A session is established, so re-verification is not required for a period of time. Subsequent requests from the user's device are allowed through.

If verification fails

The user can try again. Common causes of failure include a finger not properly placed on the sensor or the face not positioned correctly for the camera. If repeated failures occur, the user should contact the application administrator.

Troubleshooting

Biometric authentication not available

The user's device lacks biometric hardware (fingerprint reader, Face ID, or Windows Hello camera), or biometric authentication is not enabled. On Windows, the user can ensure Windows Hello is set up in Windows Settings Accounts Sign-in options. On Mac, the user can ensure Touch ID is enabled in System Preferences Touch ID. On mobile devices, the user can ensure Face ID or Touch ID is enabled in device settings. If the device lacks biometric capability, the user should try accessing from a device with biometric capability.

Verification failed

The biometric scan was not recognized. The user should ensure their finger is clean and dry, position their face properly for Face ID, and try again. Sometimes a second attempt succeeds. When using a fingerprint reader, the user can try a different registered finger.

Browser does not support verification

The browser is outdated or does not support WebAuthn. The user should update their browser to the latest version. Supported browsers are Chrome 67 or later, Safari 14 or later, Firefox 60 or later, and Edge 79 or later. The user can try a different browser.

Verification not working in private or incognito mode

Some browsers limit WebAuthn functionality in private browsing mode. The user should try using a regular (non-private) browser window.

Technical requirements

Browser compatibility

End users must use a browser that supports WebAuthn.

Device requirements

Users must have a device with biometric capability. Devices without Touch ID, Face ID, Windows Hello, or equivalent biometric sensors are unable to complete verification and will be blocked. This affects older desktops without biometric hardware, budget mobile devices without fingerprint or face sensors, corporate devices with biometrics disabled by policy, and virtual machines or cloud desktops.

Limitations

Current implementation 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 would lose request body data. Support for state-changing HTTP methods is planned for future releases. Users without biometric capability are blocked—there is no fallback option. This is by design to ensure bot protection. Desktop biometric authentication (Windows Hello or Touch ID) must be enabled; 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.

Mobile app considerations

Mobile Safari on iOS is supported with Face ID or Touch ID. Chrome Mobile on Android is supported with device biometrics. Native mobile apps may require additional integration. Hybrid apps (such as those built with React Native or Flutter) have varying compatibility.

Multi-device access

Each device must complete verification independently. Sessions are device-specific rather than user-specific. This is appropriate for bot protection because verification confirms that a human is using a particular device, not the identity of the user.

Privacy and data

No personally identifiable information is collected during verification. Devices are identified only by cryptographic credential ID. Authenticity challenge policies are GDPR-compliant because no personal data is stored.