Most organisations that manage devices with Intune eventually need to put certificates on those devices. The classic way to do that — Active Directory Certificate Services (ADCS) plus the Network Device Enrollment Service (NDES) — was designed for a world where everything lived on the corporate network. If your estate is cloud-first, or you simply don't want to babysit another Windows server, you have real alternatives today. This guide maps the landscape so you can pick deliberately rather than by default.
Why devices need certificates at all
Three scenarios drive almost all certificate deployment through Intune:
- Wi-Fi and wired 802.1X. EAP-TLS authentication uses a client certificate instead of a username and password. It's resistant to credential theft and phishing, doesn't break when passwords rotate, and works for devices that have no user signed in. It's the strongest widely supported method for network authentication, and it's where most Intune certificate projects start.
- VPN. Certificate authentication for VPN gateways (including Always On VPN device tunnels) removes stored credentials from the equation and lets the tunnel come up before anyone logs in.
- Email signing and encryption (S/MIME). Users need certificates to sign and decrypt mail, and the same encryption key must often exist on several devices — a requirement that shapes which delivery protocol you choose, as we'll see.
There are secondary uses too — authenticating to internal web apps, derived credentials, some app-level mutual TLS — but if you nail the three above, you've covered the vast majority of real deployments.
How Intune delivers certificates: SCEP and PKCS
Intune doesn't issue certificates itself in the base product; it orchestrates issuance from a certificate authority using one of two profile types.
SCEP (Simple Certificate Enrollment Protocol) profiles instruct the device to generate a key pair locally, build a certificate signing request, and submit it to a SCEP endpoint along with a one-time challenge that proves Intune authorised the request. The private key is created on the device and never leaves it — on modern hardware it can live in a TPM or Secure Enclave. This is what you want for authentication scenarios like Wi-Fi and VPN, where each device should hold its own non-exportable key.
PKCS profiles work the other way round: the key pair and certificate are created on the server side and delivered to the device as a protected package. Because the key exists outside the device, the same certificate can be delivered to every device a user owns — which is exactly what S/MIME encryption needs, since mail encrypted to one key must be readable on the user's phone, laptop and tablet alike.
The rule of thumb: SCEP for authentication, PKCS when the key genuinely must be portable or recoverable. The SCEP vs PKCS guide goes deeper on renewal behaviour and edge cases.
What NDES is, and why people replace it
NDES is the Windows Server role that exposes a SCEP endpoint in front of an ADCS certificate authority. Paired with the Intune Certificate Connector, it validates Intune's challenges and passes requests to your CA. It works, and thousands of organisations run it — but it accumulates operational friction:
- It's a chain of on-prem dependencies. NDES needs IIS, a service account, an enterprise CA, and Active Directory. Every link is something you patch, monitor and renew.
- It must be reachable from the internet. Devices enrol from anywhere, so the SCEP URL has to be published — typically through Entra application proxy or a reverse proxy. That's a security-sensitive publishing exercise many teams would rather not own.
- It's fragile in well-documented ways. IIS request-size limits, certificate template misconfiguration, connector service account issues, and the infamous single-registration-authority-certificate expiry have filled years of forum threads. When NDES breaks, certificate issuance and renewal stop silently until someone notices failed deployments.
- It assumes you have (and want) ADCS. Cloud-only organisations would need to stand up an entire on-prem PKI just to feed NDES — the tail wagging the dog.
None of this makes NDES wrong. If you already run a healthy ADCS environment with people who understand it, keeping NDES is a legitimate choice. The question is what to do when you don't.
Your options
Option 1: on-prem ADCS + NDES
The incumbent. Zero additional licensing if you have Windows Server, full control over CA policy, and certificates chain to a CA you own outright. The costs are operational: servers to run, an internet-facing endpoint to secure, and a skills dependency. Choose this if you already have mature PKI operations and on-prem infrastructure isn't going anywhere.
Option 2: Microsoft Cloud PKI
Microsoft's first-party answer, available as part of the Intune Suite or as a standalone add-on licence. It gives you Microsoft-hosted certificate authorities with a built-in SCEP service — no NDES, no connector, no ADCS. It can also anchor its issuing CA to an existing private CA if you need certificates to chain to a root you already trust. Integration with Intune is native, and lifecycle management lives in the same admin centre you already use.
Consider the constraints honestly: it's an additional per-user licence on top of Intune, it delivers certificates via SCEP to Intune-managed devices (it is not a general-purpose PKI for servers, appliances or unmanaged machines), and you're adopting Microsoft's operational model for CA management. For many Intune-centric shops those trade-offs are perfectly acceptable, and if you're already buying the Intune Suite it may effectively be free to you. Evaluate it first — it's the path of least resistance for a pure Intune estate.
Option 3: third-party cloud SCEP services
A category of services that host the CA and SCEP endpoint for you and integrate with Intune the same way NDES would — you point your SCEP profile at their URL and upload their root for trust. Compared with Cloud PKI, third parties compete on price (often per-certificate or flat rather than per-user), broader platform support beyond Intune, features like certificate lifecycle visibility and REST APIs, and sometimes support for other MDMs alongside Intune. Compared with NDES, everything in the previous section's complaint list disappears.
The trade-offs: you're trusting an external party to operate a CA that your network authentication depends on, so scrutinise their security posture, tenancy model and key protection. Check exactly how challenge validation is done (static challenges are weaker than per-request validation against Intune). And confirm the service supports the platforms and SAN configurations you need — Android EAP-TLS in particular has specific SAN requirements.
Option 4: run your own PKI in the cloud
Standing up ADCS on an Azure VM, or an open-source CA, moves the hardware problem but keeps every operational one. It's rarely the right answer purely for Intune certificate delivery, though it can make sense as part of a broader PKI consolidation.
A decision framework
Work through these questions in order:
- Do you already run healthy ADCS with NDES, and is it staying? Keep it. Migrating a working PKI to save a server is rarely worth the disruption. Revisit when the hardware, the OS, or the person who understands it is due for retirement.
- Is your estate Intune-only and are you licensed (or willing to license) the Intune Suite? Microsoft Cloud PKI is the obvious first candidate. Test it against your actual profiles — especially Android and any unusual SAN requirements — before committing.
- Do you need per-certificate pricing, multi-MDM support, or capabilities Cloud PKI lacks? Evaluate third-party cloud SCEP services. Run a proof of concept covering issuance, renewal at threshold, and revocation, on every platform you manage.
- Do servers, network devices, or unmanaged machines need certificates from the same CA? Neither Cloud PKI nor most Intune-focused SCEP services will cover this alone. You'll need a broader PKI strategy — possibly a hybrid of a private CA for infrastructure and a cloud service for devices.
Whichever path you choose, the profile-level work is the same: get the subject and SAN configuration right for your RADIUS or VPN infrastructure, set a renewal threshold that survives device offline windows (see certificate renewal pitfalls), and deploy the issuing chain via trusted certificate profiles before the SCEP or PKCS profile lands. The CA behind the endpoint matters less than most people expect; the configuration in front of it causes most of the incidents.