PCI DSS 1.4 trusted and untrusted network connections

What PCI DSS 1.4 asks for and why boundary controls fail

Requirement 1.4 asks you to prove that every connection between trusted and untrusted networks is controlled at the boundary, and that systems holding cardholder data cannot be reached directly from the internet. If you are a compliance lead or engineer preparing for assessment, the work is less about buying a firewall and more about showing, for each boundary, which network security controls (NSCs) sit there, what they allow, and who approved that. PCI DSS v4.0.1 is the only active version of the standard, so assessors will test against its wording. Your organization owns these controls. An implementation partner can help build and document them, but only the assessor can judge whether they meet the requirement. The five sub-requirements cover different failure points. Requirement 1.4.1 expects NSCs between trusted and untrusted networks. Requirement 1.4.2 limits inbound traffic from untrusted networks to components that deliberately provide public services, plus replies to sessions started inside the trusted network, with everything else denied. Requirement 1.4.3 expects anti-spoofing measures so that packets claiming an internal source address arriving from outside are dropped. Requirement 1.4.4 prohibits direct access from untrusted networks to system components that store cardholder data. Requirement 1.4.5 limits disclosure of internal IP addresses and routing information to authorized parties. The risks behind these are direct internet reach to card data, over-broad inbound rules, forged internal traffic and exposed internal addressing that helps an attacker map the network.

Boundary controls usually fail for predictable reasons. Rules accumulate as teams add temporary exceptions for vendors, monitoring or troubleshooting, and nobody records why they exist or when they can be removed. In cloud environments, security groups, route tables and load balancers change through infrastructure code and console edits, so the boundary an assessor sees on the day of testing may differ from the one documented months earlier. Routing and address information also leaks through diagrams, DNS records and error messages that were never reviewed as disclosure. A practical starting point is to list every path from the internet into the cardholder data environment, record the business reason and owner for each rule, and confirm with your assessor which evidence (rule exports, configuration history, network diagrams and test results) they expect for each sub-requirement. Confirm your exact scope and the applicable approach with your assessor before you rely on any design.

Which connections and systems 1.4 covers

Requirement 1.4 applies wherever a trusted network meets an untrusted one, and the boundary is wider than the internet edge. The decisions below determine which links, hosts and third parties fall under the control and how much evidence each one produces.

Every trusted and untrusted link

Map each connection that crosses from a trusted network to an untrusted one, including internet uplinks, partner and payment gateway links, vendor remote access, and wireless segments that touch the cardholder data environment. Each link needs a network security control at the boundary under 1.4.1. Missing a link is the most common scoping gap, because partner VPNs and guest Wi-Fi often sit outside the main firewall review. Ask for a list of every boundary crossing with its controlling device, and confirm it matches the network diagram.

Memory used as storage

The SAQ D note to 1.4.4 separates volatile-only memory from memory used as persistent storage. A RAM disk, a tmpfs mount that holds files, or a cache that writes card data to disk is in scope, while memory that holds account data only during processing is not. This choice changes which hosts must be protected from direct untrusted access. Check host configuration, container volumes and application caches for persistence before deciding that a system is out of scope.

DMZ and public-facing components

Web servers, APIs, payment redirect pages and load balancers in a DMZ are the only systems that should receive inbound traffic from untrusted networks under 1.4.2. Every public service needs a documented justification, and anything else reachable from the internet is a finding. The effort rises with the number of public endpoints, so inventory them first. Confirm that no system holding account data is placed in the DMZ, and that stateful responses are the only return path for sessions started internally.

Internal address and routing disclosure

Requirement 1.4.5 covers internal IP addresses and routing information that could help an attacker map the network. Exposure often comes from public DNS records, banner text, verbose error pages, trace responses and route advertisements sent to external peers. Each disclosure channel must be reviewed, not only the firewall ruleset. Ask who is authorized to receive internal addressing, and confirm that partner and vendor documentation is shared only with those parties.

Third parties managing network controls

