Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Intune WiFi certificate deployment uses three profiles: a trusted root certificate, a SCEP or PKCS client certificate, and an 802.1X WiFi profile set to EAP-TLS. Deploy them in that order, all assigned to the same Microsoft Entra ID group. SCEP creates the private key on the device, while PKCS creates it centrally. For WiFi on Windows, iOS and Android, choose SCEP.

What does Intune WiFi certificate deployment actually do?

Intune gives every managed device its own identity certificate and the WiFi settings to present it. The device then joins your staff network without anyone typing a password.

The mechanism is IEEE 802.1X, the standard for port-based network access control. Under 802.1X, the access point holds a device off the network until an authentication server approves it. That server is a RADIUS server, the service your access points query before letting a device in.

The authentication method is EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), defined in RFC 5216. Both sides prove their identity with certificates:

• The device presents a client certificate.
• The RADIUS server presents a server certificate.
• Each side checks that the other's certificate chains to a certificate authority (CA) it trusts.

No password is typed, stored or exposed to phishing.

This matters more each year. Microsoft documents that Windows Defender Credential Guard blocks single sign-on for password-based 802.1X methods such as PEAP-MSCHAPv2. PEAP (Protected EAP) sends a password inside an encrypted tunnel. Credential Guard is on by default on recent Windows 11 Enterprise builds, and Microsoft recommends certificate-based authentication instead.

Intune delivers certificate-based WiFi through three configuration profiles:

• Trusted certificate profile. Installs your root CA and any intermediate CA. The device can then trust its own certificate chain and your RADIUS server.
• SCEP or PKCS certificate profile. Issues each device a unique client certificate.
• WiFi profile. Sets the SSID (the broadcast network name), the security type and the EAP method. It also names the certificate to present and the server to trust.

For venue operators, this is the staff side of the network. Staff laptops, handhelds and tablets in Hotels, Retail and Healthcare need access to systems that guests, shoppers and patients must never reach. Your Guest WiFi keeps its captive portal, the sign-in page visitors see. Staff devices authenticate silently on a separate SSID and VLAN, a logically isolated network segment.

SCEP or PKCS: which certificate profile should you use?

Both profiles leave a client certificate on the device. The difference is where the private key is created.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) has the device generate its own key pair. The device sends a certificate signing request through a Network Device Enrolment Service (NDES) server, or through Microsoft Cloud PKI. The CA signs the request and returns the certificate. The private key never leaves the device. On Windows, the SCEP profile can place that key in the Trusted Platform Module (TPM), the hardware security chip.

PKCS profiles use the Certificate Connector for Microsoft Intune to request the certificate from your CA. The key pair is created away from the device. Intune then delivers the certificate and private key to the device in encrypted form. You avoid running NDES, but the private key has existed somewhere other than the device.

A third type, PKCS imported certificates, delivers certificates you already hold. Its usual job is S/MIME email encryption, where keys are escrowed. It is the wrong tool for WiFi.

	SCEP via NDES and AD CS	SCEP via Microsoft Cloud PKI	PKCS via connector and AD CS
Where the private key is created	On the device	On the device	Off the device, then delivered
Certificate authority	Your Active Directory Certificate Services (AD CS) enterprise CA	Microsoft-hosted CAs, or your own root	Your AD CS enterprise CA
On-premises servers you run	CA, NDES server, Certificate Connector	None	CA, Certificate Connector
Internet-facing component	NDES URL, published through Microsoft Entra application proxy	None: Microsoft hosts the SCEP endpoint	None: the connector connects outbound only
Extra licence	None beyond Windows Server	Cloud PKI add-on or Microsoft Intune Suite	None beyond Windows Server
Setup effort	Highest: CA, NDES, connector and proxy publishing	Lowest: CAs created in the Intune admin centre	Medium: CA and connector, no NDES
Who it suits	Estates with AD CS that want keys kept on-device	Cloud-first estates with no on-premises PKI	Estates with AD CS that cannot publish NDES

For WiFi, choose SCEP unless you cannot meet its infrastructure needs. A key that never leaves the device cannot be copied from a server or intercepted in transit. Choose Microsoft Cloud PKI if you have no on-premises PKI and do not want to build one. Choose PKCS if you run AD CS but cannot publish an NDES endpoint to the internet.

What do you need before you deploy WiFi certificates with Intune?

Confirm each item before you create a single profile. Most failed rollouts trace back to a gap on this list.

