> ## Documentation Index
> Fetch the complete documentation index at: https://stytch.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Challenge verdict
> Handling `CHALLENGE` verdicts for medium-risk devices.
## Overview
When Stytch returns a `CHALLENGE` verdict, that indicates unusual configuration that is often associated with attacks, but also has legitimate use cases. For example:
For example, if the request has characteristics of running in a virtual machine (VM), we may return a `CHALLENGE` verdict. Sometimes, VMs are used in automated attacks, but they are also used for legitimate applications like enterprise browsers. As a result, how you want to handle the request depends on your risk profile and the reason for the `CHALLENGE`.
Common strategies for handling `CHALLENGE` verdicts are:
* Requiring some additional user input (like requiring MFA or surfacing a CAPTCHA) before allowing the request to proceed.
* For sensitive applications, blocking all requests that receive `CHALLENGE` verdicts.
* Or, allowing all requests that receive `CHALLENGE` verdicts to proceed.
***
## Challenge verdicts in the API
When you receive a `CHALLENGE` verdict in the [Fingerprint Lookup](/api-reference/fraud/api/fingerprint-lookup) response, we generally recommend introducing some additional verification (such as a CAPTCHA, MFA, or other step that requires user input) to ensure that the user is legitimate before allowing them to proceed.
We return a `verdict.reasons` array in the Fingerprint Lookup response that will indicate the reason for the `CHALLENGE` verdict. For example, the following response indicates that the request received a `CHALLENGE` verdict because it may have resulted from automatic browser traffic:
```json theme={null}
"verdict": {
"action": "CHALLENGE",
"detected_device_type": "UNKNOWN",
"is_authentic_device": false,
"reasons": ["POSSIBLE_BROWSER_AUTOMATION"]
}
```
If you maintain your own risk score based on cumulative Device Fingerprinting verdicts, you should assign a medium level of risk to a `CHALLENGE` verdict. You may also choose to assign different risk scores to different verdict reasons.
See [Reference guides](/fraud-risk/development/overview) for a full list of verdict reasons.
## Challenge verdicts in Protected Auth
When [Protected Auth](/fraud-risk/device-fingerprinting/protected-auth) is enabled in *Enforcement mode*, the Stytch SDK will allow requests that hit `CHALLENGE` verdicts to proceed by default.
For increased strictness, you can configure the behavior under [Frontend SDK settings](https://stytch.com/dashboard/sdk-configuration) to either block requests that result in a `CHALLENGE` verdictor to trigger a CAPTCHA:
### Run reCAPTCHA on a CHALLENGE verdict
Stytch offers a JavaScript SDK integration with Google's Invisible reCAPTCHA that runs before each SDK method call. Invisible reCAPTCHA is a type of CAPTCHA that evaluates traffic without requiring any interaction from the user.
If [reCAPTCHA](https://stytch.com/dashboard/captcha/recaptcha) is configured and a user calls a Stytch SDK method, the SDK retrieves a CAPTCHA token that is sent along with the SDK request. The Stytch backend calls the Google API on your behalf and returns an error if the reCAPTCHA doesn't meet the threshold that you set.
When *Challenge handling* is set to **Trigger CAPTCHA** and a `CHALLENGE` verdict is returned, the SDK will trigger the CAPTCHA flow in order to add another layer of protection from malicious requests.
***
## Allow or block a device or device group
If you'd like to allow or block a device or group of devices that's receiving an `CHALLENGE` verdict, you can [set a rule](/fraud-risk/device-fingerprinting/decisioning/set-rules).
## Override verdict reasons
You can [override verdict reasons](/fraud-risk/device-fingerprinting/decisioning/override-verdict-reasons) if you do expect traffic with the warning flags that default to `CHALLENGE`, but would like to allow or block them.