Microsoft gives you every primitive you need to run NDES and Cloud PKI side by side, and no doctrine at all for getting from one to the other. The sequencing is yours to own. Done in the right order it is an anticlimax, and the honest accounting at the end is that NDES retires, the connector retires conditionally, and Active Directory Certificate Services almost never does.
This family has designed the hierarchy, walked the lifecycle, and chosen the authenticator. What remains is the move itself, and the first thing to know about it is that you will not find it written down. The official documentation offers a single sentence about reducing workloads for AD CS and a warning not to mix NDES URLs into Cloud PKI profiles, and that is the entire migration corpus. Everything else, the order of operations, the coexistence rules, the accounting of what actually gets decommissioned, is practitioner knowledge. This article is my version of it.
What coexistence actually gives you
The primitives are better than the documentation, so start there. A tenant runs the old world and the new one concurrently without complaint: your NDES-backed SCEP profiles keep issuing through the connector while Cloud PKI profiles issue through the cloud, as long as they remain separate profiles, which they must. A device holds certificates from both hierarchies at once, and nothing breaks, because possession is not the deciding factor in anything. What decides is reference. As I covered in the RADIUS article, a Wi-Fi or VPN profile names the specific certificate profile whose credential it presents, so the certificate a device uses for network authentication changes exactly when you change that reference and not before. That single fact is what makes this migration calm: the risky-looking step, putting new certificates onto the whole fleet, changes nothing in production, and the actual cutover is one dropdown on a network profile, made population by population, reversible by changing it back.
The sequence
The order of operations follows from the dependency chain, and every step is boring by design. Trust goes first: the new root and issuing CA certificates deploy to every platform before anything requests a certificate from the new hierarchy, because a certificate that arrives before its chain is trusted produces exactly the class of intermittent, device-specific failure that consumes a week of troubleshooting. The new SCEP profiles go second, assigned to the same groups as the trust profiles they depend on, and then you stop and verify: issuance climbing in the console, certificates present on sampled devices across every platform you serve, subjects and usages correct. The authenticator learns to trust the new chain third, alongside the old one, and both chains stay trusted for the entire life of the migration. Only then does the cutover happen, the network profile’s certificate reference flipped for a pilot ring, then site by site or population by population, with the old reference one change away the whole time. Last comes retirement, and its order matters as much as everything before it: unassign the old SCEP profile, let the old certificates age toward expiry or revoke them deliberately, and only when the final population has flipped and settled does the old root leave the authenticator’s trust list. Nothing about that sequence is clever. Its entire virtue is that no step can strand a device, because every device can authenticate with the certificate it already has until the moment you deliberately move it.
The failures I have seen all come from compressing that sequence. Trust and SCEP profiles assigned to almost-matching groups, so a slice of devices requests certificates against a root they were never taught. The old root pulled from the RADIUS server while three hundred devices still present old certificates, which looks precisely like a RADIUS outage. And the quiet one: the migration declared finished with the old NDES profile still assigned, both hierarchies issuing forever, because nobody owned the retirement step. A migration without a decommission date is not a migration, it is a second PKI.
What retires, and what pretends to
Now the accounting, because this is where expectation and reality diverge. The NDES role retires completely, and with it the reverse proxy or application proxy that published it, and that is a real win: an internet-facing role with a long, unflattering security history, gone. The Intune Certificate Connector retires conditionally, and the condition is easy to state. Cloud PKI took over SCEP. The connector also brokers PKCS certificates and imported PFX files, and Cloud PKI does neither, so if anything in the estate depends on them, S/MIME encryption being the classic case, the connector stays, patched and monitored, doing the part of its old job the cloud declined to take. There is nothing deprecated about it; Microsoft maintains it actively and says nothing about its retirement. The connector’s fate in your environment is decided by your certificate inventory, not by Microsoft’s roadmap.
You are not retiring your PKI. You are retiring the worst-exposed room of it.
And then Active Directory Certificate Services. Walk the dependency list before promising anyone its decommission: domain controller certificates for LDAPS and certificate-based sign-in, internal web and service TLS, code signing, smart cards, autoenrollment for member servers, and 802.1x for every device that is not Intune-enrolled, the printers, cameras, badge readers, and appliances that authenticate to the same network your laptops do and that Cloud PKI will never issue for. In most estates of any age, several of those are live. What Cloud PKI migrates is Intune-managed endpoint SCEP issuance, full stop. That is the highest-traffic, worst-exposed, most operationally annoying room of the PKI house, and emptying it is worth doing on its own merits. But the house stands, smaller and quieter, and the design posture that follows is to run AD CS deliberately for what remains rather than resentfully as a thing you failed to kill.
The bridge, and its bill
For estates with appliances and infrastructure that already trust the corporate root, the bring-your-own-CA model is the natural bridge: the cloud issuer chains under the existing root, everything that trusted the old hierarchy trusts the new certificates on day one, and the network side of the migration shrinks dramatically. Take the bridge with its bill attached. The constraints from the hierarchy article apply in full, HTTP distribution points settled before the signing ceremony because the URLs are frozen into the certificate at that moment, and the responsibility split persists for the bridge’s whole life: your root’s revocation infrastructure remains yours to operate, and its failure fails every certificate the cloud issuer has produced. A bridge is also, by nature, temporary. If the destination is a fully cloud-anchored hierarchy, that second move, new root, new trust distribution, another ringed cutover, is the same migration again at smaller scale, which is an argument for deciding up front whether the bridge is a phase or the end state, and writing that decision down while everyone still remembers making it.
On the future of AD CS
One prediction circulating in vendor marketing deserves a direct answer: the claim that AD CS is on its way out and migration is therefore urgent. There is no Microsoft signal to that effect, no deprecation notice, no end-of-support date, and the engineering evidence points the other way; Microsoft has continued investing in the role, including early work on post-quantum signature algorithms, while Cloud PKI remains RSA-only. If anything, the cryptographic long game currently favors the on-premises product. Migrate endpoint issuance to Cloud PKI because it removes exposed infrastructure and standing toil, not because anyone’s countdown clock says you must. Urgency invented by people selling the remedy is not a design input.
That closes the doctrine tier of this family. The hierarchy is a one-shot decision, the lifecycle has edges you now know by name, the authenticator is a choice about your directory’s future, and the migration is a boring sequence with an honest ledger at the end. What remains is execution, and the last two pieces are build sheets: standing up the CAs and the profile trio, and wiring certificate-based Wi-Fi end to end.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3.3] The RADIUS Question: EAP-TLS in a Cloud-Native Estate
Next: [12.3.5] Build Sheet: Cloud PKI CAs and the Profile Trio ›
