Replacing Microsoft AD CS with PKIaaS: Migration Strategy and Pitfalls

Microsoft Active Directory Certificate Services has been the default enterprise PKI for Windows environments for over two decades. For organizations running a standard two-tier AD CS hierarchy with a standalone offline root CA and an enterprise issuing CA integrated with Active Directory, autoenrollment works reliably for domain-joined machines and users. The problem is not that AD CS does not work. The problem is everything it does not do: it does not handle non-Windows systems well, it has no native ACME or EST support, it requires on-premises infrastructure to operate and maintain, it gives security teams limited visibility into what has been issued, and it becomes a significant operational liability as Windows PKI engineers age out of organizations and are not replaced.

This guide covers the end-to-end migration from Microsoft AD CS to PKI as a Service: the architecture of the replacement, how autoenrollment continues without interruption during migration, how to map AD CS certificate templates to PKIaaS certificate profiles, how to manage the coexistence period, and the pitfalls that most migration projects encounter. It is written for the security architects and PKI engineers doing the work, not a high-level overview for management.

Quick Answer: How Does AD CS Replacement Work?

AD CS autoenrollment is replaced by deploying a PKIaaS WSTEP autoenrollment proxy in the on-premises environment. The proxy receives certificate requests from Windows autoenrollment clients (which have not changed at all), authenticates the requester identity against Active Directory, and forwards the approved request to the PKIaaS issuing CA. The Group Policy Object Certificate Enrollment Policy is updated to point to the proxy’s WSTEP endpoint instead of the AD CS issuing CA. When the GPO is applied, Windows machines begin obtaining certificates from PKIaaS without any client-side changes. Non-Windows systems migrate in parallel via ACME, EST, or SCEP. Existing AD CS-issued certificates run to their natural expiry during the coexistence period. AD CS is decommissioned when the last certificate it issued has been replaced or expired.

Key Takeaways

• Windows autoenrollment does not need to be rebuilt. The WSTEP protocol used by Windows autoenrollment since Windows Server 2008 R2 is supported by PKIaaS autoenrollment proxy deployments. The migration requires deploying an on-premises proxy and updating a GPO, not re-engineering how Windows clients request certificates.
• Certificate template migration is the most labor-intensive preparation step. Every active AD CS template must be audited and mapped to a PKIaaS certificate profile before the GPO is changed. Templates that issue certificates with the wrong profile after migration cause authentication failures that are difficult to diagnose under time pressure.
• The coexistence period, during which PKIaaS issues new certificates while AD CS-issued certificates expire naturally, is the safest migration pattern for large environments. It avoids mass revocation of existing certificates and keeps the user experience unchanged. It requires a CLM layer that tracks certificates from both CAs in a unified inventory.
• The AD CS root CA trust store distribution is the most commonly missed migration step. Removing the AD CS root from domain machines’ trusted root stores must happen via Group Policy after the AD CS CA is decommissioned, not before. If removed prematurely, existing AD CS-issued certificates still in service will fail validation.
• Domain Controller certificates are the most critical AD CS certificates to migrate carefully. DCs use certificates for LDAPS, Kerberos PKINIT, and smart card logon. A DC certificate failure caused by a mis-configured PKIaaS profile or an enrollment timing issue can cause domain authentication failures for the entire environment.

Understanding What AD CS Is Actually Doing

Before planning the migration, it is worth being precise about what AD CS components are in scope. A standard enterprise AD CS deployment has the following elements, each of which has a PKIaaS equivalent or migration path.

Standalone offline root CA: A Windows Server with AD CS role installed, not domain-joined, used exclusively to sign the enterprise issuing CA certificate and the CRL. It is kept offline between uses. In the PKIaaS model, this is replaced by the PKIaaS provider’s offline root CA, which performs the same function with FIPS 140-3 Level 3 HSM-backed keys and documented M-of-N key ceremony procedures.

