Cloud RADIUS and 802.1X: network authentication without NPS

For twenty years, the default answer to "how do we do secure Wi-Fi authentication?" was Windows NPS talking to Active Directory. That default is quietly collapsing — not because NPS stopped working, but because the assumptions it's built on (domain-joined machines, on-prem AD, passwords as network credentials) no longer describe most estates. This guide covers how 802.1X actually works, why NPS is being retired from so many environments, what the replacement landscape looks like, and why nearly every road leads to certificate authentication.

802.1X in five minutes

802.1X is a port-level access control standard: nothing gets past the switch port or wireless association until the connecting device proves who it is. Three roles are involved:

• The supplicant — the client device (or rather, the 802.1X software on it, built into every modern OS).
• The authenticator — the switch or wireless access point/controller. It doesn't verify anything itself; it just relays the conversation and enforces the verdict.
• The authentication server — a RADIUS server, which does the actual verification and tells the authenticator to allow or deny (and often which VLAN to assign).

The conversation between supplicant and authentication server runs over EAP (Extensible Authentication Protocol), a framework with pluggable methods. The methods you'll actually encounter:

• PEAP-MSCHAPv2 — a TLS tunnel to the server, inside which the client proves knowledge of a password using MSCHAPv2. The long-time enterprise default, and the source of most of 802.1X's bad reputation: MSCHAPv2 is cryptographically weak by modern standards, the whole scheme collapses if clients don't strictly validate the server certificate (enabling evil-twin credential harvesting), and it needs a backend that can process MSCHAPv2 — in practice, Active Directory with NTLM-era hash storage. Cloud-only identities can't do it at all: there's no MSCHAPv2 against Entra ID.
• EAP-TLS — mutual certificate authentication. The client proves identity with a certificate and private key; the server proves its identity with its own certificate. No passwords on the wire or anywhere near the wire, phishing-resistant, and independent of any password backend. It requires getting certificates onto devices — which is exactly what MDM-driven certificate deployment (SCEP profiles in Intune and equivalents) has made routine.
• EAP-TTLS/PAP and others exist and have niches, but for a managed fleet the realistic decision is "EAP-TLS, and how fast can we get there".

Why NPS is being retired from so many estates

NPS (Network Policy Server) is Windows Server's RADIUS implementation. It's free with the OS, battle-tested, and deeply wired to Active Directory. That last property is now the problem:

• The AD dependency cuts both ways. NPS authenticates against AD. If your devices are Entra-joined with cloud-only identities, there's no AD computer or user object to authenticate — password-based 802.1X simply has no path. Even for EAP-TLS, NPS's model maps certificates to AD accounts, which gets awkward to impossible for cloud-only users and devices.
• It drags on-prem infrastructure behind it. Keeping NPS means keeping domain controllers, Windows Server licensing, patching, and — since RADIUS is availability-critical (RADIUS down means Wi-Fi down) — at least two of everything across sites or with careful network reachability from every authenticator.
• It's a maintenance-mode product. NPS receives little investment. Operational gaps that were tolerable in 2010 — thin logging you have to parse out of the event log, no modern dashboard, RADIUS shared secrets managed by hand per network device — feel increasingly out of step.
• The strategic direction is away from it. Organisations decommissioning AD as part of cloud migration find NPS is one of the last workloads chaining them to domain controllers. For many, the RADIUS migration is the AD exit project's critical path.

None of this means NPS is wrong for you today. A hybrid estate with healthy AD, domain-joined Windows devices, and staff who know NPS can keep running it — ideally having already moved from PEAP-MSCHAPv2 to EAP-TLS. The retirement pressure applies to estates going cloud-only, and to teams who'd rather not own RADIUS servers at all.

The options landscape

Keep NPS (or stand it up) — DIY on Windows. Cheapest on licensing, most expensive on operations. Makes sense when AD is staying anyway and you have the skills in-house. Plan for redundancy, certificate lifecycle on the server side, and honest log analysis capability.

