Because machine identities often hold authority equivalent to privileged users, delegation on those objects can convert a weak entry point into domain-level control. The risk rises when the identity can reset passwords, replicate directory data, or mediate identity services. That makes delegated computer objects a direct escalation path, not a configuration footnote.
Why machine-account Kerberos delegation becomes an escalation primitive
kerberos delegation is risky on machine accounts because the delegated identity is not a harmless technical placeholder. On many Windows estates, a computer object can carry powerful directory privileges, and delegation turns that trust into an action path an attacker can reuse. The result is often not just access to a host, but a route into higher-value authentication and directory operations.
What makes this dangerous is the combination of reach and trust. A delegated machine account may be able to present or obtain tickets on behalf of other principals, interact with identity services, and operate across services that assume the computer object is legitimate. Once an attacker controls that delegation path, the trust relationship can be expanded into actions that outstrip the original foothold.
Machine-account delegation also changes the blast radius of a compromise. If the delegated object can influence password resets, directory replication, or other identity-management functions, the attacker is no longer limited to lateral movement from a single host. They can pivot into authority that is functionally comparable to privileged administrative control, which is why delegated computer objects demand the same seriousness as human admin paths.
Why delegated computer objects often sit inside identity control boundaries
Kerberos delegation is fundamentally an authorization design choice, not just a protocol setting. The machine account is acting with borrowed authority, so the real question is whether that authority is bounded tightly enough to prevent impersonation from becoming administrative reach. In practice, that means reviewing what the delegated account can access, what tickets it can obtain, and which identity services it can influence.
Delegation on machine accounts becomes especially hazardous when the object is trusted by directory infrastructure or service tiers that other systems treat as authoritative. A compromised machine identity can become a bridge between otherwise separated control planes, which is why delegation settings must be evaluated alongside service ownership, tiering, and administrative boundaries rather than in isolation.
For practitioners, the key point is that machine accounts are often long-lived, widely trusted, and easy to overlook during reviews. That combination makes delegation more dangerous than a comparable setting on a narrowly scoped service principal, because the account may already sit close to privileged workflows before delegation is added.
What breaks first when delegation is too broad
When delegation is over-permissive, the first failure is usually impersonation depth. An attacker who controls the delegated machine account can move from a local compromise to service impersonation, then to directory-level action if the object can reach sensitive endpoints. The risk is highest where delegation intersects with password management, replication permissions, or other control surfaces that affect many users at once.
Another failure is visibility. Delegated activity can look like legitimate service behavior, so defenders may miss the moment when a computer object starts acting outside its expected workload. That makes it important to distinguish normal service-to-service access from actions that imply administrative authority or directory manipulation.
For a concrete threat view, the escalation path is not theoretical: once a machine identity can operate as a trusted intermediary, it can be used to chain access into broader control of authentication infrastructure. The escalation is therefore caused by trusted delegation plus excessive privilege, not by Kerberos alone.
Risk and Threat Considerations
Machine-account delegation is high risk because it can convert a single compromised endpoint into a trusted impersonation path inside the directory trust fabric. When that object can reach identity or replication functions, an attacker can use it to amplify a foothold into broad authentication control.
Failure mechanism: Excessive delegation lets a machine object obtain or present authority that was never meant to survive a compromise, so the attacker can reuse legitimate trust to perform privileged identity operations.
Impact: The compromise can expand from one host to domain-wide escalation, including credential reset, ticket abuse, service impersonation, and directory-level persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegation on machine accounts is an access-scoping problem. |
| IA-5 — Authenticator Management | Machine-account delegation depends on secret and ticket handling. | |
| AC-2 — Account Management | Delegated computer objects must be inventoried and governed as accounts. | |
| Recommendation — Limit delegated machine-account privileges to the minimum required. Protect, rotate, and revoke machine credentials and tickets promptly. Inventory delegated machine accounts and review their trust paths regularly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegated machine trust should not be assumed inside the trust fabric. |
| Recommendation — Treat delegated machine accounts as untrusted until explicitly validated. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Delegation abuse often alters or leverages account settings for escalation. |
| Recommendation — Map delegated-account abuse to account-manipulation detections and alerts. | ||
Practitioner Guidance
What to verify: Confirm exactly which machine accounts are trusted for delegation, which services they can impersonate, and whether any of those paths touch directory administration, password operations, or replication-related access. If a computer object can affect identity infrastructure, treat it as a high-risk control point.
Common mistake: Teams often review delegation as a local service setting and miss its directory consequences. The dangerous condition is not “delegation exists”, but “delegation exists on an object that can reach privileged identity functions”.
Decision rule: If a delegated machine account can influence authentication or directory state, reduce scope or remove delegation before investigating whether it has already been abused.
Practitioner takeaway: The escalation risk comes from trust reuse, so the safest posture is to assume delegated machine accounts are privileged until you can prove their authority is narrow, observable, and non-transferable.
Related resources from NHI Mgmt Group
- Why do non-human identities create more risk than many human accounts?
- Why do non-human identities create more remediation risk than many human accounts?
- Why do service accounts and delegation settings create so much risk in Active Directory?
- Why do vendor accounts create higher breach risk than internal user accounts?