Microsoft Cloud PKI for WiFi: EAP-TLS certificate deployment with Intune and Entra ID

Yes. Microsoft Cloud PKI, the hosted certificate authority in the Intune Suite, issues EAP-TLS WiFi certificates to Intune-managed devices. A SCEP certificate profile requests them directly, so you need no NDES server, certificate connector or on-premises CA. Your RADIUS server trusts the imported Cloud PKI root and checks each certificate against the CRL the service publishes.

What does Microsoft Cloud PKI do for WiFi authentication?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) is the 802.1X method in which both sides prove their identity with certificates. IEEE 802.1X is the port-based access control standard behind WPA2-Enterprise and WPA3-Enterprise. The access point passes each connection attempt to a RADIUS server, the authentication server that accepts or rejects the device. With EAP-TLS there is no password to phish and no shared key to leak. Each device holds its own private key and certificate.

The hard part has always been the PKI (public key infrastructure) behind it. Getting certificates onto Intune-managed devices traditionally needed four things:

• an Active Directory Certificate Services (AD CS) issuing CA
• an NDES (Network Device Enrollment Service) server
• the Intune Certificate Connector
• a reverse proxy or Microsoft Entra application proxy to publish NDES to the internet

Each one needs patching, backups and monitoring.

Microsoft Cloud PKI replaces that stack with a certificate authority hosted in your Intune tenant. Devices request certificates over SCEP (Simple Certificate Enrollment Protocol), and Cloud PKI answers those requests itself. It validates each request against Intune, signs the certificate and returns it. The device generates its private key locally, and the key never leaves it.

For Entra ID-joined fleets, this removes the last on-premises dependency in the certificate chain. Devices that have never seen a domain controller can still get a WiFi certificate.

How the Cloud PKI CA hierarchy works

Cloud PKI uses a two-tier hierarchy. A root CA signs one or more issuing CAs, and the issuing CA signs device certificates. Microsoft holds the CA signing keys in hardware security modules (HSMs), so you never manage key material.

You choose one of two anchors:

• Cloud PKI root. Microsoft hosts both the root and the issuing CA in your tenant. This is the simplest option for a greenfield Entra ID estate.
• Bring your own CA (BYOCA). You create a Cloud PKI issuing CA, download its certificate signing request and sign it with your existing private root, such as an AD CS root. Anything that already trusts that root then trusts the new issuing CA's chain.

You set extended key usages (EKUs) when you create each CA. WiFi client certificates need the Client Authentication EKU, so include it at both tiers. Plan this carefully, because the EKUs are fixed when the CA is created.

One boundary matters for design. Cloud PKI issues certificates to Intune-managed devices through SCEP. It is not built to issue your RADIUS server's own certificate, so that certificate normally comes from a public CA or your existing PKI.

How Cloud PKI compares with SCEP with NDES and PKCS

	Cloud PKI (SCEP)	SCEP with NDES	PKCS
CA hosting	Microsoft-hosted in your Intune tenant	Your AD CS or third-party CA	Your AD CS or third-party CA
On-premises servers	None	Issuing CA, NDES server, connector host	Issuing CA, connector host
Internet-published component	None	NDES, via reverse proxy or application proxy	None
Where the private key is generated	On the device	On the device	On the CA side, delivered to the device as a PFX
Fit for Entra ID-only fleets	Native	Works, but keeps on-premises dependencies	Works, but keeps on-premises dependencies
Revocation	Revoke in the Intune admin center, published by CRL	Through the connector and your CA's CRL	Through the connector and your CA's CRL
License model	Intune Suite or Cloud PKI add-on, per seat	Windows Server licenses plus Intune	Windows Server licenses plus Intune
Who it suits	Cloud-first estates retiring on-premises PKI	Estates with a mature AD CS team and a long CA roadmap	Cases that need the same key on more than one platform, such as S/MIME

Our separate guide to Intune certificate deployment with SCEP and PKCS covers the two on-premises routes in depth.

What do you need before you deploy Cloud PKI for EAP-TLS?

Check these six items before you create anything. Each one maps to a failure in the troubleshooting section below.

• Licensing. An Intune Plan 1 subscription plus either the Microsoft Intune Suite or the standalone Cloud PKI add-on.
• Permissions. The Intune Administrator role, or a custom role with the Cloud PKI permissions.
• Enrolled devices. Windows, macOS, iOS/iPadOS or Android devices enrolled in Intune, grouped in Microsoft Entra ID security groups.
• An EAP-TLS-capable RADIUS server. It must let you import CA certificates, reach the Cloud PKI CRL over HTTP, and map certificate identities to Entra ID objects. Microsoft NPS (Network Policy Server) looks up accounts in on-premises Active Directory, so cloud-only devices fail there.
• A RADIUS server certificate. You also need the root and any intermediate certificates that issued it, because devices must validate the server.
• 802.1X-capable access points. These must broadcast a WPA2-Enterprise or WPA3-Enterprise SSID pointed at your RADIUS server.

