An Adaptive Authentication customer enabled the new V7.3 P7 Back Office parameter Enable Other Device Param verification. Soon after enabling the parameter, they started seeing a rise in their challenge rate.
From the V7.3 P7 Release Notes ... Enhanced Device Identification Capabilities Adaptive Authentication 7.3 P7 includes enhanced device identification capabilities, to more accurately identify the user device and increase detection of fraudulent activity. In the Back Office application, there is a new Enable Other Device Param verification parameter. This parameter sends additional device details together with the devicetokencookie to identify the user device. Note: If you enable the Enable Other Device Param verification you must provide the required device details in every SOAP call. By default, the Enable Other Device Param verification parameter is disabled, and the devicetokencookie is used to identify the device. For more information, see the Back Office User Guide, Device Management Parameters.
The customer was able to reproduce the issue in one of their non-production environments. They also were able to enable SOAP call logging and reproduced the issue with SOAP call logging enabled. The resulting log file was shared with Engineering for their review.
AAOP Engineering was able to analyze the SOAP calls, and found that the customer was not passing the devicePrint value in their authenticate calls. The customer was passing the devicePrint value in deviceRequest section of their Analyze request, and a deviceTokenCookie was returned in the Analyze response. Since the devicePrint was passed in the Analyze request, the resulting deviceTokenCookie was associated with all of the device data passed in the Analyze request, including the devicePrint.
However, when the customer sent back the deviceTokenCookie in their Authenticate request, but not the devicePrint information, AA detected a difference in the device information since the Enable Other Device Param verification parameter was enabled, and performing the extended device information checking. This extra checking saw the missing devicePrint value as a difference, and as a result, created a new device, and bound that new device to the user's account.
When the customer came back with a new Analyze request, passing both the devicePrint value, and the deviceTokenCookie associated with the device that had the missing devicePrint value. Again, the devices did not match up, the device was not bound, and a recommendation to challenge was passed back in the Analyze response.
It has been recommended to the customer to pass the devicePrint value in the Authentication request, along with the deviceTokenCookie.