What breaks when organisations leave machine account creation permissions at their default level?

When machine account creation stays open, attackers can create their own computer objects and use them as an exploitation platform. That breaks a key trust boundary because the new account can support Kerberos ticket abuse, especially where service principal names and delegation behavior are involved. The result is not just excess accounts, but a practical route to domain compromise.

What actually breaks when machine account creation is left open?

Leaving creation permissions at the default level turns machine account from managed trust objects into an attacker-controlled foothold. Once an adversary can register a computer object, they can often shape the account for abuse, including ticket-related attacks, delegation misuse, and persistence. The real failure is not just “too many accounts”, it is loss of control over who can introduce trusted principals.

That matters because machine accounts are not passive inventory. They participate in authentication, service placement, and trust decisions. If the environment lets anyone create them, the directory starts accepting attacker-supplied objects as if they were legitimate infrastructure, which undermines the assumptions that protect domain services and downstream access paths.

For practitioners, the important question is whether machine account creation is intentionally scoped or merely inherited from defaults. If it is not explicitly governed, the permission can become a bridge between low-privilege access and high-value identity abuse.

Why the trust boundary fails so quickly

The boundary fails because directory services treat the new machine object as a real participant in the trust fabric. That can give the attacker a place to obtain or manipulate Kerberos artifacts, use service principal name behavior, and interact with delegation settings in ways that normal user accounts cannot. In practice, the account becomes an exploitation platform, not just an extra object in inventory.

This is also why the issue is not solved by counting accounts alone. The meaningful control question is whether the created object can authenticate, request tickets, or be referenced by services in a way that expands the attacker’s reach. If the answer is yes, the permission has created a trust boundary violation, not a mere hygiene problem.

Where directories allow broad creation rights, the attacker does not need to steal an existing machine account first. They can manufacture one that fits the abuse path they want, which is far easier than compromising a hardened system account already under watch.

What that means for domain security and control design

The security consequence is domain-level privilege expansion. A permissive machine account creation setting can support ticket abuse, delegation abuse, and lateral movement opportunities that eventually land in domain compromise. It also weakens investigation quality, because defenders now have to distinguish legitimate infrastructure objects from attacker-created ones under the same naming and trust model.

For a control to be effective, it must address both permission and follow-on abuse. That means treating machine account creation as a privileged administrative capability, not a convenience feature. It also means pairing the permission decision with monitoring for unexpected computer object creation, unusual service principal names, and abnormal ticket activity tied to new objects.

In environments with many automated workflows, the risk scales with the number of places where machines can appear without a human review step. The more frictionless the default, the easier it is for a malicious object to blend into ordinary directory operations.

Risk and Threat Considerations

Open machine account creation is attractive to attackers because it gives them an identity-like object they can use to stage ticket abuse, impersonation attempts, and directory trust manipulation. The danger is highest where delegation is enabled, where service principal names are accepted without tight governance, or where new computer objects are not reviewed quickly.

Failure mechanism: An attacker abuses default creation rights to register a computer object, then leverages that object to obtain authentication material, influence Kerberos flows, or position itself for delegation and lateral movement.

Impact: The organisation loses control over a trust-bearing principal, which can enable persistence, hidden abuse paths, and in the worst case domain compromise.

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, CIS Controls v8 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	Open machine account creation expands what non-human principals can do in the domain.
	NHI-04 — Insecure Authentication	Attacker-created machine objects can be used to abuse Kerberos and delegation flows.
Recommendation — Restrict creation rights and remove excess permissions from machine accounts. Harden authentication paths for machine accounts and block abusive trust relationships.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Creation of computer objects is a privileged capability that should be narrowly assigned.
	IA-5 — Authenticator Management	Machine accounts rely on credentials and ticketing material that must be controlled and rotated.
	AU-2 — Event Logging	Unexpected computer object creation and subsequent auth use need audit visibility.
Recommendation — Limit machine account creation to tightly scoped administrative roles. Manage machine credentials with rotation, retention limits, and inventory control. Log machine account creation and review anomalous authentication from new objects.
CIS Controls v8	CIS-5 — Account Management	The issue is uncontrolled account creation and lifecycle governance for machine principals.
Recommendation — Review and restrict machine account creation as part of account lifecycle governance.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication and Access Control	Machine account creation is an identity and access control decision with trust implications.
Recommendation — Apply identity and access controls to tightly govern machine account creation.

Practitioner Guidance

What to prioritise: Treat machine account creation as a controlled administrative action, not a baseline entitlement. If non-administrative users can create computer objects, review whether that capability is still needed and whether it should be scoped to a specific workflow or join process.

What to verify: Check who can create computer objects, whether the limit is intentionally configured, and whether newly created machine accounts are monitored for service principal name changes, delegation settings, and unexpected authentication activity.

Common mistake: Teams often focus on password complexity or naming conventions while leaving the creation path open. That misses the real issue, which is not how the object is named, but that an untrusted actor can introduce a trusted principal.

Practitioner takeaway: If an attacker can create the machine account, they may be able to use the directory’s own trust model against you, so the control objective is to constrain creation, observe it, and treat every new computer object as a potential abuse path until proven otherwise.