Cloud PKI puts a client certificate on every managed device and then stops. Something on your network still has to decide whether to believe that certificate, Microsoft does not sell that something, and choosing it is the real design problem in a cloud-native estate. Whichever way you choose, you are also choosing how much Active Directory you keep.
The lifecycle article ended with the certificate delivered, renewing, and revocable. This one is about the other end of the transaction. Certificate-based network authentication, whether wireless, wired, or VPN, is EAP-TLS: the device presents its certificate, and an authentication server validates the chain, checks revocation, and tells the network gear to open the port. Intune builds every client-side piece of that beautifully. The server side, the thing that terminates EAP-TLS and renders the verdict, is simply not in the catalog, and the gap surprises people who assumed that buying the certificate issuer meant buying the decision point.
The gap nobody owns
Be clear-eyed about the vendor landscape before designing anything. Entra ID speaks no RADIUS. The NPS extension Microsoft offers is a multifactor bolt-on for password-based flows, not an EAP-TLS terminator, and Microsoft’s own architecture guidance quietly encourages moving VPN authentication to SAML rather than investing further in RADIUS at all. Global Secure Access, whatever its merits for application access, is not a network access control plane and does not answer an access point asking whether to admit a laptop. When Microsoft’s own support channels field this question, the answer they give is to consider a cloud RADIUS solution, which is to say: someone else’s product. So the design space has exactly three honest shapes, and each one repositions your Active Directory dependency rather than merely picking a server. If the reason you are reading this is that the directory itself is on its way out, [AD 5] puts this decision in its place among the rest of the estate that has to be replaced before the domain can go.
Option one: keep a small NPS box
The incumbent answer is Network Policy Server, and for a hybrid estate it still works, provided you understand what it demands. NPS does not evaluate certificates in the abstract. It authorizes against Active Directory, which means the certificate a device presents must map to a computer or user object in the directory, and since the strong-mapping enforcement I covered in the lifecycle article became permanent, that mapping must be the embedded security identifier, not a name lookup. Follow the chain of implications. The device must be hybrid joined, its object must sync, and its certificate must carry the SID. An Entra-joined-only laptop has no computer account, nothing to map to, and no registry knob left to soften the rejection; the failure is immediate and unambiguous. NPS as your EAP-TLS terminator therefore quietly commits you to hybrid join for every device that touches the network, which is precisely the dependency most cloud-native programs are trying to shed.
It also keeps the operational estate you were retiring. The NPS role wants a server, a patch cycle, high availability, and its own server certificate, and Cloud PKI cannot issue that certificate because it does not serve Windows Server. You will source it from a public CA or from whatever private CA survives, and either way you are running the infrastructure Cloud PKI was supposed to let you decommission. My verdict: keeping NPS is defensible exactly when Active Directory is staying anyway and your fleet is hybrid joined as a matter of policy. In that estate it is cheap, known, and already trusted. Anywhere else it is an anchor dressed as a bargain.
Option two: RADIUS as a service
The second shape is the one that actually matches a cloud-native estate: a hosted RADIUS service that terminates EAP-TLS in someone’s cloud and validates your Cloud PKI chain directly, with no directory object mapping in the path at all. The trust configuration is refreshingly literal. You give the service your root and issuing CA certificates, you point it at the revocation list, and from then on possession of a valid, unrevoked certificate from your chain is the credential. Several of these services integrate with Intune further, checking device compliance alongside the certificate, and the modern ones speak RadSec so the leg between your access points and their cloud is itself certificate-secured rather than trusting a shared secret across the internet. I am deliberately not naming vendors or comparing them, because the category moves quickly and this decision is architectural: what matters is that the category exists, is mature, and is the only option whose assumptions match an Entra-joined fleet.
The costs are equally plain. It is a subscription, network authentication now depends on your sites reaching the internet, and you have placed the front door of your network in a vendor’s hands. The first two are engineering problems with known answers, and the WAN-outage question in particular deserves a deliberate answer at the switch and access point layer rather than the default behavior, whatever it happens to be, discovered during an incident. The third is a trust decision you should make consciously, the same way you made it when the certificate authority itself moved into Microsoft’s cloud.
Option three: let the box decide
The third shape deletes RADIUS instead of relocating it: some wireless and network vendors can terminate EAP-TLS on the access point or controller itself, validating client certificates against a CA you upload directly to the equipment. No server, no service, no subscription. The trade is expressiveness. Policy at that layer is thin, VLAN and role logic is limited, revocation handling varies by vendor and firmware, and the design binds you to one equipment line as surely as NPS binds you to AD. For a small, single-vendor, single-site estate that simply wants certificate Wi-Fi without standing up infrastructure, it is a legitimate answer and I have recommended it. For anything with growth ambitions, it is the option you outgrow first.
Microsoft sells the certificate. Deciding whether to believe it is infrastructure you still have to choose.
The plumbing that is true in every option
Whichever terminator you pick, three pieces of plumbing follow the certificates around. First, revocation checking runs against the Cloud PKI revocation list, which lives on a Microsoft-hosted public endpoint, and your authenticator must be able to reach it. That sentence has teeth for on-premises servers, because RADIUS boxes tend to live in datacenter segments with no default internet egress, and NPS in its default posture rejects every certificate connection when it cannot locate a revocation list. Notably, the Cloud PKI endpoints do not currently appear in Microsoft’s own network-endpoints allowlist documentation: the URLs are read off each CA’s properties page, and your firewall rules are built from what you find there. Second, the revocation list itself is published on a multi-day cadence with a seven-day validity, so a freshly revoked certificate can authenticate successfully until caches roll over; if that window is unacceptable for a termination scenario, the compensating control is disabling the account and retiring the device, not waiting on the CRL. Third, the server side of EAP-TLS presents a certificate too, and the client profiles you deploy should pin both the trusted root and the expected server names, because a client that will accept any plausible server certificate is a client that will hand its authentication to a rogue access point. The Wi-Fi build sheet later in this family wires all three of these into configuration.
Deciding
Strip the vendor noise away and the decision is about where your directory will be in five years. If Active Directory is a permanent resident and hybrid join is policy, NPS is the cheap, boring, correct answer and you should not let cloud purism talk you out of it. If the estate is Entra joined or heading there, the strong-mapping mathematics make NPS a dead end regardless of sentiment, and hosted RADIUS is the shape that fits, with the box-local option covering the small end of the market. What you should not do is defer the choice, stand up Cloud PKI, and assume the network side will sort itself out, because the certificate rollout will succeed, the Wi-Fi cutover will be scheduled, and the absence of an authenticator will be discovered by the project plan at the worst possible moment. Next in this family: the migration itself, what actually gets to retire when Cloud PKI takes over issuance, and what only pretends to.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3.2] Certificate Lifecycle: Issuance, Renewal, and the Revocations That Do Not Happen
Next: [12.3.4] Migrating Off NDES: What Retires and What Pretends To ›