Enterprise issuing CA: A domain-joined Windows Server with AD CS role installed, connected to Active Directory. This CA publishes certificate templates to AD, issues certificates based on those templates, publishes CRLs to a distribution point, and responds to certificate requests from domain-joined machines through the MS-WCCE (DCOM-based) or WSTEP (HTTP-based) protocols. In the PKIaaS model, this is replaced by the PKIaaS issuing CA, which issues certificates via the autoenrollment proxy.

Certificate templates: Active Directory objects published by the enterprise CA that define the certificate parameters (subject fields, key usage, EKU, validity period, CSP/KSP restrictions, issuance policy) and the enrollment permissions (which security groups can auto-enroll, enroll, or read the template). In the PKIaaS model, templates are replaced by PKIaaS certificate profiles.

Group Policy autoenrollment: GPO settings that trigger Windows autoenrollment and configure the Certificate Enrollment Policy (CEP). The CEP tells the autoenrollment client which CA to contact for each certificate type. In the PKIaaS model, the CEP is updated to point to the PKIaaS autoenrollment proxy’s WSTEP endpoint.

CRL Distribution Point (CDP) and AIA: HTTP endpoints (and sometimes LDAP paths) where the enterprise CA publishes its Certificate Revocation List and Authority Information Access (OCSP and CA certificate download). In the PKIaaS model, the provider operates these endpoints. Certificates issued by PKIaaS will reference the provider’s CDP and AIA URLs in the certificate extensions rather than the AD CS server’s URLs.

Step 1: Pre-Migration Audit of the AD CS Environment

The most common cause of migration failure is incomplete knowledge of the existing AD CS environment at the time the migration starts. The audit phase should produce a complete picture of what is in scope before any configuration changes are made.

Enumerate Active Certificate Templates

Run the following command on the enterprise CA server to list all published templates and their version numbers:

certutil -catemplates

For each template, document: the template display name and internal name; the certificate validity period; the subject name source (built from AD attributes, supplied in request, or common name only); the key usage and extended key usage OIDs; the minimum key size and allowed CSP/KSP; the enrollment permissions (which security groups have Auto-Enroll, Enroll, and Read); and whether the template uses subject alternative names from AD (UPN, email, DNS, IP).

Then cross-reference against the CA’s issued certificate log to determine which templates have actually been used. Templates with zero issued certificates in the last 12 months are inactive and do not need to be migrated. Trim the migration scope to active templates only.

Pay particular attention to these certificate types, which require careful migration planning:

• Domain Controller certificates: Used for LDAPS, Kerberos PKINIT, and smart card authentication. The Domain Controller template (or Domain Controller Authentication template) issues certificates to all DCs automatically. These must be the first certificates verified in the pilot phase and the last to be migrated at scale because a failure here affects the entire domain.
• Domain Controller Authentication certificates: A superset of the Domain Controller template, adding Client Authentication EKU alongside the Server Authentication and Smart Card Logon EKUs. Most modern AD environments use this template for DCs.
• Kerberos Authentication certificates: Used for Kerberos PKINIT. These must carry the Client Authentication, Smart Card Logon, and Kerberos Client Authentication EKUs (1.3.6.1.5.2.3.4). If the PKIaaS profile for this template is missing the Kerberos OID, Kerberos PKINIT will fail silently.
• Smart Card Logon certificates: Used for user authentication with physical or virtual smart cards. Subject Alternative Name must include the user’s UPN from AD. If the UPN is missing from the SAN in the PKIaaS profile, smart card logon fails.
• Computer certificates: Machine authentication for 802.1X wired/wireless and VPN. Subject must include the machine’s FQDN as CN and in the SAN DNS field.

Build the Certificate Inventory

Export the AD CS CA’s issued certificate database to a CSV using certutil or the Certification Authority MMC snap-in. This gives the expiry profile of every outstanding certificate, which certificates are closest to expiry, and which templates issued the most certificates. The expiry profile determines how urgently the migration must move: if large numbers of high-priority certificates (Domain Controller, 802.1X computer) are expiring within 90 days, the migration must proceed at pace.

