NSCs Between Wireless and CDE

PCI DSS 4.0.1 Requirement 1.3.3 requires network security controls (NSCs) between every wireless network and the cardholder data environment (CDE) so wireless-to-CDE traffic is denied by default and only explicitly authorized, business-justified traffic is allowed. To operationalize it, inventory all wireless segments, enforce segmentation with firewalls/ACLs, document allowed flows, and retain configuration and testing evidence. (PCI DSS v4.0.1 Requirement 1.3.3)

Key takeaways:

• Put an enforceable choke point between any wireless network and the CDE, even if the wireless network is “trusted” or corporate. (PCI DSS v4.0.1 Requirement 1.3.3)
• Default-deny is the baseline; every exception needs a business purpose, documented scope, and rule-level approval. (PCI DSS v4.0.1 Requirement 1.3.3)
• Audit success depends on evidence: diagrams, rulebases, allowlist rationale, and validation that wireless cannot laterally reach the CDE. (PCI DSS v4.0.1 Requirement 1.3.3)

Wireless is a high-variability entry point: it changes with office moves, new SSIDs, guest access, remote sites, and third-party managed access points. PCI DSS treats that variability as a segmentation and access-control problem, not a “Wi‑Fi hardening” problem. Requirement 1.3.3 focuses on one outcome: wireless traffic must not reach the CDE unless you have deliberately allowed it for a documented business reason. (PCI DSS v4.0.1 Requirement 1.3.3)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this requirement as a repeatable pattern: (1) identify every wireless network that exists or could exist, (2) define where the CDE boundary is, (3) enforce a default-deny control between them, and (4) manage exceptions through a tight allowlist process. If you can show auditors a clean story with network diagrams, rule review evidence, and validation testing, 1.3.3 becomes predictable.

This page gives requirement-level implementation guidance you can hand to network and security teams, plus the evidence package you need to retain for assessment.

Regulatory text

Requirement (verbatim): “NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that all wireless traffic from wireless networks into the CDE is denied by default and only wireless traffic with an authorized business purpose is allowed into the CDE.” (PCI DSS v4.0.1 Requirement 1.3.3)

Operator interpretation (what you must do):

• Place a technical control (for example, firewall, segmentation gateway, or equivalent NSC) on the path between any wireless network and the CDE. “Any” includes corporate Wi‑Fi, guest Wi‑Fi, warehouse Wi‑Fi, site-to-site wireless bridges, and SSIDs run by third parties on your premises. (PCI DSS v4.0.1 Requirement 1.3.3)
• Set the NSC policy so wireless-to-CDE is denied by default. No “any/any” rules, no implied trust because it’s “internal.” (PCI DSS v4.0.1 Requirement 1.3.3)
• Allow wireless-to-CDE traffic only when you can state an authorized business purpose and implement that purpose as narrow, rule-level allowlisting (source, destination, protocol, port, and direction). (PCI DSS v4.0.1 Requirement 1.3.3)

Plain-English requirement meaning

You are proving a simple claim: “If a device connects over Wi‑Fi, it cannot talk to CDE systems unless we explicitly approved and configured that specific communication.” (PCI DSS v4.0.1 Requirement 1.3.3)

This is not satisfied by:

• A policy statement that Wi‑Fi is “separate.”
• An SSID name like “Guest.”
• WPA2/WPA3 encryption alone.
• VLANs with no enforced inter-VLAN controls.

Auditors look for enforcement points and rule evidence. If your diagrams show Wi‑Fi and CDE in different subnets but there is routing without a deny-by-default NSC, expect a finding.

Who it applies to

Entities: Merchants, service providers, and payment processors that have a CDE and any wireless networks in the environment. (PCI DSS v4.0.1 Requirement 1.3.3)

Operational contexts that commonly trigger 1.3.3 scope:

• Corporate Wi‑Fi used by employees who also access payment applications.
• Guest Wi‑Fi provided in stores, clinics, hotels, restaurants, or offices.
• Warehouse/retail RF scanners and tablets on Wi‑Fi.
• Third-party managed Wi‑Fi (MSP, landlord, co-lo) where your CDE is present.
• “Temporary” Wi‑Fi hotspots used during outages, events, or store openings.

If a wireless segment exists anywhere that could route to the CDE, this requirement is in play. “Regardless of whether the wireless network is a CDE” is the standard’s way of preventing a common loophole: treating Wi‑Fi as “out of scope” and forgetting it still has a path to CDE assets. (PCI DSS v4.0.1 Requirement 1.3.3)

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

