Modernizing your Internal PKI: From Microsoft ADCS to EJBCA

Migrating from Microsoft ADCS to EJBCA helps retain existing Windows workflows while moving to a PKI platform built for automation, APIs, containers, HSMs, and consistent policy enforcement.

The Role of Microsoft CA / ADCS

Microsoft Active Directory Certificate Services (ADCS), sometimes called Microsoft CA, is widely deployed in Windows-centric enterprises to issue and manage digital certificates. Integrated with Active Directory and typically deployed on-premises, ADCS is commonly used for:

User and device authentication
TLS certificates for internal Microsoft services
VPN, RDP, and Wi-Fi authentication
Kerberos and domain controller operations
Code signing and digital signatures

For mobile and managed devices, ADCS is often extended using Network Device Enrollment Service (NDES), which implements the Simple Certificate Enrollment Protocol (SCEP). NDES enables certificate enrollment for Intune-managed devices and other MDM platforms, supporting device authentication and access control.

While functional, ADCS and NDES introduce significant operational complexity, especially in multi-domain, hybrid, or cloud-connected environments. High availability requires multiple CA servers, each managed independently. Scaling across forests is difficult, automation is limited, and support for modern cryptography, APIs, and cloud-native deployment models is constrained.

MS ADCS does not support multi-tenancy; each Certification Authority must be deployed and operated on its own dedicated server

Why Organizations Are Migrating Now

Enterprise PKI requirements have changed.

Organizations are adopting DevOps, CI/CD, Zero Trust, non-Microsoft OS, and cloud-native architectures, all of which require automated, API-driven certificate lifecycle management. At the same time, enterprises must support:

Hybrid and multi-cloud infrastructure
Linux and Kubernetes workloads
Mobile and non-Windows devices
Regulatory and compliance mandates
Crypto agility and post-quantum readiness

Legacy ADCS deployments struggle to meet these demands. Many teams also face growing technical debt, maintaining large numbers of CA servers, complex NDES setups, and fragile configurations tied closely to Active Directory.

As a result, enterprises are increasingly looking to decouple PKI from AD, centralize certificate management, and adopt a platform that scales with modern infrastructure, without breaking existing Windows enrollment workflows.

Why Choose EJBCA for ADCS Migration

EJBCA is an enterprise-grade PKI platform designed for modern, heterogeneous environments. It addresses the limitations of ADCS while supporting Microsoft-native enrollment mechanisms such as Auto-enrollment, NDES, and SCEP.

EJBCA can act as the backend for:

Windows Auto-enrollment
NDES / SCEP for Intune and MDM
ACME and EST for non-Windows platforms
API-based enrollment for applications and services

This allows organizations to migrate from ADCS without changing how endpoints enroll, while gaining the benefits of a centralized, scalable PKI platform.

Common EJBCA PKI setup in a modern enterprise environment

Key Advantages of EJBCA

Scalability & Deployment Flexibility

Multiple issuing CAs hosted in a single platform
High availability and horizontal scaling
Containerized and Kubernetes-based deployments
On-premises, hybrid, or SaaS deployment models

Automation & Integration

Full certificate lifecycle management via REST APIs
Integration with CI/CD pipelines and DevOps tooling
Native support for NDES/SCEP and MDM platforms
Protocol support beyond Windows-only environments (ACME, EST, and more)

Security & Compliance

HSM-backed key protection
Crypto agility and post-quantum readiness
Fine-grained certificate policy control
Separation of PKI administration from domain administration

Operational Efficiency

Significant reduction in the number of CA servers
Centralized configuration and policy management
Exportable and versionable PKI configurations
Simplified operations across domains and environments

Example: Customer Success Story

A large global enterprise consolidated more than 90 PKI servers into approximately 20 by migrating from Microsoft ADCS to EJBCA. This change dramatically simplified operations, improved scalability, and reduced long-term maintenance overhead.

Multiple Microsoft ADCS instances consolidated into a single multi-tenant EJBCA deployment, reducing Windows server sprawl and operational overhead.

Overview of the Migration Process

Before migration, enterprises typically operate single-tier or two-tier ADCS hierarchies tightly coupled to Active Directory. Each domain or forest may maintain its own CA infrastructure, increasing complexity and operational risk.

After migration, EJBCA provides:

Centralized, API-driven PKI management
HSM-backed CAs and externalized RAs
Containerized, highly available deployments
Hosted Microsoft CRLs to enable coexistence
Real OCSP support

EJBCA supports parallel operation with ADCS, allowing gradual migration and safe decommissioning of legacy infrastructure.

Consider Running ADCS and EJBCA in Parallel

When migrating to EJBCA, two primary approaches are used:

Parallel deployment (recommended)

EJBCA is introduced alongside ADCS. New certificates are issued from EJBCA while existing certificates continue to function until expiration. This enables incremental testing, minimal risk, and zero disruption. ADCS is decommissioned when it is no longer needed.

Hard cutover

Existing Microsoft CAs are migrated in a single step. This approach can be faster but requires extensive planning and is typically suited only for smaller or less complex environments.

Key considerations include trust chain management, CRL hosting, RA chaining, and staged Group Policy updates to ensure continuity during the migration process.

About EJBCA Microsoft Auto-enrollment (MSAE)

EJBCA Microsoft Auto-enrollment (MSAE) enables seamless migration from ADCS by letting Windows devices continue enrolling certificates exactly as they do today, while EJBCA becomes the issuing backend. This preserves existing workflows and avoids reconfiguring endpoints.

EJBCA MSAE achieves this by:

Reading certificate templates from Active Directory via LDAP(S)
Securing CEP/CES traffic using Kerberos, SPNs, and keytabs
Supporting single- and multi-domain forests
Mapping AD templates to EJBCA profiles for full template compatibility
Maintaining auto-enrollment for users and computers, even in complex AD topologies
Integrating securely with existing AD security controls

Hands-On Example: Replacing ADCS Auto-enrollment

Our step-by-step guide Replace ADCS with EJBCA Microsoft Auto-enrollment demonstrates MSAE in real-world AD environments.

By following the guide, administrators can fully replace ADCS for auto-enrollment, supporting Windows certificate issuance and renewal while centralizing PKI management and enabling a scalable, modern PKI architecture.

The guide covers:

Service account setup (LDAP bind + Kerberos)
SPN and keytab configuration
Global Catalog and multi-domain considerations
Certificate template mapping
CEP/CES endpoint configuration
End-to-end enrollment validation

Conclusion

If you are running ADCS today, you already know where it starts to break down: scaling across domains, managing NDES/SCEP, handling template sprawl, and supporting modern workloads that extend beyond Windows.

EJBCA provides a practical migration path. You retain existing Windows enrollment workflows while moving to a PKI platform built for automation, APIs, containers, HSMs, and consistent policy enforcement across all workloads.

Most enterprises migrate by running EJBCA in parallel with ADCS. With MSAE, NDES/SCEP support, and API-based enrollment, you can modernize PKI without disruption.

Contact us

Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.

Request a Demo