MIGRATION · ADCS AND NDES
Switch off the last certificate server.
ADCS often survives for three reasons: NDES for Intune, autoenrollment for domain-joined PCs and the Kerberos certificates of the domain controllers. SCEPman covers all three from your Azure tenant, so the CA, the CDP web server and the NDES box can go, one use case at a time.
- No NDES
- Group policy autoenrollment without client software
- Domain controller certificates
- Intermediate CA under your existing root
COMPARED
What it takes to run ADCS, NDES and SCEPman
The effort of each option, as our documentation lists it.
| Microsoft CA with PKCS connector | NDES with SCEP | SCEPman | |
|---|---|---|---|
| Setup | 2 to 3 days and more: CRL distribution points, templates, GPOs, service accounts, connector versions | 2 more days and more: NDES servers, one per certificate type, two more templates, hard to debug | under 30 minutes for the core service |
| Maintenance | CDP monitoring, connector monitoring, operating system updates | All of that, plus renewing the enrollment agent certificate by hand | Health monitoring in Azure; App Service updates the platform |
| Revocation | Manual; searching the CA database is hard | Manual | Automatic from Entra ID, Intune and Jamf; manual in Certificate Master |
| Availability | Several failure points: virtualization, OS, CDP web server, connector | Same, plus NDES | App Service, optionally in two regions behind Traffic Manager |
| Scaling | Needs a CA cluster, by hand | Duplicate NDES servers | Autoscaling or a few clicks |
| Backup | CA database, CA key and configuration, regularly | Same | Core service stateless; key in Key Vault; optional storage backup |
| Attack surface | A tier 0 server talks to the internet through the connector | Inbound access to NDES, a tier 0 asset | Entra-authenticated endpoints, Key Vault and Storage behind private endpoints |
| MDMs | Intune only | Several, with an NDES instance each | Intune, Jamf Pro and other MDMs |
ENTERPRISE EDITION · SINCE 3.0
Certificates for domain-joined Windows without ADCS
Windows clients in your domain already know how to enroll: group policy points them at an enrollment service, Kerberos proves who they are, and autoenrollment does the rest. SCEPman's Active Directory endpoint is that service. You register a service principal in your AD, point the group policy at SCEPman, and computers and users enroll with the tools built into Windows. Nothing to install on the clients.
- Templates for user, computer, RDP server and domain controller, each switched on separately.
- Clients renew on their own when less than 20% of the validity is left.
- Limit enrollment to members of AD groups you name.
- SCEPman adds the SID extension, so the certificates meet the strong mapping domain controllers enforce since KB5014754.
KERBEROS
Certificates for your domain controllers
Domain controllers need a Kerberos authentication certificate so that Entra-joined and hybrid-joined devices can sign in to on-premises resources, and Windows Hello for Business in hybrid key trust needs it, too. SCEPman issues it through the domain controller template of the Active Directory endpoint, or through its dedicated DC endpoint. The certificate carries the extended key usages Client Authentication, Server Authentication, Kerberos Authentication and Smart Card Logon.
COEXISTENCE
Add SCEPman as an intermediate CA below your root
You don't have to replace your root on day one. In Enterprise Edition, SCEPman can run as an intermediate CA: your existing root signs SCEPman's CA certificate, which stays in your Key Vault. Devices that trust your root trust SCEPman's certificates at once, and you move use cases over while ADCS still issues the rest.
A migration path in five steps
Plan the order with your network team: RADIUS servers and VPN gateways have to trust the new root before the first device presents a SCEPman certificate.
- Decide the rootDecide the rootA new SCEPman root, deployed by your MDM and group policy, or SCEPman as an intermediate under your current root.
- Add a SCEP profileAdd a SCEP profileA new SCEP profile in your MDM pointing at SCEPman, next to the old one; remove the NDES profile once the devices have their new certificates.
- Move WindowsMove WindowsEnable the Active Directory endpoint and point the autoenrollment policy at it, template by template.
- Move serversMove serversServer certificates through Certificate Master, EST or the API; domain controllers through their template.
- Retire ADCSRetire ADCSRevoke what's left, publish a last CRL and retire the CA, the CDP and NDES.
Questions about leaving ADCS
01Can SCEPman and ADCS run in parallel?
Yes. They are separate CAs; devices can hold certificates from both while you move.
02Do we need Enterprise Edition for this?
For the Active Directory endpoint, domain controller certificates, Certificate Master and the intermediate CA, yes.
03What about certificates for users who never touch your MDM?
Domain-joined users get theirs through the Active Directory endpoint; everyone else through Certificate Master or self-service enrollment.
04Does SCEPman need to be in our network?
No. Clients reach it over HTTPS; the Active Directory endpoint authenticates them with Kerberos through the service principal you register.
Plan your move off ADCS.
Start with your MDM and NDES, the part that hurts most, and keep ADCS until the last template has moved.