Securing Your PKI: Where ADCS Breaks Down

---

Active Directory Certificate Services (ADCS) remains the default enterprise PKI in many Windows estates. Public research has shown that several of its most serious privilege paths are not "unpatched CVEs waiting for a Tuesday update." They are configuration and architecture outcomes: certificate templates that trust the requester, enrolment paths that accept NTLM relay, and a CA private key that lives in one place.

This page summarises the structural problems, credits the public research that documented them, and describes how a different CA signing model (threshold MPC, cryptographic SAN enforcement, no NTLM enrolment, real-time revocation) addresses the failure modes patching alone cannot.

---

Table of Contents

1. The problem: ESC1 to ESC8
2. The golden certificate
3. Why patching is not enough
4. Architectural response
5. How this maps to DuoKey PKI
6. FAQ

---

The problem: ESC1 to ESC8

Researchers at SpecterOps documented a family of ADCS privilege-escalation techniques commonly labelled ESC1 through ESC8. The details differ by template and enrolment path; the pattern does not:

The important architectural point: several of these paths succeed because ADCS trusts configuration flags and Active Directory ACLs that operators rarely audit end to end. An organisation can be "fully patched" and still exposed.

Published CVEs have addressed specific ADCS and related enrolment weaknesses over time (for example issues tracked under identifiers such as CVE-2022-26923 and subsequent ADCS-related advisories). Treat CVE IDs as evidence that vendors and researchers recognise the class of problem; do not treat a green patch dashboard as proof that ESC-class template risk is gone.

Credit for the systematic public mapping of ESC1–ESC8 belongs to SpecterOps' ADCS research publications. This page does not list offensive tooling; the research record is enough to justify a design conversation.

---

The golden certificate

If an attacker obtains the CA private key, they can forge certificates for arbitrary subjects for as long as relying parties trust that CA. That is the golden certificate scenario: indefinite forgery until every trust anchor that embeds the CA is replaced.

In a classic ADCS deployment the CA private key typically sits in one HSM partition or one software key store. That concentration is exactly the high-value target. Patching enrolment bugs does not change the fact that a single successful theft of the CA key ends the trust story for that hierarchy.

---

Why patching is not enough

ESC1 through ESC4-class issues largely follow from template and permission design, not from a single memory-corruption bug you can close with a cumulative update. As long as:

• templates allow requester-specified SANs without cryptographic binding to the authenticated identity,
• enrolment agents or CA ACLs are over-broad,
• NTLM remains acceptable on web enrolment,

the escalation surface remains a configuration and protocol problem. Security teams that only track CVEs will under-estimate residual risk.

---

Architectural response

A PKI designed to remove those failure modes looks different from "ADCS plus better hardening guides":

1. Threshold MPC for CA signing operations. The CA signing key is split across nodes. No single administrator, appliance, or cloud component can produce a valid CA signature alone. Stealing one share does not yield a golden certificate. See MPC vs HSM.
2. SAN validation enforced cryptographically, not only as a template checkbox. Subject alternative names must bind to the authenticated enrolment identity at the policy and crypto layer, so ESC1-style "request as anyone" paths fail closed.
3. No NTLM on enrolment paths. Remove the relay primitive ESC8 depends on. Modern auth only.
4. Real-time revocation without waiting on CRL distribution lag for the control plane that issues and retires certificates. When an identity must die, relying systems should learn it without a weekend CRL window.

None of that replaces inventory, monitoring, or certificate lifecycle discipline. It changes the trust architecture underneath them.

---

How this maps to DuoKey PKI

DuoKey's PKI and certificates product combines certificate lifecycle (issue, renew, retire, audit) with MPC-backed key protection so CA and high-value signing material are not a single-appliance secret. The same control plane that governs certificates also ties into agentic identities for non-human principals that need machine certificates without inheriting ADCS template debt.

Practical programme shape:

• Inventory templates, enrolment endpoints and CA key custody first
• Eliminate NTLM enrolment and over-permissive SAN templates on any ADCS that must remain
• Move high-value CA signing toward threshold MPC custody
• Put issuance and revocation on a single audited control plane

---

FAQ

Q: Can we keep ADCS if we harden templates?

You can reduce risk. ESC-class issues show that template and ACL review is mandatory if ADCS stays. Hardening does not give you threshold CA keys or remove the golden-certificate concentration by itself.

Q: Is this only a Windows problem?

ADCS is the common enterprise case study because of Active Directory coupling. Any CA that stores a monolithic private key and trusts weak enrolment identity binding has the same structural risks.

Q: Why not name exploit tools here?

Public CVE identifiers and SpecterOps' research are enough to establish the problem on a public product site. Tooling details belong in a private technical workshop, not in marketing copy.

---

Conclusion

ADCS failures that matter most for domain compromise are often configuration and key-custody failures: ESC1-style impersonation via templates, ESC8-style relay against NTLM enrolment, and a CA key that becomes a golden certificate when stolen. Patching helps where a CVE exists. It does not rewrite template trust or split a monolithic CA key. Threshold MPC signing, cryptographic SAN binding, NTLM-free enrolment and real-time revocation are the architectural answers.

---

References

• SpecterOps: public ADCS / ESC research series (credit for ESC1–ESC8 taxonomy)
• Microsoft security updates and advisories for ADCS-related CVEs (including CVE-2022-26923 and subsequent ADCS guidance)
• DuoKey PKI and certificates
• MPC vs HSM