On the access point side, every major platform supports 802.1X. That includes Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. For a vendor-specific walkthrough, see Configuring 802.1X on Juniper Mist with cloud RADIUS.

How do you set up Cloud PKI certificates for WiFi?

The sequence below summarizes the build. Use Microsoft's Cloud PKI documentation on Microsoft Learn for the current screens and field-by-field steps, because the admin center layout changes between releases.

Step 1: create the root CA, or bring your own

In the Intune admin center, create a root CA under tenant administration. Choose the key size, validity period and EKUs, including Client Authentication.

For BYOCA, skip the root. Create the issuing CA as a BYOCA type and export its certificate signing request. Sign the request on your private CA using a template that includes Client Authentication, then upload the signed certificate and its chain.

Step 2: create the issuing CA

Create an issuing CA anchored to the root from step 1. Its EKUs must include Client Authentication. Once created, its properties page shows three things you will need later:

• the SCEP URI
• the CA certificate download
• the CRL distribution point

Step 3: deploy trusted certificate profiles

Download the root and issuing CA certificates. Create one trusted certificate profile for each, per platform. Assign them to the same groups that will receive the SCEP and WiFi profiles.

Devices need this chain before the SCEP profile can succeed. Create a further trusted certificate profile for the CA that issued your RADIUS server certificate, if devices do not already trust it.

Step 4: create the SCEP certificate profile

Create a SCEP certificate profile per platform and point it at Cloud PKI. These are the key decisions:

• SCEP server URL. Paste the SCEP URI from the issuing CA exactly as shown. Leave its placeholder text unedited, because Intune resolves it at issuance.
• Root certificate. Select the trusted certificate profile for the Cloud PKI root, not the issuing CA.
• Certificate type. Choose device certificates for shared devices such as front-desk tablets or store handhelds. Choose per-person certificates where staff carry their own laptop and you want policy tied to the individual.
• Subject and subject alternative name (SAN). Include an identifier your RADIUS server can map to Entra ID. Examples are the Entra device ID variable {{AAD_Device_ID}} or the UPN variable {{UserPrincipalName}}.
• Key usage and EKU. Set Digital signature and Key encipherment, with Client Authentication.
• Key storage on Windows. Enroll to the TPM (Trusted Platform Module) key storage provider, so the private key is hardware-bound and non-exportable.
• Renewal threshold. Set the percentage of remaining lifetime at which Intune renews, so certificates never lapse unnoticed.

Step 5: make the RADIUS server trust Cloud PKI

Import both the Cloud PKI root and issuing CA certificates into your RADIUS server's trusted CA store. Importing only the root is the most common cause of "unknown CA" rejections.

Enable CRL checking, and allow the RADIUS server outbound HTTP access to the CRL distribution point listed in each certificate. With BYOCA, the RADIUS server may already trust your root, so you add only the new issuing CA certificate.

If Purple's cloud RADIUS authenticates your Staff WiFi, your Purple account team will confirm how the Cloud PKI chain is loaded for your tenant.

Step 6: build the WiFi profile

Create an Intune WiFi profile with enterprise security and EAP-TLS as the EAP type. Set three fields:

• Client authentication certificate. Select the SCEP profile from step 4.
• Root certificates for server validation. Select the trusted certificate profile for your RADIUS server's issuing root.
• Certificate server names. Enter names that match the RADIUS server certificate exactly.

Assign the profile to the same groups as the SCEP and trusted certificate profiles.

How does revocation work with Cloud PKI?

You revoke Cloud PKI certificates from the issuing CA in the Intune admin center. Open the list of issued certificates, select the device's certificate and revoke it. Cloud PKI then publishes the change to its CRL (certificate revocation list), which sits at the HTTP distribution point embedded in every certificate it issues.

Your RADIUS server enforces the revocation, not Intune. It downloads the CRL and rejects any certificate whose serial number appears on it.

Most RADIUS servers cache a CRL until its next-update time. A revoked device can therefore keep connecting until the RADIUS server fetches a fresh list. Close that window in three ways:

1. Revoke explicitly. Do not rely on removing a profile assignment or deleting a device record. Revoke the certificate itself as part of your joiners, movers, leavers process.
2. Pair revocation with identity checks. If your RADIUS service checks Entra ID account or device status at each authentication, disabling the account blocks access before the CRL refreshes.
3. Watch CRL retrieval. Alert on failed CRL downloads. A RADIUS server holding a stale CRL either keeps admitting revoked devices or rejects every device, depending on its failure policy.

How do you check Cloud PKI WiFi authentication works?

Pilot with a test group of five to 10 devices across each platform you support. Confirm five things:

