What breaks when attackers can create computer objects and abuse them to request certificates in Active Directory?

Why This Matters for Security Teams

The failure here is not simply certificate abuse. It is the combination of weak directory guardrails and over-permissive machine account creation, which gives an attacker a foothold to mint a controllable identity inside active directory and then leverage certificate services for impersonation. That changes the problem from password theft to trust fabrication, where the directory itself helps validate the attacker’s access.

This pattern matters because certificate-based authentication often bypasses many of the controls defenders rely on for user accounts, especially when templates, enrollment rights, or subject-mapping rules are loose. NHI Management Group’s research on The Critical Gaps in Machine Identity Management report shows how machine identity oversight remains a persistent weakness, with 57% of organisations lacking a complete inventory of their machine identities. In environments with active directory certificate services, that lack of visibility turns a small privilege mistake into a durable escalation path. The same pattern of trust abuse is reflected in broader breach analysis such as 52 NHI Breaches Analysis, where identity creation and credential control failures repeatedly compound each other.

In practice, many security teams encounter this only after a low-privilege account has already been used to stand up a malicious identity and request a certificate, rather than through intentional review of directory provisioning rights.

How It Works in Practice

Attackers first look for any path that allows them to create a computer object, either directly or through delegated join rights. Once they can create that object, they may control attributes that are later consumed by certificate enrollment logic. If a vulnerable template permits enrollment by that machine principal, the attacker can request a certificate that maps to a privileged user or service identity. From there, the certificate can be used for authentication, impersonation, or lateral movement.

The defensive issue is that the object lifecycle, not just the certificate lifecycle, has to be controlled. Certificate security guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls supports restricting privileged configuration paths and enforcing least privilege, while directory hardening must ensure only trusted admins can create or join computer accounts. For operators, that means checking:

• who can create computer objects in each OU or delegation boundary
• which certificate templates allow machine enrollment
• whether subject alternative name or mapping rules can be abused
• how quickly newly created computer objects are reviewed and revoked if suspicious
• whether certificate issuance is tied to monitored change workflows

For incident responders, correlation matters: certificate requests, directory object creation, and authentication events should be reviewed together, not as separate logs. Broader NHI security guidance from Top 10 NHI Issues and external attacker tradecraft references like the MITRE ATT&CK Enterprise Matrix both reinforce the same lesson: once identity creation is delegated too widely, abuse becomes stealthy and fast. These controls tend to break down in hybrid AD environments with legacy certificate templates, inconsistent delegation, and poor monitoring of machine object creation.

Common Variations and Edge Cases

Tighter control over computer creation often increases operational overhead, requiring organisations to balance provisioning speed against abuse resistance. That tradeoff is especially visible in environments that automate workstation enrollment or use delegated join accounts for scale.

Some environments only expose the problem when certificate templates are misconfigured, while others are vulnerable because of overly broad rights on the directory object itself. Current guidance suggests treating both as part of one trust chain, but there is no universal standard for exactly how to partition responsibility between directory administrators, PKI operators, and endpoint teams. In mature environments, best practice is evolving toward separate approval paths for machine creation and certificate issuance, with time-bound access and explicit logging at each step.

Edge cases also matter. A domain-joined server fleet may appear well controlled until a service account is allowed to create new machine objects for automation. Similarly, a template that looks harmless for device auth can become dangerous if it permits subject manipulation or weak mapping to user principals. The safest assumption is that any ability to create a computer object is a potential identity issuance path unless it is deliberately constrained. For practitioners mapping this risk to machine identity programmes, The Critical Gaps in Machine Identity Management report is a useful reminder that visibility and ownership are usually the first missing controls.

Related resources from NHI Mgmt Group

• How should security teams detect and contain RBCD abuse in Active Directory before attackers use it for lateral movement?
• What breaks when Active Directory names can be manipulated?
• Why do non-transitive trusts create unexpected privilege risk in Active Directory forests?
• Why does SPN scanning create so much risk in enterprise Active Directory?