• Licensing. Each person needs an Intune licence. Intune is included in Microsoft 365 E3, E5 and Business Premium, and in Enterprise Mobility + Security E3 and E5.
• Enrolled devices. Windows devices are joined to Microsoft Entra ID, often through Windows Autopilot. iOS and iPadOS devices are enrolled through Apple Business Manager automated device enrolment. Android devices use Android Enterprise. Microsoft has ended device administrator management for devices with Google Mobile Services, so plan on Android Enterprise.
• A certificate authority. This means an AD CS enterprise CA, Microsoft Cloud PKI, or a third-party CA that Intune supports.
• A certificate template. On AD CS, publish a template with the Client Authentication extended key usage.
• Connector infrastructure. SCEP on AD CS needs an NDES server and the Certificate Connector for Microsoft Intune. PKCS needs only the connector.
• A RADIUS server that supports EAP-TLS. Its server certificate must chain to a root you will deploy. Record the exact name on that certificate, because the WiFi profile needs it.
• Reachable revocation. Your RADIUS server must reach the certificate revocation list (CRL) or an OCSP (Online Certificate Status Protocol) responder. If it cannot, authentication fails.
• Enterprise SSIDs. Your access points must broadcast a WPA2-Enterprise or WPA3-Enterprise SSID pointed at your RADIUS server. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet all support 802.1X.
• Entra ID groups. Create one pilot group and one production group. Decide now whether they hold people or devices.
• A bootstrap network. A device needs internet access to collect its certificate before it can join the 802.1X SSID. Provide wired access, mobile data or an isolated onboarding SSID. Trains operators issuing tablets to on-board crew should provision them at the depot, before the tablets travel.

How do you set up SCEP or PKCS WiFi certificates in Intune?

Microsoft's Intune documentation holds the field-by-field steps for each platform. The sequence and the decisions below are what determine success. Create one set of profiles per platform: Windows, iOS/iPadOS and Android Enterprise.

Step 1: deploy the trusted root certificate profile

Export your root CA certificate as a .cer file. Create a trusted certificate profile that contains it. Each trusted certificate profile holds one certificate, so create separate profiles for the root and for each intermediate CA.

On Windows, send the root to the computer root store and intermediates to the intermediate store. If a different CA signed your RADIUS server certificate, deploy that root too. Without it, devices cannot validate the server.

Step 2: deploy the SCEP or PKCS certificate profile

Start with the certificate type, because it drives everything else.

• Device certificates suit shared handhelds, kiosks and laptops that must connect at the Windows sign-in screen. Use a subject name built from the device identifier, such as CN={{AAD_Device_ID}}.
• Person-based certificates suit phones and laptops assigned to one member of staff. Use CN={{UserPrincipalName}} in the subject. Add the same value as a subject alternative name, because many RADIUS servers read identity from there.

Then set the remaining fields:

• Key usage: digital signature and key encipherment.
• Extended key usage: Client Authentication, OID 1.3.6.1.5.5.7.3.2.
• Key size: 2048 bits as a minimum.
• Validity: no longer than your CA template allows.
• Renewal threshold: Microsoft's default is 20% of the certificate's lifetime remaining.
• Root certificate: select the trusted certificate profile from step 1.
• Key storage on Windows: choose the TPM option for hardware-backed keys.

For SCEP, enter the external NDES URL or your Cloud PKI SCEP URI. For PKCS, enter the CA name and template name instead.

If you use Microsoft NPS (Network Policy Server) with hybrid identities, read Microsoft's KB5014754 on strong certificate mapping. Microsoft documents a subject alternative name URI that carries the on-premises security identifier for exactly this case.

Step 3: deploy the 802.1X WiFi profile

Create an enterprise WiFi profile with these settings:

• Enter the SSID exactly as your access points broadcast it.
• Set the security type to WPA2-Enterprise, or WPA3-Enterprise where your access points and the platform support it.
• Set the EAP type to EAP-TLS.
• Enter certificate server names that match the name on your RADIUS server certificate. This stops devices handing their identity to a rogue access point.
• Select the step 1 profile as the root certificate for server validation.
• Select the step 2 profile as the client authentication certificate.

What differs on Windows, iOS and Android?

• Windows connects with a device certificate before anyone signs in. A person-based certificate connects only after sign-in, which breaks first sign-in on shared laptops.
• iOS and iPadOS trust the RADIUS server by matching the certificate server names you enter. A mismatch produces a trust failure, not a silent fallback.
• Android Enterprise requires a RADIUS server domain name and a root certificate for validation. Recent Android releases removed the option to skip server validation.

What happens when a new device enrols?

This is the certificate deployment sequence on a newly enrolled device:

