Category: Network Security

Untrusted Network

Also known as: Untrusted Zone, Hostile Network

Simply put

An untrusted network is any network that an organization does not control or manage directly, and which is therefore treated as potentially insecure. Because data crossing such a network could be intercepted or altered by malicious parties, connections to and from it require added protections. Common examples include the public internet and other external networks outside an organization's secured internal environment.

Formal definition

An untrusted network is a network segment or connection external to the boundaries an organization manages and secures, and which is assumed to carry a risk of interception, modification, or malicious traffic. In practice it is any network outside the defined trust boundary of the internal environment, most commonly the public internet, and traffic between trusted and untrusted networks is typically mediated by controls such as firewalls, segmentation, and encryption. The designation is a risk-based control assumption rather than an assertion about a specific technology; whether a given network is treated as trusted or untrusted, and the controls required at that boundary, depend on the organization's architecture, segmentation decisions, and applicable requirements, which should be confirmed against the current published standard governing the environment.

Why it matters

The concept of an untrusted network underpins much of network security architecture and PCI DSS boundary controls. Because data crossing an untrusted network such as the public internet could be intercepted or altered by malicious parties, the designation forces organizations to apply protections at the trust boundary rather than assuming traffic is safe by default. Treating the wrong network as trusted, or failing to enforce controls at the boundary between trusted and untrusted zones, can expose cardholder data and other sensitive information to interception or manipulation.

In payment environments, the distinction matters because it drives where controls like firewalls, segmentation, and encryption of transmitted data are required. Cardholder data transmitted across an untrusted network is typically expected to be protected with strong cryptography, while sensitive authentication data must not be stored after authorization regardless of the network it traverses. The specific requirements applicable to transmission across untrusted networks differ between PCI DSS versions in numbering and wording, so readers should confirm the applicable controls against the current published standard governing their environment.

Because the untrusted designation is a risk-based control assumption rather than a statement about a particular technology, the same physical network can be treated as trusted or untrusted depending on architecture and segmentation decisions. Misjudging this boundary is a common source of scope and control gaps; the correct classification depends on the organization's architecture, not on the label alone.

Who it's relevant to

Security Engineers and Network Architects

Those designing network boundaries use the trusted versus untrusted distinction to decide where to place firewalls, segmentation, and encryption controls. Correctly identifying which segments fall outside the managed trust boundary is essential to protecting data in transit and isolating sensitive environments from hostile networks and untrusted clients.

Compliance Officers

Compliance teams rely on the untrusted network concept to determine where transmission protections and boundary controls apply within scope. Because requirement numbering and wording differ between PCI DSS versions, they should confirm the specific controls for data crossing untrusted networks against the current published standard rather than assuming a fixed requirement.

Payment Processors and Acquirers

Organizations transmitting cardholder data across external networks such as the public internet must treat those paths as untrusted and apply appropriate protections, including strong cryptography for transmitted data. This helps reduce the risk of interception or manipulation while data crosses networks the organization does not control.

Merchant Risk and Infrastructure Teams

Teams managing merchant environments use the classification to justify segmentation between internal systems and untrusted zones. Isolating internal domains from hostile untrusted networks with untrusted clients is intended to limit exposure, though its effectiveness depends on correct implementation and validation.

Inside Untrusted Network

Definition of untrusted network

A network that is external to an entity's cardholder data environment (CDE) or that the entity does not control, and whose security posture cannot be assured. In PCI DSS terminology, any network not explicitly identified as trusted is generally treated as untrusted. Confirm exact wording against the current published PCI DSS, as terminology and requirement numbering differ between versions.

Public networks

Networks such as the internet, wireless technologies open to the public, and mobile carrier networks that fall outside the entity's control. Transmission of cardholder data across such networks typically triggers requirements to protect data in transit, for example using strong cryptography and secure protocols.

Trust boundary

The logical demarcation between an entity's trusted internal networks (including the CDE) and untrusted networks. Controls such as firewalls, network segmentation, and access controls are placed at this boundary to restrict and inspect traffic crossing between untrusted and trusted zones.

Data in transit versus data at rest

The untrusted network concept concerns data in transit. Protecting cardholder data crossing untrusted networks is distinct from storage controls for data at rest. Note that sensitive authentication data must not be stored after authorization even when encrypted, whereas some cardholder data may be stored under defined controls; transmission protections address a different point in the data lifecycle.

Third-party and connected networks

Networks belonging to partners, service providers, or other connected entities that the entity does not fully control may be treated as untrusted unless their trust status and controls are validated. Scope depends on connectivity and how the relationship is assessed against the current standard.

Common questions

