Android 802.1X and EAP-TLS troubleshooting: a deployment checklist for Intune and Entra ID

Managed Android cell phones usually fail EAP-TLS for one of four reasons. The WiFi profile lacks a CA certificate or domain, so Android rejects the RADIUS server. The client certificate sits in a different profile. The RADIUS server names field does not match the server certificate. Or the trusted root profile never reached the device.

What does an EAP-TLS failure look like on Android?

EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) authenticates a device with a certificate instead of a password. It runs inside IEEE 802.1X, the port - based access control standard. 802.1X hands authentication to a RADIUS (Remote Authentication Dial - In User Service) server.

When this fails on Android, you will typically see one of these symptoms:

• The network appears in the list but never moves past "Connecting", then drops back to "Saved".
• The device shows a generic authentication error. The wording varies by manufacturer.
• The network works on Samsung handsets but not on Google Pixel, or the reverse.
• The network works on corporate - owned cell phones but fails on personally owned devices enrolled with a work profile.
• Nothing appears in your RADIUS logs at all.

That last symptom matters most. A device that never reaches RADIUS has a profile problem, not an authentication problem.

What usually causes Android EAP-TLS failures?

Stricter server validation in recent Android releases

Recent Android releases removed the "Do not validate" option for new enterprise networks. Android now needs two things before it will send its certificate: a CA certificate to trust and a domain to match.

Without both, the device refuses to complete the TLS handshake. Profiles that worked for years on older builds can fail once a device takes an operating system update.

Certificate in the work profile, network joined from the personal side

Android Enterprise separates the work profile from the personal side, and each has its own certificate store. Intune installs the client certificate and the trusted root in the work profile. A staff member who adds the SSID by hand from personal settings cannot reach those certificates, so authentication fails.

The RADIUS server names field

The Intune Android Enterprise WiFi profile includes a RADIUS server names field. Microsoft's documentation asks for the DNS name in the certificate your RADIUS server presents. Android places this value in its domain field and compares it with the server certificate. If the field is blank, misspelled or holds an IP address, validation fails.

The trusted root profile

The WiFi profile points to a separate Intune trusted certificate profile. That profile must hold the root CA that issued the RADIUS server's certificate. A common mistake is deploying the root behind your client certificates when a different CA signed the server certificate. The two profiles must also target the same groups and the same Android Enterprise enrollment type.

Manufacturer differences

Samsung, Google Pixel, and other manufacturer builds label and arrange enterprise WiFi settings differently. Some show extra options, such as online certificate status checks. Use your own fleet's devices as the reference, not screenshots from another brand.

How do you work out which cause you have?

Start on the device, then confirm in the RADIUS logs. The pattern in the logs usually points to the cause.

Symptom	What RADIUS shows	Likely cause	First fix
No attempt reaches RADIUS	No request from the device	WiFi profile not applied, or SSID name mismatch	Check per-device profile status in Intune
Handshake stops after the server sends its certificate	TLS alert from the client, such as "unknown CA"	Wrong or missing trusted root, or domain mismatch	Deploy the server's root CA and correct RADIUS server names
Handshake completes the server side, then fails	No client certificate presented	SCEP or PKCS certificate missing or in the wrong profile	Confirm the certificate profile succeeded for that device
Certificate accepted, then rejected	Access-Reject after certificate validation	Identity mapping, revocation or policy rule	Check the certificate subject or SAN against the identity provider
Fails only on personally owned devices	No request, or no client certificate	SSID joined from the personal side	Deploy the profile to the work profile and stop manual joins

Read the failure on the device

In the Microsoft Intune admin center, open the device and check each configuration profile's status. A WiFi profile shown as pending or in error never reached the device. A certificate profile in error means SCEP (Simple Certificate Enrollment Protocol) or PKCS (Public Key Cryptography Standards) issuance failed. Fix that before you touch the network.

On lab devices, Android Debug Bridge logs from the WiFi supplicant show the exact TLS alert. Use this for a test handset, not for a production fleet.

Read the RADIUS logs

FreeRADIUS, Microsoft Network Policy Server, and cloud RADIUS platforms all record where the EAP exchange stopped. Search by the device's MAC address or certificate identity. A client-sent TLS alert means the phone rejected your server. An Access-Reject after a valid certificate means your server rejected the phone.

If devices authenticate and then drop as staff walk between floors, the cause is different. Read Resolving Roaming Issues in Corporate WLANs. Disconnects that line up with channel changes point to radar events instead. See DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

How do you fix it in Intune and on each Android build?

In Intune

1. Open the Android Enterprise WiFi profile that matches the enrollment type. Fully managed, dedicated and corporate-owned work profile devices use one profile type. Personally owned work profile devices use another.
2. Set the EAP type to EAP-TLS.
3. Enter the RADIUS server certificate's DNS name in RADIUS server names. The exact name from the certificate is the safest value. Never enter an IP address.
4. Select the trusted certificate profile that holds the server's root CA.
5. Select the SCEP or PKCS profile for client authentication.
6. Assign all three profiles to the same group.

On Samsung, Pixel and other builds

