A new SSID profile sits in Intune as Succeeded, but the laptop never offers that network. Or it shows Pending for a day. Or the profile is there, Windows tries EAP-TLS, and authentication fails. The usual first moves are to delete and recreate the Wi-Fi profile, force a sync, or rebuild the certificate infrastructure.
Hold off. A Wi-Fi profile is a short chain: assignment → check-in → profile XML on the device → certificate (if EAP needs one) → WLAN AutoConfig → RADIUS. Most "Wi-Fi not applying" tickets break in the first three steps, not at the access point. This post walks the chain in order. Every step below only reads until the change table at the end.
If the symptom is a missing client certificate with a SCEP/Cloud PKI profile in Error or Pending, stop here and use the SCEP certificate profile triage first. This article assumes you are debugging the Wi-Fi configuration profile itself.
TL;DR
- User vs device assignment decides when the profile arrives and which certificate store EAP can use. A user-targeted Wi-Fi profile that expects a device (Local Computer) certificate will never authenticate cleanly.
- Portal Succeeded only means Intune delivered the CSP. It does not mean Windows connected, or that RADIUS accepted the client.
- For EAP-TLS / EAP-TTLS, confirm the client certificate is in the store the profile's identity expects before you chase SSID or AP settings.
- On the device, read WLAN AutoConfig Operational events and
netsh wlan show profiles/show interfacesbefore recreating anything in Intune. - If the device has not checked in, fix sync first (Company Portal triage).
Where in the chain did it break?
| Step | What happens | Typical symptom when it breaks |
|---|---|---|
| 1. Assignment | Intune targets users and/or devices with the Wi-Fi configuration profile | Pending forever; Succeeded on lab devices only; filter/group excludes the user |
| 2. Check-in | Device pulls policy over MDM | No recent sync; other profiles also Pending |
| 3. Profile install | Windows installs the WLAN profile from the CSP | Portal Succeeded, but netsh wlan show profiles has no SSID |
| 4. Certificate (EAP) | Client cert + root/intermediate available for the EAP method | Profile present; connect fails with cert / smart card / credentials errors |
| 5. Association + EAP | WLAN AutoConfig associates and runs 802.1X | Wrong SSID/security type; hidden SSID; PMF/WPA3 mismatch |
| 6. RADIUS / NPS | Server validates the client and returns Access-Accept | Client looks fine; server rejects issuer, EKU, or strong mapping |
In Intune admin center > Devices > Configuration > [Wi-Fi profile] > Device and user check-in status, sample three or four affected devices. If every device fails, look at the profile or certificates. If one site fails, look at RADIUS, VLAN, or AP config.
Step 1: Read the assignment (user vs device)
Open the Wi-Fi profile (read only) and note:
- Assignments: user groups, device groups, or both; any exclusion filters.
- Platform: Windows 10/11 vs iOS/Android templates are different objects. A Windows profile never lands on iOS.
- Connect automatically / Hidden network: wrong values do not block install, but they change what the user sees.
| Assignment target | When it typically arrives | Certificate store EAP often needs |
|---|---|---|
| Users | After the user signs in and the device completes user check-in | Often Current User client cert |
| Devices | After device registration / device check-in (can be earlier in Autopilot device ESP) | Often Local Computer client cert |
| Users and devices | Whichever path finishes first for that entity | Must match the Certificate type on the paired SCEP/PKCS profile |
Microsoft's pairing rule for certificates applies here too: the Wi-Fi profile's EAP identity must match the store where the cert actually lives. A device-group Wi-Fi profile that selects a user certificate subject will sit installed and still fail 802.1X.
Troubleshooting + support > Troubleshoot, with Assignments scoped to Configuration profiles, shows whether the user is in the assigned group and when the device last checked in.
Step 2: Confirm check-in before blaming Wi-Fi
If other configuration profiles are also Pending on the same device, this is not a Wi-Fi problem yet.
On the device (authorized, read only):
# Last successful MDM sync signals (Windows)
Get-ScheduledTask -TaskPath '\Microsoft\Windows\EnterpriseMgmt\' -ErrorAction SilentlyContinue |
Get-ScheduledTaskInfo |
Select-Object TaskName, LastRunTime, LastTaskResult
Or use Company Portal > Settings > Sync, then re-check the profile status after a few minutes. No check-in → follow the Company Portal / device not syncing triage.
Step 3: Is the WLAN profile actually on the device?
Portal Succeeded means Intune reported CSP success. Verify Windows agrees:
# Read-only: which WLAN profiles exist, and how they were added
netsh wlan show profiles
# Details for the expected SSID (Key Content stays hidden without admin elevation tricks; don't chase the PSK here)
netsh wlan show profile name="<SSID>" key=clear
| Result | Meaning |
|---|---|
SSID missing from show profiles
|
Profile never installed: assignment, platform, check-in, or CSP error |
SSID present, Connection mode : Connect manually
|
Expected if you disabled connect-automatically; not an apply failure |
| SSID present, security type wrong (e.g. open vs WPA2-Enterprise) | Wrong profile settings or an old local profile shadowing MDM |
| SSID present, still not connecting | Move to Step 4–6 (cert / EAP / RADIUS) |
Also check for a user-created profile with the same SSID that was added before MDM. Windows can prefer the local profile. Compare netsh wlan show profiles all-user vs per-user contexts when troubleshooting a specific signed-in account.
MDM Admin log (read only) for profile apply noise:
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 400 |
Where-Object { $_.Message -match 'Wi-Fi|Wifi|WLAN|./Vendor/MSFT/WiFi' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message -First 25 | Format-List
Step 4: EAP and certificates (only if security is Enterprise)
Skip this step for PSK / WPA2-Personal. For WPA2/WPA3-Enterprise with EAP-TLS (or TTLS/PEAP that still needs a machine/user cert):
# Client certs that might be offered to EAP
Get-ChildItem Cert:\CurrentUser\My, Cert:\LocalMachine\My |
Where-Object { $_.HasPrivateKey } |
Select-Object PSParentPath, Subject, Issuer, NotAfter, Thumbprint
# Root / intermediate the RADIUS server chain expects on the client (server auth trust)
Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA |
Where-Object Subject -match '<your org CA CN>' |
Select-Object PSParentPath, Subject, NotAfter, Thumbprint
| Finding | What it usually means |
|---|---|
| No client cert in the expected store | SCEP/PKCS profile not applied, wrong Certificate type, or wrong assignment entity — use the SCEP triage |
| Cert in LocalMachine but Wi-Fi profile is user-scoped (or reverse) | Identity mismatch; EAP picks nothing usable |
| Client cert present, server auth trust missing | Device cannot validate the RADIUS server certificate (trusted certificate profile missing or wrong root) |
| Cert expired or EKU missing Client Authentication | Profile settings or template issue on the CA side |
Intune Wi-Fi settings that commonly disagree with the cert:
- EAP type vs what NPS/RADIUS is configured to accept
- Certificate server names / trust server certificate toggles that reject a valid but differently named RADIUS cert
- Authentication method (certificate vs username/password) left on the wrong option after a template copy
Step 5: Read WLAN AutoConfig while reproducing a connect
With the affected user session (or SYSTEM context for device profiles), attempt a connect once, then read:
# Read-only: recent WLAN AutoConfig operational events
Get-WinEvent -LogName 'Microsoft-Windows-WLAN-AutoConfig/Operational' -MaxEvents 80 |
Select-Object TimeCreated, Id, LevelDisplayName, Message -First 30 | Format-List
netsh wlan show interfaces
netsh wlan show networks mode=bssid
| Signal | Direction |
|---|---|
SSID not in show networks
|
RF / AP / wrong band / hidden SSID not probed / device not in range |
| SSID visible, association fails | Security type, PMF, transition mode, or AP reject |
| Association OK, EAP fails | Certificate, identity, or RADIUS policy |
| EAP success, no DHCP/network | VLAN / NPS authorization attribute / firewall — not Intune profile apply |
Event IDs vary by Windows build; treat the Message text as the source of truth (credential failure, explicit EAP failure, timeout, cancel).
Step 6: When the client is healthy but RADIUS rejects
If Steps 1–5 look good on several devices at one site:
- NPS / RADIUS: are requests arriving? Accept vs Reject for that machine/user?
- Issuer and EKU on the client cert trusted by the server policy?
- For hybrid / on-prem identities: strong certificate mapping / SID requirements (same class of issue called out in the SCEP FAQ when Wi-Fi still fails after event 39).
- Duplicate device objects or a cert issued to the wrong hostname/UPN.
That work is on the AAA side. Recreating the Intune Wi-Fi profile will not fix an NPS mapping reject.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| User/device assignment doesn't match cert store / EAP identity | Align Wi-Fi assignment with the SCEP/PKCS Certificate type; pilot first | Recreating the SSID profile repeatedly |
| No MDM check-in | Fix sync / Entra join / time | New Wi-Fi profiles on an offline device |
Portal Succeeded, SSID absent in netsh
|
Capture MDM Admin errors; fix CSP/platform/assignment | Deleting the only working profile for all cohorts |
| Local SSID shadows MDM | Remove the local profile for that user/device after backup of settings | "Forget network" on every PC without knowing which profile was local |
| Missing client or root cert | Fix the certificate profile chain (see SCEP post) | Switching Enterprise SSID to PSK "just for testing" in production |
| One site rejects, clients look fine | Fix NPS/RADIUS/AP VLAN | Broad Intune assignment changes |
| Hidden SSID + connect-automatically off | Adjust those two settings on a pilot | Enabling broadcast org-wide without change control |
FAQ
Why does Intune say Succeeded but the SSID never appears?
Succeeded means the configuration CSP applied from Intune's point of view. Confirm with netsh wlan show profiles. If it is missing, read MDM Admin events and assignment/platform. If it is present, you have a connect/EAP/RADIUS problem, not an apply problem.
Should Wi-Fi profiles be assigned to users or devices?
Match the rest of your stack. Device assignment fits machine certs and pre-user ESP networking. User assignment fits user certs and per-user SSIDs. Mixing a user Wi-Fi profile with a device-only client certificate is a frequent 802.1X failure.
We use PSK — do we still care about certificates?
No client cert chain. Focus on assignment, check-in, SSID/security type, and whether a local profile shadows MDM. Still verify with netsh, not only the portal tile.
Autopilot ESP is stuck and Wi-Fi is one of the Account setup apps/policies.
ESP blocking behavior is a different triage (ESP assignment checklist / Account setup stuck). Use this article once ESP is not the active symptom and you are debugging steady-state profile apply.
Is it safe to delete and recreate the Wi-Fi profile?
Only after Steps 1–5 name a profile-definition bug (wrong EAP type, wrong SSID, bad server names). Recreate on a pilot group first; a production edit reprocesses everyone and can drop working laptops off corp Wi-Fi.
Related posts
- Intune SCEP Certificate Profile Failed: A Read-First Assignment and NDES Triage
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Autopilot ESP stuck? An assignment-first triage checklist
- Autopilot ESP Stuck at Account Setup: Read-Only Triage
Free checklist
Corp Wi-Fi that depends on device compliance often sits behind Conditional Access. Before you require compliant devices on the same network path users need to enroll and remediate, the free Conditional Access pre-enforcement checklist keeps device readiness, pilot groups and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-wifi-profile-not-applying
Admin Pack Studio; not affiliated with Microsoft. Steps 1–6 only read. Test profile changes on a pilot group first, and check current Microsoft docs for CSP paths and event log names.
Top comments (0)