Physical Network Jack Controls

PCI DSS requires you to restrict the use of any network jack that the public can access inside your facilities, using physical controls (blocking, locking, relocating) and/or logical controls (port security, NAC, disabled switchports). Your goal is simple: an unauthorized person must not be able to plug in and gain network access through an exposed Ethernet port. (PCI DSS v4.0.1 Requirement 9.2.2)

Key takeaways:

• Treat exposed network jacks as “walk-up access” into your environment; control them like an entry point. (PCI DSS v4.0.1 Requirement 9.2.2)
• Controls can be physical and/or logical, but you must be able to prove they work in practice. (PCI DSS v4.0.1 Requirement 9.2.2)
• The fastest audit wins come from an inventory of public jacks, standard port configurations, and inspection/testing evidence.

“Physical network jack controls” sounds narrow, but assessors tend to look at it as a direct-path risk: if someone can walk into a lobby, conference room, shared office floor, retail area, or other publicly accessible space and plug into an active wall port, they may bypass other perimeter defenses. PCI DSS 4.0.1 Requirement 9.2.2 focuses on that exposure and requires physical and/or logical controls that restrict use of publicly accessible network jacks within the facility. (PCI DSS v4.0.1 Requirement 9.2.2)

For a Compliance Officer, CCO, or GRC lead, the work is mostly operational coordination: Facilities owns wall plates and room access, Network owns switchport configs and NAC, Security owns monitoring and policy, and IT may own cabling closets and patch panels. The requirement is straightforward, but teams fail it because they can’t show (a) which jacks are publicly accessible, (b) what control is applied per jack, and (c) evidence the control is effective.

This page gives you requirement-level implementation guidance you can deploy quickly: scope rules, step-by-step actions, a control selection matrix, evidence to retain, and audit questions to prepare for.

Regulatory text

Requirement: “Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.” (PCI DSS v4.0.1 Requirement 9.2.2)

What the operator must do

You must ensure that Ethernet ports reachable by the public (or by people not authorized for the connected network) cannot be used to gain network access. “Restrict use” means the port is blocked, locked, disabled, segmented, authenticated, or otherwise controlled so an unauthorized device cannot connect successfully. You may satisfy this through physical controls (remove/cover/lock) and/or logical controls (switchport configuration, authentication, or access controls at the port). (PCI DSS v4.0.1 Requirement 9.2.2)

Plain-English interpretation

Treat every publicly accessible network jack as a potential unauthorized entry point. If someone can plug a device into that jack, your environment must prevent meaningful connectivity unless the person/device is authorized. The control must be durable (not “we usually keep the door closed”) and testable (you can demonstrate that plugging in does not grant access). (PCI DSS v4.0.1 Requirement 9.2.2)

Who it applies to

Entity types: merchants, service providers, and payment processors in scope for PCI DSS. (PCI DSS v4.0.1 Requirement 9.2.2)

Operational contexts where this commonly shows up:

• Retail floors, customer service areas, and kiosks
• Building lobbies, waiting rooms, and training rooms
• Conference rooms and hot-desking areas
• Shared office spaces with visitors, third parties, or building staff
• Warehouses and shipping/receiving areas with frequent non-employee presence
• Any site where jacks exist outside controlled telecom rooms or secured office areas

Scoping note (practical): Even if your cardholder data environment (CDE) is segmented, assessors often expect you to control public jacks broadly because unmanaged connectivity can undermine segmentation assumptions. Keep your stance simple: if it’s public, it’s controlled; if it must remain active, it’s authenticated/segmented. (PCI DSS v4.0.1 Requirement 9.2.2)

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

1) Define “publicly accessible” for your facilities

Write a short internal definition aligned to how your sites operate. Include:

• Spaces accessible to the general public (customers, visitors)
• Semi-public spaces (conference rooms used for visitors, shared tenant areas)
• Any space where you cannot reliably enforce “authorized personnel only” without an access control mechanism

This definition becomes your scoping rule for walkthroughs and audits.

2) Build and maintain an inventory of network jacks in public areas

You need a list that ties physical jacks to network ports. Minimum fields:

