A delegable machine account can be impersonated in Kerberos flows, which lets an attacker turn routine service trust into privileged directory access. The risk is greatest when the computer object anchors Tier 0 infrastructure such as domain controllers or identity services. In practice, the break is not just technical exposure but a collapsed trust boundary around the control plane.
What actually breaks when delegation is left on for a machine account?
The break is trust, not just configuration. A delegable computer account can be used as an impersonation foothold in Kerberos, so the attacker can inherit the machine’s allowed trust path and move into systems that were supposed to trust that account. Once the account sits near Tier 0, the failure becomes a control-plane exposure, not an ordinary host compromise.
That matters because delegation is supposed to represent a narrow, intentional trust relationship. When it is left on broadly, the machine account stops being a simple service endpoint and becomes a reusable authorization bridge. The practical effect is that a compromise of one machine can become a path to directory-level authority, especially where the computer object can reach domain controllers or identity services.
In other words, the issue is not only whether the account can log on. It is whether the account can be used to present someone else’s identity across services. In active directory, that turns service trust into a privilege-transfer mechanism, which is why delegation misconfiguration is treated as an escalation primitive rather than a housekeeping defect.
Why delegation turns routine service trust into directory compromise
Kerberos delegation exists so one service can act for a user to reach a downstream service. That design works only when the delegated trust boundary is tightly scoped and the machine is genuinely allowed to impersonate in that context. If the scope is too wide, the account can be abused to request or relay access it should never be able to exercise directly.
A sensitive machine account becomes especially dangerous when it is tied to infrastructure that protects the identity layer itself. Domain controllers, certificate services, authentication brokers, and other Tier 0 systems amplify the impact because the delegated machine identity can become a path into the very systems that enforce authentication and authorization. Active Directory and Entra ID Hardening Guide covers why delegation and tiering have to be treated as control-plane design decisions, not mere account settings.
The key failure condition is that the account is trusted more broadly than its actual job requires. Once that happens, the attacker does not need to “break” the protocol itself. They only need to abuse the existing trust path, which is why this problem often shows up as privilege escalation, lateral movement, and eventual directory takeover rather than as a visible authentication failure.
On the defensive side, this is also why lifecycle visibility matters. NHI Lifecycle Management Guide is useful here because delegation risk is often sustained by stale ownership, incomplete inventory, and forgotten service relationships that survive long after the original business need has changed.
What changes when the delegable machine account sits in Tier 0 infrastructure?
Tier 0 changes the blast radius. If the machine account can reach domain controllers, identity services, or privileged management components, compromise stops being local to one host and becomes an attack on the trust fabric. That is why delegable machine accounts near the directory core are so serious: they can be used to impersonate across a boundary that should have been strongly protected.
Administratively, the object often looks ordinary because it is “just” a computer account. Operationally, it may carry rights that are far more powerful than its label suggests. A delegated machine identity can therefore collapse segmentation, bypass intended separation between service tiers, and expose credentials or tickets that should never be available outside the control plane.
This is also where incident patterns become instructive. Cisco Yanluowang breach 2022 and Cisco Active Directory credentials leak 2025 both show how once machine or directory credentials are exposed, the attacker’s next move is usually trust abuse and expansion into higher-value identity assets. The lesson is consistent: machine trust paths become strategic when they touch the authentication tier.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegable machine accounts can gain excessive impersonation power. |
| NHI-04 — Insecure Authentication | Delegation misuse turns Kerberos trust into impersonation abuse. | |
| Recommendation — Restrict delegation scopes and remove unused impersonation paths from machine accounts. Validate Kerberos delegation settings and harden authentication paths for sensitive machines. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegation that exceeds service need violates least-privilege access control. |
| IA-5 — Authenticator Management | Machine-account secrets and tickets must be managed to prevent impersonation abuse. | |
| IA-9 — Service Identification and Authentication | Machine accounts authenticate services to each other in Kerberos flows. | |
| Recommendation — Limit delegated rights to the smallest service scope required. Rotate and protect machine account authenticators and related secrets on a defined schedule. Authenticate service-to-service interactions with tightly scoped machine identities. | ||
Practitioner Guidance
What to prioritise: Treat any delegable machine account that can influence privileged directory paths as a Tier 0 finding until proven otherwise. The first question is not whether the host is patched, but whether the trust relationship itself is still justified and bounded to a narrowly defined service need.
What to verify: Confirm whether the account is unconstrained, constrained, or protocol-transition capable, and whether that scope matches the real application flow. If the machine can reach domain controllers or identity services, validate the exact downstream services it can impersonate to, not just the existence of delegation on the object.
Common mistake: Teams often review the server and forget to review the trust edge. A machine that looks low risk can still be a high-value impersonation proxy if its delegation setting survives long after the original application design changed.
Practitioner takeaway: Delegation on a sensitive machine account is a trust-boundary issue first and an account-setting issue second, so the right response is to reduce or remove the trust path unless you can clearly justify every service the machine is allowed to speak for.
Related resources from NHI Mgmt Group
- What breaks when Account Operators is left enabled in Active Directory?
- How should security teams govern Active Directory service accounts?
- What breaks when non-privileged users can create machine accounts in managed Active Directory?
- What breaks when Machine Account Quota and ADCS templates are left loose?