When a managed service provider, hosting company or cloud partner administers firewalls, security groups or cloud network policies, the responsibility for 1.4 is shared and must be documented. The entity remains accountable for evidence that the controls work, so contracts and responsibility matrices should state who sets rules, who reviews them and who produces the logs. Ask providers for their attestation, scope boundaries and the change records for controls they manage on your behalf.

How a QSA tests each 1.4 sub-requirement

This table compares, for each sub-requirement of Requirement 1.4, how a Qualified Security Assessor typically tests it, which evidence the assessor asks for, and the findings that most often come up. Use it to prepare the evidence set and to check boundary rules before the assessment starts, since the same few gaps recur across many environments.

Sub-requirement	Typical test approach and evidence requested	Common findings
1.4.1 NSCs between trusted and untrusted networks	Interview the network owner, review the network diagram and trace each path from the internet to the CDE. Ask for the list of NSCs placed at every trusted and untrusted boundary and confirm each one is in the diagram.	Internet connections that bypass the firewall, such as a forgotten VPN or cloud peering link, or a boundary device missing from the diagram.
1.4.2 Restricted inbound traffic from untrusted networks	Review the inbound rulebase and sample rules against the list of components that are authorized to provide public services. Confirm that return traffic is limited to sessions started inside the trusted network and that the final rule denies all else.	Broad allow-any inbound rules left from testing, source ranges wider than needed, or a missing default deny at the end of the ruleset.
1.4.3 Anti-spoofing measures	Inspect the boundary interface configuration and check that packets claiming internal source addresses are dropped when they arrive from the untrusted side. Ask for the anti-spoofing settings and a sample of rule logs showing those drops.	Missing anti-spoofing on a boundary interface, especially on a secondary link or cloud gateway, or spoofing protection that exists on paper but is not enabled on the device.
1.4.4 No direct access from untrusted networks to stored account data	Trace whether any system holding stored account data can be reached from an untrusted network, including through NAT, load balancers and management interfaces. Confirm the component inventory and check that storage on RAM disks or other persistent memory is treated as storage.	A database or file share with a public address, a NAT rule that forwards to a storage host, or a RAM disk treated as volatile memory without review.
1.4.5 Internal IP addresses and routing disclosure	Review what internal addresses and routing details appear in public DNS, certificates, error pages, email headers, API responses and outbound documents. Ask for the authorized-party list and confirm that disclosure is limited to those parties.	Internal host names or RFC 1918 addresses in public DNS or error messages, routing tables exposed through a public routing protocol, or traceroute output visible from outside.

Which evidence passes 1.4 at assessment

An assessor testing 1.4 wants proof that the boundary between trusted and untrusted networks is designed, configured, and monitored as described. The cards below cover the artifacts that show this, and each one needs a refresh routine so it still matches the live environment at the next assessment.

Current network and data-flow diagrams

These diagrams show where trusted networks meet untrusted ones and where cardholder data enters and leaves the environment. Assessors compare them against the live rulesets, so a diagram that omits a VPN, a third-party connection or a DMZ segment will fail the review. Keep them current by tying each change request to a diagram update and reviewing the set at least once a year, and after any significant boundary change. Confirm the review date and approver are recorded on each diagram.

Exported NSC rulesets with justifications

Export the rulesets from each network security control at the boundary, such as the OPNsense rules that pass, block or reject traffic by source, destination, port and protocol. Each inbound allow should carry a written business justification that names the public service it supports. Keep the exports in version control so the history is visible, and rerun the export after every change window. An allow rule without a justification is the most common gap assessors raise.

Anti-spoofing configuration on boundary interfaces

Evidence here shows that packets claiming internal source addresses cannot enter from the untrusted side, and that internal-range traffic cannot leave in a way that conceals its origin. Capture the interface configuration and the filter rules that drop spoofed sources, then test them with a crafted packet from outside the trusted range. Re-test after firewall upgrades or interface changes, because default settings can differ between versions. Record the test date and result alongside the configuration.

Route and address disclosure settings

