Intune WiFi profile not applying: where it really fails

An Intune WiFi profile fails in a way that is hard to read. The policy reports success in the admin centre, the network appears on the device under Areas managed by Microsoft, and the laptop still sits on the guest SSID. Rebuilding the profile is the obvious response and it almost never helps, because the profile is rarely the part that is broken. This page walks the dependency chain in the order it fails, names the error codes worth recognising, and says where the evidence lives on a Windows device.

If you arrived here from a wider outage rather than one network, start with the symptom index in Intune troubleshooting and work back. If the device is not checking in at all, nothing below applies yet.

What a successful Intune WiFi profile actually proves

Windows applies the profile through the WiFi configuration service provider, which writes the profile XML to a node named for the network.

1# The CSP nodes a WiFi profile is written to. A success in the Intune console
2# means one of these nodes was set. It means nothing beyond that.
3./Device/Vendor/MSFT/WiFi/Profile/{SSID}/WlanXml
4./User/Vendor/MSFT/WiFi/Profile/{SSID}/WlanXml

The matching entry on the device is event ID 1506 in the Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider admin log, and Microsoft’s own example of it reads WiFiConfigurationServiceProvider: Node set value, type: (0x4), Result: (The operation completed successfully.). That is the entire claim. A blob of XML was accepted. It says nothing about whether the EAP configuration inside the blob is coherent, whether the client certificate exists yet, or whether your RADIUS server would accept the identity it presents. Intune cannot see past the node, so a green tick in the console and a device that will not associate are not contradicting each other.

The WiFi CSP reference adds a detail the Intune interface never mentions: the profile name in the node has to match the name element inside the WLANProfile XML, and if it does not, the documentation warns the profile can be marked as user-provisioned rather than MDM-provisioned. A user-provisioned profile is not managed. It will not be corrected, replaced or removed by the policy that created it, and it will keep whatever settings it already had.

The three things an Intune WiFi profile silently waits for

An enterprise profile is a wrapper around an EAP configuration, and that configuration usually points at a certificate a different profile has to deliver. Microsoft’s troubleshooting article puts exactly this at the top of its cause list: the WiFi profile is linked to trusted root and SCEP profiles, and those profiles were not deployed first.

There is no dependency ordering for configuration profiles in Intune. You cannot declare that the trusted root must land before the network. So the first check-in after enrolment can deliver the WiFi profile before the certificate exists, and what happens then depends on the platform. On Android the state is named out loud in Omadmlog.log.

1# Android, Omadmlog.log, filtered on wifimgr. This is the only place Microsoft
2# names the pending-certificate state explicitly in a log file.
3Skipping Wifi profile <profile ID> because it is pending certificates.

Windows has no equivalent line, which is the whole reason the Windows case takes longer. The profile is written, the certificate is absent, and the only symptom is a device that fails authentication. Deploy the trusted root, the certificate profile and the network to the same group. If you are still choosing an issuance method, which certificate profile to use, SCEP or PKCS decides more than it appears to.

The second thing it waits on is certificate matching. The same article quotes the Android case where the extended key usage on the issued certificate does not satisfy the criteria the profile asked for.

1# Android, CertUtils. The certificate is present and is still rejected, because
2# the template does not carry the EKU the SCEP profile asked for.
3Excluding cert with alias User<ID1> and requestId <requestID1> as it does not have any purpose EKU.
40 cert(s) matched criteria:
52 cert(s) excluded by criteria:

The third is the assignment, and it is usually the culprit when a subset of devices fails rather than all of them. If another policy is setting the same thing, or group membership resolved after the last check-in, the device is working from an older view of the world than the console is showing you.

Authentication mode decides whether it can ever work

For a Windows enterprise profile, Authentication mode takes one of Not configured, User, Machine, User or machine, or Guest. This is the setting that has to agree with your network policy server, and it produces the most misread failure in the list: the profile is correct, the certificate is present, and the device only joins the network once somebody has signed in.

