Entra ID + RADIUS: Authenticating WiFi Users Without On-Prem AD

The Problem: Entra-First Orgs Hit a RADIUS Wall

Most enterprises have already cut the cord on on-prem Active Directory for SaaS. Microsoft 365, Azure, and a growing share of internal apps now authenticate against Microsoft Entra ID (formerly Azure AD). Then someone tries to lock down the corporate WiFi with 802.1X and discovers a problem nobody warned them about: Entra ID has no RADIUS endpoint.

The protocol mismatch is fundamental. RADIUS (RFC 2865) is a UDP-based AAA protocol designed in the 1990s for dial-up and VPN. Entra ID is a modern cloud identity provider that speaks SAML, OIDC, and OAuth2 — protocols that browsers and SaaS apps use, not access points and switches. Microsoft has never shipped a first-party "Entra-to-RADIUS" service. WiFi access points still expect RADIUS, so something has to bridge the gap.

This article walks through the three approaches Microsoft customers actually use, explains why EAP-TLS with certificates is the recommended path with Entra, and shows what an end-to-end deployment looks like. If you came here because you Googled "Entra ID RADIUS" or "Azure AD WiFi 802.1X" and got mostly forum posts, this is the missing piece.

Why 802.1X Still Matters for WiFi

Before the options: a refresher on what's at stake. 802.1X is the IEEE port-based authentication framework that turns a WiFi association into an identity event. The access point asks "who are you?" before letting traffic flow, the supplicant on the device responds inside an EAP (Extensible Authentication Protocol, RFC 3748) exchange, and a RADIUS server adjudicates the answer. Without 802.1X, the AP either uses a shared WPA2-Personal pre-shared key (one secret for everyone) or no encryption at all.

For an enterprise on Entra ID, 802.1X provides three things a PSK can't:

• Per-user identity at the WiFi association. Logs name the person, not the device or the SSID.
• Group-based policy at the network layer. The Entra group "Finance" can be assigned to a specific VLAN, bandwidth tier, or ACL — no firewall change required.
• Instant deprovisioning. When HR offboards an employee in Entra, WiFi access stops. With a PSK, the secret has to be rotated across every device.

This is why every Microsoft customer eventually wants Entra ID and 802.1X to talk to each other. The question is how.

Approach 1: Entra Domain Services + NPS in Azure

The closest thing to a Microsoft-native answer: spin up Microsoft Entra Domain Services, a managed Active Directory that synchronizes from Entra ID, then deploy Network Policy Server (NPS) on a Windows Server VM joined to that domain. NPS is Microsoft's RADIUS implementation, and it has spoken RADIUS for two decades.

This works. But it reintroduces almost everything you cut on-prem AD to escape:

• Two paid Azure resources (Entra Domain Services + a Windows Server VM, ideally a redundant pair behind a load balancer).
• Patch cycles for Windows Server, regular reboots, Group Policy hygiene.
• NTLM hash storage in the managed AD — a known credential-theft target with its own MITRE ATT&CK technique (T1550.002).
• Manual cert enrollment via AD Certificate Services if you want EAP-TLS, since NPS does not natively integrate with Intune SCEP.

Reasonable choice for a shop that has deep AD operations expertise and is genuinely lifting-and-shifting that workload. For most Entra-first organizations, it trades one set of problems for another.

Approach 2: NPS Extension for MFA

If you still have on-prem Active Directory and just want Entra MFA gating WiFi, the NPS Extension for Azure AD Multi-Factor Authentication bolts onto an existing NPS server and triggers an MFA challenge after the primary RADIUS authentication succeeds.

Two limitations make this a transitional solution rather than a destination:

• It still requires on-prem AD. NPS itself authenticates against AD; the extension only adds MFA on top. No path here for an org that has fully retired AD.
• MFA on every WiFi association is friction users will not tolerate. Microsoft's own guidance is to scope it narrowly. Once you scope it, you have a partial-coverage solution that auditors don't love either.

Approach 3: Cloud RADIUS + Intune SCEP + Entra Group Sync (Recommended)

The modern path, and the one most Entra-first organizations land on, replaces NPS entirely with a cloud RADIUS service that integrates directly with Entra ID and Microsoft Intune. Authentication is certificate-based EAP-TLS (RFC 5216), not PEAP. There is no Windows Server, no NTLM hash store, no domain controller.

The architecture has three components:

1. Entra ID remains the source of truth for users, groups, and conditional access. It does not handle the RADIUS exchange itself.
2. Microsoft Intune issues X.509 device certificates via SCEP (or PKCS) to every managed Windows, macOS, iOS, iPadOS, Android, and ChromeOS device. The certificates are bound to the user or device identity in Entra and renew automatically.
3. Cloud RADIUS trusts the same certificate authority, terminates the 802.1X EAP-TLS handshake, and applies policy based on Entra group membership synced via SCIM or graph API.