Assessors check that internal IP addresses and routing details are not published to untrusted parties. Evidence includes DNS split-horizon settings, route advertisement filters on border routers, and the list of parties authorized to receive internal addressing, such as a managed service provider. Review the list whenever a partner or vendor is onboarded or offboarded. Retain the approval for each authorized recipient so the disclosure can be justified.

Tests showing direct access to card data is blocked

Penetration and boundary tests should attempt direct connections from untrusted networks to systems that store cardholder data and record the blocked results. Include both scanner-based checks and manual attempts through any published service. Schedule the tests on a recurring basis and after significant boundary changes, and keep the raw output so an assessor can trace each finding. A passing summary without the underlying traffic results is weak evidence.

Change records for boundary rule modifications

Each change to a boundary rule should have a ticket with the requester, the approver, the business reason, the rule diff, and the post-change verification. Assessors sample these records to confirm that unapproved rules do not appear in production. Use log evidence from tools such as Suricata or Zeek to compare observed traffic against approved rules, and investigate any traffic that matches no approved flow. Reconcile the change log against the ruleset export at each review.

How to implement 1.4 step by step

This sequence turns Requirement 1.4 into a working boundary: every trusted and untrusted connection is known, guarded by a network security control, limited to an approved list, and proven by testing and logs. Each step ends with a named artifact that an assessor can read.

Confirm the trusted and untrusted boundaries
Start from the current network and data-flow diagrams and list every point where a trusted network meets an untrusted one, including internet links, partner connections, VPN concentrators, wireless segments and cloud network edges. The security team and network owners review the list against live routing and firewall tables, not only against the diagrams. The output is a signed-off boundary inventory that names each connection, its owner and the network on each side. The step is complete when the inventory matches the diagrams and nobody can name an unlisted path.
Place network security controls at every boundary
Put a network security control (NSC) such as a stateful firewall or an equivalent filtering device at each boundary in the inventory, so that no traffic crosses between trusted and untrusted networks without passing through it. Where a boundary carries web traffic to public services, decide whether an application-layer filter such as a web application firewall sits in front of those services. The output is a placement table linking each boundary to its NSC and the management plane that controls it. The step is complete when a test packet path through each boundary crosses the NSC.
Define the public-services allow list and deny everything else
For each NSC, write the inbound rules so that only components authorized to provide public services accept traffic from untrusted networks, and add a final deny rule for all other inbound traffic. Record each permitted service with its destination system, port, protocol and business reason, and have the rule owner approve it. The output is an approved inbound rule list reviewed against the boundary inventory. The step is complete when every rule traces to a named service and the default action is deny.
Configure stateful return handling for sessions
Allow inbound traffic only as stateful responses to sessions that began inside the trusted network, so that return packets for internal outbound connections pass while unsolicited inbound packets are dropped. Test this on each NSC with a session started from inside and a matching packet arriving unsolicited from outside. The output is a test record showing both outcomes for each boundary. The step is complete when the unsolicited case is blocked on every device.
Enable anti-spoofing and restrict routing disclosure
Configure the NSCs to drop packets that arrive from an untrusted interface with a source address belonging to the trusted network, and confirm that internal IP addresses and routing details are not published to untrusted networks, such as in public DNS, banners, error pages or route advertisements. Limit disclosure to parties with a documented need. The output is an anti-spoofing configuration record and a disclosure review listing what is visible from outside. The step is complete when a spoofed test packet is dropped and the external review finds no internal addressing.
Verify with testing, logging and sign-off
Confirm the boundary works as documented by running rule-set tests, an external view of exposed services, and a review of the logs each NSC produces for denied and allowed traffic. Where you use intrusion detection or flow analysis tools, confirm they receive boundary traffic and write records an analyst can search. Retain the rule-set review, test results and log samples as evidence, then have the control owner sign the verification report and the final diagram. The output is a verification report and a signed-off diagram that match the boundary inventory. The step is complete when the report has no open exceptions or each exception has an approved owner and remediation record.