Do not ask staff to edit enterprise settings by hand on any brand. Manual changes bypass Intune and land on the wrong side of the work profile. If one manufacturer fails and another works, compare profile status first. Then test the domain value against that build in your lab.

On the RADIUS side

Confirm the server certificate carries the DNS name you entered in Intune. Confirm its chain leads to the root you deployed. If you use Purple Staff WiFi, Purple provides the cloud RADIUS service and connects to your access points over RadSec, RADIUS carried inside TLS. The vendor setup steps live in Purple's support articles, for example Staff WiFi - Ubiquiti UniFi. Check access point requirements in Security and Hardware Compatibility.

Worked scenarios

A 200-room hotel after an Android update

Consider a 200-room hotel with 60 corporate-owned handsets for housekeeping and maintenance. After a monthly update, 40 handsets stopped joining the staff SSID. The RADIUS logs showed client-sent TLS alerts.

The WiFi profile had no RADIUS server names value, which older builds had tolerated. The IT team added the server certificate's DNS name and redeployed the profile. All 60 handsets connected after their next Intune check-in, with no factory resets. Hotel operators can find more on staff connectivity on our Hotels page.

A 120-store retail chain with personal devices

Consider a 120-store retail chain with store managers on personal cell phones enrolled with a work profile. Helpdesk tickets showed that cell phones in many stores never reached RADIUS.

Managers had added the store SSID from personal settings, where no certificate exists. The team assigned the personally owned work profile WiFi profile and told managers to remove manual entries. Failed joins stopped once each cell phone received the managed profile.

A rail operator renewing its server certificate

Consider a train operator running staff WiFi on board and in depots (Trains). The operator renewed its RADIUS server certificate from a new issuing CA. Every Android device failed overnight with "unknown CA" alerts. Uploading the new root to the trusted certificate profile before the cut-over would have prevented the outage. The operator now stages root changes two weeks ahead.

How do you stop it happening again?

Rollout checklist for Android fleets in Intune and Entra ID

• Map identities. Decide whether certificates carry the device ID or the staff member's UPN, their Entra ID sign-in name. Configure RADIUS to match that field.
• Separate by enrollment type. Build one profile set for corporate-owned devices and one for personally owned work profile devices.
• Pair the profiles. The trusted root, client certificate and WiFi profiles must share an assignment group.
• Use the right root. Deploy the CA that signed the RADIUS server certificate.
• Fill RADIUS server names. Use the DNS name from the server certificate, never an IP address.
• Pilot across manufacturers. Test at least one Samsung and one Pixel handset, plus any other brand in your fleet.
• Ban manual joins. Tell staff never to add the SSID by hand.
• Stage certificate renewals. Push new roots before the server certificate changes.
• Watch both sides. Review Intune profile status and RADIUS rejects weekly during rollout.

For identity provider integration, see How to Enable Single Sign On.

Frequently asked questions

Does Purple Staff WiFi work with Android devices managed in Intune?

Yes. Purple Staff WiFi authenticates managed Android devices with certificate-based 802.1X against Purple's cloud RADIUS. You keep Intune for certificate and WiFi profile delivery. Purple connects to Microsoft Entra ID, Okta and Google Workspace for identity. Your Intune profiles point at the Purple RADIUS server certificate instead of an on-premises server. The Android-side rules in this guide still apply: a trusted root and a matching domain are required.

Do I need new access points to run EAP-TLS with Purple?

No. Purple is hardware-agnostic and works as a cloud overlay on access points you already run. Supported vendors include Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Each vendor needs a RADIUS configuration that points at Purple. The setup steps are in Purple's support articles. Check model-level requirements in the Security and Hardware Compatibility article before you start.

Can I move from on-premises NPS to cloud RADIUS without re-enrolling Android devices?

Yes, in most cases you can. Devices keep their existing client certificates if the new RADIUS service trusts your issuing CA. You update the trusted root profile and RADIUS server names in Intune to match the new server certificate. Stage those profile changes before you switch the SSID's RADIUS target. That prevents the overnight "unknown CA" failures described in this guide.

Is EAP-TLS better than PEAP or iPSK for staff devices?

Yes, for managed fleets. EAP-TLS uses a certificate per device or identity, so there are no shared passwords to leak. PEAP (Protected EAP) relies on a username and password inside a TLS tunnel. iPSK (identity pre-shared key) gives each device or group its own key. iPSK suits unmanaged devices that cannot hold certificates. EAP-TLS suits cell phones you manage through Intune.

What compliance standards does Purple meet for staff authentication data?

Purple is certified to ISO 27001 and Cyber Essentials, and complies with CCPA/CPRA. Certificate-based 802.1X supports the strong access control that PCI DSS expects on networks near cardholder data. Purple also holds B Corp certification. Ask your account team for current certificates if your procurement process requires copies.

How long does an Android EAP-TLS rollout take?

Expect most of the effort to go into PKI and Intune, not the access points. Pointing an SSID at Purple's RADIUS follows a short vendor checklist in the support center. Building SCEP or PKCS profiles, trusted root profiles and WiFi profiles for each enrollment type takes longer. Allow time for a pilot covering every manufacturer in your fleet before the wider deployment.