Category: Network Security

Demilitarized Zone (DMZ)

Also known as: DMZ, perimeter network, neutral zone

Simply put

A DMZ is a separate network segment placed between an organization's private internal network and an untrusted network such as the internet. It acts as a buffer or neutral zone so that systems reachable from the outside are kept apart from sensitive internal systems. This adds an extra layer of separation intended to reduce direct exposure of the internal network.

Formal definition

A demilitarized zone (DMZ) is a host or network segment inserted as a neutral or perimeter zone between an organization's private (trusted) network and an external untrusted network, typically the internet. It is used to isolate publicly accessible services from the internal local-area network, providing an additional layer of segmentation intended to limit direct connectivity between untrusted sources and internal systems. Effectiveness depends on the specific segmentation, access controls, and validation implemented rather than on the presence of a DMZ alone.

Why it matters

In payment environments, the systems that must be reachable from the internet, such as web servers accepting card-not-present transactions, are among the most exposed to attack. A DMZ matters because it places these publicly accessible services in a separate network segment rather than allowing untrusted traffic to reach the internal network where sensitive systems reside. This separation is intended to reduce direct exposure of internal systems by ensuring that a compromise of an internet-facing host does not immediately grant an attacker connectivity to the trusted internal network.

For organizations handling cardholder data, network segmentation of this kind is closely tied to how the cardholder data environment (CDE) is defined and scoped. Keeping publicly reachable services isolated from systems that store, process, or transmit cardholder data can help limit the systems that fall within assessment scope and can reduce the pathways an attacker could use to move toward that data. However, the presence of a DMZ alone does not achieve this; the outcome depends on the specific segmentation, access controls, and validation that are implemented and tested.

It is important not to overstate what a DMZ provides. A DMZ is one architectural control among many and is intended to add a layer of separation, not to eliminate the risk of compromise. Misconfigured firewall rules, overly permissive connectivity between the DMZ and internal networks, or vulnerable services within the DMZ itself can undermine its intended benefit. Its effectiveness should be validated rather than assumed.

Who it's relevant to

Network and security architects

Architects use a DMZ to isolate internet-facing services from internal systems and to define trust boundaries. They are responsible for specifying the segmentation and access controls at each boundary and for ensuring the design limits direct connectivity between untrusted sources and internal networks.

Compliance officers and PCI DSS assessors

Those concerned with PCI DSS should consider how a DMZ relates to defining and isolating the cardholder data environment and to reducing assessment scope. Because effectiveness depends on how segmentation is implemented and validated, reviewers should confirm that boundaries are tested rather than assumed. Specific requirement wording differs between PCI DSS versions, so readers should confirm details against the current published standard.

Firewall and network operations teams

Operations teams configure and maintain the access control rules that make a DMZ effective, controlling traffic from the internet into the DMZ and from the DMZ into internal systems. Overly permissive or misconfigured rules can undermine the intended separation, so ongoing review and validation of these rules is important.

Merchant and application teams running public-facing services

Teams that operate web-facing systems, including those accepting card-not-present transactions, are affected because such services are typically placed in the DMZ. They should treat these hosts as exposed to untrusted traffic and secure them accordingly, recognizing that placement in a DMZ limits exposure but does not remove the need to harden the services themselves.

Inside DMZ

Perimeter or boundary network

A DMZ is a network segment positioned between an untrusted network (typically the internet) and an internal trusted network, adding a controlled buffer that limits direct external access to internal systems.

Public-facing services

Systems intended to receive inbound connections from untrusted networks, such as web servers, reverse proxies, mail relays, or DNS, are commonly placed in the DMZ so that untrusted traffic terminates there rather than in the internal network.

Firewall and access-control enforcement

Firewalls or equivalent controls govern traffic entering and leaving the DMZ in both directions, restricting inbound access from untrusted networks and limiting DMZ-to-internal connections to only what is explicitly required.

Segmentation boundary relevant to PCI DSS scope

In PCI DSS terms, a DMZ is one mechanism for network segmentation and boundary control. Whether it reduces cardholder data environment (CDE) scope depends on implementation and validation, not on the presence of a DMZ alone. Confirm specific requirement wording against the current published PCI DSS version.

Restriction on cardholder data storage

PCI DSS guidance generally directs that cardholder data not be stored in a DMZ or other systems directly accessible from untrusted networks. Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization anywhere, including a DMZ, even if encrypted.

Common questions

Answers to the questions practitioners most commonly ask about DMZ.