Step 1: Inventory wireless networks and map paths to the CDE

Deliverables:

• List of SSIDs, wireless controllers, AP management networks, and any point-to-point wireless links.
• Layer-3 segmentation map showing whether any wireless segment has routing to any CDE segment.

Practical method:

• Ask network engineering for WLAN controller exports and SSID configs.
• Confirm with facilities/IT operations about “shadow IT” access points and temporary hotspots.
• Tie each wireless segment to IP ranges/VLAN IDs so you can express controls as deterministic rules.

Step 2: Define your CDE boundary clearly

You need a stable definition of:

• CDE subnets/VLANs
• Payment application tiers
• Any jump hosts or admin networks that reach the CDE

If your CDE boundary is fuzzy, rule design becomes chaotic and exception creep follows.

Step 3: Place NSCs between wireless and CDE (design the choke point)

You need an enforceable barrier where you can implement deny-by-default and allowlist exceptions. Common patterns:

• Firewall/NSC between wireless VLANs and CDE VLANs
• VRF/segmentation gateway with ACLs and logging
• Centralized segmentation firewall where all wireless-to-CDE routes traverse

Non-negotiable check: the routing path must be forced through the NSC. If there is an alternate route (for example, “temporary” static route, switch ACL bypass, or another core device that routes directly), you do not have control “between” wireless and the CDE in practice. (PCI DSS v4.0.1 Requirement 1.3.3)

Step 4: Implement a deny-by-default policy for wireless-to-CDE

Baseline configuration expectation:

• Explicit deny from wireless zones/VLANs to CDE zones/VLANs.
• Only add allow rules that are scoped to a known source, destination, and service.

Tips that reduce audit friction:

• Use network object groups like WIRELESS_ALL and CDE_ALL to make the rule intent obvious.
• Put the default-deny in a place where it cannot be shadowed by broad permits above it.
• Enable logging on denies (at least sampled) so you can detect accidental dependencies.

Step 5: Build an “authorized business purpose” allowlist workflow

Treat every allowed flow as a mini control record:

• Business purpose: “Warehouse handhelds must reach payment API proxy for tokenization.”
• Owner: app owner + network owner
• Scope: source IPs/VLANs, destination hosts, ports, direction
• Data classification: confirm no direct CHD exposure over that path unless required
• Approval: documented sign-off and change ticket reference
• Review trigger: network changes, new SSIDs, new CDE segment, controller replacement

If you run Daydream for GRC evidence management, set this up as a standard control record with attachments (diagram, rule screenshot/export, ticket, test result) so audits become retrieval work, not archaeology.

Step 6: Validate the control works (and keep the proof)

Validation needs to show two things:

1. Wireless-to-CDE is blocked by default.
2. Authorized exceptions work and are as narrow as documented.

Practical test options:

• From a test device on each SSID/VLAN, attempt to reach representative CDE IPs/ports and show blocked results.
• For each approved rule, test only the documented port/protocol to the documented destination and confirm other ports fail.

Avoid relying on “we believe segmentation exists.” Auditors expect demonstrable behavior aligned to the rule. (PCI DSS v4.0.1 Requirement 1.3.3)

Required evidence and artifacts to retain

Keep an evidence packet that stands on its own:

Network and scope artifacts

• Current network diagram showing wireless segments, the NSC choke point, and CDE boundary
• Data flow diagram or narrative that explains any approved wireless-to-CDE traffic

NSC configuration artifacts

• Firewall/NSC rule export or screenshots showing:
  • Default-deny posture from wireless to CDE
  • Specific allowlist rules tied to business purposes
• Network object/group definitions (to prove what “WIRELESS” and “CDE” include)

Governance artifacts

• Change tickets for rule creation/modification (including approvals)
• Rule review records (periodic review and after material changes)
• Exception register entries for any temporary allowances with expiry

Testing artifacts

• Test plan + results (who tested, from where, when, outcome)
• Evidence that alternate routing paths do not bypass the NSC (for example, route tables, device configs, or traceroutes)

Common exam/audit questions and hangups

Auditors and QSAs tend to drill into these areas:

