How should teams decide whether software belongs on a domain controller?

Why This Matters for Security Teams

domain controller are not general-purpose servers. When software is installed there, it inherits one of the most sensitive trust zones in the environment, so the decision must be based on necessity rather than convenience. The real risk is not just malware, but privilege expansion: extra services, update agents, browser components, and interactive tools create new paths for credential theft, lateral movement, and unintended administrative use. Current guidance from NIST Cybersecurity Framework 2.0 reinforces the need to reduce exposure on critical assets. NHIMG research on secrets abuse also shows how quickly exposed credentials are acted on in the wild, which is why high-value hosts need tighter restraint than ordinary servers.

For domain controllers, the default should be deny unless the software is directly required for directory services or essential management. The question is not whether the tool is useful to administrators, but whether it is indispensable to controlling the domain itself. In practice, many security teams encounter domain controller software risk only after a convenience install has already widened the attack surface.

How It Works in Practice

Teams should evaluate each candidate application against a simple control test: does it perform directory control, or does it merely make administration easier? If it does not directly support Active Directory operations, authentication services, replication, policy enforcement, time sync, backup, or tightly scoped monitoring, it belongs elsewhere. Software that introduces an agent, an auto-update channel, a shell, a browser, or a remote support path usually creates more risk than value on a domain controller.

• Prefer dedicated management hosts for consoles, RMM tools, backup orchestration, and security products with broad telemetry.
• Keep domain controllers minimal, with only the components needed for identity and policy enforcement.
• Review every installer for services, scheduled tasks, drivers, and outbound connectivity before approval.
• Use separate administrative workstations or jump servers for interactive access instead of logging on directly to the domain controller.

This approach aligns with least privilege and reduces the chance that an administrative convenience becomes a persistent foothold. It also mirrors the operational logic behind the Ultimate Guide to NHIs — Standards, which treats high-trust systems as places where identity sprawl must be constrained rather than tolerated. Where software is truly required, teams should document the business need, limit the installation scope, and monitor for new processes or credential usage. When security tooling needs broad visibility, a separate server is usually the safer design, because a domain controller is a control plane, not a convenience platform. These controls tend to break down in small environments where one server is expected to act as domain controller, admin workstation, and monitoring host at the same time because operational shortcuts override separation.

Common Variations and Edge Cases

Tighter control on domain controllers often increases operational overhead, requiring organisations to balance administrative convenience against containment and recovery risk. That tradeoff becomes most visible when legacy tools, vendor agents, or backup software claim they must run locally to function. Current guidance suggests treating those claims as exceptions that require explicit justification, not as automatic approvals, because there is no universal standard for every product category yet.

Some environments also rely on endpoint protection, log forwarding, or privileged access components on domain controllers. If those tools are approved, they should be narrowly scoped, continuously reviewed, and isolated from interactive use as much as possible. The same caution applies to software that brings its own update service or embedded browser, because those features often expand the attack surface in ways that are hard to justify on a critical identity host. NHIMG’s analysis of DeepSeek breach and JetBrains GitHub plugin token exposure shows how quickly sensitive systems become exposed when tokens, plugins, or extra paths are allowed to proliferate. The practical rule is simple: if the software does not help control the domain directly, it should not live on the domain controller.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
• How do teams decide whether a response action belongs in automation or manual handling?
• How can teams decide whether a private AI app belongs in the enterprise?