DIY FreeRADIUS (or Radiator, etc.). FreeRADIUS is enormously capable and free, with none of NPS's AD assumptions — it does certificate-attribute-based EAP-TLS policy natively. The cost is expertise: configuration is famously unforgiving, and you own availability, upgrades, and security. A good fit for teams with Linux operations maturity and specific policy needs; a poor fit for a two-person IT team.

RADIUS-as-a-service. A now-established category of cloud-hosted RADIUS offerings — vendors include EasyRadius, RadSec-based offerings from Wi-Fi vendors, and several MDM-adjacent services — where the provider runs the RADIUS infrastructure and you point your access points at their endpoints. These services are typically built EAP-TLS-first, integrate with MDM certificate deployment, and handle the availability problem for you. Things to scrutinise when evaluating the category: how authenticator-to-service transport is secured across the internet (RadSec/TLS versus plain RADIUS to a public endpoint), latency and what happens during a WAN outage (802.1X requires the RADIUS server to be reachable — some sites want a local proxy or survivability story), how the service validates certificates and expresses policy, and per-device or per-user pricing at your scale.

Wi-Fi vendor built-ins. Some wireless vendors offer embedded or cloud-attached authentication tied to their ecosystem. Convenient if you're single-vendor; evaluate the lock-in consciously.

There's no first-party Microsoft cloud RADIUS service to point at — Entra ID does not speak RADIUS. Microsoft's adjacent answer for wired/wireless is NPS on-prem or partner solutions; this is one of the few areas of the Microsoft-centric stack where a third party or DIY is structurally required.

Don't forget wired, and don't forget availability

Two considerations that get skipped in Wi-Fi-centric planning. First, wired ports speak 802.1X too, and the same RADIUS backend can secure them — meeting-room wall ports and desk drops are otherwise an unauthenticated path onto the network that all the wireless work does nothing about. If you're rebuilding RADIUS anyway, scope wired in from the start; the marginal cost is switch configuration, not new infrastructure.

Second, RADIUS availability is network availability. When the authentication server is unreachable, new connections fail — existing sessions typically survive until reauthentication, which softens but doesn't remove the problem. Whatever option you pick, interrogate its failure story: for DIY, that means at least two servers and authenticators configured with both; for cloud services, it means multiple service endpoints, an understanding of behaviour during your internet outage (not theirs), and knowing what your switches and APs do when all configured servers time out. Deciding the failure posture — fail closed for security, or a limited fail-open VLAN for continuity — is a business decision worth making explicitly, in daylight, rather than discovering during an outage.

EAP-TLS as the end state

Whichever server you choose, the method decision has effectively been made for you. Password-based 802.1X is dying of three separate causes: MSCHAPv2's cryptographic weakness, its incompatibility with cloud-only identity, and the industry-wide push to phishing-resistant authentication. EAP-TLS solves all three, and its historical blocker — getting certificates onto devices — is solved by MDM. The modern reference architecture is:

1. MDM deploys client certificates via SCEP (from ADCS/NDES, Microsoft Cloud PKI, or a cloud SCEP service) with subject and SAN contents designed around what the RADIUS policy will evaluate.
2. MDM deploys the trust anchors and the Wi-Fi profile, including strict server certificate validation — the setting that makes evil-twin attacks fail.
3. RADIUS validates the client chain and identity and returns the access decision, ideally with VLAN/role assignment for segmentation.

Sequencing matters when you migrate: run the new SSID or the new RADIUS backend in parallel with the old one, move a pilot group, watch the server-side logs (they, not the clients, tell you why failures happen — see troubleshooting EAP-TLS failures), then move the fleet and finally retire the password-based SSID. The certificate deployment should be complete and verified — decode real issued certificates, check renewal works — before the first user's Wi-Fi depends on it.

The honest summary: 802.1X with EAP-TLS is the strongest network authentication most organisations will ever deploy, the pieces are all commodity now, and the main decisions left are who runs your RADIUS and who runs your CA. Both have good answers at every point on the build-versus-buy spectrum; what's no longer defensible is new deployments of password-based Wi-Fi authentication.