1. “Show me all wireless networks.” If your SSID inventory misses a site or a “temporary” SSID, the rest of your story weakens.
2. “Prove traffic is denied by default.” They will look at rule ordering and implicit allows. Expect them to challenge broad permits like “wireless to internal any.”
3. “Explain each allowed flow’s business purpose.” “Operations needs it” is rarely enough. Tie it to a system, function, and owner. (PCI DSS v4.0.1 Requirement 1.3.3)
4. “Is the wireless network part of the CDE?” Even if you argue it is, the requirement still expects NSCs “between all wireless networks and the CDE.” Plan for segmentation controls regardless. (PCI DSS v4.0.1 Requirement 1.3.3)
5. “What changed since last assessment?” Wireless changes fast; show controlled change management and updated diagrams.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Treating “guest Wi‑Fi” as automatically isolated	SSID naming is not a control	Show enforced segmentation via NSC rules and routing path evidence
VLAN separation without an enforced choke point	Routing can still exist	Force inter-VLAN traffic through a firewall/NSC with deny-by-default
Broad allow rules (“any” destinations or ports)	Not aligned to “authorized business purpose”	Require per-application allowlist entries with narrow scope and owners (PCI DSS v4.0.1 Requirement 1.3.3)
No evidence package	Control may exist but is unprovable	Standardize evidence capture: rule export, diagram, tickets, tests
Forgetting third-party wireless	It still connects to your environment	Contractually require disclosure, segment it, and include it in inventory

Risk implications (why assessors care)

Wireless expands the set of devices that can get “on network” quickly: personal devices, contractor laptops, IoT, and misconfigured access points. If wireless can reach the CDE, compromise paths multiply and segmentation arguments collapse. Requirement 1.3.3 is a segmentation backstop: it forces you to demonstrate that wireless does not become an unmonitored bridge into payment systems. (PCI DSS v4.0.1 Requirement 1.3.3)

Practical 30/60/90-day execution plan

First 30 days: Stabilize scope and visibility

• Produce a wireless inventory (SSIDs, controllers, VLANs, IP ranges, site coverage).
• Update the CDE boundary definition and confirm CDE subnets.
• Identify every route path between wireless and CDE, including unintended routing.

Days 31–60: Implement or harden NSCs and default-deny

• Confirm an NSC choke point exists on every wireless-to-CDE path.
• Implement explicit denies wireless→CDE.
• Stand up an allowlist intake form that captures business purpose, owner, and rule parameters.

Days 61–90: Prove it works and make it repeatable

• Execute validation tests from each wireless network type and retain evidence.
• Run a rule review meeting with network + app owners; prune overly broad rules.
• Operationalize ongoing change control: diagram updates, controller changes, new SSIDs, new sites.
• Centralize artifacts in a system of record (Daydream works well if you want assessment-ready evidence sets by requirement).

Frequently Asked Questions

Does this apply if our wireless network is “corporate” and uses strong authentication?

Yes. The requirement is about placing NSCs between all wireless networks and the CDE and denying by default, not about how strong the Wi‑Fi authentication is. (PCI DSS v4.0.1 Requirement 1.3.3)

If the wireless network is considered part of the CDE, do we still need NSCs “between” wireless and the CDE?

The text says “regardless of whether the wireless network is a CDE,” so you should plan to enforce wireless-to-CDE controls as if the wireless segment needs explicit restriction. Build the choke point and document allowed flows. (PCI DSS v4.0.1 Requirement 1.3.3)

What counts as an NSC for this requirement?

PCI DSS uses NSC as a functional term; in practice, you need a control that enforces deny-by-default and supports precise allowlisting between wireless and CDE networks. The key is enforceability and evidence. (PCI DSS v4.0.1 Requirement 1.3.3)

Can we satisfy this with VLANs and switch ACLs instead of a firewall?

Possibly, if the ACLs are the enforced control point on all paths and implement deny-by-default with only business-justified allows. Be ready to show configs, rule intent, and test results that prove there is no bypass route. (PCI DSS v4.0.1 Requirement 1.3.3)

How detailed does “authorized business purpose” documentation need to be?

It should identify the application/system need, the owner, and the exact traffic required (source, destination, protocol/port). If you cannot explain why a specific port to a specific destination is required, the rule usually needs tightening. (PCI DSS v4.0.1 Requirement 1.3.3)

What evidence is fastest to produce for an auditor?

A current diagram showing wireless segments, the NSC choke point, and the CDE boundary, plus a rule export that clearly shows wireless→CDE default-deny and a small set of allowlisted exceptions with change tickets and test results. (PCI DSS v4.0.1 Requirement 1.3.3)