Inconsistent Duplicate Passkey Error Messages Across Android Devices

Products

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

Issue/Introduction

When an application requests the creation of a passkey that already exists on a user's device, different Android hardware models display varying error string formats.

• Standardized / Expected Error Response:

  A passkey for this account already exists on this device. (or standard InvalidStateError / TYPE_INVALID_STATE_ERROR DOM exception).

• Observed Variations:

  • OEM Variant A (e.g., Samsung Galaxy S24, Google Pixel 9):

    One of the excluded credentials exists on the local device.

  • OEM Variant B (e.g., Motorola):

    [50157] One of the excluded credentials exists on the local device.

Cause

1. Source of the Error Message

Passkey creation and verification flows are managed by low-level system services within the Google Play Services (GPS) / FIDO2 system stack and the Android Credential Manager API running on the underlying OS.

The error message—including raw internal failure codes such as [50157]—is emitted directly by Google Play Services during local credential exclusion checks.

2. Why Error Code [50157] Appears on Some OEM Devices

The prefix [50157] corresponds to an internal status code generated within the Google Play Services FIDO2 module indicating a duplicate credential collision.

Differences in displayed strings between devices are driven by two main underlying mechanisms:

• API Flow Routing: Devices running different Android OS builds or Play Services versions may route passkey registration requests through either the Credential Manager API path or the legacy FIDO2 API path.

• OEM System Image Customizations: Device manufacturers deploy varying Android OS builds, Google Play Services bundle updates, and proprietary system image configurations. Certain builds preserve or expose raw Play Services error string prefixes (e.g., [50157]), while others strip numeric prefixes before returning the string to calling applications.

Resolution

Because this behavior originates at the Android OS and Google Play Services subsystem layer, it cannot be modified or overridden directly within external client SDKs or application codebases.

Resolution & Next Steps

• SDK Level Fixes: No SDK code change is being committed at this time to intercept or normalize hardware/OS-level error strings, as internal string parsing introduces fragility across varying Android releases. Broadcom Eng team will research this in future to check if anything can be done from SDK perspective but at this time it is recommended to reach out to the vendors.

• Vendor Escalation (Recommended): Hardware vendors and enterprise deployment teams observing unexpected error prefixes are encouraged to open technical support tickets directly with the respective OEM support channels (e.g., Motorola Support) and Google Android Partner Engineering to request standardized error formatting in future Play Services updates.