Passpoint SSID Prompts for a Password Instead of Auto-Joining

What's happening

Normally, a Passpoint (Hotspot 2.0) network should connect automatically — no password prompt, no manual sign-in. If devices at a specific site are instead being prompted for a username/password when they see the SSID, and this is happening consistently across multiple devices (not just one), it usually points to a network-side configuration issue rather than anything wrong with the individual devices.

How to tell if it's site-specific or device-specific

Before troubleshooting configuration, confirm the scope of the issue:

• Check whether the same devices work fine at other sites. If a device auto-joins normally elsewhere but gets prompted at one particular location, that points to the site's network configuration rather than the device.

• Check your usage/connection data (portal) for the affected site(s). If a site shows no successful connections at all — across different devices and carriers — that confirms a site-wide issue rather than isolated device problems.

   

Root cause

This is commonly caused by missing or incomplete Hotspot 2.0 (HS2.0) configuration on the wireless controller serving that site. HS2.0 configuration is what allows devices to use their SIM card to authenticate automatically — without it fully configured, devices fall back to prompting for manual credentials, since they have no way to auto-authenticate.

If you manage multiple sites across more than one wireless controller (for example, some sites on one platform and others on a different one), check whether the affected sites share a specific controller — that's often the fastest way to isolate where the configuration is missing.

Troubleshooting steps (for your network/IT team)

1. Confirm the scope. Use connection/portal data to determine whether the issue affects a specific site, a specific controller, or specific devices.
2. Review the HS2.0 (Hotspot 2.0) settings on the controller serving the affected site(s). Confirm HS2.0 is fully enabled — not just partially configured.
3. Check NAI realm configuration. Each supported carrier/roaming partner typically needs its own realm entry, with the correct authentication method configured for that realm (methods vary — e.g. certificate-based, MSCHAPv2, or SIM-based depending on the carrier and platform). AT&T Android devices in particular often need a dedicated realm entry to authenticate reliably — if AT&T Android devices specifically are failing while other devices work, check this first.
4. Check roaming consortium IDs. Missing or incomplete roaming consortium entries can also prevent certain devices from recognizing the network as one they can auto-join.
5. Check RADIUS server timeout and retry settings. A timeout that's too short can cause intermittent auth failures that look similar to this issue — a timeout around 5 seconds with a small number of retries (e.g. 3) is often more reliable than aggressive defaults.
6. If you use multiple controller platforms or templates, apply the fix consistently across all of them — a setting corrected on one controller/template won't help sites served by a different one.
7. After a platform migration (e.g. moving to a new controller vendor or software version), specifically re-verify RADIUS authentication and accounting ports and shared secrets, along with NAI realms and carrier MCC/MNC codes — migrations can reset or drop these values even when the rest of the configuration carries over.
8. If a specific device remains stuck after a fix is applied, try rebooting it to clear any cached failed-connection state before assuming the fix didn't work.
9. If a device that was working suddenly stops without any local configuration changes, check whether your carrier had a known service update or outage — occasionally, realm or NAS ID configuration can need to be reapplied once carrier-side service is restored, even if nothing changed on your end.

10. Test live after making changes. A successful fix typically shows the SSID auto-joining and displaying the carrier name, rather than prompting for credentials.

     

Workaround for persistent Android connection issues

If a specific Android device continues to fail to auto-join after the above checks, manually selecting the correct EAP method (e.g. EAP-AKA) one time on the device can sometimes work as a temporary workaround while the underlying configuration is further investigated.

Also worth checking: radio band settings

If connections are working but still feel unstable after fixing HS2.0, consider setting the SSID to prefer or require the 5 GHz band over 2.4 GHz where supported — this can improve connection reliability, though it's a secondary optimization rather than the primary fix for a password-prompt issue.

If the issue continues

If HS2.0, NAI realms, and roaming consortiums all look correctly configured and devices are still being prompted for a password, contact support with:

• The affected site(s) and which controller/platform serves them
• Confirmation of what you've already checked from the list above

Our team can work with your network admin to review the full configuration in more detail.

Book a call: Contact American Bandwidth