No Direct Access to CHD from Untrusted Networks

“No direct access to CHD from untrusted networks” is a network architecture and access-path control requirement, not a generic “put a firewall in front of it” statement. For assessors, the question is simple: can an attacker on an untrusted network establish direct network connectivity to any system component that stores CHD? If the answer is “yes,” you have a high-risk finding because it increases the likelihood that a single perimeter weakness becomes a CHD compromise.

Operationalizing PCI DSS 4.0.1 Requirement 1.4.4 requires two things: (1) precision on scope (which systems actually store CHD) and (2) demonstrable network enforcement (firewalls, segmentation controls, routing, and access gateways) that prevents direct connectivity from untrusted networks. In practice, teams fail this requirement when they confuse “no direct access” with “requires authentication.” Authentication does not satisfy the requirement if the CHD storage system is still directly reachable from untrusted networks.

This page gives you requirement-level implementation guidance you can execute quickly: applicability, step-by-step control buildout, evidence to retain, typical audit hangups, and a practical phased execution plan.

Regulatory text

Requirement statement: “System components that store cardholder data are not directly accessible from untrusted networks.” (PCI DSS v4.0.1 Requirement 1.4.4)

Operator interpretation: You must design and run your network so that no inbound path exists from untrusted networks to any system that stores CHD. If access is needed (for example, customer-facing apps, admin workflows, third-party support), you place intermediary controls between the untrusted network and CHD storage systems, such as a DMZ tier, reverse proxy, application tier, VPN with a jump host, or other controlled gateway. (PCI DSS v4.0.1 Requirement 1.4.4)

What an assessor will try to confirm:

• You know which components store CHD.
• Untrusted networks cannot directly connect to those components at the network layer.
• Any allowed access path is indirect and controlled (segmented tiers, restricted ports, approved sources, strong administrative access patterns).

Plain-English requirement: what “no direct access” means

“Directly accessible” is about network reachability, not whether the system requires a login. If an IP on an untrusted network can route to your CHD database host (or storage node) on any port, that is direct accessibility.

A practical mental model:

Scenario	Direct access to CHD storage?	Why it passes/fails
Internet → database server that stores CHD (even if port is “nonstandard”)	Yes	Direct network path exists
Internet → app server → database that stores CHD	No (if DB is not reachable from untrusted)	DB is behind an internal segment; only app tier can reach it
Internet → VPN → RDP/SSH directly to CHD database host	Usually yes	VPN does not automatically make the network “trusted”; direct reachability still exists
Internet → VPN → jump host in management subnet → controlled admin to CHD DB	No (if DB not reachable from untrusted; only from mgmt subnet)	Access is brokered through an intermediary with tighter controls

The point: CHD storage should live in a protected network zone that is not exposed to untrusted networks, with only narrowly defined inbound paths from trusted internal tiers.

Who it applies to

This requirement applies to any organization in PCI scope that stores CHD, including:

• Merchants
• Service providers
• Payment processors
  (PCI DSS v4.0.1 Requirement 1.4.4)

Operational contexts where it shows up:

• On-prem data centers with internet-facing services
• Cloud networks (VPC/VNet) with public subnets and security groups
• Hybrid environments with site-to-site connectivity and third-party remote access
• Managed hosting where a third party administers infrastructure that includes CHD storage

If you do not store CHD anywhere (for example, you fully outsource and only handle tokens), this requirement may not apply in the same way. Your first task is to prove whether CHD storage exists.

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

1) Identify every system component that stores CHD

Make a storage map, not a guess. Include:

• Databases (relational, NoSQL)
• File/object storage buckets
• Backups, replicas, snapshots
• Log stores that may capture CHD accidentally
• Analytics exports and data lakes

Deliverable: CHD data store inventory with system owner, environment, network location, and purpose.

2) Define “untrusted networks” for your environment

Treat the internet as untrusted by default. Also consider:

• Partner networks
• Guest Wi‑Fi
• Third-party remote access networks
• User/home networks for remote staff

