[Due for payment 2026-04-01] [Due for payment 2026-03-31] Android - Biometrics - Cannot register biometrics

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.42-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84610
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 16 - Samsung Galaxy A06
App Component: User Settings

Action Performed:

1. Open Expensify App
2. Go to Account-Troubleshoot or do four-finger tap
3. Tap "Test" next to "Biometrics (Not Registered)"

Expected Result:

User can complete verification and register biometrics

Actual Result:

Verification failed with "Oops, something went wrong. Your authentication attempt was unsuccesful."

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7110752_1774275007929.c6db7df1-8c18-4781-a690-b40f82167f5d.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #84610

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #84610 - "[ECUK In-App 3DS] Add Passkeys/WebAuthn support for multifactor biometric authentication" by @dariusz-biela (High confidence)
Related Issues: None

Recommendation: REVERT

PR #84610 introduced a breaking change in the native biometrics registration flow on Android. The PR refactored the biometrics system to add Passkeys/WebAuthn support, but introduced strict validation that fails when authType is undefined.

Labels: Keeping DeployBlockerCash (App PR caused the issue, blocks mobile deploy). No DeployBlocker label is currently present.

Detailed Analysis

Evidence

• The issue reports that biometrics registration fails on Android with "Your authentication attempt was unsuccessful"
• Melvin-bot correctly identified PR [ECUK In-App 3DS] Add Passkeys/WebAuthn support for multifactor biometric authentication #84610 as the likely cause
• The PR was a large refactor (80+ files changed) that restructured the biometrics implementation to support both native biometrics and passkeys
• Bug is reproducible in staging (version 9.3.42-0) which contains this PR
• Issue states "Unable to validate in Prod" suggesting this is a new regression

Verification

The affected code is in /home/runner/_work/App/App/src/components/MultifactorAuthentication/biometrics/useNativeBiometrics.ts:

Registration flow (lines 55-116):

const privateKeyResult = await PrivateKeyStore.set(accountID, privateKey, {nativePromptTitle: translate('multifactorAuthentication.letsVerifyItsYou')});
const authTypeEntry = Object.values(SECURE_STORE_VALUES.AUTH_TYPE).find(({CODE}) => CODE === privateKeyResult.type);

const authType = authTypeEntry
    ? {
          code: authTypeEntry.CODE,
          name: authTypeEntry.NAME,
          marqetaValue: authTypeEntry.MARQETA_VALUE,
      }
    : undefined;

if (!privateKeyResult.value || authType === undefined) {  // Line 74 - FAILURE HERE
    onResult({
        success: false,
        reason: privateKeyResult.reason,
    });
    return;
}

Authorization flow (lines 148-165): Similar logic that fails if authType is undefined.

Root Cause

When PrivateKeyStore.set() or PrivateKeyStore.get() is called, it returns a type value from expo-secure-store via the returnUsedAuthenticationType option. The code then looks up this type in SECURE_STORE_VALUES.AUTH_TYPE to get the authentication method details.

The bug occurs because:

1. On certain Android devices (like Samsung Galaxy A06 running Android 16 as reported), expo-secure-store may return undefined or an unexpected value for type
2. The strict validation authType === undefined at line 74 causes the entire registration to fail
3. This was likely not caught in testing because it depends on specific device/Android version combinations

Before PR #84610: This validation logic did not exist or was more lenient
After PR #84610: Strict validation blocks the flow if authType cannot be determined

The error message "Your authentication attempt was unsuccessful" comes from the default failure screen shown when registration fails.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android (Samsung Galaxy A06, Android 16), tapping "Test" next to "Biometrics (Not Registered)" in Settings → Troubleshoot fails immediately with "Oops, something went wrong. Your authentication attempt was unsuccessful." This is a regression introduced by PR Expensify/App#84610, which refactored the biometrics module to add Passkeys/WebAuthn support.

What is the root cause of that problem?