Which open-source tools support 1.4 evidence

Requirement 1.4 asks for evidence that the boundary between trusted and untrusted networks is enforced, watched and documented. The four tools below each produce a different kind of record: packet filter rules, web attack blocking, network alerts and flow metadata. Each one needs its own configuration, retention plan and confirmation with the assessor before it is cited as evidence.

OPNsense packet filter rules

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses so that boundary rules stay readable as the environment grows. Each rule can log its matches, and the live log view lets a reviewer confirm that inbound traffic from untrusted networks is limited to approved public services and that everything else is denied. Confirm that the rule set, its export and its logs meet your assessor's expectations for the NSC evidence the boundary requires. License: BSD-2-Clause.

Coraza web application firewall

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It is aimed at attacks such as SQL injection, cross-site scripting and code injection that a packet filter cannot see, because they travel inside allowed HTTP traffic. It integrates with Caddy, HAProxy, Traefik and Nginx. Check that the rule set is tuned to your applications, that blocked requests are logged, and that the placement of the WAF keeps public traffic from reaching system components directly. License: Apache-2.0.

Suricata EVE JSON alerts

Suricata inspects network traffic and writes its findings to EVE output as JSON records. These cover rule match alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, along with dropped packets and engine statistics. EVE records can be split into separate files for a log management tool, which helps when you need to show that unexpected inbound or outbound traffic across the boundary was detected. Confirm the rule sources, retention period and alert review process your assessor will expect. License: GPL-2.0-only.

Zeek connection and protocol logs

Zeek writes a set of logs by default, and they are linked by a unique connection identifier. The conn.log records who talked to whom, for how long, how much data moved and over which protocol for TCP and UDP traffic. Protocol logs such as dns.log and http.log add detail, and weird.log captures anomalous events. Together they can show which internal addresses were reached from outside and whether internal IP and routing details were exposed. Confirm where the logs are stored, how long they are kept and who reviews them. License: BSD-3-Clause.

What meeting 1.4 costs in money and effort

This table breaks down the cost components of meeting Requirement 1.4 for boundary controls, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build the questions for a fixed-scope written quote and the assessor's own fee schedule, since no supplied price exists for this work.

Cost component	One-time or recurring	What drives it up or down
NSC licenses or open-source alternative (for example OPNsense, Suricata, Coraza)	Licenses recur for commercial NSCs; open-source software has no license fee but still needs hosting and support time	Number of boundaries and the vendor's per-appliance or per-throughput licensing; self-hosted open source removes license spend but moves effort to build and patch
Engineering time to build and verify boundary rules	One-time for initial build, then recurring for changes	Count of trusted and untrusted interfaces, public services exposed, and whether rules are tested before deployment
Ruleset and network diagram upkeep	Recurring	Rule churn, frequency of third-party connection changes, and whether diagrams are generated from live configuration
Log storage and monitoring of boundary events	Recurring, scales with retention and traffic volume	Retention period, volume of Suricata EVE or Zeek logs, and whether alerts are reviewed by a person or a managed service
External penetration testing or review of boundary controls	Recurring, at least as often as the testing the organization already runs for its CDE	Number of internet-facing entry points, changes to public services, and whether the tester has access to configuration files
Assessor sampling time for Requirement 1.4 evidence	Recurring with each assessment	Quality of evidence on hand, such as exported rulesets, dated review records and change tickets, which shortens sampling
Third-party connection reviews for inbound and outbound paths	Recurring	Number of vendors connecting to the environment and whether each connection is documented with its allowed traffic

Who owns 1.4 and what is worth outsourcing

Your organization owns the controls under Requirement 1.4. The boundary between trusted and untrusted networks is a business and technical decision, and only your staff can decide which inbound services are public, which internal addresses may be disclosed and who approves each change. An assessor will ask your people to explain the reasoning behind every rule, so that knowledge cannot sit only with a vendor.