Also run network certificate discovery across the environment using a CLM tool to find certificates deployed on systems that may not be in the AD CS issued certificate log, such as certificates issued by a different CA but deployed on systems that rely on the AD CS root for trust.

Document the GPO Enrollment Configuration

Document all GPOs that contain certificate enrollment settings: the autoenrollment GPO settings (Computer Configuration and User Configuration), the Certificate Enrollment Policy servers configured (CEP URLs), and which OUs each GPO applies to. This is the map you will use to update the enrollment policy during migration.

Step 2: Stand Up the PKIaaS CA Hierarchy

Before any AD CS configuration is changed, the PKIaaS CA hierarchy must be fully operational, the root CA key ceremony must be complete with a documented evidence package, and all certificate profiles must be configured and tested. Changing the GPO before the PKIaaS CA is ready is the single most common cause of migration-related outages.

The PKIaaS CA hierarchy setup involves: creating the root CA with an offline, FIPS 140-3 Level 3 HSM-backed key through a documented M-of-N key ceremony; creating one or more issuing CAs signed by the root; configuring the OCSP responder and CRL distribution points; and distributing the new PKIaaS root CA certificate to the domain trust store via Group Policy before any machine begins enrolling from it. That last point is critical: if a machine requests a certificate from PKIaaS before the PKIaaS root is in its trusted root store, the certificate will be issued but the machine will not trust its own certificate.

Distribute the PKIaaS root CA certificate to all domain machines via the Trusted Root Certification Authorities GPO policy at least one Group Policy refresh cycle (typically 90 minutes, or triggered manually with gpupdate /force) before the enrollment policy is changed to point at PKIaaS.

Step 3: Map AD CS Templates to PKIaaS Certificate Profiles

For each active AD CS certificate template identified in the audit, create a corresponding PKIaaS certificate profile. The profile must reproduce the template’s certificate content accurately; differences in key usage, EKU, or subject structure cause certificate-dependent applications to reject the PKIaaS-issued certificate even if the enrollment itself succeeds.

The mapping table below covers the most common AD CS templates and their critical profile attributes.

AD CS Template	Key Usage	Extended Key Usage (EKU)	Subject / SAN requirements	Critical migration note
Domain Controller	Digital Signature, Key Encipherment	Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), Smart Card Logon (1.3.6.1.4.1.311.20.2.2)	CN = DC FQDN; SAN DNS = DC FQDN; SAN DNS = domain name	Test with a non-production DC first. A failed DC cert breaks LDAPS and Kerberos PKINIT.
Domain Controller Authentication	Digital Signature, Key Encipherment	Server Auth, Client Auth, Smart Card Logon, KDC Authentication (1.3.6.1.5.2.3.5)	CN = DC FQDN; SAN DNS = DC FQDN; SAN DNS = domain name	KDC Authentication OID is required for newer Kerberos PKINIT; missing it causes intermittent auth failures.
Computer (Machine)	Digital Signature, Key Encipherment	Client Authentication (1.3.6.1.5.5.7.3.2)	CN = machine FQDN (from AD); SAN DNS = machine FQDN	Used for 802.1X. If NAC switches validate EKU, confirm Client Auth OID is present.
User	Digital Signature, Key Encipherment	Client Authentication, Secure Email (1.3.6.1.5.5.7.3.4), Encrypting File System (1.3.6.1.4.1.311.10.3.4)	CN = user display name (from AD); SAN RFC822 = user email; SAN UPN = user UPN	EFS-encrypted files will not be accessible with a new user cert until EFS re-encryption is completed.
Smart Card Logon	Digital Signature, Key Encipherment	Client Authentication, Smart Card Logon (1.3.6.1.4.1.311.20.2.2)	CN = user display name; SAN UPN = user UPN	UPN in SAN is mandatory for smart card logon. Missing UPN means logon fails at the domain controller.
Web Server (IIS)	Digital Signature, Key Encipherment	Server Authentication	CN = server FQDN; SAN DNS = server FQDN (+ additional SANs per server)	SANs are often supplied in the request for web server certs. Confirm the PKIaaS profile allows requester-supplied SANs with appropriate allowlist constraints.
Code Signing	Digital Signature	Code Signing (1.3.6.1.5.5.7.3.3)	CN = organization or department name	If code signing is done with HSM-backed keys, confirm the PKIaaS profile supports server-side key generation or CSR-based enrollment.
OCSP Response Signing	Digital Signature, Non-Repudiation	OCSP Signing (1.3.6.1.5.5.7.3.9)	CN = OCSP responder name	PKIaaS typically operates its own OCSP responder; this template is usually not migrated unless a customer-operated OCSP is required.