Deliverable: Network trust boundary definition approved by security/network leadership.

3) Create or validate a segmented architecture

The common compliant pattern is tiered:

• Public/edge zone (untrusted-facing)
• DMZ or application zone
• Data zone (CHD storage lives here)
• Management zone (admin access brokers/jump hosts live here)

The key control outcome: no route + no firewall allow rules from untrusted networks to the data zone CHD stores.

Deliverables:

• Current-state and target-state network diagrams
• Documented segmentation policy/standard for CHD storage components

4) Enforce “no direct access” with concrete network controls

Implement and validate controls at multiple layers:

Network routing and segmentation

• Remove public IPs from CHD storage hosts.
• Place CHD storage in private subnets/VLANs with controlled routing.

Firewalls / security groups / ACLs

• Default deny inbound to CHD storage segments.
• Allow inbound only from approved internal tiers (for example, app servers).
• Restrict source IPs, ports, and protocols to what is required.

Intermediary controls (DMZ/proxy/jump host)

• If any inbound exposure is needed for a business function, terminate connections in a controlled tier first (reverse proxy, WAF tier, app tier).
• For administrative access, require an approved remote access pattern (VPN into management zone, then jump host, then admin to CHD systems).

Deliverable: Ruleset baseline that explicitly shows “deny from untrusted → CHD storage.”

5) Validate with testing that an assessor will trust

You need proof, not intent:

• Attempt connectivity tests from an untrusted vantage point (external testing) to CHD storage IP ranges and ports.
• Validate that scanning and reachability checks show no exposure of CHD storage.

Deliverables:

• External reachability test results (method, date, tester, results)
• Network scan evidence showing no CHD storage services exposed to untrusted networks

6) Operationalize change control so it stays compliant

Most failures happen after a change:

• New public subnet, mis-scoped security group, temporary vendor access rule that never gets removed.

Operational controls to add:

• Pre-change review checklist for any change affecting: routing, firewall rules, security groups, remote access, new environments.
• Ownership for the CHD data zone ruleset.
• Periodic review of inbound rules to CHD storage segments.

Deliverables:

• Change management checklist for CHD network boundaries
• Firewall/security group review records tied to CHD scope

7) Address third-party access explicitly

If third parties support systems in scope:

• Require them to use your approved access path (VPN + jump host or similar).
• Prohibit direct inbound access to CHD storage, even “temporarily.”
• Document time-bound access approvals and logs.

Deliverables:

• Third-party access procedure for in-scope environments
• Access approval tickets and session logs for administrative pathways

Required evidence and artifacts to retain

Assessors typically ask for evidence they can reconcile across architecture, configuration, and tests.

Keep these artifacts ready:

• CHD storage inventory (systems that store CHD, owners, environments)
• Network/data flow diagrams showing trust boundaries and CHD storage zone placement
• Firewall/security group/ACL configurations and review records
• Routing documentation (showing no route from untrusted to CHD storage networks)
• Administrative access architecture (VPN/jump host design, where it terminates, what it can reach)
• Reachability test results demonstrating CHD storage is not reachable from untrusted networks
• Change tickets for any rules that affect CHD segmentation, including approvals and rollback plans

Common exam/audit questions and hangups

Expect these questions, and prepare “show-me” answers:

1. “Which systems store CHD?”
   Hangup: teams list the primary database but miss backups/snapshots or exports.

2. “Show that untrusted networks cannot reach CHD storage.”
   Hangup: policies and diagrams without config evidence.

3. “Does any CHD system have a public IP or public-facing DNS record?”
   Hangup: cloud resources accidentally assigned public IPs.

4. “How do admins and third parties access CHD systems?”
   Hangup: VPN configured to allow broad access, including direct access to CHD storage.

5. “What prevents a future change from opening access?”
   Hangup: no control owner or periodic review.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating authentication as a compensating control for direct reachability.
  Fix: Remove network path. Put CHD storage behind internal-only routing and default-deny rules.

• Mistake: “Temporary” firewall openings for troubleshooting.
  Fix: Enforce time-bound rules with automatic expiration, plus ticket-required approvals.

