Replace ADCS / NDES
Retire ADCS. Keep the certificates.
A managed exit from Active Directory Certificate Services and NDES. Chain Radius365 under the root your fleet already trusts, cut new enrollment over through Intune SCEP or ACME, and decommission the old CA server on your own schedule — no forced trust migration, no outage window.
The problem
ADCS and NDES were built for a network that doesn't renew itself
Most of the pain isn't the certificates — it's the server underneath them.
- 01
One Windows Server is the whole CA
The issuing CA is a role on a server someone has to patch, back up and keep online. If that box goes down, so does every enrollment and renewal behind it.
- 02
NDES is its own fragile add-on
Intune SCEP through ADCS means standing up NDES, its Intune connector, and a periodically-expiring challenge password cache — another IIS server to patch and monitor.
- 03
Renewals fail silently, then loudly
Without automation, certificate renewal is a person remembering a date. When they don't, Wi-Fi, VPN or an internal service goes down the moment the certificate expires.
- 04
The CA key usually isn't in an HSM
ADCS can be configured with a hardware key store, but most deployments leave the CA's private key in a software key store on the server — one disk image is enough to forge certificates.
- 05
No ACME automation — SCEP or nothing
Internal web servers, reverse proxies and Kubernetes ingresses that expect RFC 8555 automation get nothing from ADCS out of the box; renewal for them stays manual.
- 06
Audit means grepping the Windows Event Log
ADCS writes issuance and revocation events locally. Getting them into a SIEM is a forwarding pipeline you build and maintain yourself, not a feature you turn on.
The fix
Every ADCS pain point, replaced by a managed capability
Nothing here is aspirational — it's what the platform does today.
One Windows Server is the whole CA
A managed CA in Azure — patching, availability and backups are ours, not yours.
NDES is its own fragile add-on
Native Intune SCEP: paste the CA's SCEP URL into an Intune profile. Each request is validated through Intune's third-party CA API — no NDES server, no connector.
Renewals fail silently, then loudly
ACME and Azure Key Vault-issued certificates renew themselves; devices removed from Intune are revoked automatically, and a device's prior certificate is revoked the moment its replacement is issued.
The CA key usually isn't in an HSM
Every CA key is generated inside Azure Key Vault Premium, on non-exportable, HSM-protected keys. Every signature is computed inside the HSM.
No ACME automation — SCEP or nothing
ACME (RFC 8555) runs alongside SCEP on the same platform, for the same CA hierarchy, so servers and workloads automate too.
Audit means grepping the Windows Event Log
An append-only audit log for every issuance, revocation and CRL publication, with event codes that mirror Windows ADCS, exportable to Sentinel, Splunk or a webhook.
How the migration works
A side-by-side migration, not a cutover weekend
Radius365 and ADCS run at the same time until you're ready to retire the old CA.
- 01STEP 1 / 4
Stand up Radius365 alongside ADCS
Create a subordinate CA with an external parent, download its CSR, and sign it on your existing ADCS root — the same way you'd stand up any new issuing CA. Devices that already trust that root trust the new CA immediately; nothing is redistributed.
- 02STEP 2 / 4
Cut new enrollment over
Point new Intune SCEP profiles and ACME clients (certbot, win-acme, cert-manager) at Radius365. Certificates ADCS already issued are untouched and keep working until they expire or are renewed.
- 03STEP 3 / 4
Let the fleet roll over naturally
As devices re-enroll and services renew, they pick up Radius365-issued certificates automatically — auto-enrolled through Intune, or auto-renewed through ACME and Key Vault. No forced re-issuance, no maintenance window.
- 04STEP 4 / 4
Decommission ADCS and NDES on your schedule
Once nothing is enrolling against the old CA, retire the NDES server first, then the CA server itself — or leave the old root as a dormant offline trust anchor if you'd rather not touch it at all.
Side by side
ADCS / NDES vs. Radius365 PKI
Every claim here is something the platform does today — check the product page for the details.
| Feature | ADCS / NDES | Radius365 PKI |
|---|---|---|
| CA private key | Usually a software key store on the CA server; HSM support exists but must be licensed and configured by you. | Generated inside an Azure Key Vault Premium HSM and non-exportable, by default. |
| SCEP for Intune | Requires deploying, patching and monitoring an NDES server plus the Intune connector. | A SCEP URL you paste into an Intune profile. Requests are validated through Intune's third-party CA API — no on-premises component. |
| ACME (RFC 8555) | Not supported. | Built in, with External Account Binding, for certbot, win-acme, cert-manager and any RFC 8555 client. |
| Auto-renewal | Manual, or whatever you script yourself. | Automatic for ACME and Azure Key Vault-issued certificates. |
| Per-device supersede on reissue | Not built in. | A device's prior SCEP certificate is revoked automatically when Intune issues its replacement. |
| Revocation publishing (CRL / AIA / OCSP) | CRL is native; OCSP needs a separately deployed Online Responder role. | CRL, AIA and a live OCSP responder published automatically for every CA. |
| Servers to patch | The CA server, and NDES if you enroll devices. | None — fully managed. |
| Audit trail & SIEM export | Windows Event Log; forwarding to a SIEM is a pipeline you build. | Append-only audit log with export to Microsoft Sentinel / Log Analytics, Splunk or a generic webhook. |
| Billing | Windows Server and CAL licensing, plus the infrastructure it runs on. | A flat monthly plan billed through the Microsoft commercial marketplace — spend counts against your existing Azure or MACC commitment. |
Radius365 PKI can also chain under your existing ADCS root instead of replacing it outright, so trust doesn't have to move on day one. See plans and pricing →
FAQ
Common questions about migrating off ADCS
01Can Radius365 run alongside ADCS during migration?
Yes — that's the intended path. Create a Radius365 subordinate CA with an external parent, sign its CSR on your existing ADCS root, and it's trusted by every device that already trusts that root. ADCS and Radius365 both keep issuing until you decide to cut ADCS off.
02Do I still need NDES?
No. Radius365's SCEP CA gives you a SCEP URL you put directly into an Intune SCEP profile, and each request is validated through Intune's third-party CA API. There's no NDES server, no Intune connector and no on-premises component to run.
03What happens to certificates ADCS already issued?
Nothing — Radius365 doesn't touch them. They keep working until they expire or are renewed normally. You point new enrollment (Intune SCEP profiles, ACME clients) at Radius365, and the fleet transitions certificate by certificate as things renew.
04Does my fleet need to trust a new root certificate?
Not if you don't want it to. Chain the Radius365 issuing CA under your existing ADCS root (or an offline root) by signing its CSR yourself. Devices, RADIUS and VPN infrastructure that already trust that root trust the new CA on day one — nothing to redistribute by GPO.
05Can I decommission ADCS immediately after switching over?
We recommend a phased approach: cut new enrollment over first, confirm nothing still depends on the old CA for issuance, then retire NDES and the CA server. The old root can stay as a dormant offline trust anchor if you'd rather not touch it at all.
06Is there a step-by-step migration guide?
Yes — the documentation has a full tutorial for chaining Radius365 under an existing on-premises ADCS root, including the certreq/certutil commands and common troubleshooting.
Active Directory, Active Directory Certificate Services (ADCS), NDES, Windows Server, Intune, Azure and Entra are trademarks of the Microsoft group of companies. Radius365 PKI is an independently operated service built for Microsoft and Azure environments — it is not produced, endorsed or certified by Microsoft.
Ready to plan the migration off ADCS?
A demo takes thirty minutes: bring your current hierarchy and we'll map it to a Radius365 layout, including how it chains under your existing root.