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.
Expanded Definition
machine account Quota, often abbreviated MAQ, is an Active Directory control that limits how many computer objects a standard user can create. In NHI security, it matters because each newly created machine object can become a foothold for unmanaged trust, mis-scoped permissions, or credential material tied to join workflows. The setting is not a complete safeguard on its own: the effective risk depends on who can join devices, what group memberships are inherited, and whether directory administrators can actually enforce the intended boundary in a managed tenant.
Definitions vary across vendors and directory-management tools, but the security intent is consistent: reduce the ability of ordinary users to create ad hoc machine identities that bypass governance. In practice, MAQ should be read alongside join rights, delegated administration, and identity lifecycle controls described in the NIST Cybersecurity Framework 2.0. The most common misapplication is treating MAQ as a standalone hardening measure, which occurs when organisations lower the quota but leave machine-join permissions and group membership paths unchanged.
Examples and Use Cases
Implementing Machine Account Quota rigorously often introduces operational friction for device onboarding, requiring organisations to weigh user convenience against tighter control over machine creation paths.
- Restricting ordinary users from creating extra computer objects during workstation onboarding so only approved join processes can introduce new machines.
- Using MAQ as a backstop while helpdesk or automation accounts handle domain joins under monitored delegation rather than broad user permissions.
- Reviewing whether a managed directory still permits self-service device creation even after the quota is reduced, since join rights may remain the real exposure.
- Investigating anomalous machine-object growth after an incident, especially when a user account unexpectedly created a computer object that later mapped to suspicious access.
- Comparing MAQ settings with lessons from incidents such as the Schneider Electric credentials breach, where identity misuse and weak control boundaries can amplify impact.
In larger environments, MAQ is best treated as one input into identity governance rather than a complete policy outcome. If a directory’s join workflow is permissive, the quota may only delay abuse rather than prevent it, so teams often pair it with NIST Cybersecurity Framework 2.0 access control practices and explicit approval workflows.
Why It Matters in NHI Security
Machine Account Quota matters because machine objects are not just records in a directory; they can become non-human identities with authentication material, trust relationships, and downstream permissions. When ordinary users can create them freely, defenders may lose visibility into which systems are legitimate and which were introduced for abuse. That ambiguity is especially dangerous in environments already struggling with service-account sprawl, where NHI Mgmt Group reports that 97% of NHIs carry excessive privileges and only a small share of organisations maintain full visibility into service account. A weak MAQ posture can therefore feed the same governance failures that expose secrets, privilege boundaries, and device trust paths.
The broader lesson is that MAQ is a control over identity creation, not just directory hygiene. If left unreviewed, it can provide attackers with a low-noise way to manufacture persistence or impersonate managed endpoints inside a trusted domain, especially where lifecycle checks are weak and join rights are poorly delegated. Organisations typically encounter the consequences only after a suspicious computer object appears in incident response, at which point the quota becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Machine object creation is part of NHI lifecycle governance and trust boundary control. |
| NIST CSF 2.0 | PR.AC-4 | MAQ supports least-privilege access by constraining identity creation rights. |
| NIST Zero Trust (SP 800-207) | N/A | Zero Trust requires explicit verification of device identity before trust is granted. |
Limit who can create machine identities and review every join path for delegated abuse.