From the user's perspective, joining the WiFi looks like nothing — the device presents its certificate silently, the connection is encrypted, and the Entra group determines which VLAN, bandwidth, and ACL apply. From the security team's perspective, every authentication is logged with a real identity and is revocable in seconds via Intune.

EAP Method Choice: Why EAP-TLS Wins With Entra

EAP is the umbrella protocol; the actual cryptographic dance happens inside an EAP method. Two are relevant to Entra customers:

EAP-TLS (Recommended)

The device presents an X.509 certificate, the RADIUS server validates it against the trusted CA, and a TLS-protected tunnel establishes the session keys. There is no password anywhere in the exchange. EAP-TLS is the only method on this list that is phishing-resistant by design, satisfies the CISA guidance on phishing-resistant MFA, and works without any password hash store on the RADIUS side. With Intune SCEP issuing the certificates and a cloud RADIUS validating them, every piece of the chain is cloud-native.

PEAP-MSCHAPv2 (Legacy, problematic with Entra)

PEAP wraps an inner MSCHAPv2 password challenge inside a TLS tunnel. The RADIUS server has to verify a hash of the user's password — historically, an NT hash retrieved from Active Directory. Microsoft Entra ID does not store NT hashes, which means a RADIUS server pointed at Entra cannot validate a PEAP-MSCHAPv2 attempt. The only way to make PEAP work with Entra is to deploy Entra Domain Services for the AD-style hash store, which puts you back in Approach 1.

PEAP also breaks with conditional access in a frustrating way: the RADIUS exchange has no browser, so it can't satisfy MFA prompts, device compliance checks, or risk-based session controls that conditional access policies expect. Certificate-based EAP-TLS sidesteps this by carrying the device identity (and therefore the Intune compliance state) inside the certificate itself.

For a deeper technical comparison, see our breakdown of EAP-TLS, PEAP, and EAP-TTLS.

The Three Approaches Compared

Dimension	Entra Domain Services + NPS	NPS Extension for MFA	Cloud RADIUS + Intune SCEP
Requires on-prem AD?	No (managed AD in Azure)	Yes	No
Requires Windows Server?	Yes (NPS VM)	Yes (existing NPS)	No
Authentication method	PEAP or EAP-TLS	PEAP + MFA prompt	EAP-TLS (cert-based)
MFA support	Manual via NPS extension	Native (purpose-built)	Implicit via cert + device compliance
Phishing-resistant?	Only if EAP-TLS configured	No (PEAP base)	Yes
Time to deploy	Days to weeks	1–2 days	30–60 minutes
Ongoing operations	Patch Windows + AD	Patch Windows + AD	None (SaaS)
Cert lifecycle	Manual (AD CS)	Manual (AD CS)	Automatic via Intune SCEP

Cloud RADIUS plus Intune SCEP is the only column where every row is "modern." It also happens to be the cheapest at scale — there are no Windows Server licenses to renew and no Azure VMs running 24/7 just to terminate RADIUS.

How Deployment Actually Works

Assuming Entra ID and Intune are already in place — most enterprises evaluating this article will have both — the working deployment for cloud RADIUS plus EAP-TLS takes four steps and roughly an hour for a pilot SSID.

1. Connect cloud RADIUS to Entra ID

An OAuth flow (admin consent in Entra) authorizes the cloud RADIUS service to read users, groups, and group memberships from Microsoft Graph. No service principal credentials get stored on disk anywhere. Group changes in Entra propagate to RADIUS policy on the next authentication, not on a sync schedule.

2. Configure Intune SCEP profile

In Intune, create a SCEP certificate profile pointing at the cloud RADIUS-managed CA, scoped to the device groups that need WiFi access. Intune pushes the cert to Windows, macOS, iOS, iPadOS, and Android Enterprise devices automatically. Enrollment is silent; the user never sees a prompt. See our SCEP integration overview for the exact field mappings.

3. Configure the WiFi SSID

On any RADIUS-capable access point — Cisco, Meraki, Aruba, Ruckus, Ubiquiti UniFi, Fortinet, Juniper Mist, Cambium, Extreme, TP-Link Omada, MikroTik, EnGenius — create a WPA2-Enterprise (or WPA3-Enterprise) SSID with the cloud RADIUS server as the auth target. Specify the shared secret and EAP-TLS as the method. Existing AP hardware does not need replacement; this is a config change, not a refresh. Vendor-specific guides: Cisco, Meraki, Aruba, Fortinet, Ubiquiti, Juniper Mist.

4. Map Entra groups to network policy

In the cloud RADIUS console, create conditional access policies that key on Entra group membership: "Finance" → VLAN 20, 100 Mbps, business hours only; "Contractors" → VLAN 30, internet-only, 30-day expiry; "Servers" → VLAN 10, no time restriction. Policy lives at the identity layer, not in firewall rules.

From a pilot device, joining the SSID is now silent: certificate gets presented, RADIUS validates it against the Intune-trusted CA, group lookup happens against Entra, VLAN gets assigned. No password ever entered.

