Home About Tools Projects Guides & Blog ⚡ Hire Me ✦ Websites Contact →
📶 Intune

Configuring 802.1X Wi-Fi Authentication via Intune

Published 19 March 2026

Pre-shared key Wi-Fi is a liability in a corporate environment. One person shares the password, it gets texted to a contractor, screenshotted by a visitor, or just memorised by an ex-employee - and now anyone with that string can join your network. 802.1X solves this by authenticating the device (or the user) against a RADIUS server using a certificate, instead of a shared secret. There's no password to leak.

With 802.1X deployed via Intune, managed devices authenticate to the corporate SSID automatically using a SCEP-provisioned certificate - no user interaction, no password. Unmanaged devices can't connect at all.

How 802.1X Works

🧠 Concepts

The 802.1X authentication flow involves three components:

  • Supplicant - the Windows device (your Intune-managed laptop)
  • Authenticator - the wireless access point or switch
  • Authentication Server - a RADIUS server (NPS on Windows Server, or a cloud RADIUS like Cisco ISE, Aruba ClearPass, or Foxpass)

When a device tries to connect to the 802.1X SSID, the AP challenges it. The device presents its certificate to the RADIUS server via EAP-TLS. The RADIUS server checks the certificate against a trusted CA, and if valid, tells the AP to let the device connect. The device never sees a password prompt - it just connects.

ℹ️
EAP-TLS vs PEAP
This guide uses EAP-TLS (certificate-based, both sides authenticate with a cert). PEAP-MSCHAPv2 is an alternative that uses username/password inside a TLS tunnel - easier to set up but weaker. EAP-TLS is significantly more secure and is the recommended approach when you have Intune managing certificates via SCEP.

Prerequisites

📋 Before You Start

Before creating the Intune profiles, you need the following in place:

  • RADIUS server - either Windows Server NPS, or a cloud RADIUS service. The RADIUS server must be reachable from your APs over UDP 1812/1813.
  • A Certificate Authority (CA) - either an on-premises Windows CA (ADCS) or a cloud-based CA. Intune's SCEP connector needs to talk to the CA to issue device certificates.
  • Intune SCEP connector - if using on-premises ADCS, the Microsoft Intune Certificate Connector must be installed on a server that can reach your CA.
  • Trusted root CA certificate (.cer) - the root certificate of your CA, which you'll push to devices so they trust the RADIUS server cert.
  • RADIUS server certificate - the RADIUS server (NPS) needs its own certificate issued by the same CA.
⚠️
Cloud RADIUS is easier for Intune-only environments
If you don't have on-premises AD or Windows Server, cloud RADIUS services like Foxpass, JumpCloud RADIUS, or Microsoft Entra-based Network Access (currently in preview) are much simpler. They integrate directly with Entra ID and eliminate the need for an on-prem CA and SCEP connector. Worth evaluating before building out on-prem infrastructure.

Step 1 - Deploy Trusted Root Certificate

🔐 Certificates

Devices need to trust your CA before they'll accept a certificate issued by it. Push the root CA certificate to all targeted devices first - the Wi-Fi profile won't work if devices don't trust the cert chain.

  • Platform: Windows 10 and later
  • Profile type: Trusted certificate
🔐
Trusted Root Certificate Profile
Pushes your CA root certificate to device certificate stores
Certificate fileUpload your root CA .cer file here. Export it from your CA as a DER encoded binary.
CA-Root.cer
Destination storeWhere the certificate is placed on the device.
Computer certificate store - Root

Name this profile something like CORP-WiFi-TrustedRoot and assign it to the same device group you'll use for the Wi-Fi profile. It must deploy successfully before the Wi-Fi profile will authenticate correctly.

Step 2 - Create SCEP Certificate Profile

📜 SCEP

The SCEP profile tells Intune to request a unique client certificate from your CA for each device. This is the certificate the device presents to your RADIUS server to authenticate.

  • Platform: Windows 10 and later
  • Profile type: SCEP certificate