Answers to the questions practitioners most commonly ask about Untrusted Network.

Is the internet the only network that should be treated as untrusted?

No. An untrusted network is any network whose security controls are outside your control or cannot be verified, not solely the public internet. Wireless networks, partner and third-party connections, guest segments, and even portions of an internal network can be untrusted relative to the cardholder data environment. Treating only the internet as untrusted can leave internal or partner-facing paths inadequately protected. Trust should be determined by demonstrated controls and verification, not by whether a network is labeled internal or external.

If a network is inside our own facility, does that make it trusted by default?

Not automatically. Being internal or on-premises does not by itself make a network trusted. Trust is a function of the controls applied and validated, such as segmentation, access restrictions, and monitoring, rather than physical or organizational location. An internal segment that connects to systems with unverified or weaker controls may be untrusted with respect to the cardholder data environment. Each connection should be assessed on its actual controls, and readers should confirm applicable expectations against the current published PCI DSS.

How do we determine whether a specific network should be classified as untrusted?

Classification depends on whether you can verify and rely on the network's security controls. Document the network's ownership, the controls in place, how they are monitored, and whether they are within your ability to enforce. Where controls cannot be verified or are outside your control, treat the network as untrusted and apply corresponding protections at the boundary. Base the decision on assessed controls rather than on a network label, and confirm the applicable requirements against the current published PCI DSS version.

What controls are typically placed at the boundary between a trusted and an untrusted network?

Boundaries between trusted and untrusted networks are generally protected by controls that restrict and inspect traffic, such as firewalls or equivalent network security controls, with rules that permit only necessary connections. Segmentation can be used to separate the cardholder data environment from untrusted networks, and connections may be monitored for anomalous activity. The specific control expectations and requirement wording differ between PCI DSS versions, so confirm the exact requirements against the current published standard rather than assuming fixed numbering.

How should data be protected when it must traverse an untrusted network?

When cardholder data is transmitted over an untrusted or open network, it is generally expected to be protected using strong cryptography during transmission. Note that encryption in transit addresses confidentiality of data while it moves, and is distinct from tokenization, truncation, masking, or hashing, which transform or reduce stored data differently. Encryption in transit does not by itself remove a system from scope; scope effects depend on implementation and validation. Confirm the applicable transmission requirements against the current published PCI DSS version.

Does adding segmentation to isolate the cardholder data environment from untrusted networks reduce PCI DSS scope?

Segmentation can help isolate the cardholder data environment from untrusted networks, and effective, verified segmentation may reduce scope. However, the scope-reducing effect depends on how segmentation is implemented and validated, not on the presence of a control alone. Segmentation that is misconfigured or not verified may leave connected systems in scope. The methods used to confirm segmentation effectiveness and their expectations differ between PCI DSS versions, so confirm against the current published standard.

Common misconceptions

Encrypting data over an untrusted network removes that network from PCI DSS scope.

Encryption using strong cryptography helps protect cardholder data in transit, but whether it affects scope depends on implementation and validation, not the label alone. Encryption in transit is a distinct control from tokenization, truncation, masking, or hashing, and does not by itself remove connected systems from scope. Confirm scoping outcomes against the current published PCI DSS and your assessor.

Internal networks are automatically trusted and require no protection.

Trust is determined by an entity's controls and validation, not by whether a network is labeled internal. A network segment can be treated as untrusted relative to the CDE, and traffic between segments may still require controls. Segmentation must be verified rather than assumed.

Only the public internet counts as an untrusted network.

Any network the entity does not control or whose security cannot be assured may be treated as untrusted, including certain wireless, mobile carrier, and third-party or connected networks. The internet is one example, not the sole case.

Best practices

Apply strong cryptography and secure protocols to protect cardholder data whenever it is transmitted across open, public, or otherwise untrusted networks, and verify configurations against the current published PCI DSS rather than assuming a fixed requirement number.

Clearly document and maintain the trust boundary between the CDE and untrusted networks, and validate any network segmentation used to reduce scope so that its effect is demonstrated rather than assumed.

Deploy and regularly review firewall and access control rules at the boundary to restrict inbound and outbound traffic between untrusted and trusted networks to only what is necessary.

Treat third-party and connected networks as untrusted unless their trust status and controls have been assessed and validated, and define responsibilities accordingly.

Distinguish transmission protections from storage controls: ensure sensitive authentication data is not stored after authorization even when encrypted, and confirm that in-transit encryption is not relied upon to satisfy data-at-rest requirements.

Confirm scoping decisions with a qualified assessor and against the current standard, since whether a control such as encryption affects PCI DSS scope depends on implementation and validation, not the label alone.