Migrating From Microsoft NPS Without Downtime

For organizations already running NPS for WiFi, the safe migration pattern is parallel rollout with a pilot SSID:

1. Stand up cloud RADIUS as a secondary auth target — no traffic yet.
2. Create a new SSID (e.g., corp-wifi-cert) pointing at cloud RADIUS only, broadcast on a small subset of APs.
3. Push the SCEP profile to a pilot device group via Intune. Confirm cert-based authentication works end to end.
4. Validate that conditional access policies apply correctly: VLAN assignment, bandwidth, time windows.
5. Expand the pilot SSID to all APs once confidence is high. Cert enrollment continues in the background for the rest of the fleet.
6. Cut over the production SSID's RADIUS target from NPS to cloud RADIUS during a maintenance window. Decommission the NPS VMs after a soak period (typically two weeks).

Most production fleets complete this migration in one to three weeks. The rate-limiting step is certificate enrollment across devices, not the RADIUS layer itself. Devices that are offline during the SCEP push pick up the cert on next check-in. For a longer migration playbook covering PSK-to-802.1X (which is harder than NPS-to-cloud-RADIUS), see our PSK migration guide.

What About Guests and Unmanaged Devices?

Cloud RADIUS plus EAP-TLS handles managed corporate devices. Guests, contractors, and BYOD that aren't in Intune need a different path:

• Guests: a captive portal on a separate SSID, with social, SMS, or sponsor sign-in. Entra group membership doesn't apply because guests aren't in Entra.
• Contractors with Entra B2B accounts: issue a short-lived certificate via a self-service enrollment portal that authenticates against the contractor's Entra B2B identity.
• BYOD employees: same enrollment portal, scoped to a "BYOD" Entra group with restrictive conditional access (no privileged VLANs).
• IoT devices and printers: covered by MAC-based RADIUS authentication or device-specific certificates issued by the cloud PKI directly.

The point is that the cloud RADIUS layer handles all of these consistently — no separate guest server, no second authentication backend.

Frequently Asked Questions

Can Microsoft Entra ID act as a RADIUS server for WiFi 802.1X?

No. Entra ID is an identity provider that speaks SAML, OIDC, and OAuth2 — not RADIUS. To authenticate WiFi users against Entra over 802.1X, you need a separate RADIUS layer. The two practical paths are cloud RADIUS validating Intune-issued certificates (recommended) or Microsoft NPS running on Windows Server joined to Entra Domain Services (legacy).

How do you do 802.1X WiFi without on-prem Active Directory?

Three steps: (1) issue X.509 device certificates via Intune SCEP to every managed device; (2) point a cloud RADIUS service at the Intune-trusted CA so it validates certificates on every WiFi association; (3) sync user groups from Entra ID into the cloud RADIUS policy engine so VLAN and access rules follow group membership. Authentication is fully passwordless EAP-TLS.

What is the difference between Entra ID and Entra Domain Services?

Entra ID is the cloud identity provider for SaaS, web, and modern apps (SAML, OIDC, OAuth2). Entra Domain Services is a separate, paid managed Active Directory in Azure that supports legacy LDAP, Kerberos, NTLM, and domain-join. Entra ID alone cannot back NPS via PEAP-MSCHAPv2 because it has no NTLM hashes; Entra Domain Services can, at the cost of running another directory.

Why does PEAP-MSCHAPv2 not work with Entra ID?

PEAP-MSCHAPv2 requires the RADIUS server to verify an NT hash of the user's password. Entra ID does not store or expose NT hashes, so MSCHAPv2 cannot validate against Entra directly. The fixes are deploying Entra Domain Services (which does store the hashes) or migrating to certificate-based EAP-TLS where no password is ever exchanged.

What replaces Microsoft NPS for WiFi authentication?

Cloud RADIUS that integrates directly with Entra ID and Intune. It terminates 802.1X EAP-TLS, validates Intune-issued certificates, and applies group-based policy from Entra — with no Windows Server to patch, no domain controllers, no NPS extensions. Most NPS migrations finish in one to three weeks via parallel rollout.

The Bottom Line

Microsoft Entra ID is one of the best cloud identity providers ever built — for SaaS. For WiFi 802.1X, it leaves a gap that Microsoft has never closed natively. The legacy answer is Entra Domain Services plus NPS, which reintroduces every operational cost on-prem AD imposed. The modern answer is cloud RADIUS validating Intune-issued certificates, with Entra group sync driving network policy.

Certificates replace passwords, so the entire MSCHAPv2 attack class disappears. EAP-TLS is phishing-resistant by construction, so conditional access policies stay coherent. Cloud RADIUS is a SaaS commitment, not a Windows Server one. And the deployment fits in an afternoon — assuming Entra ID and Intune are already in place, which for most readers of this article they are.

If your network is still authenticating against NPS, a domain controller, or a shared PSK, this is the migration to put on next quarter's roadmap. The longer the legacy stack sits in place, the more expensive replacing it gets.