1. The device enrols and lands in its assigned Entra ID group.
2. Intune delivers the trusted root and intermediate profiles.
3. The device requests its client certificate. Under SCEP, it generates a key pair and sends a signing request with a one-time challenge. The connector validates that challenge with Intune before the CA issues anything. Under PKCS, the connector requests the certificate and Intune delivers it.
4. The device reports the installed certificate to Intune.
5. The WiFi profile, which depends on both certificate profiles, applies.
6. The device presents its certificate to the SSID. RADIUS validates the chain, checks revocation and accepts the device. It can then assign a VLAN through RADIUS attributes.
7. Intune renews the certificate when it reaches the renewal threshold. Intune revokes it when you retire or wipe the device, provided the connector holds revocation rights on the CA.

How do you check Intune WiFi certificates are working?

Test with a pilot of 10 to 20 devices per platform before you widen assignments. Check four places.

1. Intune profile status. Each of the three profiles should report Succeeded for every pilot device. A status of Pending, Error or Not applicable on any one blocks the WiFi profile.
2. The device itself. On Windows, open the personal certificate store and confirm the Client Authentication purpose and your issuing CA. On iOS and Android, confirm the certificate and WiFi profile appear in the management profile and work profile credentials.
3. RADIUS logs. Look for successful EAP-TLS authentications with the expected subject name. On NPS, event ID 6272 records granted access and 6273 records denied access, with a reason code.
4. Connector and NDES logs. The Certificate Connector writes to the Windows event log. NDES requests appear in the IIS logs.

Then test revocation on purpose. Retire one pilot device in Intune and confirm the certificate shows as revoked on the CA. Publish the CRL, and confirm RADIUS denies the next authentication.

What goes wrong with Intune WiFi profiles, and how do you fix it?

The WiFi profile shows Error or Not applicable

The certificates arrived, but the WiFi profile failed. The usual cause is mixed group targeting. For example, the SCEP profile is assigned to a group of people while the WiFi profile targets a device group. Intune cannot resolve the dependency. The fix is to assign all three profiles to the same group, or at least to the same group type.

The SCEP certificate never arrives

NDES IIS logs show HTTP 403 or 500 responses. Check that the connector service account has Read and Enrol permissions on the certificate template. Check that your firewall, reverse proxy or application proxy is not stripping SCEP query strings such as operation=GetCACaps. Then confirm the external NDES URL resolves from outside your network.

The device has a certificate, but RADIUS rejects it

Work through four causes in order:

1. The certificate server names in the WiFi profile do not match the RADIUS server certificate.
2. The RADIUS server does not trust the CA that issued the client certificate.
3. The RADIUS server cannot download a current CRL.
4. NPS strong mapping enforcement under KB5014754 rejects certificates without a strong mapping.

The NPS reason code points to the right one.

Revocation checks cause an outage

If the CRL distribution point goes offline or the CRL expires, strict RADIUS servers reject every certificate. Publish CRLs on a highly available HTTP location that your RADIUS server can reach. Monitor the CRL's next-update time.

Devices keep joining the old network

A legacy pre-shared key or PEAP profile still on the device takes priority. Remove the old profile through Intune once the new one reports success, then retire the old SSID.

How does Intune certificate-based WiFi work in a real venue?

The two scenarios below are worked examples built on Microsoft's documented behaviour. They describe venue types, not named deployments.

A 12-hotel group retiring a shared staff password

Situation. A group of 12 hotels, each around 200 rooms, runs one staff SSID on a pre-shared key. The key is shared by 840 devices: reception PCs, housekeeping iPhones, and Android handhelds in food and beverage. The network is connected to the cardholder data environment. PCI DSS v4.0 requirement 2.3.2 therefore requires the key to change whenever someone who knows it leaves. With front-of-house turnover, every rotation strands devices until someone re-enters the key.

What was done. The team deploys SCEP through NDES, published with Microsoft Entra application proxy. Reception PCs receive device certificates so they connect at the sign-in screen. Phones receive person-based certificates. A 20-device pilot runs at one hotel for two weeks. After that, one hotel moves each week, with the old SSID running in parallel.

Measurable outcome. After 12 weeks, all 840 devices authenticate with EAP-TLS and the pre-shared key SSID is switched off. The number of shared keys to rotate falls from one across 12 sites to zero. A leaver's access now ends when their device is retired and the CRL is republished, not at the next key rotation.

A 150-store retail chain with shared handhelds

Situation. Each store runs four shared Android handhelds and two Windows back-office laptops, 900 devices in total. Handhelds pass between staff every shift, so person-based certificates make no sense. The chain's cloud RADIUS service cannot reach a CRL published only on the internal network.

What was done. The chain enrols the handhelds as Android Enterprise dedicated devices and issues device certificates through SCEP. One WiFi profile per platform serves every store, because the SSID is identical everywhere. The CRL moves to an internet-reachable HTTP distribution point.

Measurable outcome. No shared handheld carries a WiFi password. Store staff stop asking for the key after each change. A lost handheld is cut off by retiring it in Intune, and its certificate fails at the next authentication once the CRL refreshes.