Does placing a system in the DMZ make it out of PCI DSS scope?

No. A DMZ is a network segmentation construct that separates untrusted external networks from internal trusted networks, but placement in a DMZ does not by itself remove a system from PCI DSS scope. Systems in the DMZ that store, process, or transmit cardholder data, or that can affect the security of the cardholder data environment (CDE), remain in scope. Scope is determined by connectivity and data flows, not by network zone label alone. Confirm scoping against the current published PCI DSS and any segmentation validation.

Is a DMZ enough on its own to protect cardholder data?

No. A DMZ is intended to reduce direct exposure of internal systems to untrusted networks by providing an intermediate, controlled zone, but it is one layer among many. It does not replace controls such as encryption of data in transit, tokenization or truncation of stored data, access controls, logging, vulnerability management, and monitoring. A DMZ may mitigate certain external attack paths, but it does not prevent all compromise and should be combined with other defenses.

What kinds of systems are typically placed in a DMZ?

Systems that must be reachable from untrusted networks, such as public-facing web servers, reverse proxies, or externally accessible application front ends, are commonly placed in a DMZ so that inbound traffic terminates there rather than directly on internal systems. The intent is to keep systems that store cardholder data on internal segments and avoid direct external reachability. The specific architecture depends on your environment and should be validated against the current published PCI DSS.

How should traffic be restricted between the DMZ and the internal network?

Traffic between the DMZ and internal networks should be limited to only what is explicitly necessary, using firewall or equivalent controls that restrict source, destination, port, and protocol. Direct inbound connections from untrusted networks to internal systems that hold cardholder data are generally not permitted; such traffic should terminate in the DMZ. Rules should be documented, justified by business need, and reviewed periodically. Confirm specific requirement wording against the current version of PCI DSS.

Can cardholder data be stored on systems in the DMZ?

The common design intent is to avoid storing cardholder data in the DMZ, keeping such storage on more protected internal segments. If any system in the DMZ stores, processes, or transmits cardholder data, it is in scope and subject to applicable controls. Note that sensitive authentication data must not be stored after authorization anywhere, including the DMZ, even when encrypted. Validate your data flows and storage decisions against the current published standard.

How can I validate that a DMZ is providing effective segmentation for scope reduction?

Effective segmentation is demonstrated through configuration review and testing rather than by assertion. This typically includes reviewing firewall and routing rules, verifying that intended isolation holds, and performing segmentation testing to confirm that untrusted zones cannot reach in-scope systems by unintended paths. If segmentation is relied upon to reduce scope, the adequacy and testing expectations depend on the current PCI DSS version; confirm the applicable requirements and testing frequency against the published standard.

Common misconceptions

A DMZ by itself keeps a system out of PCI DSS scope.

Placement in a DMZ does not automatically remove a system from scope. Scope reduction depends on how segmentation is implemented, how connectivity is restricted, and how it is validated. Systems in a DMZ that store, process, or transmit cardholder data, or that can affect the security of the CDE, remain in scope.

A DMZ prevents attacks against internal systems.

A DMZ is intended to reduce direct exposure of internal systems and help contain compromise, but it does not prevent attacks. Misconfigured firewall rules, vulnerable public-facing services, or overly permissive DMZ-to-internal paths can still allow lateral movement. It is one control among many, not a guarantee.

Encrypting data means it is safe to store cardholder or authentication data in the DMZ.

Encryption does not change the prohibition on storing sensitive authentication data after authorization, which applies even when data is encrypted. Cardholder data is generally directed away from DMZ systems that are directly reachable from untrusted networks, and encryption alone does not authorize such storage.

Best practices

Restrict inbound traffic from untrusted networks to only the specific DMZ systems, ports, and protocols required, and deny all other traffic by default.

Limit connections from the DMZ into the internal network to only what is explicitly necessary, avoiding direct paths from DMZ systems into the cardholder data environment.

Avoid storing cardholder data on DMZ systems that are directly accessible from untrusted networks, and never store sensitive authentication data after authorization anywhere, including the DMZ, even when encrypted.

Validate segmentation and boundary controls through testing appropriate to your environment to confirm that the DMZ actually restricts access as intended, rather than assuming its presence reduces scope.

Harden and maintain public-facing DMZ services, keeping them patched and running only necessary functions to reduce the exposure that a boundary network is intended to contain.

Confirm the specific applicable controls and requirement wording against the current published PCI DSS version, since numbering and language differ between versions.