additional.isTrustedDeviceEnabled Not Returned in Authentication Response Despite Correct Trusted Device Configuration
search cancel

additional.isTrustedDeviceEnabled Not Returned in Authentication Response Despite Correct Trusted Device Configuration

book

Article ID: 441130

calendar_today

Updated On:

Products

Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

You have configured Trusted Devices in Symantec Identity Security Platform (IDSP) AuthHub according to the official documentation. The tenant configuration and authentication policy are correctly set, the device signature is submitted, and a deviceId is returned. However, the expected field additional.isTrustedDeviceEnabled=true is absent from the last authentication factor API response (e.g., the OTPGenerator call), preventing the "Remember This Device" flow from completing.

Symptoms

  • Trusted Device configuration steps have been completed:
    • isTrustedDeviceEnabled is set to true in Tenant Config.
    • The Authentication Policy has mfaFrequency: OnceForTrustedDevice configured.
    • The device fingerprint is submitted and a deviceId is returned successfully from the /auth/v1/authenticate call.
  • The additional.isTrustedDeviceEnabled=true field is not present in any authentication API response.
  • The "Remember This Device" checkbox is not displayed in the client application UI.
  • The full MFA flow cannot be bypassed on subsequent logins from the same device.

Environment

Symantec Identity Security Platform (AuthHub) 

Version: 4.0

Cause

The root cause is a misconfigured tagExpireInSeconds setting in the Device Recognition risk rule. In the reported environment, this value was set to 60 seconds, which is the minimum allowed value.

The tagExpireInSeconds parameter controls how long a newly issued device tag remains valid during a risk evaluation. Specifically, it governs the window in which the device tag — issued at the start of the authentication flow — must remain active throughout the entire multi-factor authentication sequence.

When tagExpireInSeconds is set too low, the device tag expires before the user completes the full authentication flow (e.g., Password → SMS OTP). By the time the last authentication factor API call (e.g., /factor/v1/OTPGenerator) is reached, the device tag has already expired. As a result:

  1. The Risk Engine is unable to associate the in-progress authentication with the device tag.
  2. The device cannot be identified as a recognized, trusted-eligible device within the session.
  3. The additional.isTrustedDeviceEnabled=true flag is not returned in the API response.
  4. The remember-this-device and x-device-tag headers in the final OTPVerifier call have no effect, and the device is never registered as trusted.

Resolution

Increase the value of tagExpireInSeconds in the Device Recognition risk rule to a value that comfortably exceeds the expected duration of the complete authentication flow.

Out-of-the-box (OOTB) default: 1800 seconds (30 minutes). This value supports typical MFA flows. Set the value based on the observed or expected time a user may take to complete all authentication factors. Avoid setting the value unnecessarily high in security-sensitive environments, but ensure it is always greater than the maximum realistic authentication session duration.

Additional Information

  • When risk is enabled for Trusted Devices, it is essential that the Device Recognition risk rule is also active ("enabled": true). Disabling this rule will prevent the device tag from being issued or evaluated.
  • If multiple authentication policies are assigned to an application and one of them has mfaFrequency: EveryTime, it will take precedence over mfaFrequency: OnceForTrustedDevice, overriding the trusted device behavior regardless of this fix.