Microsoft Cloud PKI and Cloud RADIUS Integration Guide

Microsoft Cloud PKI (a cloud-hosted Public Key Infrastructure service) handles certificate issuance for Intune-managed devices, but it does not include a RADIUS server. Without a RADIUS server, devices that receive Cloud PKI certificates still cannot authenticate to a WPA2-Enterprise Wi-Fi network. Understanding this gap in Microsoft Cloud PKI and Cloud RADIUS integration is the first step toward building a complete, cloud-managed 802.1x authentication stack.

Many organizations are mid-migration from on-premises Active Directory Certificate Services (ADCS) and Network Policy Server (NPS) to a fully cloud-managed stack. Microsoft Cloud PKI solves the certificate authority half of that equation. The RADIUS half requires a separate solution.

This article covers what Microsoft Cloud PKI does, where the authentication stack ends, and what a RADIUS server provides that Cloud PKI does not. It also explains the seven-step architecture for connecting them.

What Is Microsoft Cloud PKI?

Microsoft Cloud PKI is a fully managed, cloud-hosted public key infrastructure service available as part of the Microsoft Intune Suite or as a standalone add-on. It replaces the need for on-premises ADCS servers, Network Device Enrollment Service (NDES) connectors, and the Intune Certificate Connector. All core PKI components —the root CA, issuing CA, Simple Certificate Enrollment Protocol (SCEP) service, and Certificate Revocation List (CRL) — are hosted entirely in Microsoft’s cloud. Devices enrolled in Intune receive certificate profiles pushed via Mobile Device Management (MDM). The device generates a key pair, submits a certificate signing request (CSR) to Cloud PKI’s built-in SCEP endpoint, and the issuing CA returns a signed client certificate. No on-premises infrastructure is required for the certificate authority side.

Cloud PKI supports Windows, macOS, iOS/iPadOS, and Android. It handles certificate issuance, renewal, revocation, and lifecycle monitoring from the Intune admin center. For organizations that already have an existing PKI, the Bring Your Own CA (BYOCA) deployment model lets you anchor a Cloud PKI issuing CA to an existing private CA, such as ADCS, preserving your existing certificate hierarchy while gaining cloud-managed issuance.

Does Microsoft Intune Support RADIUS?

No. Microsoft Intune does not include a RADIUS server, and Microsoft has not announced a native cloud RADIUS service for Intune.

This is the single most common point of confusion for organizations deploying Cloud PKI for Wi-Fi. Cloud PKI manages the certificate authority. It does not do anything during network authentication. When a device tries to connect to an 802.1x-secured Wi-Fi network, the access point sends an EAP-TLS authentication request to a RADIUS server. Cloud PKI is not in that loop.

For organizations migrating from an on-premises NPS setup, Microsoft does not provide an equivalent cloud replacement. NPS has its own limitations in a modern environment: authenticating native Entra ID (formerly Azure AD)- joined devices via NPS requires the device to have an Active Directory account, which cloud-native and Entra-only devices do not have. Cloud PKI solves the problem of certificate issuance. It does not solve the RADIUS problem.

What Microsoft Cloud PKI Can Do for Wi-Fi Authentication

Cloud PKI handles everything on the certificate issuance side of the stack. Here is what it manages:

Root CA and Issuing CA in the cloud. When you create a Cloud PKI deployment, you provision a two-tier hierarchy: a root CA and one or more issuing CAs. These live entirely in Microsoft’s cloud, backed by Azure Managed HSM keys on licensed tenants.

SCEP certificate profiles for Intune-managed devices. Cloud PKI exposes a SCEP endpoint URL that you reference in Intune SCEP profiles. The profile specifies the certificate type (device or user), key usage (Client Authentication), key size (RSA 2048, 3072, or 4096), and the SCEP URL. Separate profiles are required per OS platform.

Trusted certificate profiles. Before devices can validate server certificates during EAP-TLS, they need to trust the CA chain. Intune deploys Trusted Certificate Profiles containing the root CA and issuing CA public certificates to all managed devices.

Certificate lifecycle management. Cloud PKI monitors issued certificates from the Intune admin center, supports revocation, and provides a CRL distribution point for relying parties. The CRL validity period is seven days, with refresh every 3.5 days and immediate updates on revocation.

BYOCA support. If your organization has an existing PKI, you do not need to abandon it. BYOCA lets you create a Cloud PKI issuing CA that chains to your existing private CA hierarchy. Intune generates a CSR; your private CA signs it; the resulting issuing CA then handles Intune device certificate issuance.

What You Still Need: A Cloud RADIUS Server

Certificates issued by Cloud PKI establish device identity. Acting on that identity at network authentication time requires a RADIUS server.

