There's a category of Intune problem where everything reports success and nothing works. Android Enterprise Wi-Fi with EAP-TLS is a reliable member of that category: the SCEP profile deploys, the certificate shows as issued, the Wi-Fi profile applies without error — and the device sits at "Saved" and never joins the network. Very often, the root cause is the certificate's subject alternative name (SAN) configuration. This is the hard-won lesson this guide exists to save you from learning in production.
The short version
When you build a SCEP (or PKCS) profile for Android Enterprise devices that will authenticate to Wi-Fi with EAP-TLS:
- Include an appropriate SAN in the certificate profile — for user-based authentication that means a User Principal Name (UPN) SAN carrying the user's UPN; for device certificates, a SAN your RADIUS server can actually evaluate, such as a DNS or URI entry with a stable device identifier.
- Make sure the identity the RADIUS server derives from the certificate matches what it expects. NPS maps the UPN SAN to an Active Directory account; cloud RADIUS services each document which fields they read.
- Don't rely on subject CN alone. A certificate with only a CN and no SAN may enrol perfectly and still fail authentication, because the components involved look for the identity in the SAN.
If your certificates were designed for Windows and "just worked" there, they may still be structurally wrong for the rest of your fleet — Windows tolerates configurations that Android and your RADIUS backend will not.
How Android selects and presents the client certificate
Understanding the failure modes requires knowing how Android handles certificates differently from Windows:
Certificates live in a managed keystore, accessed by alias. When Intune delivers a certificate to an Android Enterprise device, it lands in the work-profile or device keystore. The Wi-Fi configuration references it via the linkage you create in the Intune Wi-Fi profile — the "identity certificate" setting that points at your SCEP profile. There is no fallback discovery: if that linkage doesn't resolve to a usable certificate at connection time, the connection silently fails. This is why the Wi-Fi profile and SCEP profile must both be assigned to the same group and the certificate must be present before the Wi-Fi profile is evaluated.
The EAP identity matters separately from the certificate. EAP-TLS involves an outer identity string as well as the certificate itself. Depending on Android version, OEM, and the RADIUS server's policy, mismatches between the identity string and the certificate's identity fields can cause rejections that look inexplicable from the client side. Keeping the certificate's SAN aligned with the identity your RADIUS policy evaluates removes a whole class of these mismatches.
Older certificates aren't cleaned up aggressively. After re-enrolment or profile changes, stale certificates can linger in the keystore. If the Wi-Fi profile's linkage resolves to an expired or superseded certificate, you get authentication failures with a "valid" certificate visibly present — check issuance timestamps, not just presence.
Why the SAN specifically
On the server side, EAP-TLS authentication isn't just "does the client have a certificate from a trusted CA". The RADIUS server extracts an identity from the certificate and evaluates policy against it:
- NPS performs mapping of the certificate to an AD account, and the UPN SAN is the field it uses for user certificates. A certificate without a UPN SAN — or with a UPN that doesn't correspond to an account — fails authentication regardless of how trusted the chain is. On the NPS side this typically logs as event 6273 with a credentials-mismatch reason code, which sends admins hunting for password problems that don't exist.
- Cloud RADIUS services vary: some evaluate the CN, some the SAN, some let you choose. But the safe, portable configuration — the one that works across NPS, cloud services, and future migrations between them — is a certificate whose SAN carries a real, resolvable identity.
The trap is that Intune will happily issue whatever you configure. A SCEP profile with subject CN={{DeviceName}} and no SANs is valid configuration, produces valid certificates, and deploys with green ticks everywhere. Nothing in the issuance pipeline knows or cares that the resulting certificate is useless to your RADIUS policy.
User certificates vs device certificates
For user-targeted profiles, the standard answer is straightforward: add a SAN of type UPN with the {{UserPrincipalName}} variable. Add an email SAN too if any consuming system expects RFC 822 names. This gives NPS its account mapping and gives cloud services an unambiguous identity.
For device-targeted profiles (userless devices, kiosks, shared devices), it's messier because there's no UPN to map. Options include a DNS SAN or URI SAN populated with a device identifier variable, evaluated by a RADIUS policy that authenticates devices by certificate attributes rather than directory lookup. Be aware that Android's privacy hardening has progressively restricted access to hardware identifiers, so verify that whichever Intune variable you choose actually populates on your Android versions — issue a test certificate and decode it rather than trusting the profile preview. NPS's AD-account-mapping model fundamentally struggles with cloud-only device certificates; this is one of the pressures pushing organisations toward RADIUS servers that do certificate-attribute policy natively.
Common failure symptoms and what they mean
| Symptom | Likely cause |
|---|---|
| Network stuck at "Saved", never attempts or immediately drops | Wi-Fi profile's certificate linkage doesn't resolve — SCEP profile not assigned, cert not yet issued, or profiles reference mismatched cert |
| Authentication attempt visible on RADIUS, rejected with credential/account mismatch | Identity extraction failed — usually missing UPN SAN or UPN not matching an account |
| Rejected with untrusted-chain errors on the server | RADIUS server doesn't trust the issuing CA of the client cert — import the full chain server-side |
| Client distrusts the server certificate | Root CA for the RADIUS server cert not deployed to the device, or the Wi-Fi profile's server trust configuration doesn't match |
| Worked for months, broke for everyone at once | Server certificate expired, or the issuing CA for client certs rotated and the server wasn't updated |
| Works on Windows, fails on Android with identical profiles | Windows tolerating a subject-only certificate or performing selection Android won't — fix the SAN rather than chasing Android |
A verification checklist
Before blaming Android, verify each link in the chain:
- Decode an actually-issued certificate from a test device and confirm the SAN contains what you intended, with variables expanded to real values — not blank, not the literal variable name.
- Confirm the EKU includes Client Authentication (1.3.6.1.5.5.7.3.2).
- Confirm the RADIUS server trusts the client certificate's full chain, including any intermediates — a missing intermediate on the server side fails exactly like an untrusted client.
- Confirm the device trusts the RADIUS server's certificate chain, deployed via a trusted certificate profile, and that the Wi-Fi profile's server validation settings match the server certificate's actual name.
- Check the RADIUS server's logs, not the device — Android's client-side diagnostics for 802.1X are famously thin, and the server almost always knows exactly why it said no.
The overarching lesson generalises beyond Android: certificate issuance succeeding tells you nothing about certificate usability. Design the certificate contents from the RADIUS policy backwards — decide what identity the server will evaluate, then configure the SCEP profile to put exactly that in the SAN — and test the full authentication path on every platform before broad rollout.