Certificates vs. passwords: how certificate-based Wi-Fi works

If you’ve decided to move away from a shared Wi-Fi password, the next question is how each device proves who it is. With enterprise Wi-Fi (802.1X) there are two common answers: a username and password, or a certificate.

Both are better than one shared password. But they are far from equal, and the difference matters for security, for user experience and for how much work your IT team ends up doing.

The three parts of enterprise Wi-Fi

Every 802.1X setup has the same three participants:

1. The device. A laptop or phone that wants to connect.

2. The access point. It doesn’t decide anything itself; it passes the question on.

3. The RADIUS server. It checks the device’s credentials and answers “yes”, “no”, or “yes, and put it on this network”.

The interesting part is what the device presents to the RADIUS server.

Option 1: Username and password (PEAP-MSCHAPv2)

The most common password-based method is called PEAP-MSCHAPv2. Users sign in to Wi-Fi with their normal account, and it feels familiar. But it brings along every weakness of passwords:

• Passwords can be phished. If devices aren’t strictly configured to verify the RADIUS server, an attacker can set up a fake access point with the same network name and collect sign-in attempts.

• The protocol is old. MSCHAPv2 was designed in the 1990s, and its cryptography is considered broken. Captured exchanges can be cracked.

• Password changes break Wi-Fi. When a user changes their password, saved Wi-Fi credentials stop working until they’re updated on every device.

• Windows is moving away from it. On newer Windows versions with Credential Guard enabled, Microsoft blocks saved-credential sign-in with MSCHAPv2. That has pushed many organizations to look at alternatives.

Option 2: Certificates (EAP-TLS)

With EAP-TLS, the device presents a certificate instead of a password.

A certificate works like a digital ID card. It states who the device (or user) is, and it is signed by a certificate authority (CA) that your RADIUS server trusts. The device keeps a matching private key that never leaves it. During the connection, the device proves it holds that key without ever sending it.

The verification also runs the other way: the device checks the RADIUS server’s certificate before connecting. This mutual authentication is what defeats fake access points.

What this gives you in practice:

• Nothing to phish. There’s no password for users to type, reveal or reuse.

• No user interaction. The device connects automatically. Password changes don’t affect Wi-Fi.

• Individual control. A lost laptop or a departing employee? Revoke that one certificate, and the device is out. Everyone else is unaffected.

• A clear audit trail. The RADIUS server knows exactly which device connected, and when.

• Built-in support. Windows, macOS, iOS and Android all support EAP-TLS natively, as do business-grade access points.

What you need for certificate-based Wi-Fi

Three building blocks:

1. A certificate authority (PKI). This issues certificates and can revoke them. It also publishes revocation status, typically through OCSP or a revocation list (CRL), so the RADIUS server can check whether a certificate is still valid.

2. A way to deliver certificates to devices. You don’t want to install certificates by hand. In Microsoft environments, Intune does it with a SCEP profile. Each device generates its own private key, and only a certificate request is sent to the CA, so the key never leaves the device. Intune also renews certificates automatically before they expire.

3. A RADIUS server that validates certificates. It checks that a certificate was issued by your CA and hasn’t been revoked. It can also decide which network (VLAN) the device belongs on.

Why this used to be hard

In a traditional Microsoft setup, those three building blocks meant:

• Active Directory Certificate Services for the certificate authority

• NDES plus the Intune Certificate Connector to deliver certificates via SCEP

• Network Policy Server (NPS) for RADIUS

That’s several servers to install, secure, patch, back up and make highly available. They also have to be published to the internet in a way your security team is comfortable with. And when the CA certificate quietly expires after a few years, Wi-Fi stops working for everyone at once.

For a small IT team, that was a lot of infrastructure to justify. It’s the main reason so many organizations stayed with shared passwords or PEAP.

What it looks like today

With Intune managing devices, all three building blocks can now run as cloud services:

• a cloud PKI that issues certificates through Intune’s SCEP profiles

• Intune delivering and renewing certificates automatically

• a cloud RADIUS service that your access points talk to directly

No servers, no connectors to keep alive, and no on-premises Active Directory required. Devices that are cloud-only (Entra ID-joined) work just as well as hybrid ones.

What this means for you

If you’re moving to enterprise Wi-Fi, go straight to certificates. Choosing passwords means building on a method that’s already being phased out. If you’re already on PEAP-MSCHAPv2, moving to EAP-TLS is mostly a matter of deploying certificates and updating the Wi-Fi profile in Intune. Users won’t notice, except that they no longer have to sign in.

How we solve this: EasyScep is a cloud PKI that plugs directly into Intune’s SCEP profiles, with a dedicated certificate authority for each customer. EasyRadius is the cloud RADIUS service that validates those certificates and puts each device on the right network. Both are available on Azure Marketplace, billed on your Azure invoice, and count toward an existing Azure consumption commitment (MACC).

Ready to set it up? See the EasyScep documentation.