When a device presents an EAP-TLS certificate to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point forwards the authentication request to a RADIUS server. The RADIUS server does three things Cloud PKI cannot:

1. Validates the client certificate against the trusted CA chain.
2. Enforces network access policies by determining whether this device, at this moment, should be granted access, placed in a specific VLAN, or denied.
3. Returns RADIUS attributes to the access point (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) for VLAN assignment.

NPS remains an option for organizations with on-premises Active Directory, but it has well-documented limitations with cloud-native device identities. It requires domain accounts for device authentication, which Entra-only devices do not have.

Maintaining NPS servers also reintroduces the on-premises infrastructure that Cloud PKI was meant to eliminate. A cloud RADIUS service built for modern identity environments closes the gap without bringing back on-prem infrastructure.

How to Integrate Microsoft Cloud PKI with Cloud RADIUS

The full working stack for certificate-based 802.1x Wi-Fi using Microsoft Cloud PKI and JoinNow Cloud RADIUS involves seven configuration steps. The SecureW2 platform provides native trust for Cloud PKI CAs and handles EAP-TLS validation at authentication time.

For a complete walkthrough of 802.1x authentication configuration at the protocol level, that article covers the underlying EAP-TLS handshake in detail.

Step 1: Create Root CA and Issuing CA in Intune Cloud PKI

In the Intune Admin Center:

1. Navigate to:
   Tenant Administration → Cloud PKI
2. Create:

• Root CA
• Issuing CA

After deployment:

• Download the Root certificate
• Download the Intermediate/Issuing certificate
• Record the CRL Distribution Point URL
• Record the SCEP URI

The SCEP URI will later be used in Intune SCEP certificate profiles.

Step 2: Deploy Trusted Certificate Profiles to Devices

To establish trust between Microsoft Cloud PKI and SecureW2 Cloud RADIUS:

1. Navigate to:
   PKI Management → Certificate Authorities
2. Import:

• Root CA certificate
• Intermediate CA certificate

1. Configure CRL settings using the CRL Distribution Point URLs from Microsoft Cloud PKI.

This allows Cloud RADIUS to validate certificates issued by Microsoft Cloud PKI during EAP-TLS authentication.

Step 3: Create a Cloud RADIUS Network Profile

Create a new Network Profile inside the JoinNow Management Portal.

Configure:

• WPA2-Enterprise or WPA3-Enterprise
• EAP Type: EAP-TLS
• TLS authentication framework

Once configured:

• Download the RADIUS server certificate

This certificate will later be deployed to managed devices using Intune Trusted Certificate Profiles.

Step 4: Configure Entra ID Lookup Policies

SecureW2 Cloud RADIUS can integrate directly with Microsoft Entra ID to validate user and device identity during authentication.

This enables organizations to:

• Verify users are still active
• Validate device status
• Enforce policy-based authentication decisions
• Apply VLAN segmentation dynamically

Unlike static certificate validation alone, identity lookups help organizations enforce Zero Trust access policies during every authentication request.

Step 5: Create Trusted Certificate Profiles in Intune

In Intune:

1. Navigate to:
   Devices → Configuration Profiles → Create Profile
2. Create Trusted Certificate Profiles for:

• Root CA
• Intermediate CA
• RADIUS Server Certificate

These profiles ensure devices trust both the Microsoft Cloud PKI certificate chain and the Cloud RADIUS server certificate during EAP-TLS authentication.

Step 6: Configure SCEP Certificate Profiles

Next, create SCEP Certificate Profiles inside Intune.

Configure:

• Client Authentication usage
• RSA key settings
• SCEP URI from Microsoft Cloud PKI
• Certificate subject settings

Assign the SCEP profile to managed devices.

Devices will automatically enroll for certificates through Microsoft Cloud PKI using SCEP.

Step 7: Deploy Wi-Fi Profiles and Configure Network Infrastructure

1. Create Wi-Fi Profiles in Intune
2. Configure:

• WPA2-Enterprise or WPA3-Enterprise
• EAP-TLS authentication
• Trusted Root certificates
• SCEP client certificate selection

1. Configure wireless controllers or access points to use SecureW2 Cloud RADIUS.

Once deployed, devices can authenticate to enterprise Wi-Fi networks using certificates issued by Microsoft Cloud PKI and validated through SecureW2 Cloud RADIUS.

Limitations of Microsoft Cloud PKI

Cloud PKI is a strong solution for a specific scope. Understanding its constraints before deployment prevents problems downstream.

Licensing cost. Cloud PKI requires either the Microsoft Intune Suite ($10/user/month list price as of June 2026) or the Cloud PKI standalone add-on ($2/user/month list price as of June 2026) on top of an existing Intune Plan 1 subscription. For large device fleets, that cost adds up relative to purpose-built PKI platforms.

