Active Directory Certificate Services is generally not a deliberate architectural choice. It's a legacy.
In most organizations, nobody decides to adopt ADCS after a rigorous evaluation of their PKI requirements. You enable ADCS because you already use Microsoft Active Directory. The service is built-in, it appears "free", and it works well with GPOs. This initial ease explains its massive adoption.
But that "free" has a cost many organizations discover late. Operational complexity, extended attack surface, and structural dependency on Active Directory.
The Structural Problem: ADCS Lives in Your Tier 0
ADCS is not an isolated service. It is deeply embedded in Active Directory, the most critical privilege level of your infrastructure.
This has several consequences.
Compromising ADCS can open the path to compromising Active Directory. Every certificate template, every enrollment point, and every enrollment agent becomes a potential attack vector. Default permissions are designed to work immediately, not to be secure from the start.
In certain scenarios, an attacker capable of obtaining a fraudulent certificate can then authenticate as any domain user, including an administrator. The PKI becomes an indirect path to infrastructure control.
ESC Attacks: A Continuous Flow, Not an Isolated Incident
In 2021, SpecterOps researchers published the Certified Pre-Owned report and highlighted several classes of attacks against ADCS known as ESC.
The finding is brutal. Many ADCS configurations allow privilege escalation.
Since that publication, discoveries have continued.
In 2021, ESC1 through ESC8 attacks were described.
In 2022, CVE-2022-26923 revealed a new privilege escalation scenario related to machine junction and certificates.
The following years saw new variants and new abuse scenarios emerge.
The fundamental point is that these issues are not merely software bugs. They largely stem from the ADCS model itself. Permissive templates, complex delegation, and dependency on Active Directory permissions create fertile ground for abuse.
Applying patches improves the situation but does not change the nature of the system.
A PKI Locked Inside Active Directory
ADCS inherently depends on Active Directory to function. This dependency creates significant limitations in modern environments.
Today's infrastructures include cloud workloads, multi-cloud environments, containers, and ephemeral machine identities.
Platforms like Kubernetes or Docker operate with very short lifecycles and dynamic identities. Amazon Web Services, Google Cloud, and Microsoft Azure environments multiply workloads that never join an Active Directory domain.
In these contexts, ADCS becomes difficult to use natively. Containers don't join the domain. Cloud resources don't always have a traditional Active Directory identity. External partners are not part of your forest.
The PKI ends up limited to the Active Directory perimeter.
The Automation Wall
Automation has become essential in DevOps environments.
The ACME protocol has established itself as the standard for automated certificate issuance and renewal. It is used by a large part of the modern ecosystem, notably through tools like Certbot and cert-manager.
ADCS does not natively support this protocol.
In practice, several effects appear. DevOps teams bypass the internal PKI with external solutions. Scripts emerge to automate renewals. Some certificates simply expire because the processes are too complex.
Gradually, a Shadow PKI develops alongside the official infrastructure.
Low Crypto-Agility Facing the Post-Quantum Transition
The new NIST post-quantum standards, notably FIPS 203 and FIPS 204, mark the beginning of an important transition for cryptography.
PKI infrastructures will need to progressively evolve toward new algorithms, hybrid certificates, and controlled migration strategies.
Today, ADCS offers neither native support for these algorithms nor a clear roadmap for their adoption. Adapting a monolithic PKI tightly linked to Active Directory to these new requirements is likely to be complex.
Surpassing ADCS Without Necessarily Replacing It
The conclusion is not necessarily to immediately remove ADCS.
In many organizations, it remains essential for certain legacy uses. Windows authentication, smartcards, enterprise Wi-Fi, or certain VPNs still rely on it. Removing it abruptly would be costly and risky.
The real challenge lies elsewhere. ADCS should no longer be the center of gravity for PKI.
For a long time, it was used for nearly all enterprise certificates. This model corresponded to an era when infrastructure was predominantly Windows and entirely on-premises.
Today, new environments like cloud, containers, and DevOps pipelines require PKI infrastructure designed for automation and scale.
A pragmatic approach is to keep ADCS for legacy Windows uses while deploying modern certificate authorities for new environments. Certificate lifecycle management can then be orchestrated from an independent governance layer capable of driving multiple PKIs.
In this model, ADCS continues to exist but ceases to be a single critical point.
By limiting its scope and moving new use cases to PKI infrastructure suited for modern environments, the dependency on Active Directory decreases significantly and the associated attack surface is reduced.
Conclusion
ADCS has served well for over twenty years. But it was designed for a very different world than today's. A stable, centralized, and entirely internal Windows environment.
Modern infrastructures now rely on hybrid cloud, automation, and machine identities. Added to this is the progressive transition toward post-quantum cryptography.
In this context, the question is not necessarily whether to remove ADCS immediately.
The real question is how much longer your PKI will remain dependent on it as a central component.