Step 4: Deploy the Autoenrollment Proxy

The autoenrollment proxy is the on-premises component that bridges the Windows autoenrollment protocol (WSTEP, documented in MS-WSTEP) to the PKIaaS certificate issuance API. It must be deployed and validated before the GPO enrollment policy is updated. Deploying the proxy after the GPO change is the most reliable way to break autoenrollment for every machine in the domain simultaneously.

Proxy Architecture and Placement

The autoenrollment proxy is typically a Windows Server application (or a Linux-based service depending on the PKIaaS provider’s implementation) deployed in the on-premises network. It requires: outbound HTTPS connectivity to the PKIaaS API endpoint (typically on port 443); inbound HTTPS connectivity from domain-joined machines on the WSTEP port (typically 443 or a configured alternative); read access to Active Directory (LDAPS on port 636 recommended) for requester identity validation and subject attribute population; and a valid HTTPS certificate for its own WSTEP endpoint (which can be issued by the PKIaaS CA after it is operational).

For high availability, deploy at least two proxy instances behind a load balancer. A single proxy instance is a single point of failure for all Windows autoenrollment in the domain. The load balancer should use HTTPS pass-through, and the proxy instances should be configured with the same PKIaaS API credentials and the same certificate profile mappings so that any instance can serve any autoenrollment request.

Validating the Proxy Before GPO Change

Before updating any GPO, validate that the proxy is working correctly by submitting a manual test enrollment request from a domain-joined test machine. The test machine should be in a dedicated test OU that is not affected by the production enrollment GPO. Configure a temporary CEP pointing at the proxy on the test machine using the local Group Policy editor (gpedit.msc) rather than the domain GPO, and trigger autoenrollment manually using certreq -enroll -autoenroll or gpupdate /force followed by checking the machine’s certificate store (certmgr.msc) for a new certificate issued by the PKIaaS CA.

Verify the certificate: confirm the issuer is the PKIaaS issuing CA, not the AD CS issuing CA; confirm the subject and SAN match the expected values from the AD CS template; confirm the EKUs match the profile specification; and confirm the certificate is valid and not showing any chain validation errors in certmgr. If all four checks pass, the proxy is configured correctly and the GPO change can proceed.

Step 5: Update the Certificate Enrollment Policy in GPO

The Certificate Enrollment Policy (CEP) is configured under Computer Configuration and User Configuration in Group Policy:

Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Auto-Enrollment

Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Certificate Enrollment Policy

The migration sequence for the GPO change is as follows.

Phase A: Pilot OU (Day 1 to Day 7). Create a new GPO linked to a pilot OU containing a small set of test machines and test user accounts. In this GPO, configure the Certificate Enrollment Policy to point to the PKIaaS autoenrollment proxy URL as the primary CEP server, with the AD CS CEP as a secondary (fallback) server. Apply the GPO. Verify that machines and users in the pilot OU auto-enroll from PKIaaS. Check that no certificate-dependent applications (802.1X, LDAPS, VPN) are failing in the pilot OU. Run this configuration for at least 48 hours and through at least one full Group Policy refresh cycle before proceeding.

