Restrict Inbound Traffic from Untrusted Networks

Restrict inbound traffic from untrusted networks by configuring firewalls (and equivalent controls) to allow only explicitly authorized, publicly accessible services (specific systems, protocols, and ports) plus stateful return traffic for sessions initiated from trusted networks; deny everything else by default. This is a “default deny + explicit allowlist” requirement with evidence expectations. (PCI DSS v4.0.1 Requirement 1.4.2)

Key takeaways:

• Start with a written allowlist of internet-facing services (system, protocol, port, purpose, owner) and block the rest. (PCI DSS v4.0.1 Requirement 1.4.2)
• Enforce stateful inspection so only established/related return traffic is permitted back into the trusted network. (PCI DSS v4.0.1 Requirement 1.4.2)
• Keep audit-ready artifacts: rule exports, object groups, network diagrams, and change approvals that map each allowed rule to a business justification. (PCI DSS v4.0.1)

This requirement is about controlling the “internet-to-trusted” boundary with precision. If you allow inbound connections from untrusted networks (typically the public Internet) into trusted networks (where sensitive systems live, including environments that store, process, or transmit payment card data), you must constrain that inbound traffic to only what you have intentionally approved: the specific publicly accessible services you operate, on the specific protocols and ports they require, on the specific systems that should receive that traffic. Everything else must be denied. (PCI DSS v4.0.1 Requirement 1.4.2)

For a CCO or GRC lead, operationalizing this quickly means driving three outcomes across Security/Network teams: (1) an authoritative inventory of internet-exposed services and why they exist, (2) firewall and cloud security group rules that implement a true allowlist with stateful behavior, and (3) durable evidence that an assessor can trace from requirement → architecture → configuration → change records. If you cannot show that trace, teams often “feel” secure but fail the audit because the control is not provable.

The guidance below is written so you can assign work, validate it, and retain the right artifacts without becoming a firewall engineer yourself.

Regulatory text

PCI DSS 4.0.1 Requirement 1.4.2 states: “Inbound traffic from untrusted networks to trusted networks is restricted to communications with system components that are authorized to provide publicly accessible services, protocols, and ports, and stateful responses to communications initiated by system components in a trusted network. All other traffic is denied.” (PCI DSS v4.0.1 Requirement 1.4.2)

Operator interpretation (what you must do)

• Define “untrusted” and “trusted” for your environment (for most orgs: Internet/uncontrolled networks are untrusted; internal segments and controlled environments are trusted). Your scoping and diagrams must make those boundaries clear. (PCI DSS v4.0.1)
• Allow inbound only to authorized public services: inbound rules must be an allowlist tied to a specific service, system component, protocol, and port. (PCI DSS v4.0.1 Requirement 1.4.2)
• Allow stateful return traffic for connections initiated from the trusted side (established/related sessions), rather than broad inbound openings. (PCI DSS v4.0.1 Requirement 1.4.2)
• Deny everything else by default at the boundary. “Implicit allow” is not consistent with the text. (PCI DSS v4.0.1 Requirement 1.4.2)

Plain-English requirement (what “good” looks like)

If a system is not intentionally public, the Internet cannot talk to it. If a system is intentionally public (for example, a web endpoint), the Internet can reach only the specific ports/protocols needed for that service, and only on that system. Return traffic is permitted only when it is part of an established session started from inside the trusted network. All other inbound attempts are blocked and logged according to your operational practice. (PCI DSS v4.0.1 Requirement 1.4.2)

Who it applies to

Entity scope

Applies to merchants, service providers, and payment processors within the scope of PCI DSS. (PCI DSS v4.0.1 Requirement 1.4.2)

Operational scope (where you enforce it)

Applies anywhere you have a boundary where untrusted networks could reach trusted networks, including:

