This article describes how the Cequence Defender biometric challenge feature works and what network connectivity it requires for on-premises deployments.
Overview
The biometric challenge is a human-verification mechanism built into the Cequence Defender. When a mitigation policy with a Challenge action is triggered, the Defender intercepts the request and presents a WebAuthn/passkeys challenge to the end user. The user completes a biometric gesture (Touch ID, Face ID, or device fingerprint). On success, the Defender issues a signed session token and passes all subsequent requests through transparently until the token expires.
Cequence uses Descope as the identity provider that runs the WebAuthn ceremony. Descope is a Cequence-managed cloud service — customers do not need a Descope account or any Descope configuration.
Request Flow
- An incoming request matches a policy with the Challenge action.
- The Defender serves a challenge page (
biometric.html) to the end user's browser. This page is generated from a template pushed to the Defender by UAP and is served locally — no external call is required at this step. - The challenge page contains an embedded Descope web component. The user's browser calls Descope's API directly over HTTPS to run the WebAuthn ceremony and receive a signed JWT from Descope.
- The browser POSTs the Descope-signed JWT to the Defender's local finalize endpoint (
/__cq/auth/finalize). - The Defender validates the JWT against Descope's public keys and, if valid, sets a session cookie (
cq_session_cookie). All subsequent requests carrying a valid session cookie are proxied to the backend without re-challenging.
Network Requirements for On-Premises Deployments
Two components require outbound HTTPS access to Descope:
| End-user browsers | Must reach Descope's API at challenge time to complete the WebAuthn ceremony. This is a browser-to-Descope call — no traffic passes through the Defender or your server infrastructure. |
| Defender instances | Fetch Descope's public JWKS (JSON Web Key Set) to validate challenge tokens. Keys are fetched once on startup, cached locally, and refreshed approximately every hour. This is the only server-side outbound call the Defender makes to Descope. |
If your environment restricts outbound traffic, allowlist *.descope.com for both end-user browser traffic and Defender instance egress. Contact Cequence Support for the specific hostnames if a wildcard allowlist is not permitted.
What Stays On-Premises
All request proxying, session token validation, and policy enforcement happen locally within the Defender. Once the initial challenge is completed and the session cookie is set, no further calls to Descope are made on a per-request basis. The Defender validates session tokens entirely using locally cached public keys.