Phase B: Staged rollout by OU (Week 2 to Week 4). Apply the updated CEP GPO to production OUs in stages: workstations first (lower blast radius if something goes wrong), then servers, then domain controllers. Move DCs last because a DC certificate failure has domain-wide impact. At each stage, monitor the PKIaaS autoenrollment proxy logs for errors, monitor the Event Log on enrolled machines (Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-AutoEnrollment) for enrollment failures, and verify that newly enrolled machines are getting their certificates from the PKIaaS CA.

Phase C: Domain Controller migration (Week 3 to Week 4). DC certificate migration deserves its own phase because of the impact of a failure. Before changing the CEP for DCs, verify in the test OU that the DC-equivalent certificate profile (Domain Controller Authentication) is working correctly with the correct EKUs including the KDC Authentication OID. Change the CEP for the Domain Controllers OU. After the next Group Policy refresh, verify that each DC has obtained a certificate from the PKIaaS CA and that LDAPS, Kerberos PKINIT, and smart card logon continue to function. Keep the AD CS CA online during this phase.

Step 6: Migrate Non-Windows Systems

AD CS has limited native support for non-Windows certificate consumers. Most organizations with mixed environments have addressed this with NDES (Network Device Enrollment Service) for SCEP, or with manual certificate issuance for Linux servers. The PKIaaS migration is an opportunity to replace these workarounds with modern enrollment protocols.

Linux servers and applications: Migrate from manual certificate issuance or NDES/SCEP to ACME (RFC 8555) with the PKIaaS ACME endpoint. Linux ACME clients (certbot, acme.sh, or the ACME client built into HashiCorp Vault, Kubernetes cert-manager, or infrastructure management tools) can be configured with the PKIaaS ACME endpoint URL and External Account Binding credentials. Renewal automation becomes fully automatic, eliminating the manual renewal process that is common in mixed AD CS environments for Linux servers.

Network devices (routers, switches, access points): Migrate from NDES/SCEP to the PKIaaS SCEP endpoint. Most network device vendors (Cisco, Palo Alto, Fortinet, Aruba) support SCEP for certificate enrollment. The SCEP challenge password model changes from the NDES one-time password model to the PKIaaS SCEP challenge model; update the SCEP configuration on devices accordingly.

MDM-managed devices (Intune, Jamf, Workspace ONE): If the AD CS environment was serving MDM-managed devices through NDES and Intune SCEP profiles, migrate the SCEP profile endpoint to the PKIaaS SCEP endpoint with native Intune integration. PKIaaS providers with native Intune integration eliminate the NDES server from the architecture entirely, which is itself a significant operational simplification. For Jamf-managed macOS and iOS devices, configure the new Jamf SCEP profile to point to the PKIaaS SCEP endpoint.

DevOps and CI/CD pipelines: Migrate from manual certificate issuance or SCEP to ACME or the PKIaaS REST API. Code signing certificates used in CI/CD pipelines can be provisioned through the PKIaaS REST API or ACME, with private keys stored in HSM-backed key storage rather than developer workstations or pipeline secrets stores.

Managing the Coexistence Period

During the coexistence period, two CA hierarchies are simultaneously active: the original AD CS CA issuing renewals for machines that have not yet migrated, and the new PKIaaS CA issuing certificates for machines that have been updated. This is a normal and expected state during migration. The risk is losing track of which certificates are issued by which CA, and failing to notice when an AD CS-issued certificate expires without being renewed by PKIaaS.

Managing the coexistence period requires a CLM layer that maintains a unified certificate inventory across both CAs. Encryption Consulting’s CertSecure Manager provides connectors for both the AD CS CA (via the AD CS API or certificate database export) and the PKIaaS CA (via the PKIaaS API), displaying both inventories in a single view with issuing CA attribution. This enables the migration team to track migration progress (what percentage of certificates have moved to PKIaaS), identify machines that have not received their PKIaaS certificate after the GPO change (which may indicate enrollment failures), and catch AD CS-issued certificates approaching expiry that were not renewed by PKIaaS due to a profile mismatch or enrollment failure.