• On-prem perimeter firewalls and internal segmentation firewalls between Internet/DMZ and internal networks.
• Cloud controls such as security groups, network ACLs, cloud firewalls, and managed perimeter services.
• Kubernetes ingress/edge gateways when they expose services to the Internet (coordinate with network-layer controls so you still meet the “deny all other traffic” intent). (PCI DSS v4.0.1)

If your third party hosts or operates internet-facing components in your PCI scope, you still need evidence that the boundary controls meet the requirement, even if the third party implements them. Treat this as shared-responsibility control validation. (PCI DSS v4.0.1)

What you actually need to do (step-by-step)

Step 1: Define trusted/untrusted boundaries and list entry points

1. Update a network diagram that shows: Internet/untrusted networks, perimeter/edge controls, DMZ (if used), trusted segments, and which segments contain PCI in-scope components. (PCI DSS v4.0.1)
2. Enumerate all inbound paths from untrusted to trusted, including:
   • Direct internet-to-internal (should be none).
   • Internet-to-DMZ-to-internal (common).
   • Internet-to-cloud VPC/VNet subnets.
   • Site-to-site connections from networks you do not control (treat as untrusted until governed). (PCI DSS v4.0.1)

Deliverable: “Inbound Exposure Register” (service name, system, owner, environment, data sensitivity, justification).

Step 2: Create an allowlist of authorized public services

Build a table you can hand to engineers and assessors:

Field	What “audit-ready” means
System component	Hostname/IP, load balancer, or service endpoint that receives traffic
Service	What the public can do (e.g., HTTPS to a customer portal)
Protocol/port	Exact protocol and port(s)
Source	“Any” only if justified; otherwise restricted ranges
Business justification	Ticket or approval reference
Owner	Named service owner accountable for the exposure
Expiration/review trigger	Conditions to revisit exposure (e.g., decommission date)

This table is your policy-to-config bridge. Each inbound rule should map to one row. (PCI DSS v4.0.1 Requirement 1.4.2)

Step 3: Implement “default deny” inbound at the boundary

1. Set firewall policy to deny inbound by default from untrusted to trusted.
2. Add explicit allow rules only for the authorized services from Step 2.
3. Avoid broad “ANY-ANY” objects and “temporary” rules that never expire. Where an emergency change is required, enforce an expiration and post-implementation review in your change process. (PCI DSS v4.0.1 Requirement 1.4.2)

Practical configuration intent:

• Internet → DMZ web tier: allow TCP 443 to the specific web VIPs.
• Internet → internal trusted subnet: deny.
• Internet → admin interfaces (SSH/RDP): deny; if remote admin is required, route through a controlled access path and restrict sources tightly.

Step 4: Enforce stateful responses (established/related)

Stateful behavior means the firewall tracks connections and only permits inbound packets that are part of a session initiated from the trusted network (or that are explicitly allowed as a public service). (PCI DSS v4.0.1 Requirement 1.4.2)

Operator checks you can request from engineers:

• Confirm stateful inspection is enabled on the relevant boundary devices/policies.
• Confirm rules are written using “established/related” (or equivalent) for return traffic rather than opening ephemeral ports inbound broadly.
• Confirm asymmetric routing exceptions are understood; if the return path bypasses the stateful device, you can accidentally break the control or create holes.

Step 5: Validate with testing, not only configuration review

You need evidence that the boundary behaves as intended. Options:

• External and internal scanning (from untrusted vantage points where feasible) to confirm only intended ports are reachable.
• Rule recertification checks: sample inbound rules and confirm each maps to an approved entry in your allowlist register, with a current owner and justification.
• Packet-flow validation for stateful return traffic: confirm internal-initiated sessions work without adding permissive inbound rules. (PCI DSS v4.0.1)

Step 6: Operationalize with change control and periodic review

To keep compliance after the initial cleanup:

• Require an approval workflow for any inbound rule creation/modification, with documented justification and owner.
• Maintain a recurring recertification process for the public-service allowlist and matching rules, aligned to your broader PCI governance cadence. (PCI DSS v4.0.1)

