Why EasyRadius Uses Certificate-Based Authentication (EAP-TLS)
A common question from organizations evaluating EasyRadius is: "Can we authenticate WiFi users against Entra ID using their username and password?"
The short answer is no — and this is a deliberate security decision, not a missing feature. This page explains the reasoning.
The problem with password-based WiFi authentication
Credential exposure and lateral movement risk
When a user authenticates to WiFi using their Entra ID credentials (via EAP-PEAP/MSCHAPv2), those credentials are passed through your RADIUS infrastructure for validation. In practice, this means a third-party system needs to relay or validate live domain credentials. If those credentials are intercepted or compromised at any point in that chain, the attacker does not just gain WiFi access — they gain access to Microsoft 365, Azure, and every other service tied to that identity. WiFi becomes a path to everything.
With certificate-based authentication, there are no reusable credentials in the authentication exchange. A device certificate proves the device is enrolled and trusted; no password is ever transmitted.
MSCHAPv2 is cryptographically broken
The protocol that underpins password-based WiFi authentication — MSCHAPv2 — has well-documented cryptographic weaknesses. It is vulnerable to offline dictionary attacks: an attacker who captures a single authentication handshake can attempt to crack the underlying password without any further interaction with the network. Microsoft themselves have acknowledged these weaknesses. Certificate-based authentication sidesteps this problem entirely — there is no password hash to capture and crack.
Passwords bypass your strongest identity controls
Entra ID's security value comes from Conditional Access policies and Multi-Factor Authentication. However, a WiFi connection cannot trigger an MFA prompt — authentication happens at the network layer before any user interface is involved. This means password-based WiFi authentication falls back to the weakest Entra ID authentication mode: username and password alone. You would be bypassing the security controls your organization relies on for every other resource.
Evil twin attacks and credential harvesting
With password-based WiFi, a user connecting to a rogue access point (an "evil twin") will typically just send their credentials to the attacker — they have no way to verify they are connecting to a legitimate network. With EAP-TLS, authentication is mutual: the client verifies the RADIUS server's certificate before completing the handshake. A rogue server cannot present a valid certificate, so the connection fails. No credentials are ever exposed.
This is also the core reason why the AirSnitch attack framework's most dangerous escalation path — building a rogue RADIUS/AP infrastructure to harvest credentials — does not work against EAP-TLS deployments.
Architectural and compliance reasons
Entra ID does not natively support RADIUS
Microsoft has deliberately moved away from cloud RADIUS integration. Network Policy Server (NPS), the traditional on-premises bridge between RADIUS and Active Directory, has no cloud-native equivalent in Entra ID. Any implementation that attempts to validate Entra ID passwords via RADIUS requires maintaining local password hashes or credential sync mechanisms — which introduces additional attack surface and operational complexity. This is not a path Microsoft recommends or supports for new deployments.
Zero Trust alignment
Microsoft's own Zero Trust guidance recommends certificate-based device authentication for network access. Devices should prove their identity and management state using a certificate issued through a trusted MDM pipeline (such as Microsoft Intune with SCEP) — not by relaying user passwords. This is exactly the model EasyRadius and EasyScep implement:
- EasyScep acts as your SCEP Certificate Authority, issuing certificates to enrolled devices through Intune
- EasyRadius validates those certificates when devices connect to your network
The device's certificate proves it is enrolled, compliant, and managed — without exposing any user credentials to the WiFi infrastructure.
Separation of concerns
WiFi authentication should answer one question: is this a trusted, managed device? A certificate issued through your MDM pipeline answers that question precisely. A password only answers whether someone knows a string of characters — it says nothing about the state of the device, whether it is enrolled, or whether it should be on your corporate network.
Summary
| Password-based (PEAP/MSCHAPv2) | Certificate-based (EAP-TLS) | |
|---|---|---|
| Entra ID credentials exposed to RADIUS | Yes | No |
| Vulnerable to offline cracking | Yes (MSCHAPv2) | No |
| Supports MFA | No | N/A — device identity, not user identity |
| Vulnerable to evil twin credential theft | Yes | No (mutual certificate validation) |
| Natively supported by Entra ID cloud | No | Yes (via Intune/SCEP) |
| Zero Trust aligned | No | Yes |
| Proves device is managed and enrolled | No | Yes |
EasyRadius uses EAP-TLS because it is the stronger, safer, and architecturally correct choice for enterprise network authentication. Combined with EasyScep for certificate issuance, it provides a complete, cloud-native, Zero Trust-aligned authentication infrastructure — without exposing your Entra ID credentials to any third party, including us.
For questions about certificate deployment and network authentication setup, see the Intune WiFi Setup guide or contact support@just-software.com.