The coexistence period ends when the last certificate issued by the AD CS CA has either expired or been replaced by a PKIaaS-issued certificate. Do not decommission the AD CS CA while it still has active, unexpired certificates in the environment. Keep the AD CS CA online and its CRL publication current throughout the coexistence period to ensure that AD CS-issued certificates can be validated and revoked if needed.

Rollback Planning

Every phase of the migration should have a documented rollback procedure that can be executed within 30 minutes if a critical failure is detected. The rollback procedures are straightforward because the migration does not delete or modify the existing AD CS infrastructure until the decommissioning phase.

For the GPO CEP change: the rollback is reverting the CEP configuration to the AD CS CEP URL and running gpupdate /force on affected machines. Machines that have already received a PKIaaS certificate will continue using it until it expires; the rollback prevents new enrollments and renewals from going to PKIaaS. Because AD CS is still online and its CRL is current, the rollback does not cause any certificate failures for machines that already enrolled from PKIaaS (their certificates remain valid under the PKIaaS chain).

For the autoenrollment proxy: if the proxy fails, Windows autoenrollment will fail for machines configured to use it as the primary CEP. With a properly configured secondary CEP pointing at AD CS, Windows will fall back to AD CS enrollment automatically. Always configure the AD CS CEP as the secondary CEP during the migration phases, not after.

Do not revoke the AD CS issuing CA certificate as part of any phase until the decommissioning phase. Premature revocation of the AD CS issuing CA causes every certificate it issued to fail validation immediately, which is a domain-wide outage for environments where AD CS-issued certificates are still in service.

Common Migration Pitfalls

Pitfall 1: Changing the GPO Before the Proxy Is Validated

The most common migration failure. If the CEP is updated to point at the PKIaaS proxy before the proxy has been validated against each active certificate template profile, the first autoenrollment cycle produces either enrollment errors (proxy not reachable or returning errors) or certificates with incorrect content (wrong EKU, wrong subject structure). Both outcomes are operationally disruptive at scale. Always complete the test OU validation phase fully before touching any production OU GPO.

Pitfall 2: Distributing the PKIaaS Root Too Late

If a machine receives a certificate from the PKIaaS CA before the PKIaaS root CA certificate is in its Trusted Root Certification Authorities store, the machine will not trust the certificate it just received. The certificate will fail chain validation even though it was correctly issued. Applications that check chain trust at startup (IIS, RDP, 802.1X supplicants) will fail. Distribute the PKIaaS root CA certificate via GPO before the enrollment policy changes. Verify it is present in certmgr on test machines before proceeding.

Pitfall 3: Missing EKUs in Profile Configuration

AD CS templates use specific EKU OIDs that applications check precisely. The Kerberos Client Authentication OID (1.3.6.1.5.2.3.4) required for Kerberos PKINIT is not included in the standard Client Authentication EKU set and must be added explicitly to the Domain Controller Authentication profile in PKIaaS. The Smart Card Logon OID (1.3.6.1.4.1.311.20.2.2) must be present for smart card authentication. The OCSP No Check extension (1.3.6.1.5.5.7.48.1.5) must be present on OCSP responder certificates. Missing any of these causes application-specific failures that may not manifest during initial enrollment testing but appear when the feature is exercised in production.

Pitfall 4: Removing the AD CS Root from Trust Stores Too Early

Removing the AD CS root CA certificate from the domain Trusted Root Certification Authorities store via GPO before all AD CS-issued certificates have expired or been replaced causes every AD CS-issued certificate in the environment to fail chain validation immediately. This includes certificates on servers, domain controllers, and network equipment that have not yet migrated to PKIaaS. The AD CS root must remain in trust stores until the coexistence period is complete. The GPO to remove it should be staged and piloted on a non-critical OU first to verify no remaining certificates depend on it before applying domain-wide.

Pitfall 5: Not Accounting for NDES and SCEP Consumers

