Android Kiosk web app shows access denied in Hexnode Browser LiteSolved

For Android Website Kiosk with Hexnode Browser Lite, the allowlist must include every URL that the browser is expected to load, not just the first URL configured for the web app. If the original web app URL redirects to a separate sign-in path, that redirected URL also needs to be added to the allowlist.

In this case, add entries similar to the following:

• The original web app URL
• The redirected sign-in URL, for example: https://<domain>/ui/v1/signin
• The same sign-in URL with a trailing slash, for example: https://<domain>/ui/v1/signin/
• The root domain, for example: https://<domain>/

After saving the policy, allow the device to receive the updated policy or manually sync the device from the Hexnode portal. The access denied message usually appears when the page redirects to a URL that is not included in the kiosk browser allowlist.

Adding the sign-in URL alone didn’t work for me at first. Once I added the root domain with the trailing slash and waited for the device policy to update, the login page started loading correctly.

That behavior is expected. Some websites load or redirect through the root domain before completing authentication. If the root domain is missing from the allowlist, Hexnode Browser Lite can still block the session even if the visible login URL is already added. For the inactivity requirement, Hexnode does not force the website itself to log out.

However, you can configure the kiosk browser to redirect back to the home page after inactivity: Go to the kiosk policy > Kiosk Lockdown > Website Kiosk settings > Advanced Website Kiosk Settings, then enable the option to redirect the web app to the home page after a period of inactivity.
This works as an inactivity redirect. If the website requires an actual account logout, that behavior must also be supported by the website or web application.

Is there any option to stop users from saving passwords in Hexnode Browser Lite while using the web app in kiosk mode? I may switch to Chrome if that cannot be controlled.

Currently, Hexnode Browser Lite does not provide a separate setting to disable the browser’s save password prompt in website kiosk mode. The configurable options for Hexnode Browser Lite kiosk are available under the kiosk policy’s Advanced Website Kiosk Settings. If password-saving control is a requirement, using Chrome in kiosk may be a better option depending on the Chrome configurations available for your deployment. The website kiosk URL allowlist can still be used when configuring Chrome for the web kiosk flow. You can also use managed app configurations for Chrome where applicable to apply additional Chrome-specific behavior.

This usually happens when the Android kiosk device cannot complete a stable network handshake or when the router treats the device as a different client because of MAC randomization. If the device is already offline, Hexnode cannot send remote actions such as disabling kiosk mode or syncing a new policy until the device gets internet access again.

You will need to restore connectivity locally first. Try one of these options to bring the device online temporarily:

1. Exit kiosk locally using the kiosk exit passcode. If normal taps do not show the prompt, try tapping the top-left corner rapidly 10 times. In Hexnode Browser kiosk, use the browser menu and select Exit Kiosk if available.
2. Connect the device using a USB-to-Ethernet adapter if the device supports it.
3. Use a mobile hotspot with the exact same SSID and password as the saved Wi-Fi network so the device can auto-join.
4. Restarting the access point or router can help if the router has a stale DHCP session, but it may only be temporary if MAC randomization is still active.

Once the device is online, apply these changes:

• Go to Policies > Wi-Fi and set MAC Randomization to Disabled.
• Let the policy sync to the device.
• Update the router’s static IP reservation to bind the IP to the device’s permanent hardware MAC address.
• In Policies > Kiosk Lockdown > Android Kiosk Lockdown > Peripheral Settings, enable the required Wi-Fi controls so the device can reconnect to saved Wi-Fi networks when needed.

Disabling MAC randomization is the key permanent fix when the router is rejecting or mishandling randomized MAC addresses.

A static reservation against the randomized MAC can help stabilize the device long enough for the policy to sync, but it should not be treated as the final configuration. Once MAC Randomization is changed to Disabled and the device syncs the updated Wi-Fi policy, Android will use the permanent physical MAC address. At that point, update the router’s DHCP/static IP reservation to use the physical MAC instead of the temporary randomized one. This change should not negatively impact the kiosk device. It generally improves stability in networks that use MAC filtering, static DHCP reservations, or strict client tracking.

Enabling Wi-Fi controls in the kiosk policy does not automatically give regular kiosk users full access to Android Settings or the notification shade. In kiosk mode, users still cannot disable Wi-Fi locally unless your kiosk policy explicitly allows access to the native Settings app, notification/status bar, or another path to Android network settings. For this use case, enabling the required Wi-Fi control options allows managed reconnection behavior without exposing unrestricted device settings to end users.

Inactivity is based on Hexnode agent communication with the Hexnode cloud, not whether the kiosk screen or web page appears active locally. So an alert can be triggered if the device fails to sync with Hexnode for the configured inactivity duration. To configure email notifications for this scenario:

1. Go to Admin > General Settings > Inactivity Settings.
2. Set the inactivity threshold based on how long a device can remain without agent sync before being treated as inactive.
3. Go to Admin > Alert Profile.
4. Create or edit an alert profile.
5. Under Events, choose Device events such as Device out of compliance. You can also include relevant disenrollment or agent removal events if needed.
6. Under Actions, select Email.
7. Choose the technicians/admins or add external recipients.
8. Save the alert profile.

With MAC randomization disabled and the router reservation updated to the physical MAC, the device should maintain a stable connection and the offline alerts should become more meaningful.