Como configurar o WiFi corporativo em dispositivos Android com EAP-TLS

How to Set Up Enterprise WiFi on Android Devices with EAP-TLS A Purple Technical Briefing — Approximately 10 Minutes --- INTRODUCTION AND CONTEXT — approximately 1 minute Welcome to the Purple Technical Briefing series. I'm your host, and today we're getting into the specifics of deploying 802.1X EAP-TLS authentication on Android devices — whether you're managing a hotel estate, a retail chain, a stadium, or a public-sector campus. If you're responsible for a network that needs to authenticate corporate or BYOD Android devices without relying on shared passwords, this episode is for you. EAP-TLS is the gold standard for enterprise WiFi security — it uses mutual certificate-based authentication, which means no credentials to phish, no passwords to rotate, and a compliance posture that satisfies PCI DSS, ISO 27001, and most public-sector security frameworks. By the end of this briefing, you'll understand exactly how EAP-TLS works on Android, what your deployment options are, and the three most common mistakes that cause failed rollouts. Let's get into it. --- TECHNICAL DEEP-DIVE — approximately 5 minutes Let's start with the architecture. 802.1X is the IEEE standard that governs port-based network access control. When an Android device connects to an enterprise WiFi network — one configured as WPA2-Enterprise or WPA3-Enterprise — the access point acts as what's called an authenticator. It doesn't make the authentication decision itself; it passes the conversation between the device and a RADIUS server, which is the actual authentication server. EAP-TLS — that's Extensible Authentication Protocol with Transport Layer Security — is the authentication method running inside that 802.1X framework. What makes it different from EAP-PEAP or EAP-TTLS, which use username and password inside a TLS tunnel, is that EAP-TLS uses X.509 certificates on both sides. The RADIUS server presents a server certificate to the device, and the device presents a client certificate back to the RADIUS server. Both parties validate each other. That's mutual authentication, and it's what makes EAP-TLS the most secure option available. Now, on Android specifically, there are a few things you need to understand. Android 11 and later introduced stricter certificate validation requirements. If you're deploying on Android 11 or above — which at this point is the vast majority of your estate — the device will refuse to connect unless the RADIUS server certificate is explicitly trusted. You cannot rely on the system trust store alone; you must either push the root CA certificate to the device or configure the WiFi profile to explicitly reference it. Let's talk about the certificate chain. You need three components in place before a single Android device can authenticate via EAP-TLS. First, a Certificate Authority — either your internal PKI, Microsoft Active Directory Certificate Services, or a cloud PKI like SCEP via Intune. Second, a server certificate issued to your RADIUS server, signed by that CA. Third, a unique client certificate issued to each device or user, also signed by the same CA. The device presents its client certificate during the TLS handshake, and the RADIUS server validates it against the CA's certificate revocation list, or CRL, or via OCSP — Online Certificate Status Protocol. For Android, the client certificate and private key are typically packaged as a PKCS12 file — that's a dot-P12 or dot-PFX file — which contains both the certificate and the encrypted private key. On a manually configured device, the user imports this file through Settings, then Security, then Install a Certificate. On an MDM-managed device, the certificate is silently pushed to the device's managed keystore — no user interaction required. Now let's talk about the WiFi profile itself. When configuring an enterprise WiFi connection on Android, you need to specify: the SSID, the security type — WPA2-Enterprise or WPA3-Enterprise — the EAP method — which is TLS — the CA certificate for server validation, the client certificate for device authentication, and the identity string, which is typically the device's Common Name or the user's UPN. On Android 11 and above, you also need to specify the domain suffix match or the server certificate subject to prevent man-in-the-middle attacks. For MDM deployments — and this is where the real scale comes in — you're pushing all of this as a structured configuration profile. In Microsoft Intune, you create a SCEP certificate profile that automatically requests and installs a unique client certificate on each enrolled Android device. You then create a WiFi configuration profile that references that certificate profile. When the device checks in, it receives both the certificate and the WiFi profile, and it connects to your 802.1X network automatically. No user interaction, no support calls. If you're using Intune for this, our companion guide on how to use Microsoft Intune to push WiFi certificates to devices walks through the exact configuration steps — I'd recommend reading that alongside this briefing. For VMware Workspace ONE and Jamf Connect, the process is architecturally identical — SCEP or PKCS certificate profile, followed by a WiFi profile that references it. The specific UI differs, but the certificate chain and RADIUS configuration requirements are the same. One thing worth flagging on the RADIUS side: if you're running FreeRADIUS, Microsoft NPS, or Cisco ISE, make sure your server certificate includes the correct Extended Key Usage attributes — specifically, Server Authentication, OID 1.3.6.1.5.5.7.3.1. Android is strict about this. A certificate that works fine with Windows clients may fail on Android if the EKU is missing or misconfigured. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes Right, let's talk about what actually goes wrong in the field, because this is where most deployments hit trouble. The first and most common failure is certificate trust. Android 11 and above will not connect if the RADIUS server's certificate chain cannot be validated. The fix is straightforward: push your root CA certificate to the device's user certificate store via MDM, and explicitly reference it in the WiFi profile's CA certificate field. Do not leave this as "Do not validate" — that's a security hole and it will fail on some Android versions anyway. The second pitfall is certificate expiry. Client certificates typically have a one- to two-year validity period. If you don't have automated renewal in place via SCEP or NDES, you will wake up one morning to find that half your device estate has lost WiFi access simultaneously. Build certificate renewal automation into your MDM workflow from day one, not as an afterthought. The third issue is RADIUS server capacity. EAP-TLS handshakes are computationally more expensive than PEAP handshakes because of the full mutual certificate exchange. At a stadium or conference centre with thousands of simultaneous authentications, an undersized RADIUS server will become a bottleneck. Size your RADIUS infrastructure for peak concurrent authentications, not average load. Finally, on the Android side, be aware that different manufacturers — Samsung, Google, Xiaomi — have slightly different implementations of the WiFi configuration API. Test your MDM-pushed profiles on representative devices from each manufacturer in your estate before rolling out at scale. Samsung devices in particular have historically required the identity field to be explicitly set, even when it can be inferred from the certificate. --- RAPID-FIRE Q AND A — approximately 1 minute A few quick questions I get asked regularly. Can I use EAP-TLS for BYOD devices? Yes, but it requires the user to install a client certificate on their personal device. For BYOD at scale, consider whether EAP-TTLS with PAP or PEAP-MSCHAPv2 is a more practical trade-off, with EAP-TLS reserved for corporate-owned devices. Does EAP-TLS work with WPA3-Enterprise? Yes, and WPA3-Enterprise with 192-bit mode actually mandates EAP-TLS. If you're deploying WPA3-Enterprise in high-security environments, EAP-TLS is your only compliant option. What's the minimum Android version I should target? Android 8 and above supports EAP-TLS natively. For Android 11 and above, enforce explicit CA certificate validation. For Android 13 and above, you can leverage the improved certificate management APIs for more granular control. Can Purple's platform integrate with EAP-TLS networks? Purple's guest WiFi and analytics platform operates on a separate SSID from your 802.1X corporate network. Your corporate devices authenticate via EAP-TLS on the secure SSID, while guest devices use Purple's captive portal on the guest SSID. The two coexist on the same access point infrastructure, with VLAN separation providing the security boundary. --- SUMMARY AND NEXT STEPS — approximately 1 minute To wrap up: EAP-TLS on Android is the most secure enterprise WiFi authentication method available, and with modern MDM tooling it's entirely practical to deploy at scale. The three things to get right are: a properly configured PKI with automated certificate renewal, explicit CA certificate trust on Android 11 and above, and a RADIUS infrastructure sized for peak load. If you're deploying at a venue with mixed corporate and guest traffic, Purple's platform gives you the analytics and engagement layer on the guest network while your EAP-TLS infrastructure secures the corporate side. The two complement each other well. For your next steps: review our architecture diagram in the full guide, work through the Intune deployment walkthrough, and run a pilot on a subset of devices before rolling out to your full estate. Start with a controlled group of fifty devices, validate certificate delivery and WiFi connectivity, then scale with confidence. Thanks for listening to the Purple Technical Briefing. You'll find the full written guide, diagrams, and configuration references at purple.ai. Until next time.