This is indeed unusual, especially since the issue appears to affect only a single user and device, which makes a FusionAuth configuration issue unlikely.

A few things to check and try:

Open in External Browser Ask the user to tap the three-dot menu (if available) in the webview and choose “Open in Chrome” or their default browser. If the page loads correctly there, the issue is likely related to the embedded webview rather than FusionAuth itself.

WebView / Browser-Specific Issues

Some Android devices (including certain Xiaomi models) ship with custom WebView implementations or aggressive privacy/security settings that can interfere with embedded web content.

Ensure the device has the latest Android System WebView and browser updates installed.

Domain / CNAME Edge Cases

There have been rare cases where mobile browsers or webviews behave unexpectedly if the domain includes characters such as underscores (_) or dashes (-) in certain positions.

While this typically results in explicit errors (like “Address not found”), it’s still worth reviewing your domain and CNAME setup—especially since you’re self-hosting.

Given that the login works for the same user on other devices, this is most likely a device- or WebView-specific issue rather than a problem with FusionAuth itself. If opening the login page in a full browser works, that should help narrow the root cause to the embedded webview implementation on that device.

You’re correct: FusionAuth’s Lambda environment does not provide access to external libraries (including AWS SDKs or SigV4 helpers), and there is no secure secrets store available to Lambdas. That means if you need AWS SigV4 signing from inside a Lambda, you would have to implement the signing logic yourself and embed any required credentials directly in the Lambda code—this is generally not considered secure.

Also, if you are using FusionAuth Cloud, you cannot place Lambdas into your private network (for example, the same VPC/network as your API Gateway), so that option isn’t available in hosted deployments.

If you need this capability, the recommended approach is typically to move the signing and secret handling into a system you control (for example, a backend service that FusionAuth calls), rather than performing SigV4 signing directly in a FusionAuth Lambda.

Related issue tracking:
https://github.com/fusionauth/fusionauth-issues/issues/1629

This is a known bug, and it looks like the underlying issue has already been identified and fixed. The fix will be included in the next FusionAuth release.