• Site/building, floor, room/area
• Wall plate ID or jack label
• Switch name, switchport identifier
• Current port status (enabled/disabled)
• Control type applied (physical, logical, both)
• Exception owner and business justification (if any)

Fast path: Start from switchport data (what ports exist and are active), then validate physically during a walkthrough with Facilities/IT. The mismatch between “documented” and “actually patched” is where findings happen.

3) Choose the control pattern per jack (decision matrix)

Use the simplest control that meets the business need and is easy to evidence.

Scenario	Recommended control	Why it passes an audit
Jack not needed	Disable switchport + document as unused	Clear “restricted use” with easy evidence (config + test). (PCI DSS v4.0.1 Requirement 9.2.2)
Jack needed occasionally (e.g., events)	Keep port disabled by default; change-control to enable temporarily	Demonstrates restriction and governance. (PCI DSS v4.0.1 Requirement 9.2.2)
Jack needed for managed devices only	802.1X / NAC or equivalent authentication; restrict by device identity	Shows that plugging in does not equal access. (PCI DSS v4.0.1 Requirement 9.2.2)
Jack in a truly public spot	Physically block/lock/cover + disable port (belt and suspenders)	Reduces reliance on config drift and deters opportunistic use. (PCI DSS v4.0.1 Requirement 9.2.2)
Jack must remain available for guests	Put on isolated guest network/VLAN with controlled routing	Restricts access to sensitive networks by design. (PCI DSS v4.0.1 Requirement 9.2.2)

Important: “We rely on signage” or “front desk staff watches the area” is rarely persuasive by itself. If you use compensating administrative practices, pair them with a physical or logical restriction that you can test.

4) Standardize switchport configurations for public-area ports

Work with Network Engineering to define “public jack port profiles,” such as:

• Disabled/unused profile: administratively down, documented description
• Guest/isolated profile: assigned to a guest VLAN with restricted routing
• Authenticated profile: requires authentication; unauthorized devices land in a restricted network (or have no access)

Keep these profiles in a controlled configuration standard so you can show consistency across sites.

5) Implement physical controls where they make operational sense

Physical controls vary by facility type:

• Lockable wall plates or port blockers in lobbies and waiting rooms
• Moving jacks inside secured areas where feasible
• Locking network cabinets/patch panels in semi-public areas

Coordinate with Facilities so controls remain in place through remodels and move/add/change work.

6) Test the control and document the result

A control that exists only on paper will fail quickly during an onsite review. Build a simple test procedure:

• Pick a sample of public jacks per site
• Attempt a connection with an unauthorized device
• Record the observed outcome (no link, no DHCP, captive guest network, authentication required, etc.)
• Keep evidence (screenshots, switch logs, NAC logs, test checklist sign-off)

7) Handle exceptions with discipline

Sometimes a public jack must be active for a business reason. Require:

• Written justification
• Control selection (guest isolation or authentication)
• Named owner
• Periodic revalidation that the exception still exists and controls still work

8) Operationalize change management (the hidden failure mode)

Most findings come from drift: a port gets enabled for a project and never re-secured, or a room gets repurposed and becomes “public.” Add two triggers:

• Facilities ticket for space changes routes to Network/Security for jack review
• Network changes on public-jack ports require peer review or automated policy checks

Where Daydream fits: If you manage many sites, evidence collection and exception tracking becomes the bottleneck. Daydream can centralize your jack inventory, map each jack to its control and owner, and keep assessor-ready evidence (configs, test results, approvals) tied to Requirement 9.2.2. (PCI DSS v4.0.1 Requirement 9.2.2)

Required evidence and artifacts to retain

Keep artifacts that prove three things: you know where public jacks are, you restricted them, and you validate the restriction.

Core artifacts

• Publicly accessible jack inventory with jack-to-switchport mapping
• Network configuration standards for public-area ports
• Switchport configuration extracts or screenshots showing port status/VLAN/auth requirements
• NAC/802.1X policy evidence (where used)
• Physical security evidence: photos of port blockers/locked plates (date-stamped if possible)
• Test records: sampling plan, checklist, results, and who performed the test
• Exception register with approvals and control details
• Change-management tickets for enabling/disabling ports in public areas

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me which jacks are publicly accessible at this site and how you determined that.”
• “Pick a conference room jack. What happens if I plug in my laptop?”
• “How do you prevent a technician from enabling a public port and forgetting it?”
• “If you use NAC, show the policy outcome for an unknown device.”
• “How do you keep your inventory current after office moves or renovations?”