What does Intune WiFi certificate deployment cost, and what do you get back?

What it costs

• Licences. Most estates already own Intune through Microsoft 365 or Enterprise Mobility + Security, so there is no new per-seat cost.
• Servers. AD CS, NDES and NPS are Windows Server roles that need no separate licence beyond Windows Server.
• Cloud PKI. Microsoft Cloud PKI is a paid add-on, also included in Microsoft Intune Suite. Weigh its cost against building and maintaining an on-premises CA and NDES.
• Effort. The work sits in PKI design, NDES publishing and the pilot. The three profiles take hours, not weeks.

What you get back

• No shared WiFi keys. This removes the key rotation that PCI DSS requirement 2.3.2 imposes on wireless networks connected to the cardholder data environment.
• Leaver access you can revoke. Retiring a device in Intune can revoke its certificate, so WiFi access follows your joiners, movers and leavers (JML) process.
• Compatibility with Credential Guard. EAP-TLS keeps working where Windows blocks password-based 802.1X single sign-on.
• No credential to phish. A certificate bound to a TPM cannot be typed into a fake login page.
• No password expiry. Certificates renew automatically before they expire, removing password resets as a cause of WiFi tickets.

Plan GDPR handling from the start. Certificate subjects containing a staff member's sign-in name are personal data in your RADIUS logs. Set a retention period and restrict access to those logs.

Purple runs Staff WiFi and Guest WiFi side by side across 80,000+ live venues (Purple data). The platform is hardware-agnostic across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple holds ISO 27001 certification. Our Identity-Based Networks work with Microsoft Entra ID, Okta and Google Workspace, so staff access follows the same identity source as your Intune estate. On the visitor side, WiFi Analytics reports on guest connections separately from staff traffic.

Frequently asked questions

Do you need extra licences to deploy WiFi certificates through Intune?

No, not for SCEP through NDES or for PKCS. Intune is included in Microsoft 365 E3, E5 and Business Premium, and in Enterprise Mobility + Security E3 and E5. Active Directory Certificate Services and NDES are Windows Server roles, so they need only your existing Windows Server licensing. The exception is Microsoft Cloud PKI, a paid add-on also included in Microsoft Intune Suite. Budget for it only if you want to avoid running an on-premises CA.

Will certificate-based WiFi from Intune work with your existing access points?

Yes, provided your access points can broadcast a WPA2-Enterprise or WPA3-Enterprise SSID. EAP-TLS runs between the device and the RADIUS server, and the access point only relays it under IEEE 802.1X. Purple is hardware-agnostic and runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep the hardware you already own and change only the SSID security settings.

Can you move from PEAP or a shared password to EAP-TLS without downtime?

Yes. Run the new 802.1X SSID alongside the old one, or configure your RADIUS server to accept both PEAP and EAP-TLS during the transition. Deploy the three Intune profiles to a pilot group first. Confirm successful EAP-TLS authentications in your RADIUS logs, then widen the assignment in waves. Remove the legacy WiFi profile only after the new one reports success, then retire the old SSID.

Should you choose SCEP or PKCS for staff WiFi?

Choose SCEP. With SCEP the device generates its own private key, which never leaves it, and Windows can store that key in the TPM. PKCS creates the key off the device and delivers it. That removes the NDES server but widens where the key has existed. Pick PKCS only when you run Active Directory Certificate Services and cannot publish NDES, or use Microsoft Cloud PKI for SCEP without NDES.

Do you still need an NDES server?

Only for SCEP with an on-premises Active Directory Certificate Services CA. Microsoft Cloud PKI provides a hosted SCEP endpoint, so you run no NDES server, connector or on-premises CA. PKCS profiles also avoid NDES, because the Certificate Connector for Microsoft Intune requests certificates from your CA over outbound connections. Third-party certificate authorities that Intune supports can also issue SCEP certificates without NDES.

How quickly does WiFi access end when someone leaves?

As fast as your revocation pipeline allows. When you retire or wipe a device in Intune, the Certificate Connector can revoke its certificate on your CA. Access ends when your RADIUS server sees that revocation, through a refreshed CRL or an OCSP check. Shorten the CRL publication interval, or use OCSP, if same-hour removal matters. Disabling the account alone may not stop a valid certificate unless RADIUS also checks the directory.

Does certificate-based WiFi help with PCI DSS and GDPR?

Yes. PCI DSS v4.0 requirement 2.3.2 requires wireless keys on networks connected to the cardholder data environment to change whenever someone who knows them leaves. Per-device certificates mean no shared key exists to rotate. For GDPR, treat certificate subjects containing a staff member's sign-in name as personal data. Set a retention period for RADIUS logs, restrict access to them, and record the processing.