TL;DR: CISA’s AA26-237A shows that two critical infrastructure organisations can face the same red-team tradecraft and yet diverge sharply on detection, with default Machine Account Quota and ESC1 ADCS templates turning ordinary domain users into certificate-based domain impersonators, according to SafeBreach. The lesson for identity teams is that cloud and on-prem controls fail together when privilege, visibility, and certificate issuance are governed as separate problems.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on SafeBreach's blog post: Under CISA AA26-237A, default Machine Account Quota and weak ADCS certificate templates let unprivileged users pivot into domain impersonation and broader compromise.
Why it matters: Identity teams need to treat AD CS, domain join rights, and cloud token pathways as one governance problem, because a gap in any one of them can collapse the rest of the trust model.
Context
This article examines how weak Active Directory Certificate Services configuration and a non-zero Machine Account Quota can turn an ordinary domain user into an impersonator for any identity in the domain. In identity governance terms, the failure is not only technical misconfiguration. It is the assumption that certificate issuance, machine creation rights, and downstream access control can be managed independently.
SafeBreach frames the CISA AA26-237A findings through two controlled assessments that reached domain compromise with the same tradecraft. The useful lesson for practitioners is that prevention and detection both matter, but neither works if the underlying identity path lets low-privilege users create or borrow trust they should never hold.
For IAM, PAM, and NHI programmes, the article reinforces a cross-domain point: certificates, service trust, and cloud authentication artefacts are part of one identity estate. When those controls are governed in silos, defenders can still lose even when endpoint detection is active and the environment looks monitored.
Key questions
Q: What breaks when Machine Account Quota is left at the Windows default?
A: It gives ordinary domain users enough identity capacity to create machine accounts that can become part of a privilege chain. By itself that setting is not a breach, but in combination with weak certificate templates or poor monitoring it can let a low-privilege user create trust-bearing objects that support impersonation and escalation.
Q: Why do weak AD CS templates matter so much in domain compromise?
A: Because a template that lets the requester choose the subject disconnects the certificate from the real identity behind the request. That turns a certificate into a forgeable trust token, so a low-privilege user may request identity material that authenticates as someone else and bypasses normal account protections.
Q: How do security teams detect certificate abuse in real environments?
A: Teams should look for unexpected signed binaries, unusual publisher lineage, companion DLL loading, and malware that appears only after trusted execution paths are used. Logging certificate inventory is not enough if the delivery chain can still abuse support tickets or vendor portals. Detection must combine file provenance, endpoint behavior, and certificate lifecycle monitoring.
A: Accountability usually sits with the teams that own identity governance, directory administration, and cloud access control, because these groups define permissions, credential policy, and enforcement. Security leadership should ensure review cadence, logging, and response ownership are documented. The practical test is whether each risky permission or credential exception has a named control owner.
Technical breakdown
How Machine Account Quota becomes a privilege bridge
Machine Account Quota controls how many computer accounts a non-administrative user can create in Active Directory. When the default remains in place, an ordinary user can stand up a computer object and use that object’s machine trust as a stepping stone into more privileged authentication paths. The issue is not the account itself, but the fact that domain join rights become a transferable identity primitive. Once that primitive is available, abuse can combine with other misconfigurations, including certificate enrollment paths, to produce impersonation at scale.
Practical implication: treat machine creation rights as governed identity capacity, not a harmless default.
Why ESC1 ADCS templates turn certificates into domain impersonation
An ESC1-misconfigured certificate template allows the enrollee to supply the subject, which means a requester can ask for a certificate that names a different identity from the one actually requesting it. In practice, that breaks the link between requestor and subject, so the certificate becomes a reusable proof of identity rather than a constrained credential. If enrollment restrictions are weak, the certificate can authenticate as a user, service, or privileged principal depending on how the template is configured and trusted. That is why AD CS hardening is an identity control, not just a PKI housekeeping task.
Practical implication: lock down enrollee-supplied subject fields and review every template that can mint identity-bearing certificates.
How cloud identity abuse follows on-prem certificate compromise
The article shows that once an attacker reaches trusted identity material, the next step is often token or application abuse rather than noisy malware activity. A certificate, primary refresh token, or application credential can open cloud services even when password-based controls appear intact. That is the real governance problem: on-premises trust, directory trust, and cloud token trust are chained together, so compromise in one plane can bypass assumptions in another. Identity programmes that separate these layers miss the attack path entirely.
Practical implication: govern certificate, token, and application credential trust as one end-to-end identity path.
Threat narrative
Attacker objective: The objective was to demonstrate how ordinary domain access can be turned into trusted domain impersonation and then into broader enterprise compromise.
- Entry began with a low-privilege domain user path that could be expanded because Machine Account Quota remained permissive and ADCS enrollment was misconfigured.
- Credential access followed when the red team used the machine-account and certificate path to obtain identity material that could impersonate other principals in the domain.
- Escalation occurred as that identity material was used to move from ordinary user access into domain-level compromise and cloud-relevant authentication opportunities.
- Impact was full domain compromise, plus access to sensitive business systems and cloud mail and application resources.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Machine Account Quota is a governance decision, not a convenience setting. The default value effectively grants low-privilege users a pathway to create their own trust-bearing objects inside the domain. That assumption was designed for administrative flexibility, not for environments where machine accounts can become ingredients in impersonation chains. The implication is that join rights must be treated as privileged identity capacity, not operational background noise.
ESC1 templates expose a certificate-issuing trust collapse. AD CS templates that let the requester control the subject break the basic premise that a certificate identifies the entity actually being authenticated. That failure matters because certificate trust is often treated as stronger than passwords. In reality, the certificate becomes an identity forgery mechanism when enrollee restrictions are weak. Practitioners should read this as a proof that PKI governance and IAM governance are the same control surface.
Cloud identity risk is downstream of on-prem trust, not separate from it. The advisory shows that directory compromise, certificate abuse, and application-token access sit on one chain of trust. The field still over-separates endpoint, directory, and cloud teams, then acts surprised when a compromise crosses all three. The result is an identity blast radius that is wider than any single control owner expects, so cross-plane governance has to be the organising model.
Detection cannot compensate for permissive identity primitives. One SOC can spot the attack faster than another, but both still lost ground because the identity path itself was viable. That is the deeper lesson for the market: visibility is necessary, but controls that allow low-privilege users to mint trust will always outrun detection. The practitioner conclusion is to reduce the attack path first, then tune the SOC around what remains.
Identity blast radius should be the unit of measurement for AD CS and domain trust. This article makes clear that the meaningful question is not whether a template or quota looks normal in isolation. It is how far a compromised low-privilege identity can travel once those settings combine. That shifts governance from checklist compliance to measurable compromise range, which is the right frame for modern IAM and NHI oversight.
What this signals
Identity blast radius is the control variable here. The article shows that the decisive issue is not whether an alert fires, but how far a low-privilege identity can travel once machine creation rights and certificate issuance are permissive. Programmes that still separate AD CS governance from cloud authentication governance will keep underestimating compromise range.
When a certificate template lets the requester define the subject, the environment has already accepted an identity forgery pathway. That means the right audit question is not whether PKI exists, but whether any template can mint a certificate that outlives or outranks the identity that requested it. Teams should treat that as a directory and cloud trust problem, not a niche PKI issue.
For practitioners
- Zero out Machine Account Quota Set Machine Account Quota to zero unless a documented operational need exists, and restrict any exception to the smallest possible administrative group.
- Harden AD CS templates Review every certificate template for enrollee-supplied subject settings, weak enrollment restrictions, and any path that lets low-privilege users mint identity-bearing certificates.
- Treat certificates as identity credentials Inventory which services accept certificate-based authentication and map those certificates back to the business identities and privileges they can impersonate.
- Join cloud and on-prem identity telemetry Correlate AD directory events, AD CS issuance, Entra sign-ins, and application credential changes so one control owner can see the full attack chain.
- Test the exact compromise sequence Run red-team validation for the path from low-privilege domain user to machine account creation to certificate issuance to impersonation, and verify which stage is actually blocked.
Key takeaways
- Default Machine Account Quota and weak AD CS templates create a direct identity path from ordinary user access to domain impersonation.
- CISA’s two assessments showed that the same misconfigurations can lead to full compromise even when SOC maturity differs.
- The control that matters most is not detection alone, but removing the trust primitive that lets low-privilege users mint machine or certificate-based identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine Account Quota creates unnecessary privilege for ordinary domain users. |
| NHI-04 — Insecure Authentication | Weak AD CS templates let certificates authenticate the wrong identity. | |
| Recommendation — Reduce machine-creation rights and remove unnecessary privilege paths that let users mint trusted identity objects. Harden certificate issuance so authentication material cannot be detached from the real subject. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate-based identity material and tokens require lifecycle governance. |
| Recommendation — Apply authenticator management to certificate and token issuance, renewal, and revocation. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path depends on credential theft and movement through trusted identity material. |
| Recommendation — Map the compromise chain to credential access and lateral movement to prioritise detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on excess permissions and weak authorization boundaries in identity systems. |
| Recommendation — Review entitlements that let low-privilege users create trusted objects or obtain impersonation-capable credentials. | ||
Key terms
- Machine Account Quota: The Active Directory setting that limits how many computer objects a non-admin user can create. In managed directories, the quota may remain in place even when customers cannot fully administer the domain, which makes the surrounding join workflow and group membership just as important as the setting itself.
- Active Directory Certificate Services: Microsoft infrastructure for issuing and managing certificates inside an enterprise directory environment. It becomes a security concern when certificate templates, enrollment permissions, or authority boundaries create durable access that survives password resets and account changes.
- ESC1 template misconfiguration: A certificate template weakness where the enrollee can supply the subject and enrollment restrictions are too weak. That combination lets the requester obtain a certificate for a different identity, which breaks the trust boundary between requestor and authenticated principal.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 27, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org