Rulesets and approvals: Maintain the network security control rules at the internet edge and at every boundary into the cardholder data environment, with a named approver for each allow rule.
Inbound justification: Be able to explain every inbound allow, why each public service is authorized and why all other inbound traffic is denied.
Diagrams and disclosure: Keep network and data-flow diagrams current and decide who is authorized to see internal IP addresses and routing information.
Change records: Retain tickets showing when boundary rules changed, who requested them and who approved them.
Monitoring ownership: Assign people to review alerts and logs from boundary controls.

Before assessment, confirm that a staff member who did not write the rules can walk an assessor through them.

Where 1.4 implementations usually fall short

Requirement 1.4 is tested at the boundary between trusted and untrusted networks, so the gaps that matter most sit where traffic crosses that line. The cards below cover the places assessors tend to find problems: diagrams, inbound rules, interface settings, DNS, management paths and change reviews.

Diagrams that omit cloud and partner links

Network diagrams often show the data center and the corporate firewall but leave out cloud VPCs, SaaS integrations, payment processor connections and partner VPNs. Each of those links is a path between a trusted and an untrusted network, and an assessor will ask where the NSC sits on it. Walk every connection that reaches the cardholder data environment from the cloud console, the firewall config and the vendor contracts, then compare the result to the diagram. Confirm that each boundary control is shown on the diagram.

Inbound rules with broad sources

Inbound rules that allow any source, or a wide CIDR range, to reach internal services are common after troubleshooting or migrations. Requirement 1.4.2 expects inbound traffic from untrusted networks to be limited to components that provide public services and to return traffic for sessions started internally, with everything else denied. Each remaining rule should name a business owner, a destination, a port and a reason. Remove rules that cannot be tied to one of those owners.

Anti-spoofing missing on some interfaces

Anti-spoofing checks are often configured on the main internet interface but not on secondary links, DMZ segments, VPN tunnels or management interfaces. Requirement 1.4.3 expects packets claiming an internal source address to be blocked when they arrive from the untrusted side. Review the ingress filtering settings on every interface that faces an untrusted network, and test with a spoofed internal address from outside to confirm the packet is dropped and logged.

Internal addresses leaking through public DNS

Internal host names, private address ranges and routing details sometimes appear in public DNS records, certificate transparency logs, error pages, email headers or public API responses. Requirement 1.4.5 limits disclosure of internal IP addresses and routing information to authorized parties. Query public DNS for internal naming patterns, review web server error output and response headers, and check that split-horizon DNS keeps internal zones off public resolvers.

Card data reachable through management paths

A jump host, backup server, monitoring agent or remote support tool can give an untrusted network a route to a system that stores cardholder data, even when the database itself is well protected. Requirement 1.4.4 covers direct access from untrusted networks to system components holding account data, and it applies where memory is used as persistent storage, such as a RAM disk. Map every route into storage systems, including administrative and backup paths, and confirm that none can be reached directly from an untrusted network.

No evidence of rule review after changes

Rulesets often change during incidents, vendor onboarding and application releases, but the change record and the review record rarely match. An assessor will expect evidence that rules affecting trusted and untrusted boundaries were reviewed after each change, not just at the periodic review. Keep rule change tickets linked to the firewall configuration history, and run a comparison of the current ruleset against the last approved version to find changes that were never reviewed.

What buyers ask about 1.4 cost, effort and outside help

How much effort does requirement 1.4 take for a small merchant compared with a service provider?

Effort scales with the number of boundary connections, the systems that face untrusted networks and how much of the payment environment you run yourself. A small merchant that outsources payment pages and has one or two internet-facing connections usually has a short list of boundary controls to document and confirm. A service provider hosting many customer environments has more boundaries, more shared infrastructure and more tenant separation to explain, so the same five sub-requirements (1.4.1 to 1.4.5) require substantially more work. Ask any provider to show how many untrusted-to-trusted paths exist in your own network diagram before you estimate the work.

Can our own team meet requirement 1.4 without outside help?