Organizations often discover during the migration that more NDES consumers exist than were initially scoped. Network devices, Intune SCEP profiles, and third-party applications that use NDES for certificate enrollment are often not tracked in the AD CS certificate template inventory because NDES operates independently of the enterprise CA’s template-based enrollment. Audit NDES traffic logs (IIS logs on the NDES server) to identify all SCEP consumers before decommissioning, and confirm each has been migrated to the PKIaaS SCEP endpoint before NDES is taken offline.

Pitfall 6: EFS-Encrypted Files After User Certificate Replacement

If the AD CS User template included the Encrypting File System EKU and users have EFS-encrypted files, replacing user certificates without re-encrypting those files first will make the files inaccessible with the new certificate. Before migrating user certificates for accounts that may have used EFS, check for EFS-encrypted files and either decrypt them first or ensure the EFS recovery agent certificate is available. Most modern environments disable EFS, but older AD environments frequently have it enabled in the default User template.

Step 8: Decommissioning AD CS

AD CS decommissioning should happen in the following sequence, not before the conditions at each step are met.

Confirm through the CLM unified inventory that no active certificates attributable to the AD CS issuing CA remain in the environment. If any remain, they must be replaced before decommissioning proceeds. Revoke the AD CS issuing CA certificate from the AD CS root CA. Publish a final CRL from the AD CS issuing CA that reflects the revocation of all issued certificates (including the issuing CA’s own certificate). This final CRL should have a validity period extending beyond the maximum validity period of any certificate the issuing CA ever issued, so that revocation checks against old certificates can still be satisfied from cached CRL data after the server is gone. Publish the final CRL to all CDP distribution points and keep those distribution points accessible for the full CRL validity period.

Remove the AD CS server role from the Windows Server. Remove the AD CS issuing CA from the Enterprise PKI objects in Active Directory (using pkiview.msc or the Active Directory Sites and Services snap-in). Remove the AD CS root CA certificate from the domain Trusted Root Certification Authorities via GPO, after piloting on a non-critical OU to verify no remaining certificates chain to it.

Keep the offline AD CS root CA server available (powered off, not decommissioned) for at least 12 months after the last certificate it signed (the issuing CA certificate) expires, in case forensic investigation requires access to it.

How Encryption Consulting Can Help

Encryption Consulting has executed AD CS to PKIaaS migrations for enterprise environments across regulated industries, including environments with complex template sets, Intune and Jamf MDM integrations, and mixed Windows and Linux certificate consumers.

• PKI Assessment Service: The right starting point for any AD CS replacement program is an accurate assessment of the current environment. Encryption Consulting’s PKI Assessment Service audits the AD CS deployment, produces the certificate template inventory and expiry profile, identifies migration risks, and delivers a phased migration plan with effort estimates and rollback procedures.
• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the replacement CA infrastructure with FIPS 140-3 Level 3 HSM-backed keys, WSTEP autoenrollment proxy support for Windows domain autoenrollment, native Intune and Jamf MDM integration, ACME (RFC 8555) for Linux and DevOps workloads, SCEP for network devices, EST (RFC 7030) for constrained devices, and M-of-N root CA ceremony with full evidence documentation. Contact us at Encryption Consulting to discuss your AD CS replacement timeline.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the unified CLM layer that makes the coexistence period manageable, with connectors for both the AD CS CA and the PKIaaS CA displaying migration progress and catching certificates that have not moved to PKIaaS before their AD CS-issued predecessors expire.
• PKI Services: For organizations that need expert hands-on support through the migration rather than a managed service replacement, Encryption Consulting’s PKI Services provide advisory and implementation support through template mapping, proxy deployment, GPO migration, staged rollout, and AD CS decommissioning.

Conclusion