After thorough code analysis, the refactoring in PR Expensify/App#84610 appears structurally correct — the platform-specific routing, keyInfo construction, and API call format are all consistent with the pre-PR behavior. However, I was unable to identify a definitive root cause from static code analysis alone.

Here is what I confirmed works correctly:

• Platform routing: useBiometrics/index.native.ts correctly resolves to useNativeBiometrics on Android, returning deviceVerificationType: 'BIOMETRICS'
• Scenario config: BiometricsTest allows [BIOMETRICS, PASSKEYS] — the Android type is permitted
• Device support check: doesDeviceSupportAuthenticationMethod() uses PublicKeyStore.supportedAuthentication (biometrics OR credentials) — should pass on devices with a screen lock
• keyInfo construction: The new useNativeBiometrics.ts:97-108 constructs the same keyInfo structure that the old processing.ts did (same fields: rawId, type, response.clientDataJSON, response.biometric.publicKey, response.biometric.algorithm)
• API format: registerAuthenticationKey() still sends {keyInfo: JSON.stringify(keyInfo), authenticationMethod} — unchanged

The error screen shown ("Oops, something went wrong") maps to DefaultServerFailureScreen in OutcomePage.tsx:36. The isServerError() function (OutcomePage.tsx:12-18) returns true for any error where httpStatusCode === undefined (unless it's a user cancellation), which means it could be triggered by:

1. A client-side expo-secure-store failure during PrivateKeyStore.set() (biometric prompt fails) — no httpStatusCode is set
2. A backend RegisterAuthenticationKey API failure — would include httpStatusCode >= 500
3. The device support check failing — no httpStatusCode

To identify the exact failure point, Sentry breadcrumbs from the failing device are needed. The MFA flow logs detailed breadcrumbs at every step:

• 'Device check failed' — if doesDeviceSupportAuthenticationMethod() returns false
• 'Authentication method not allowed' — if the allowedAuthenticationMethods check fails
• 'Biometric registration completed' with success: false — if expo-secure-store key storage fails
• 'Backend registration completed' with success: false and httpStatusCode — if the API call fails

What changes do you think we should make in order to solve the problem?

Immediate debugging steps (to identify the exact failure point):

1. Check Sentry breadcrumbs for the [MFA] category on Android devices running v9.3.42-0 to determine which step fails and what reason value is set
2. If no Sentry data is available, add a temporary console.log at each gate in Main.tsx:process() and reproduce on an Android emulator running API 35+ (Android 16)

Once the failing step is identified, apply the targeted fix:

• If doesDeviceSupportAuthenticationMethod() returns false on Android 16: This would be an expo-secure-store compatibility issue with the new Android version. The fix would be to check the expo-secure-store library version and potentially upgrade or add a workaround for Android 16.

• If PrivateKeyStore.set() fails: The biometric prompt is failing. Check if expo-secure-store v14.2.4 supports Android 16 API changes. The error would be decoded by NativeBiometrics/helpers.ts:decodeExpoMessage() — the reason in the Sentry breadcrumb will reveal the specific Expo error.

• If processRegistration() backend call fails: The httpStatusCode and message in the Sentry breadcrumb will reveal the backend error. Check if the backend Auth PRs (Expensify/Auth#19657, Expensify/Auth#20520) and Web-Expensify PR (Expensify/Web-Expensify#51463) are deployed to the staging environment.

What alternative solutions did you explore? (Optional)

I verified that the refactoring did not alter the API contract or data flow. The keyInfo construction was moved from processing.ts to useNativeBiometrics.ts but produces identical output. The register() function now receives registrationChallenge as a parameter (instead of having it passed to processRegistration separately), but accesses the same .challenge property for constructing clientDataJSON.

One notable observation: the isServerError() function in OutcomePage.tsx treats ALL non-cancellation errors without httpStatusCode as "server errors", which makes the "Oops, something went wrong" screen show even for client-side failures like expo-secure-store errors. This makes the UI error message misleading for diagnostic purposes.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.