Yes, many organizations do, provided they have people who can read firewall rules, explain traffic flows and keep documentation current. The work is mostly verification: confirming that network security controls sit at every boundary, that inbound rules allow only public services and stateful responses, that spoofed traffic is blocked and that internal addressing is not disclosed to untrusted parties. Teams that lack this skill set, or that have never reviewed their boundary rules against a written standard, often bring in an implementation partner for the gap analysis and remediation. The organization owns the control either way, and an independent assessor still validates it.

What does requirement 1.4 need from our internal staff?

Internal staff remain responsible for the decisions and the evidence, even when an outside team does the technical work. Typically you need a network owner who can approve boundary rules, a system owner who knows which components store or process account data, and someone who can explain change history to an assessor. Security or operations staff must review logs and rule matches on a recurring basis, not only during the assessment. Plan for these people to spend time on walkthroughs, rule reviews and document approval, and ask your partner to list those internal touchpoints in the written scope.

How long does the work for requirement 1.4 usually take, and what drives it?

No duration is supplied for this requirement, so treat any figure you hear with caution and ask for the basis. The main drivers are the number of boundary paths, how current your network and data-flow diagrams are, whether rulesets are documented and how much remediation the review uncovers. Environments with legacy flat networks, undocumented exceptions or inbound rules that were never retired usually take longer, because cleanup must happen before evidence can be collected. Work on a fixed scope is easier to time than an open-ended review, so agree on the systems and boundaries in writing first.

What should a quote for requirement 1.4 work include?

A useful quote separates one-time work from recurring work and names who performs each task. Ask for the following items:

The boundaries, network segments and systems in scope, listed by name
Which sub-requirements (1.4.1 to 1.4.5) are covered, and what evidence each deliverable produces
Assumptions about internal staff time, access to rulesets and existing diagrams
Remediation work, if any, and whether it is included or priced separately
Recurring tasks after go-live, such as periodic rule reviews and log checks
Who owns the final documentation and what the assessor is expected to receive

A quote that omits the assessor's fees is incomplete, because those are paid to a separate party.

Can the consultant who helps us with 1.4 also perform the assessment?

Generally, no. A consultant that designs or implements your boundary controls cannot also act as the independent assessor for the same environment, because that would compromise the independence the assessment depends on. Implementation partners prepare systems, controls and evidence. Only a Qualified Security Assessor issues a Report on Compliance, and a Self-Assessment Questionnaire with its Attestation of Compliance is completed by the entity under the rules of the standard. Confirm with your acquirer or the relevant payment brand which validation route applies to you, and ask any firm to state its independence position in writing. Certificates from any party are not accepted as validation.

How DeployOpen prepares 1.4 evidence

DeployOpen plans and implements self-hosted open-source network security controls inside your own infrastructure, so the boundary between trusted and untrusted networks is documented, configured and testable for 1.4. We prepare the systems and evidence, while your organization owns the controls and an independent QSA issues the Report on Compliance or the Attestation of Compliance.

How we scope

Written scope names every boundary between trusted and untrusted networks that 1.4 covers in your environment
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
Scope lists which systems storing cardholder data must have no direct route from untrusted networks
Your QSA should confirm the scope and sampling approach before any build work begins

How we build

Network security controls at each trusted and untrusted boundary, configured with explicit deny-by-default inbound rules
Stateful inbound rules limited to public service components and responses to sessions started internally
Anti-spoofing filtering and monitoring tuned for the specific interfaces and address ranges in your network
Security testing of boundary rules, including attempts to reach cardholder data systems directly from untrusted networks

How we hand over

Documentation of each boundary control, its rule set, owner and the reason each allowed flow exists
Log outputs from boundary controls retained in a form your assessor can sample for 1.4 evidence
Configuration files and change records kept under version control, with a clear owner for each change
Handover walkthrough so your team can explain the boundary design and evidence to the assessor

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Periodic review of boundary rules as services, IP ranges and routing change in your environment
Retesting of boundary controls after significant changes, scoped in writing with your team
Your team keeps ownership of the control and of the assessment, with DeployOpen supplying the evidence it needs