Device risk tags
Risk category | Risk tag | Description |
Device risk (Native SDK) | ROOT | The device appears to be rooted or jailbroken. |
HOOK | The device appears to be hooked. | |
VPN | The device appears to be using a VPN. | |
Emulator | The device appears to be an emulator. | |
SystemVirtual | The device is running system-level app clones. Important Android only | |
ThirdVirtual | The device is running third-party app clones. Important Android only | |
AdbModel | Developer mode is enabled on the device. Important Android only | |
DebugModel | Debug mode is enabled. | |
NoSimCard | No SIM card is inserted in the device. | |
VirtualVideo | A virtual video tool is installed. | |
UsingVirtualVideo | A virtual video tool is in use. | |
MirroredScreen | The screen is being recorded or captured. Important iOS only | |
RiskROM | The device is running a high-risk custom ROM. Important Android only | |
UnusualROM | The device is running a non-standard ROM. Important Android only | |
AutoOperation | The environment or tools appear to be automated. | |
BlackTool | A high-risk tool from the cyber underground economy chain is installed. | |
CloudPhone | The device is a cloud phone. Important Android only | |
BootUnLock | The device bootloader is unlocked. Important Android only | |
BootCountLittle | The device has a low boot count. Important Android only | |
ChargeScreenBright | The screen stays on while the device is charging. Important Android only | |
ChargeScreenNoSecure | The device is charging and is configured to keep the screen on while charging. Important Android only | |
ChargeWithUsb | The device is charging via USB. Important Android only | |
FakeDevice | The device has been modified. This includes but is not limited to tampering with the device model or features. | |
AbnormalPort | The device has an abnormal port. Important Android only | |
Device risk (Web SDK) Important
Due to browser sandbox restrictions, the detection capabilities of the Web SDK are limited to the browser layer. It cannot access low-level information such as hardware sources or drivers, which creates bottlenecks in detecting injection techniques. Therefore, it is recommended to combine server-side image liveness detection and business risk control measures to build a multi-layered defense-in-depth system, rather than relying solely on the Web-side Device Guard for decision-making. | VirtualBrowser | The browser appears to be a virtual browser. |
VirtualCamera | A virtual camera appears to be installed. | |
UsingVirtualCamera | A virtual camera appears to be in use. | |
AutoOperation | The environment or tools appear to be automated. | |
BrowserTampered | Browser parameters appear to be tampered with. | |
Debugger | The page JavaScript appears to be in debug mode. | |
CloudPhone | The environment appears to be a cloud phone. | |
WebCrawler | Indicates a suspected malicious web crawler or automated calls based on protocol. | |
CookieDisabled | Cookies are disabled. | |
Incognito | The browser is in incognito mode. | |
MediaHook | The browser's video stream API is hooked. | |
NoRefer | The ID Verification page has no referrer source. Note This tag requires integration with ID Verification for Financial Services and is not available for standalone Face Liveness SDK integrations. | |
UnmatchOsUrl | The initialization client and authentication client do not match. Note This tag requires integration with ID Verification for Financial Services and is not available for standalone Face Liveness SDK integrations. | |
DeviceToken risk | TokenIsNull | The deviceToken is empty. |
TokenTampered | The deviceToken is tampered with. | |
TokenInvalid | The deviceToken is invalid. | |
TokenExpired | The deviceToken has expired (valid for 7 days). | |
General | BizIdNotMatch | The bizId passed during the business query does not match the bizId bound in the getDeviceToken call on the client. This is common in token replacement attacks. Note If this tag appears frequently, first check that the bizId used in the getDeviceToken method call matches the bizId passed to the Face Liveness SDK query interface during client integration. |
DeviceBadNet | Poor network environment (Face Liveness SDK failed to initialize). Note If this tag appears frequently, check the client integration process first. This issue usually occurs because the client initialization and the getDeviceToken call do not follow the standard sequence shown in the official documentation. Adjust the token acquisition timing as described in the documentation. | |
ReportingGap | Security Guard is failing to report data. Note If this tag appears frequently, check the client integration process first. This issue usually occurs because the client initialization and the getDeviceToken call do not follow the standard sequence shown in the official documentation. Adjust the token acquisition timing as described in the documentation. | |
Business scenario | HighRiskEnv | Indicates a high-risk environment associated with the cyber underground economy chain, based on a comprehensive assessment. Note This is a composite tag. The result is determined by a multi-dimensional analysis based on our accumulated online attack and defense experience. |
MiddleRiskEnv | Indicates a medium-risk environment associated with the cyber underground economy chain, based on a comprehensive assessment. Note This is a composite tag. The result is determined by a multi-dimensional analysis based on our accumulated online attack and defense experience. | |
LLM mining Note This type of tag is only supported by the Device Assistant solution. | QwenSeekRisk | The Large Language Model (LLM) has identified a high-risk environment during the authentication process. |
Other | NoRisk | Low device risk. This tag is returned when the system does not detect any of the risks listed above. |
NoTag | No data is returned. The system automatically returns this tag when a system error in ID Verification prevents risk tags from being retrieved. |
FAQ
Can I change the blocking level for a specific threat type, such as ROOT?
No, you cannot change the blocking level based on the threat type. For example, you cannot globally lower the blocking level for the ROOT tag. However, if you determine that a threat from a specific device can be ignored, you can add the device to the whitelist individually on the General Settings > Whitelist Settings page in the console.
Does whitelisting apply to a device or a CertifyId?
Whitelisting is bound to the device ID. The `CertifyId` serves only as an index to locate a device. The system uses the `CertifyId` to retrieve the corresponding device ID and add the device to the whitelist. A device remains on the whitelist for the entire validity period, even if its `CertifyId` changes. The system supports the following three whitelisting patterns:
Whitelist by `CertifyId`: The system parses the device ID from the `CertifyId` and allows authentication requests from the device for the duration of the validity period.
Whitelist by national ID number: The system automatically allows authentication requests associated with the national ID number for the duration of the validity period.
Whitelist by national ID number and `CertifyId`: The system parses the device ID from the `CertifyId`. The whitelist entry is effective only when both the device ID and the national ID number match.
Which device threats are bypassed by whitelisting?
The whitelist only bypasses policy blocks (error code 206) that are triggered by device environment threats. These threats include tags such as ROOT, HOOK (injection), Emulator, VirtualCamera, and UsingVirtualCamera (camera hijacking).
Whitelisting does not affect the results of identity verification or algorithm checks. Abnormalities at the identity or algorithm layer, such as a face mismatch, are still blocked. Whitelisting is designed for cases where internal test machines or specific devices are incorrectly flagged because of environment threats. This ensures that non-algorithmic policies do not interfere with the testing process.
The liveness detection actions are complete. Why did authentication still fail?
Policy blocks typically occur after liveness detection but before face comparison. If the system detects a high-risk device or runtime environment, such as ROOT, Emulator, or MirroredScreen, it aborts the authentication because of a high threat score and returns error code 206. This type of failure is unrelated to face image quality. Investigate the device environment threats instead.
Does USB debugging mode affect authentication?
Yes, USB debugging mode affects authentication. Enabling developer mode on Android devices triggers the `AdbModel` threat tag, which can cause authentication to fail and return an error code such as Z5128. When testing on a physical device, disconnect the USB cable and disable USB debugging mode before running the authentication test.