Blog
What happens to RADIUS when devices leave Active Directory?
Move devices from domain join to Entra join and, for many estates, the first thing to break is the office Wi-Fi. NPS and PEAP-MSCHAPv2 quietly depend on Active Directory computer accounts that Entra-joined devices simply do not have. Here is why it breaks, what actually fixes it, and why the network work has to come first.
Why NPS trusts the domain, and only the domain
The classic enterprise 802.1X stack is Windows Network Policy Server speaking RADIUS, with PEAP-MSCHAPv2 as the inner method. It works because everything on the network is domain joined: machine authentication validates the computer account's password against Active Directory, and user authentication validates a hash of the user's domain credentials. NPS is not really a network product at all; it is an Active Directory product that happens to speak RADIUS.
An Entra-joined device has no computer account in Active Directory. There is nothing for NPS to validate, so machine auth fails outright. User auth can limp on where accounts are synchronised from AD, but it was already living on borrowed time: Credential Guard, on by default since Windows 11 22H2 on Enterprise editions, blocks the credential access that PEAP-MSCHAPv2 single sign-on depends on. Microsoft's own guidance for that scenario is blunt: move to certificate-based authentication.
How it actually bites
The failure mode is cruelly well timed. Your Entra join pilot works beautifully for weeks, because pilot users are at home on their own broadband. Then someone brings a pilot device into the office. The Wi-Fi profile attempts machine auth, NPS logs “the specified user account does not exist”, and the device never gets an address. On wired networks with port-based NAC the same device drops to the guest VLAN at the desk, taking docking stations and peripherals with it. If Autopilot provisioning itself depends on that corporate SSID, new devices cannot even reach the internet to enrol.
NPS is not really a network product at all; it is an Active Directory product that happens to speak RADIUS.
To the service desk this presents as “the new laptops can't get on the Wi-Fi”, and it lands after the join change has shipped, when rollback is expensive and the project has an audience.
The honest options
There are three credible paths, and each has a trade-off worth naming.
EAP-TLS with Intune-issued certificates. This is the destination: Intune deploys SCEP or PKCS certificate profiles to every device, and the network authenticates the certificate rather than a password. No credentials on the wire, no Credential Guard conflict, and it works identically for Entra-joined and hybrid devices. The wrinkle is the RADIUS layer itself: NPS still tries to map the presented certificate to an AD object, which Entra-only devices do not have. Stub computer objects with explicit strong mappings can paper over this, but they are fragile at scale, and the strong certificate mapping enforcement Microsoft completed in February 2025 removed the lazier workarounds. Realistically, EAP-TLS for a cloud-native estate means a RADIUS platform that validates the certificate chain directly: Cisco ISE, Aruba ClearPass, FreeRADIUS, or a cloud service.
Cloud RADIUS services. Several vendors now terminate 802.1X in the cloud, validate Intune-issued certificates and check Entra device state as part of the decision. You retire NPS entirely and gain compliance-aware access control. The trade-offs: your switches and access points now depend on an internet path to authenticate anything, pricing is per user per month, and your network team inherits a black box they cannot packet-capture.
Microsoft Cloud PKI. Generally available since February 2024, as part of the Intune Suite or as a standalone add-on, Cloud PKI gives you Intune-hosted certificate authorities and removes the main historical objection to EAP-TLS: building and feeding an AD CS and NDES estate just to issue device certificates. Be clear about what it is, though. It issues and revokes certificates; it does not authenticate anyone. You still need a RADIUS layer that trusts its issuing CA.
Sequence the network before the join
The gotcha is not technical, it is sequencing. Network authentication gets discovered as a dependency during pilot, when it should have been closed off before the first device changed join type. The order that works: inventory every 802.1X touchpoint first, including Wi-Fi SSIDs, wired NAC policies and any VPN still authenticating through NPS. Stand up certificate issuance, whether Cloud PKI or your existing PKI with SCEP. Deploy EAP-TLS profiles to the current hybrid-joined estate and prove them while PEAP still works underneath as a safety net. Move RADIUS validation off computer-account lookups. Only then change the join type, knowing the network no longer cares what the device is joined to.
This is exactly the kind of dependency our discovery tooling exists to surface early: NPS policies, certificate templates and Wi-Fi profiles are all evidence, and they all predict this failure months before a user hits the office Wi-Fi. Found in discovery, it is a workstream. Found in pilot, it is an incident.
Planning a move to Entra join?
We map network authentication dependencies before the join change, so your users never find them on the office Wi-Fi.