📜
SCEP Certificate Configuration
Issues a unique device certificate from your CA
Certificate typeDevice certificates authenticate the machine itself, regardless of which user is logged in. Preferred for Wi-Fi.
Device
Subject name formatCN={{DeviceId}} is common - creates a cert with the Intune device ID as the CN, making it easy to identify in the CA.
CN={{DeviceId}}
Subject alternative nameAdd DNS={{DeviceName}} to make certs easier to identify in NPS logs.
DNS = {{DeviceName}}
Certificate validity period1 year is standard. Intune will auto-renew before expiry.
1 year
Key storage provider (KSP)TPM stores the private key in hardware - it can't be exported. Highly recommended.
Enroll to TPM KSP if present
Key usageDigital Signature is required for EAP-TLS authentication.
Digital signature
Key size (bits)
2048
Hash algorithm
SHA-2
Root certificateSelect the Trusted Root profile you created in Step 1.
CORP-WiFi-TrustedRoot
Extended key usageClient Authentication (1.3.6.1.5.5.7.3.2) must be present for EAP-TLS.
Client Authentication
SCEP Server URLsThe URL(s) of your Intune Certificate Connector / SCEP server endpoint.
https://your-scep-server/certsrv/mscep/mscep.dll
Verify SCEP issuance before moving on
After assigning the SCEP profile to a test device, check that the certificate appears in the device's certificate store (certlm.msc → Personal → Certificates) before configuring the Wi-Fi profile. If the cert isn't there, the Wi-Fi profile will fail silently. Check the Intune device configuration status and the NDES/SCEP connector logs on the server.

Step 3 - Create the Wi-Fi Profile

📶 Wi-Fi Profile

With certificates in place, create the Wi-Fi profile that references them:

  • Platform: Windows 10 and later
  • Profile type: Wi-Fi
📶
Wi-Fi Profile - 802.1X Enterprise
Certificate-based enterprise Wi-Fi configuration
Wi-Fi type
Enterprise
Wi-Fi name (SSID)Must match your SSID exactly - case sensitive.
CORP-WiFi
Connection nameFriendly name shown in Windows network list.
Corporate Wi-Fi
Connect automatically when in range
Enabled
Connect to more preferred networks when available
Disabled
Security type
WPA2-Enterprise
EAP typeEAP-TLS uses certificate-based mutual authentication.
EAP-TLS
Certificate server namesThe CN or SAN of your RADIUS server certificate. Prevents devices connecting to rogue RADIUS servers.
radius.yourdomain.com
Root certificates for server validationSelect the Trusted Root profile - devices use this to validate the RADIUS cert.
CORP-WiFi-TrustedRoot
Authentication methodCertificate - select the SCEP profile created in Step 2.
Certificate
Client certificate for client authenticationSelect the SCEP certificate profile you created.
CORP-WiFi-SCEP
⚠️
Always specify the certificate server name
The Certificate server names field pins the RADIUS server's identity. Without it, a rogue RADIUS server could present any valid cert and your devices would connect to it - handing over credentials or being redirected. Always specify the FQDN or CN of your RADIUS server certificate here.

Step 4 - Assign and Verify

✅ Deployment

Assign all three profiles (Trusted Root, SCEP, Wi-Fi) to the same device group. Intune handles the dependency order automatically if you've linked the profiles correctly (SCEP → Trusted Root, Wi-Fi → SCEP), but deploy them together.

After a policy sync, verify the connection on a test device:

  1. 1
    Confirm the certificate was issued
    Open certlm.msc on the device → Personal → Certificates. You should see a certificate with the CN matching your SCEP subject name format, issued by your CA.
  2. 2
    Check the Wi-Fi profile applied
    Go to Settings → Network & Internet → Wi-Fi. The corporate SSID should appear in the list. If it's configured correctly it should connect automatically when in range.
  3. 3
    Check RADIUS / NPS event logs
    On your NPS server, open Event Viewer → Custom Views → Server Roles → Network Policy and Access Services. A successful EAP-TLS authentication shows as Event ID 6272. Failures show as 6273 with a reason code.
  4. 4
    Verify in Intune device configuration status
    In Intune, go to the Wi-Fi profile → Device and user check-in status. All three profiles should show Succeeded against the test device.
Common NPS failure reason codes
16 - Authentication failed (cert not trusted by RADIUS). Check your trusted root profile deployed correctly. 23 - The client certificate has expired or is not yet valid. 48 - Password change required (not applicable for EAP-TLS). 65 - EAP authentication failed - check your NPS network policy conditions match the certificate attributes being presented.
// monthly tips

Get M365 tips in your inbox

Practical Intune and Microsoft 365 tips, once a month. No spam, no fluff.