Intune enrollment required. Cloud PKI can only issue certificates to devices enrolled in Intune. On-premises servers, BYOD devices not enrolled in Intune, and non-managed devices cannot receive certificates from Cloud PKI. This includes the RADIUS server itself; Cloud PKI cannot issue certificates to the RADIUS server, so a separate CA is required for the RADIUS server certificate.

CA count limit. A maximum of six CAs can be created per tenant across all types (root, issuing, BYOCA). Larger organizations with complex PKI hierarchies may hit this limit.

CA configuration is immutable. Once a Cloud PKI CA is created, its properties (extended key usages, CA name, key settings) cannot be edited. If a future requirement demands a different EKU, a new CA hierarchy must be built from scratch.

No OCSP support. Cloud PKI publishes CRLs but does not support OCSP for real-time certificate revocation checking. RADIUS servers that perform revocation validation must check the CRL. As of June 2026, the CRL refresh cadence is every 3.5 days, so recently revoked certificates may remain valid at the RADIUS layer for a short time. (Verify CRL refresh cadence is still current before publishing — Microsoft has updated this value previously.)

RSA-only keys. Elliptic Curve (EC) keys are not supported. Organizations with requirements for ECDSA certificates cannot use Cloud PKI for those use cases.

Trial CA key limitations. CAs created during an Intune Suite or Cloud PKI trial use software-backed keys. After purchasing a license, those keys cannot be upgraded to HSM-backed keys. Production deployments should be created after licensing is confirmed.

Why SecureW2 Cloud RADIUS Fills the Gap

JoinNow Dynamic PKI and JoinNow Cloud RADIUS are purpose-built for certificate-based network authentication in modern, cloud-managed environments. Where Cloud PKI ends, the SecureW2 platform picks up.

JoinNow Cloud RADIUS natively trusts Microsoft Cloud PKI CAs. Import your Cloud PKI root and issuing CA certificates, and Cloud RADIUS can immediately validate EAP-TLS authentication requests from devices holding Cloud PKI certificates. No on-premises connectors or NPS are required.

Cloud RADIUS also supports identity lookups at authentication time. When a device authenticates, Cloud RADIUS queries Entra ID (or Okta, or Google Workspace) to verify the user or device is still active and compliant. If a user is disabled in Entra or a device falls out of Intune compliance, access is revoked at next authentication without waiting for certificate expiration.

JoinNow Dynamic PKI extends certificate automation for organizations that need more than Cloud PKI provides: support for BYOD devices not enrolled in Intune, more flexible PKI hierarchy options, and ACME-based enrollment alongside SCEP.

Intune and Cloud PKI handle client certificate issuance. SecureW2 Cloud RADIUS enforces network access. Together, they give IT teams a fully cloud-managed 802.1x stack without on-premises servers.

If you are deploying Microsoft Cloud PKI and need to close the RADIUS gap, schedule a demo with SecureW2 to see how Cloud RADIUS integrates with your existing Intune and Entra ID environment.

---

Frequently Asked Questions

Does Microsoft Intune support RADIUS servers?

No. Microsoft Intune does not include a RADIUS server. Cloud PKI handles certificate issuance, but a separate RADIUS server is required for 802.1x Wi-Fi and wired network authentication.

What is Cloud PKI in Intune?

Microsoft Cloud PKI is a cloud-hosted certificate authority service included in the Intune Suite. It issues, renews, and revokes digital certificates for Intune-managed devices without requiring on-premises ADCS servers or NDES connectors.

How does certificate-based Wi-Fi authentication work with Intune?

Intune pushes a SCEP certificate profile to managed devices. Devices request a client certificate from the Cloud PKI SCEP endpoint. Intune also pushes a Wi-Fi profile configured for EAP-TLS, pointing to a RADIUS server. When the device connects to Wi-Fi, the RADIUS server validates the client certificate and grants or denies access.

What is the difference between SCEP and PKCS in Intune?

SCEP uses a challenge-response mechanism where the device generates its own key pair, and the private key never leaves the device. PKCS#12 certificates are generated by the CA and delivered to the device, including the private key. For 802.1x authentication with Microsoft Cloud PKI, SCEP is the standard approach because the built-in certificate registration authority uses it.

Can I use Microsoft Cloud PKI without a third-party RADIUS server?

Only if you already have a RADIUS server, such as an on-premises NPS instance. If you are building a fully cloud-managed stack and have no existing RADIUS infrastructure, you need a cloud RADIUS service. Microsoft does not provide one.

How do I configure RADIUS in Intune?

Intune does not host or configure a RADIUS server. Intune pushes Wi-Fi profiles that reference an external RADIUS server address. You configure the RADIUS server separately (SecureW2, NPS, or another solution), then reference that server’s IP and shared secret in the Intune Wi-Fi profile.