• Mistake: Overly broad VPN access.
  Fix: Terminate VPN into a management zone, require jump hosts, and restrict which subnets VPN clients can reach.

• Mistake: Mis-scoped cloud security groups (0.0.0.0/0 inbound) on data stores.
  Fix: Use least-privilege security group referencing (app tier SG → DB SG), and require change review.

• Mistake: Forgetting non-production.
  Fix: Apply the same pattern anywhere CHD is stored, including test environments, or eliminate CHD from non-prod.

Enforcement context and risk implications

PCI DSS 4.0.1 Requirement 1.4.4 is a “blast radius” reducer. If CHD storage is reachable from untrusted networks, a single perimeter mistake (misconfigured rule, exposed service, compromised edge host) can become a direct path to CHD. Keeping CHD storage off untrusted networks forces an attacker to break through additional controlled tiers and logs more detectable choke points. (PCI DSS v4.0.1 Requirement 1.4.4)

Practical execution plan (30/60/90-day)

Use phases so you can show progress quickly without inventing timelines or overpromising.

First 30 days (stabilize and prove scope)

• Build/confirm the CHD storage inventory, including backups and replicas.
• Produce a current-state network diagram with trust boundaries.
• Run external reachability checks against CHD storage IP ranges.
• Freeze changes to CHD network boundaries without security review.

Days 31–60 (remediate architecture and access paths)

• Remove public IPs and public exposure from CHD storage systems.
• Implement segmented zones (data zone for CHD storage) with default deny inbound from untrusted networks.
• Introduce or tighten intermediaries: DMZ/app tier for inbound services; management zone + jump host for admin access.
• Document the standard access pattern for employees and third parties.

Days 61–90 (make it durable)

• Add recurring reviews for firewall/security group rules affecting CHD storage.
• Bake checks into change management for network/security changes.
• Centralize and retain logs for admin sessions through jump hosts and access gateways.
• Prepare an “assessor packet” with diagrams, rulesets, and test evidence.

Where Daydream fits naturally: If you struggle to keep diagrams, inventories, third-party access procedures, and change evidence aligned, Daydream can act as the system of record for your PCI requirement artifacts. The goal is simple: one place to show scope, architecture intent, control evidence, and review history without rebuilding the story at audit time.

Frequently Asked Questions

Does a VPN make a network “trusted” for this requirement?

Not automatically. If VPN users can directly reach CHD storage systems, you still have direct accessibility from an untrusted network path; route VPN into a management zone and require a jump host. (PCI DSS v4.0.1 Requirement 1.4.4)

Can CHD storage ever be internet-facing if it’s behind a login or MFA?

A login does not change network reachability. The requirement is to prevent direct access from untrusted networks, so put an intermediary tier in front of any workflow that needs internet exposure. (PCI DSS v4.0.1 Requirement 1.4.4)

What counts as “system components that store cardholder data”?

Any component where CHD is stored, including primary databases, files/object stores, backups, replicas, and snapshots. Your inventory needs to reflect real storage, not just the main application database. (PCI DSS v4.0.1 Requirement 1.4.4)

Do I need a DMZ to satisfy this requirement?

PCI DSS 4.0.1 requires that CHD storage is not directly accessible from untrusted networks; a DMZ is a common pattern, but any architecture that removes direct reachability and uses controlled intermediaries can meet the outcome. (PCI DSS v4.0.1 Requirement 1.4.4)

How do I handle third-party support access to systems in scope?

Force third parties through your controlled access path (VPN to management zone, then jump host) and document approvals and logs. Do not allow direct inbound access to CHD storage “for convenience.” (PCI DSS v4.0.1 Requirement 1.4.4)

What evidence usually convinces an assessor fastest?

A clean network diagram tied to actual firewall/security group rules, plus reachability tests showing no inbound connectivity from untrusted networks to CHD storage. Pair that with documented admin access paths. (PCI DSS v4.0.1 Requirement 1.4.4)