Hangup: Teams present a policy statement but can’t produce a facility-level inventory or port-level configs. Make the evidence concrete and site-specific.

Frequent implementation mistakes (and how to avoid them)

1. Relying only on “port labels” or “employee awareness.”
   Fix: Pair awareness with a technical restriction (disabled port, authentication, or isolation). (PCI DSS v4.0.1 Requirement 9.2.2)

2. No mapping between wall jacks and switchports.
   Fix: Require labeling at both ends and keep it in a single inventory system.

3. Guest VLAN exists but routes too broadly.
   Fix: Treat “guest” as untrusted; restrict routing and access to internal systems.

4. Temporary enables become permanent.
   Fix: Time-box enables via tickets and add a decommission step to project closeout.

5. Ignoring semi-public areas (conference rooms, training spaces).
   Fix: Use your “publicly accessible” definition to classify spaces consistently.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is direct: exposed jacks can allow rogue devices, packet capture, lateral movement, or bypass of wireless controls. In PCI terms, it also weakens confidence in segmentation and physical security assumptions, which can expand audit scope and remediation work. (PCI DSS v4.0.1 Requirement 9.2.2)

Practical execution plan (30/60/90)

Time-bound plans require validated resourcing; treat this as a phased approach you can start immediately.

First 30 days (Immediate)

• Publish your definition of “publicly accessible network jacks.”
• Identify all facilities in scope and assign site owners.
• Pull switchport inventories and flag ports in known public rooms.
• Establish standard port profiles (disabled, guest-isolated, authenticated).

Next 60 days (Near-term)

• Complete walkthroughs for highest-traffic sites.
• Build jack-to-switchport mapping and label gaps list.
• Remediate obvious exposures: disable unused public ports, add blockers where needed.
• Stand up a repeatable test procedure and run initial testing.

Next 90 days (Operationalize)

• Expand inventory and testing across remaining sites.
• Implement exception workflow and integrate with change management.
• Add remodel/move triggers with Facilities and IT.
• Prepare your assessor packet: inventory, standards, samples of configs, photos, tests, and exceptions mapped to Requirement 9.2.2. (PCI DSS v4.0.1 Requirement 9.2.2)

Frequently Asked Questions

Do we have to physically block every publicly accessible network jack?

No. The requirement allows physical and/or logical controls, so you can meet it with switchport disablement, authentication, or isolation if it reliably restricts use. Your evidence must show the control is effective. (PCI DSS v4.0.1 Requirement 9.2.2)

If a jack is on a “guest VLAN,” does that automatically satisfy the requirement?

Only if the guest network meaningfully restricts access and an unauthorized device cannot reach sensitive internal networks. Be ready to show the port configuration and the routing/access restrictions. (PCI DSS v4.0.1 Requirement 9.2.2)

How do we prove compliance during an onsite assessment?

Bring an inventory of public jacks, port configurations (or NAC policy outputs), and test results showing what happens when an unauthorized device connects. Photos of physical controls help where used. (PCI DSS v4.0.1 Requirement 9.2.2)

What counts as “publicly accessible” in a corporate office?

Areas where visitors, third parties, or non-authorized staff can reasonably access jacks without passing an access control checkpoint (for example, conference rooms used for external meetings). Document your definition and apply it consistently. (PCI DSS v4.0.1 Requirement 9.2.2)

We don’t have NAC or 802.1X. Can we still pass?

Yes. Many environments meet the requirement by disabling unused public ports and adding physical port blockers for any exposed jacks that should never be used. Where business needs an active port, segment it to a restricted network. (PCI DSS v4.0.1 Requirement 9.2.2)

Who should own this control: Facilities, IT, Network, or Security?

Make Network accountable for logical restrictions (switch/NAC configs) and Facilities accountable for physical modifications, with Security/GRC owning the policy, inventory expectations, and evidence pack. The assessor will judge the outcome, not your org chart. (PCI DSS v4.0.1 Requirement 9.2.2)