Where Daydream fits: Daydream can serve as the control “system of record” for the requirement by storing the inbound exposure register, mapping each rule to an approval artifact, and producing assessor-ready evidence packets tied back to PCI DSS 4.0.1 Requirement 1.4.2. (PCI DSS v4.0.1 Requirement 1.4.2)

Required evidence and artifacts to retain

Aim for “traceability” across design, implementation, and operation:

Design evidence

• Current network diagrams showing untrusted/trusted boundaries and in-scope segments. (PCI DSS v4.0.1)
• Inbound Exposure Register / public services allowlist with owners, ports, protocols, and justifications. (PCI DSS v4.0.1 Requirement 1.4.2)

Configuration evidence

• Firewall rulebase exports (or screenshots where exports are not feasible) for perimeter and segmentation points that enforce untrusted → trusted restrictions. (PCI DSS v4.0.1 Requirement 1.4.2)
• Cloud security group / firewall policy exports showing inbound allowlist and default-deny behavior. (PCI DSS v4.0.1 Requirement 1.4.2)
• Evidence of stateful inspection configuration or rule constructs (“established/related” or platform equivalent). (PCI DSS v4.0.1 Requirement 1.4.2)

Operational evidence

• Change tickets/approvals for inbound rule changes, including business justification and owner. (PCI DSS v4.0.1)
• Testing results showing only authorized ports are exposed from untrusted networks. (PCI DSS v4.0.1)
• Exception register for any temporary inbound allowances, with expiration and compensating controls. (PCI DSS v4.0.1)

Common exam/audit questions and hangups

Assessors and internal audit usually press on these points:

1. “Show me the list of authorized publicly accessible services.” If you only show firewall rules without a service inventory, you will struggle to prove “authorized.” (PCI DSS v4.0.1 Requirement 1.4.2)
2. “How do you know all other inbound traffic is denied?” They want proof of default-deny posture, not just a statement. Provide policy evidence and test evidence. (PCI DSS v4.0.1 Requirement 1.4.2)
3. “Where is the trust boundary?” If diagrams are stale, scoping becomes ambiguous and can expand the audit. (PCI DSS v4.0.1)
4. “Explain stateful responses in your environment.” Teams often claim “stateful” but cannot show the configuration or they have routing patterns that bypass the stateful device. (PCI DSS v4.0.1 Requirement 1.4.2)
5. “Are any administrative ports open from the Internet?” If yes, expect deep scrutiny of compensating controls and justification. (PCI DSS v4.0.1 Requirement 1.4.2)

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating the firewall rulebase as the inventory

Fix: maintain a separate “authorized public services” register and map each inbound rule to it. That register becomes the approval boundary for new exposures. (PCI DSS v4.0.1 Requirement 1.4.2)

Mistake 2: Overly broad source ranges

Fix: restrict sources where you can (partner IP ranges, trusted reverse proxies, DDoS/WAF egress IPs). Where “any” is truly required (public websites), compensate by narrowing destination scope and ports to the minimum. (PCI DSS v4.0.1 Requirement 1.4.2)

Mistake 3: Allowing inbound for “return traffic” instead of using stateful inspection

Fix: validate stateful settings and remove inbound rules that exist only to “make things work” for internally initiated connections. If a flow breaks without permissive inbound rules, diagnose routing/NAT design rather than weakening the boundary. (PCI DSS v4.0.1 Requirement 1.4.2)

Mistake 4: Cloud/network gaps between teams

Fix: treat security groups, cloud firewalls, and perimeter appliances as one control set. One permissive security group can negate a strong perimeter. Centralize evidence collection and rule recertification. (PCI DSS v4.0.1)

Mistake 5: “Temporary” inbound rules that become permanent

Fix: enforce expirations and post-change review. Track exceptions in a register that audit can sample quickly. (PCI DSS v4.0.1)

Risk implications (why this requirement is tested hard)