1. Profile status. The trusted certificate, SCEP and WiFi profiles all report success in Intune device configuration reporting.
2. Certificate on the device. On Windows, the certificate appears in the personal store with the expected subject, SAN and Client Authentication EKU. Its chain should build to the Cloud PKI root.
3. Issuance record. The certificate appears in the issuing CA's list of issued certificates in the Intune admin center.
4. RADIUS logs. The authentication log shows EAP-TLS success, the expected identity and a valid chain.
5. Revocation test. Revoke one test certificate. Once the RADIUS server picks up the new CRL, confirm that the device is rejected.

Run the revocation test before you go live. It is the only check that proves your RADIUS server can reach the CRL.

What goes wrong with Cloud PKI EAP-TLS, and how do you fix it?

Symptom	Likely cause	Fix
SCEP profile stuck in error or pending	Trusted certificate profiles not assigned to the same group, or the SCEP profile references the issuing CA instead of the root	Assign root and issuing trusted profiles to the same groups, and select the root in the SCEP profile
Certificate issued, RADIUS rejects with "unknown CA"	Only the root imported into RADIUS	Import the issuing CA certificate as well
Every device rejected after go-live	RADIUS cannot reach the CRL distribution point and fails closed	Allow outbound HTTP from RADIUS to the CRL host
Android devices refuse to connect	No server validation set; Android 11 and later require it	Deploy the RADIUS server's root as a trusted profile and set certificate server names
Windows prompts staff to trust the server	Server names in the WiFi profile do not match the RADIUS certificate	Correct the server names to match the certificate exactly
NPS rejects Entra ID-joined devices	NPS looks for an on-premises Active Directory account that does not exist	Use a RADIUS service that maps certificates to Entra ID objects
Revoked device still connects	RADIUS holding a cached CRL	Pair revocation with an Entra ID account or device disable, and review CRL caching
Certificate lacks Client Authentication	Issuing CA created without that EKU	Create a new issuing CA with Client Authentication and repoint the SCEP profile

If failures cluster in particular rooms or floors while the same devices authenticate elsewhere, the fault is radio coverage, not PKI. EAP-TLS exchanges more packets than a pre-shared key handshake, so marginal signal shows up as timeouts. WiFi Site Surveys: A Practical Planning Guide covers how to find those gaps.

Cloud PKI or SCEP with NDES: which should you choose?

Base the decision on what you already run and what you plan to retire.

Your situation	Recommendation	Why
Entra ID-joined fleet, no AD CS	Cloud PKI with a Cloud PKI root	No on-premises PKI to build or run
AD CS in place, NDES servers due for an OS refresh	Cloud PKI with BYOCA	Keeps your existing root trust and retires NDES and the connector
AD CS team with a long-term CA roadmap and other certificate templates	SCEP with NDES, review at the next server refresh	Existing investment already covers non-WiFi use cases
Need the same key pair on several devices, such as S/MIME	PKCS for that use case, Cloud PKI for WiFi	PKCS delivers exportable keys; WiFi certificates should stay device-bound
Hybrid-joined devices on NPS today, moving to Entra ID join	Cloud PKI plus a cloud RADIUS service	NPS lookups break once devices leave Active Directory

Regulated estates in Healthcare often keep AD CS for other workloads. For them, BYOCA is usually the fit, because it keeps one root of trust across the organization. Rail operators issuing certificates to onboard staff tablets on Trains tend to fit the Cloud PKI root route. Those devices are cloud-managed from day one.

What does Cloud PKI cost, and what do you get back?

Microsoft licenses Cloud PKI per seat, per month. It comes either within the Intune Suite or as a standalone add-on, on top of Intune Plan 1. Check Microsoft's current price list, because bundling changes.

Weigh that against what the on-premises route costs you:

• Windows Server licenses and virtual machines for the issuing CA, NDES and connector hosts
• the reverse proxy or application proxy publishing NDES
• CA database backups
• patching and certificate template administration

The return is fewer servers, no internet-published NDES endpoint, and device-bound keys on every platform you manage.

Worked scenario: a 30-property hotel group

Situation. A group of 30 hotels ran 900 Entra ID-joined laptops and front-desk tablets on a staff SSID secured with one shared pre-shared key. Rotating that key each quarter meant touching every device at every property. A lost tablet left the key exposed until the next rotation.

What was done. IT created a Cloud PKI root and issuing CA, then issued TPM-backed device certificates through SCEP. A cloud RADIUS service validated the chain and checked the CRL. The group ran an EAP-TLS SSID alongside the old one for the pilot, moved properties in waves, then switched off the pre-shared key network.

Outcome. The scenario arithmetic is straightforward:

• Shared secrets on the staff network fall from one to zero.
• Quarterly key rotation across 30 properties stops entirely.
• A lost tablet becomes one certificate revocation instead of a re-key of 900 devices.
• No on-premises CA, NDES server or connector is needed.