Machine authentication presents a device certificate and can therefore work before sign-in. User authentication cannot, because neither the user context nor a user certificate exists yet. If the device has to be on the network at the logon screen, single sign-on has to be set to enable before the user signs in to the device, with its own timeout of between 1 and 120 seconds. The Windows WiFi settings reference, last updated 14 April 2026, lists these alongside the EAP types on offer: EAP-SIM, EAP-TLS, EAP-TTLS and Protected EAP, each accepting a SCEP certificate, a PKCS certificate or a derived credential as the authentication method, with PEAP and EAP-TTLS also accepting a username and password.

Two defaults in that reference are worth knowing before you blame the radio. Maximum authentication failures is 1, and the authentication period is 18 seconds. A RADIUS server that is slow to answer during a morning login storm gets no second attempt unless you raise that value, and the device reports a failure that looks like a certificate problem.

0x87d1fde8, and the devices with no radio

Any fleet with desktops in it produces a wall of remediation failures the day a WiFi profile goes out to all devices. The profile is fine. The machine has no wireless adapter, so there is nothing for the CSP to configure. Worth knowing before you spend an evening on it: 0x87d1fde8 is a generic remediation failure and not a WiFi-specific code, which is why searching it returns results for half a dozen unrelated policies.

Microsoft’s answer on its own Q and A forum is that Intune does not know whether a device has a wireless card before the profile is deployed, and that the recommendation is to build a device group containing only the machines that have one and target that. The modern form of the same idea is assignment filters instead of groups, which at least keeps the scoping next to the assignment rather than in Entra ID. Either way you are inferring hardware from an inventory property such as model or enrolment profile. That is a proxy for a radio, not a test for one, and it will be wrong the first time somebody buys a small form factor machine with wireless on board.

When the imported XML is the problem

For settings the template does not expose, Windows 8.1 and later accept a WiFi configuration exported from a working device. The export is one command.

1# Export a working profile from a reference machine, then import the XML into
2# the Intune profile. key=clear writes the pre-shared key in plain text, so
3# treat the file accordingly and delete it when you are done.
4netsh wlan export profile name="Corp-Secure" key=clear folder=C:\Temp

This route is more fragile than it looks. The XML has to comply with the WLAN profile schema, the profile name has to match the name element as above, and the CSP reference notes that where keyType and protected elements are present they must appear before keyMaterial. It also notes that a replace command cannot be used unless the node already exists, which is the mechanism behind a profile that appears to update everywhere except on the devices that never received the first version.

Failure modes, and the text you will see

On Windows there are three places worth looking, in this order. Settings, Accounts, Access work or school, Info, and the Areas managed by Microsoft list, which tells you whether the profile arrived at all. The DeviceManagement-Enterprise-Diagnostics-Provider admin log in Event Viewer, with analytic and debug logs turned on in the View menu, which shows the CSP writing it. And the MDM diagnostic report, exported from that same Info page with Create report, which lands in \Users\Public\Documents\MDMDiagnostics. If you are pulling that remotely instead, collecting diagnostics from the device has its own failure modes and a fixed file list.

Microsoft’s troubleshooting article for WiFi device configuration profiles is the source of the log excerpts above and of the Android Enterprise reporting artefact in the table.

What I would do differently

I have not run this on a production fleet. My tenant is a lab, there are no device counts or timings in this post, and everything above is either a primary source or a reading of one. What I would change is the order of trust.

Stop treating the network profile as the deliverable. The certificate profiles are the deliverable, and the WiFi profile is a thin wrapper that inherits every fault in the issuance chain. Building the trusted root and the certificate profile first, proving a certificate lands on a device, and only then assigning the network turns a three-variable problem into a one-variable problem.

Stop reading the success column as a connectivity signal. Intune can tell you that a profile was written. Only the network policy server can tell you that a device authenticated, and its event log names the reason when it refuses. On a new deployment I would have the NPS log open before the Intune report.

Scope by network rather than by fleet. One group per SSID costs a few minutes and removes the entire class of failure that error 0x87d1fde8 belongs to. And raise maximum authentication failures above 1 before the first Monday morning, not after it.

Last verified: 29 September 2026