Inbound access from untrusted networks is a primary path for exploitation. The control reduces exposure by shrinking the reachable attack surface to a small set of well-defined services and preventing inbound reachability to internal systems by default. Failing this requirement typically implies both security risk (unnecessary exposure) and compliance risk (inability to demonstrate controlled network access). (PCI DSS v4.0.1 Requirement 1.4.2)

Practical execution plan (30/60/90)

You asked for fast operationalization. Use phases while keeping the labels your stakeholders expect.

First 30 days: establish the allowlist and stop obvious exposure

• Confirm trust boundaries and update diagrams for all in-scope environments. (PCI DSS v4.0.1)
• Produce the Inbound Exposure Register and get service owner sign-off for each internet-facing service. (PCI DSS v4.0.1 Requirement 1.4.2)
• Implement or verify default deny for inbound untrusted → trusted at primary boundary points; remove clearly unauthorized inbound rules. (PCI DSS v4.0.1 Requirement 1.4.2)
• Capture baseline evidence: rule exports, configs, and a snapshot of exposed ports from an external perspective. (PCI DSS v4.0.1)

Days 31–60: tighten and prove stateful behavior

• Refactor rules to remove “return-traffic” inbound openings and rely on stateful responses where appropriate. (PCI DSS v4.0.1 Requirement 1.4.2)
• Normalize rule naming, ownership, and justification so an assessor can trace quickly.
• Build a repeatable evidence packet in Daydream (or your GRC system): diagram + register + change tickets + exports + test results. (PCI DSS v4.0.1 Requirement 1.4.2)

Days 61–90: operationalize and make it durable

• Implement a formal inbound rule request workflow with required fields (service, port/protocol, system, owner, justification, expiration).
• Establish periodic recertification of the allowlist and matching rules as part of PCI governance. (PCI DSS v4.0.1)
• Run a tabletop with Network + App owners: “If we had to prove 1.4.2 tomorrow, what evidence do we hand over?” Close any gaps in evidence quality. (PCI DSS v4.0.1 Requirement 1.4.2)

Frequently Asked Questions

Does “untrusted networks” only mean the public Internet?

Usually it includes the Internet and any network you do not control or cannot govern to your security standard. Document your boundary definitions so “untrusted” and “trusted” are consistent across diagrams and rules. (PCI DSS v4.0.1 Requirement 1.4.2)

Are inbound rules to a DMZ allowed under this requirement?

Yes, if the DMZ systems are the authorized components providing publicly accessible services, and the allowed protocols/ports are explicitly listed and justified. The key is that only authorized services are reachable and all other inbound traffic is denied. (PCI DSS v4.0.1 Requirement 1.4.2)

What counts as a “stateful response” in practice?

It means the control tracks sessions and permits inbound packets only when they belong to an established connection initiated from the trusted network (or when the inbound service is explicitly allowlisted). You should be able to show configuration evidence that stateful inspection is in effect. (PCI DSS v4.0.1 Requirement 1.4.2)

We use cloud security groups instead of traditional firewalls. Can that satisfy the requirement?

Yes, if the effective inbound policy from untrusted to trusted is an allowlist for authorized public services plus stateful return traffic, and everything else is denied. Retain exports/screenshots and change records that prove the effective policy. (PCI DSS v4.0.1 Requirement 1.4.2)

What evidence should a CCO ask for to validate this control without reading every firewall rule?

Ask for the authorized public services register, a mapping of each inbound rule to an approved register entry, and a proof-of-exposure test that shows only those services are reachable from untrusted networks. Also request change approvals for a sample of rules. (PCI DSS v4.0.1)

How do we handle third parties that host our internet-facing payment pages or components?

Treat it as shared responsibility: you still need evidence that inbound access is restricted appropriately for the in-scope environment. Contract terms and third-party attestations can support this, but you should also retain architectural diagrams and configuration evidence where available. (PCI DSS v4.0.1)