Replacing AD CS with PKIaaS is a well-defined migration with a clear architecture, but it is not a forgiving one if the sequence is not followed. The most reliable path is to complete the pre-migration audit fully before touching any configuration, stand up the PKIaaS CA and validate the autoenrollment proxy before updating any GPO, pilot the GPO change in a test OU and verify all certificate-dependent applications before staging the rollout, keep the AD CS CA online throughout the coexistence period, and use a CLM layer that tracks both inventories so nothing falls through the gap.

The result on the other side of a well-executed migration is a PKI program that requires no Windows PKI expertise to operate, serves non-Windows systems natively, produces audit evidence automatically, handles the CA/Browser Forum 47-day certificate validity schedule (effective March 15, 2029) through automation rather than manual intervention, and has a documented path to post-quantum CA hierarchy migration built into the service rather than left as a future internal engineering project.

If your organization is planning an AD CS replacement or has already started and run into difficulties, reach out to Encryption Consulting. We have worked through these migrations in environments of all sizes and complexity levels and can help your team avoid the pitfalls that most commonly derail AD CS replacement programs.

This post is reviewed on a six-month cadence and when Microsoft releases updates to AD CS, Windows autoenrollment behavior, or the WSTEP/MS-WCCE protocol documentation that affect migration architecture.

Frequently Asked Questions

What is the biggest risk in replacing AD CS with PKIaaS?

The biggest risk is breaking autoenrollment for domain-joined machines and users during the GPO migration, either by updating the Certificate Enrollment Policy before the autoenrollment proxy is fully operational, or by changing the policy before PKIaaS-issued replacement certificates have been provisioned. Mitigation requires piloting the GPO change in a test OU, verifying the proxy is responding correctly to test enrollment requests, and maintaining a documented rollback that restores the original CEP within 30 minutes if the pilot fails.

Can PKIaaS replace AD CS autoenrollment for domain-joined Windows machines?

Yes. PKIaaS replaces AD CS autoenrollment through a WSTEP-compatible autoenrollment proxy deployed in the on-premises environment. The proxy receives certificate requests from Windows autoenrollment clients, authenticates the requester against Active Directory, and forwards the approved request to the PKIaaS issuing CA. No additional client software is required on domain-joined Windows machines.

What happens to certificates already issued by AD CS during the migration?

Certificates already issued by AD CS remain valid under their existing chain of trust until natural expiry. During the coexistence period, new enrollments and renewals come from PKIaaS while existing AD CS-issued certificates expire naturally. A CLM layer tracking both the AD CS-issued and PKIaaS-issued certificates in a unified inventory ensures nothing falls through the gap. The AD CS CA should remain online until all certificates it issued have expired or been replaced.

How do I handle certificate templates in the AD CS to PKIaaS migration?

Each active AD CS template needs a corresponding PKIaaS certificate profile with the same subject DN fields, SAN types, Key Usage, Extended Key Usage OIDs, and validity period. Audit which templates are actively used before creating profiles. Inactive templates do not need to be migrated. Domain Controller, Domain Controller Authentication, Smart Card Logon, and Kerberos Authentication templates require the most careful profile configuration because missing EKU OIDs cause application failures that are difficult to diagnose.

What is the Certificate Enrollment Policy and how does it change during migration?

The Certificate Enrollment Policy (CEP) is the GPO configuration that tells Windows autoenrollment clients where to submit certificate requests. In the PKIaaS migration, the CEP is updated to point to the PKIaaS autoenrollment proxy’s WSTEP endpoint URL. This single GPO change triggers Windows autoenrollment to submit new and renewal requests to PKIaaS instead of AD CS. The correct sequence is: deploy the proxy, verify it is responding correctly, update the CEP in a pilot OU, validate, then roll out to all OUs.

Should we replace AD CS completely or run PKIaaS alongside it?

Full replacement is the correct long-term outcome. Augmentation (running PKIaaS alongside AD CS) is appropriate as a transitional architecture during the migration period, not as a permanent state. The coexistence period should have a defined end date, after which the AD CS CA is decommissioned. Running two parallel CA hierarchies indefinitely doubles governance burden and creates compliance complexity.