Microsoft Cloud PKI vs AD CS: Which PKI Architecture Should You Choose?

For years, "how do we get certificates onto Intune devices" had exactly one answer: run your own PKI on Active Directory Certificate Services, publish NDES to the internet, install the Certificate Connector, and keep all of it patched and healthy. Microsoft Cloud PKI changes that. It moves the CA itself into the Microsoft cloud, and with it, most of the infrastructure that made certificate deployment a specialist job.

That doesn't make AD CS obsolete. It makes the choice a real architecture decision, with trade-offs on both sides. This post compares the two directly. If you want the full mechanics of the on-premises path first (templates, NDES, the connector, CRLs), they are covered step by step in the Intune PKI deep dive. Here we focus on what changes, and what you should choose.

The left path has four components you build, host and maintain yourself before a single device receives a certificate. The right path has none of them: the CA, the SCEP endpoint and the revocation list are all run by Microsoft, and Intune talks to them directly.

The Two Paths at a Glance

That last point is easy to miss and it matters: from the device's point of view, both architectures use the same SCEP certificate profile. What changes is everything behind the URL in that profile.

The AD CS Path: You Own Every Layer

With AD CS, you build the whole chain yourself:

• An offline Root CA and an online Issuing CA on Windows Server.
• Certificate templates that define what each certificate may contain.
• An NDES server, published to the internet through an application proxy or reverse proxy, for SCEP.
• The Certificate Connector, on the NDES server for SCEP, or on its own server for PKCS.
• CRL and AIA locations on a web server that every relying party can reach.

The reward for all of that is control. AD CS can issue to anything: Intune devices, domain controllers, web servers, network equipment, code signing, smart cards. It supports PKCS and imported PKCS as well as SCEP, and its templates can express almost any certificate policy you need.

The cost is that every one of those components is yours to patch, back up, monitor, keep highly available and eventually migrate. NDES in particular is an internet-facing server whose only job is issuing credentials, which makes it worth protecting carefully.

The Cloud PKI Path: Microsoft Runs the CA

Cloud PKI is configured from Tenant administration > Cloud PKI in the Intune admin center. You create the CA hierarchy there, and Microsoft hosts it:

• A Cloud PKI root CA and one or more issuing CAs, created with a few clicks. The CA private keys are held in Microsoft-managed hardware security modules, never on a server you have to protect.
• Each issuing CA has its own SCEP URI. You copy it into a normal Intune SCEP certificate profile, and devices enroll directly against it.
• Revocation lists are published for you at Microsoft-hosted locations, so there is no CRL web server to run and no root CRL to remember to renew.
• Certificates can be revoked from the admin center, per certificate, without logging on to a CA console.

How a device gets a certificate on this path:

BYOCA: Keeping Your Existing Root

Many organisations can't simply start a new PKI. Their Wi-Fi, VPN and RADIUS infrastructure already trusts an existing AD CS root, sometimes on thousands of devices that Intune doesn't even manage.

Bring Your Own CA (BYOCA) solves exactly that. Instead of creating a new Cloud PKI root, you create a Cloud PKI issuing CA and have its certificate signed by your existing private CA. The result:

• Certificates issued from the cloud chain up to the root your environment already trusts.
• Relying parties that trust your AD CS root need no new trust anchor.
• You still lose NDES and the connector for Intune device certificates, because issuance happens in the cloud.

BYOCA is usually the most realistic migration route for an organisation with an established PKI: keep the root you have, move only the Intune issuing workload to the cloud.

Side-by-Side Comparison

What AD CS Really Costs You

The servers are the visible part. The real cost is ownership:

• At least three servers for a resilient design (offline root, issuing CA, NDES), plus a second NDES and connector for high availability.
• An internet-facing credential service. NDES has to be published, monitored and protected.
• CRL operations. Every CRL in the chain has an expiry date, and an expired one can stop every certificate-based Wi-Fi and VPN connection at once.
• Specialist knowledge. PKI skills are rare, and an AD CS deployment is often understood by one person.
• Security exposure. A misconfigured certificate template is one of the best-known routes to domain compromise, so templates need regular review.

None of this is a reason to avoid AD CS. It is a reason to count it honestly when comparing it against a hosted service.

What Cloud PKI Costs You

Cloud PKI removes most of the operational work, but it has its own trade-offs:

• A licence, through the Intune Suite or the standalone Cloud PKI add-on. It was one of the capabilities that stayed Suite-only in the July 2026 licensing change, so check what you already own.
• SCEP only. No PKCS and no imported PKCS, so S/MIME scenarios that need the same key on every device still need another solution.
• Intune-managed devices only, as above.
• Less control. You choose key sizes, validity and usages, but you don't get the deep template customisation AD CS offers.
• Relying parties still need to trust it. Your RADIUS server or VPN gateway must trust the Cloud PKI chain and be able to reach its CRL, unless you use BYOCA to anchor it to a root they already trust.

Which Should You Choose?

Moving From AD CS to Cloud PKI

If you decide to move Intune certificate issuance to the cloud, treat it as a staged rollout, not a switch.

Summary

AD CS and Cloud PKI answer the same question in opposite ways. AD CS gives you complete control over a PKI that can issue to anything, at the cost of servers, an internet-facing NDES and ongoing operational care. Cloud PKI removes the on-premises CA, NDES and the connector entirely, for a focused job: certificates for Intune-managed devices.

For a cloud-first organisation, Cloud PKI is now the natural default for device certificates. For an organisation with an established PKI, the most practical answer is often both: BYOCA for Intune, AD CS for everything else. Either way, the device side stays the same, an Intune SCEP profile, a TPM-backed key and a certificate that makes Wi-Fi and VPN simply work. For how that device certificate is built and used, see the Intune PKI deep dive.