Worked scenario: a 250-store retail chain

Situation. A retail chain issued WiFi certificates to 4,000 store handhelds and laptops through AD CS and two NDES servers. The Intune Certificate Connector ran on a third server. All three servers were due for operating system replacement, and NDES was published through an application proxy.

What was done. The team created a Cloud PKI issuing CA as BYOCA and signed it with the existing AD CS root. The RADIUS server already trusted that root, so only the new issuing CA certificate was imported. SCEP profiles moved to Cloud PKI one store group at a time. Existing certificates stayed valid until renewal, which preserved rollback.

Outcome. The chain retired three servers: two NDES and one connector host. It also removed the internet-published NDES endpoint. No root re-trust was needed on RADIUS or on any device. The AD CS root stayed in place for other workloads.

Where Purple fits

Purple Staff WiFi uses Identity-Based Networks with cloud RADIUS, connected to Microsoft Entra ID, Okta or Google Workspace. Purple is hardware-agnostic across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Why your next WiFi upgrade doesn't need new hardware explains why moving to certificate-based staff access rarely means replacing access points.

Purple runs at 80,000+ live venues (Purple data) with 99.999% uptime, and is ISO 27001 certified. Keep staff and visitors on separate networks: certificate-based Staff WiFi for devices you manage, and Guest WiFi for everyone else.

Frequently asked questions

Can Microsoft Cloud PKI issue WiFi certificates?

Yes. Cloud PKI issues client authentication certificates to Intune-managed Windows, macOS, iOS/iPadOS and Android devices through a SCEP certificate profile. Those certificates authenticate devices to WPA2-Enterprise or WPA3-Enterprise networks using EAP-TLS. Your issuing CA must include the Client Authentication EKU, and your RADIUS server must trust the Cloud PKI root and issuing CA. Cloud PKI does not normally issue the RADIUS server's own certificate. That certificate comes from a public CA or your existing PKI.

Do I still need NDES with Cloud PKI?

No. Cloud PKI answers SCEP requests itself, so you need no NDES server, no Intune Certificate Connector and no reverse proxy publishing NDES to the internet. The SCEP profile in Intune points directly at the SCEP URI shown on your Cloud PKI issuing CA. If you use the bring-your-own-CA option, your private root signs the Cloud PKI issuing CA once. After that, device enrollment never touches your on-premises servers.

How does the RADIUS server trust Cloud PKI certificates?

You import the Cloud PKI root and issuing CA certificates into the RADIUS server's trusted CA store. Download both from the Intune admin center. Import both, because importing only the root causes "unknown CA" rejections. The RADIUS server also needs outbound HTTP access to the CRL distribution point in each certificate, so it can check revocation. For Entra ID-joined devices, it must map certificate identities to Entra ID rather than on-premises Active Directory.

How does revocation work with Cloud PKI?

You revoke a certificate from the issuing CA in the Intune admin center, and Cloud PKI publishes the change to its CRL. Your RADIUS server downloads that CRL and rejects revoked certificates. Because RADIUS servers cache CRLs, a revoked device may connect until the next refresh. Close that gap by also disabling the Entra ID account or device, provided your RADIUS service checks identity status at each authentication.

Should I choose Cloud PKI or SCEP with NDES?

Choose Cloud PKI if you run an Entra ID-joined fleet or plan to retire on-premises PKI servers. It removes the issuing CA, NDES and connector hosts. Keep SCEP with NDES if you have a mature AD CS team, a long-term CA roadmap and other certificate templates. If your NDES servers are due for refresh, Cloud PKI with BYOCA keeps your existing root trust and still retires NDES.

How is Microsoft Cloud PKI licensed?

Cloud PKI is licensed per seat, per month, on top of Intune Plan 1. It comes either as part of the Microsoft Intune Suite or as a standalone Cloud PKI add-on. Check Microsoft's current price list before budgeting, as bundles change. Set the license cost against the Windows Server licenses, virtual machines, proxy publishing and patching effort that an AD CS, NDES and connector stack requires.

Can I keep my existing on-premises root CA with Cloud PKI?

Yes, through the bring-your-own-CA option. You create a Cloud PKI issuing CA, export its certificate signing request and sign it with your existing private root, such as AD CS. Anything that already trusts that root, including your RADIUS server and devices, then trusts the new chain. You add only the issuing CA certificate. You can migrate SCEP profiles group by group while existing certificates stay valid until renewal.

Does Cloud PKI work with my existing access points?

Yes, as long as your access points support 802.1X with WPA2-Enterprise or WPA3-Enterprise. Cloud PKI only affects the certificates on devices and the trust on your RADIUS server. The access points simply forward authentication to RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet all support this. Purple's Staff WiFi runs across all eight as a hardware-agnostic cloud overlay.