What should be placed in a DMZ?

What belongs in a DMZ and why the boundary matters

A dmz is not a general-purpose subnet, it is a deliberately narrow exposure zone for systems that must accept traffic from untrusted networks. The right contents are internet-facing services such as public web, mail, or proxy systems, plus only the supporting components those services need to function. That design keeps the blast radius small if an exposed host is probed or compromised.

The practical rule is to place only the minimum set of systems that need external reachability and keep everything else internal. User endpoints, databases, directory services, and administrative tooling belong behind stronger internal controls because they usually do not need direct exposure. A DMZ should also be separated from the internal network with explicit filtering and limited trust relationships, not used as a shared landing zone for convenience.

In mature environments, DMZ placement is part of a broader segmentation strategy, not a standalone perimeter trick. Network Segmentation Guide is useful here because the same principles apply whether the boundary is a classic DMZ, a cloud security zone, or a microsegmented workload tier. The core decision is always the same: what absolutely must be reachable from outside, and what must never be directly reachable.

What should be excluded from a DMZ

Anything that stores sensitive internal state or brokers broad trust should stay out of the DMZ. That includes databases, identity directories, domain controllers, workstation pools, file shares, backup targets, and management systems. Putting these in the DMZ usually increases exposure without adding a legitimate external use case, and it weakens the assumption that the zone can be treated as partially hostile.

Administrative access should also be designed carefully. If a system needs to be managed, the management plane should not be casually exposed in the same zone as public services. A DMZ can host a jump target or a tightly controlled relay if there is a clear operational need, but the access path should be narrow, logged, and separated from the service traffic it supports.

Service dependencies matter as much as the visible host. If a public web server in the DMZ depends on an internal database or directory service, the dependency should run through tightly scoped rules and authenticated channels, not through broad network reachability. That keeps the DMZ from becoming a soft underbelly into the rest of the environment.

How to design DMZ placement so it stays defensible

A defensible DMZ starts with a strict purpose statement: each host should be there because it must face untrusted traffic, not because it is convenient to deploy there. After that, define the allowed inbound and outbound flows explicitly, and review them as a service design artefact rather than a firewall afterthought. If a service can be published through a reverse proxy, load balancer, or gateway instead of exposing the backend directly, that is usually the better pattern.

Segmentation controls should be paired with monitoring. Traffic between the DMZ and internal segments should be highly visible, with alerting on unexpected destinations, ports, or protocol changes. NIST SP 800-207 Zero Trust Architecture supports this mindset because it treats network location as insufficient trust by itself and pushes you toward explicit verification and least privilege between zones.

For practitioners, the important question is not whether a system is “internet-facing” in a vague sense, but whether its exposure can be justified, bounded, and continuously observed. A well-designed DMZ reduces trust rather than redistributing it, and it should be able to fail without giving an attacker a broad path inward.

Risk and Threat Considerations

A DMZ becomes dangerous when it is used as a convenience zone for systems that are only loosely related to public access. The more services you place there, the larger the exposed attack surface and the more likely one compromise can become a foothold for lateral movement into internal systems.

Failure mechanism: Attackers target the DMZ because it is the one place you intentionally expose to untrusted networks. If internal systems are allowed to communicate broadly with the DMZ, or if the DMZ has weak segmentation and overbroad trust, a compromise can pivot into internal applications, directories, or management planes.

Impact: Poor DMZ scoping can turn a perimeter compromise into enterprise-wide exposure. The usual failure mode is not the DMZ host alone, but the trust relationships behind it, especially when the zone contains systems that can authenticate onward or reach sensitive internal resources.

Practitioner Guidance

What to verify: Confirm that every DMZ host has a documented external business need, a minimal port list, and a clear internal dependency map. If you cannot explain why a system must be reachable from the internet, it does not belong in the DMZ.

Common mistake: Treating the DMZ as “less trusted internal space” instead of a constrained exposure zone. That mistake often leads to domain services, admin tooling, databases, or shared utilities being placed there simply because they are easy to route to.

What good looks like: Public services are isolated, east-west traffic is tightly restricted, management access is separate, and any connection from the DMZ to internal systems is narrowly scoped and monitored. The boundary should reduce the number of trusted paths, not just add another subnet name.

Practitioner takeaway: Place only externally necessary, tightly controlled entry points in the DMZ, and design every exception as if the zone will eventually be probed, abused, or partially compromised.

Related resources from NHI Mgmt Group

• Who is accountable when a regulated workload is placed in the wrong Microsoft 365 environment?
• What breaks when seized crypto assets are not placed under formal custody controls?
• What breaks when CORS middleware is not placed correctly in a Django middleware stack?
• What breaks when identity discovery does not cover disconnected or DMZ networks?