The Conventional Approach
When a critical vulnerability hits Active Directory Certificate Services, the typical response is to patch the CA, verify the deployment, and close the ticket. You might even review certificate template permissions. The belief is that vulnerabilities are isolated issues, and fixing them solves the problem.
This mindset treats Certighost (CVE-2026-54121, disclosed July 24, 2026, CVSS 8.8) as a PKI issue. Microsoft released a fix on July 14, 2026. Apply it to your Enterprise CAs, confirm the chase functionality now validates destination endpoints, and you're done. The vulnerability allowed a standard domain user to trick a CA into issuing a Domain Controller certificate by directing the CA's chase lookup to a rogue endpoint with forged identity data. The CA trusted the data, signed the certificate, and gave an attacker the tools for a DCSync attack and domain compromise. Patch applied, exposure closed, move on.
That's the conventional wisdom, and it's dangerously incomplete.
The Real Issue
Certighost isn't just a certificate bug. It's a symptom of how your organization manages trust and privilege across the identity control plane.
The vulnerability exploited a validation gap, but the attack relied on conditions unrelated to the CVE: default MachineAccountQuota settings allowing any authenticated user to create machine accounts, unchecked certificate template permissions, flat trust between the CA and directory services, and monitoring systems that ignore identity-layer activity.
Even if you remove the specific vulnerability, those conditions remain. The next attack will exploit them differently.
Your Certification Authority is a privileged identity that creates trust for every authentication flow, device enrollment, and service authentication. When it signs a certificate, every downstream system treats that signature as authoritative. That's a massive concentration of power, and most organizations manage it like a utility installed once and forgotten.
The real failure isn't that the chase functionality lacked a validation step. It's that your trust architecture assumed the CA would always communicate with legitimate endpoints, that standing privilege like MachineAccountQuota was insignificant, and that monitoring certificate enrollment wasn't necessary because "nobody attacks PKI."
Certighost proved all three assumptions wrong in a single proof-of-concept.
The Evidence
Consider the prerequisites. A standard domain user account was enough in testing because default Active Directory configuration provided everything needed. MachineAccountQuota, which allows ordinary users to create machine accounts, has been permissive for years. It's in your domain unless you've changed it.
That's not a vulnerability. It's standing privilege that accumulates where nobody governs.
The CA connected to an attacker-controlled endpoint because nothing required it to verify the destination was a genuine Domain Controller. That's a trust-validation gap, present in every system that delegates authentication decisions to unchecked components.
Once the attacker had a certificate for a Domain Controller machine account, the path to domain compromise followed known mechanics: PKINIT authentication to get a Ticket Granting Ticket, DCSync to pull credential material including the krbtgt hash, and Golden Ticket creation for persistent domain dominance. None of these steps required breaking cryptography or bypassing access controls. They required manipulating a trusted system into vouching for a privileged identity.
That's the hallmark of identity-driven attacks: the system decided to trust without checking, and the attacker simply asked.
What to Do Instead
Start by applying the patch, but don't stop there. The July 14, 2026 update adds destination validation to the chase functionality. Deploy it to every issuing CA. If deployment is delayed, the documented workaround disables chase entirely, but test it first because legitimate enrollment workflows may depend on it.
Then address the standing privilege. Set MachineAccountQuota to zero. This removes the default ability for ordinary users to create machine accounts. Some provisioning workflows assume users can join machines to the domain. Inventory those dependencies and route machine creation through controlled, delegated accounts instead of leaving it open to every authenticated user.
Constrain the CA's network posture. Restrict outbound SMB and LDAP from your Certification Authorities so they can only communicate with known, authorized Domain Controllers. This blocks the rogue-endpoint step in this attack chain and limits the CA's exposure to manipulation.
Audit certificate enrollment permissions. Which principals can request certificates from which templates? Does that population have any business holding the identity those certificates represent? Most organizations have never reviewed Enterprise CA permissions against that standard, and that's where AD CS attack paths originate.
Finally, monitor the identity control plane. Watch for unusual machine account creation, certificate enrollment activity, and DCSync operations. If your detection stack can't identify DCSync from anything other than a Domain Controller, that's a critical gap. Endpoint telemetry won't catch an identity attack it wasn't designed to see.
When the Conventional Wisdom Is Right
Patching is still foundational. The specific validation gap Microsoft fixed was real, the proof-of-concept was public, and the window between "PoC exists" and "commodity tooling includes it" is short. If you don't patch, you're leaving a documented path to domain compromise open.
Certificate template reviews matter. Overbroad enrollment permissions create exposure even when the CA is hardened. If a user who shouldn't be able to request a certificate for a service account can do so, that's a problem worth fixing regardless of which CVE prompted the review.
Monitoring certificate issuance has value beyond Certighost. Unusual enrollment patterns, certificates requested for high-privilege accounts, or enrollment from unexpected sources are all signals worth investigating.
The conventional wisdom gets the tactics right. It just mistakes the tactics for the strategy.
The Real Work
Certighost will be patched and forgotten within a quarter. The organization that learns nothing beyond the KB number will face the next identity-layer attack with the same exposures: standing privilege nobody governs, trust relationships nobody validates, and monitoring that watches the wrong layer.
Your Certification Authority has been handing out trusted identities since the day it was deployed. The work isn't patching the chase functionality. It's ensuring the CA only manufactures trust for identities you can verify, and that the privilege required to obtain those identities is controlled, delegated, and continuously audited.
Treat identity as infrastructure. Treat privilege as risk. Validate trust at every point where a system is about to act on it, not just at the perimeter you defined years ago.
