SC-7(14): Protect Against Unauthorized Physical Connections

SC-7(14): Protect Against Unauthorized Physical Connections requires you to prevent people from physically attaching unauthorized devices or cabling to the network boundary and related connection points you define in your system. Operationally, this means you must identify where physical connectivity could bypass logical controls, implement physical and technical blocking/detection, and keep audit-ready evidence that the protections work. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define the specific locations the control covers (your “where”) and treat them as high-risk ingress points.
• Combine physical controls (locked closets/patch panels) with technical controls (port security, NAC, 802.1X, rogue device detection).
• Keep evidence that protections are configured, monitored, and tested on a recurring basis. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Compliance teams often treat “physical connections” as a facilities problem and “boundary protection” as a network team problem. SC-7(14) forces you to connect those dots. The risk is straightforward: if someone can plug into an exposed switch port, patch panel, carrier handoff, or other boundary-adjacent connection, they can bypass identity controls, segmentation, and monitoring you depend on.

This page translates the sc-7(14): protect against unauthorized physical connections requirement into an execution checklist you can assign to a control owner and validate quickly. The key is scope discipline: you must clearly name the connection points covered (the control’s organization-defined parameter), then implement protections appropriate to each location’s exposure and criticality. (NIST SP 800-53 Rev. 5 OSCAL JSON)

You will see auditors focus on two themes: (1) whether you identified all realistic physical ingress points, including remote sites and third-party-managed spaces, and (2) whether you can prove your protections operate continuously, not just on paper. If you use Daydream to map control ownership and evidence schedules, you can shorten the path from requirement text to assessor-ready artifacts without overbuilding. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (verbatim): “Protect against unauthorized physical connections at {{ insert: param, sc-07.14_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do with this text

• Fill in the parameter (“where”): Decide and document what locations are in scope for protection (examples: network boundary demarcation points, data center meet-me rooms, MDF/IDF closets, exposed wall jacks in public areas, branch office wiring cabinets, OT/ICS boundary cabinets, carrier handoffs, and any third-party colocation cages that host your equipment). The control is untestable until you define this scope. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Implement protections (“how”): Put physical and technical measures in place so an unauthorized person cannot attach a device, cable, or tap and gain network access or intercept traffic at those defined points. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Prove it works (“show me”): Maintain evidence that protections exist, are configured correctly, and are monitored or tested often enough to detect drift and exceptions. (NIST SP 800-53 Rev. 5)

Plain-English interpretation

SC-7(14) is about stopping “plug-in” attacks and covert taps at places where physical access can defeat your logical boundary controls. If an attacker, disgruntled insider, or unauthorized third party can connect a laptop, rogue access point, network tap, or small unmanaged switch to a live port at or near your boundary, they can create an unapproved path into the system.

This control does not require a single specific technology. It requires an outcome: unauthorized physical connections are blocked, prevented, or rapidly detected and handled at the connection points you defined. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entity types

• Federal information systems and contractors handling federal data where NIST SP 800-53 is the governing control set (for example, systems supporting federal missions or contractual requirements that flow down NIST controls). (NIST SP 800-53 Rev. 5)

Operational contexts where auditors expect coverage

• Data centers and server rooms: Meet-me rooms, cross-connects, top-of-rack switching, and any shared spaces where non-admin staff can enter.
• Corporate offices and branch sites: Network closets, wall jacks in reception or conference rooms, and “temporary” build-out spaces.
• Remote/edge environments: Warehouses, retail locations, clinics, field offices, and pop-up sites where closets are shared with facilities or frequently left unlocked.
• Third-party-managed spaces: Colocation, managed network services, and any building where a third party can physically touch your patching or carrier handoffs.

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

1) Name your in-scope connection points (the sc-07.14_odp parameter)

Create a short, assessable list. Avoid “all network ports everywhere” unless you can prove it.

• Boundary demarcation points (carrier handoff, WAN edge rack, SD-WAN appliance location)
• MDF/IDF closets and patch panels
• Publicly accessible Ethernet ports (lobbies, training rooms, hot desks)
• Lab spaces and staging benches
• OT/IoT aggregation points where enterprise and device networks meet (if applicable)

Output artifact: “SC-7(14) In-Scope Physical Connection Points Register” with owner, location, and risk rating. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2) Classify each location by exposure and control strength

Use a simple decision matrix so you apply the right controls where they matter.

Location type	Exposure indicators	Minimum expected protections (examples)
Public/low-trust areas	Visitors present; ports reachable without escort	Disable unused ports; 802.1X/NAC; alert on link-up events; port security/MAC limits
Controlled office areas	Badge access but shared	Locked closets; patch panel labeling; periodic port audits; NAC with exception handling
Data center/meet-me	Multiple teams/third parties enter	Locked cabinets; escorted access; tamper-evident seals where practical; continuous monitoring and documented cross-connect approvals

Note: The table is implementation guidance; you still must map it back to your defined scope for SC-7(14). (NIST SP 800-53 Rev. 5)

3) Implement physical protections

Physical protections reduce opportunities for “hands on the wire.”

Checklist (apply per site classification):

• Lock network closets, racks, and cabinets; control and log key/card access.
• Control patching: only authorized staff can change patch-panel connections; require a ticket or change record for cross-connect changes.
• Secure exposed jacks in public areas: remove, block, or place behind locked covers where feasible.
• For high-risk locations, consider tamper-evident seals on cabinets or critical cross-connects, paired with inspection routines.

Evidence you need: photos of locked cabinets, facilities access control logs, and written procedures for patching approvals. (NIST SP 800-53 Rev. 5)

4) Implement technical protections at the switch/port level

This is where most programs pass or fail, because it is measurable.

Common technical measures:

• Disable unused ports by default (and document the enablement process).
• 802.1X with NAC for user/device authentication on wired ports; maintain an exception process for printers, building systems, and legacy devices.
• Port security (MAC limiting, sticky MAC where appropriate, violation actions).
• Rogue device detection through NAC, switch monitoring, or network monitoring tools; alert on new MACs or unexpected device types at sensitive ports.
• Segmentation controls so even an authorized physical connection lands in a constrained VLAN or quarantine network until authenticated.

Evidence you need: switch configuration baselines, NAC policies, screenshots/exports showing enforcement mode, and sample alerts/tickets for violations. (NIST SP 800-53 Rev. 5 OSCAL JSON)

5) Build an exception process that doesn’t hollow out the control

Auditors will ask for your “temporary port enablement” and “non-802.1X device” handling.

Minimum expectations:

• Written criteria for exceptions (business justification, duration, compensating controls).
• Approvals by network/security owner.
• Time-bounded exceptions with review.
• A record of exceptions granted and revoked.

Evidence you need: exception register, approvals, and review notes. (NIST SP 800-53 Rev. 5)

6) Monitor and test control operation

Treat this like any boundary protection control: configs drift and closets get propped open.

Operational routines:

• Alert on link state changes on sensitive ports.
• Review NAC “failed auth” and “new device” events.
• Periodically sample sites for “live but unused” ports, especially in public areas.
• Validate that facilities access logs align to authorized personnel for high-risk rooms.

Evidence you need: monitoring rules, alert samples, periodic review records, and remediation tickets. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Keep evidence organized by “design,” “implementation,” and “operation” so you can answer assessors fast.

Design

• Control statement and scope: sc-07.14_odp definition (locations in scope). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Network boundary and physical layout diagrams (high-level is fine if accurate).

Implementation

• Switch/NAC configuration standards (baseline templates).
• Facilities controls for in-scope closets/rooms (lock standard, access provisioning).
• Change management procedure for patching/cross-connects.

Operational

• Port status reports (samples showing disabled unused ports).
• NAC authentication logs and enforcement reports.
• Alert/ticket samples for unauthorized connection attempts.
• Exception register with approvals and expirations.
• Periodic access log review records for sensitive rooms.

Program management (what most teams forget)

• Named control owner, backups, and an evidence collection cadence. Daydream is commonly used here to map SC-7(14) to an owner and recurring artifacts so evidence shows up on time. (NIST SP 800-53 Rev. 5)

Common exam/audit questions and hangups

1. “What locations are included in your sc-07.14_odp scope?” If you cannot point to a list, auditors may treat your control as undefined. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Show me how you prevent an unauthorized person from connecting to an open port in a conference room.” Expect a live demo request or config excerpts.
3. “How do you handle non-802.1X devices?” Auditors look for exceptions that are approved and time-bounded.
4. “How do you know a third party in your colocation can’t patch around your controls?” You need contractual and operational controls: access restrictions, escorting, and change records.

Frequent implementation mistakes and how to avoid them

• Mistake: Defining scope as “every port” with no proof. Fix: define discrete connection-point categories, then expand scope as you mature. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Mistake: Relying only on locked doors. Fix: add technical enforcement (802.1X/NAC or equivalent) so a stolen badge does not equal network access.
• Mistake: “Monitor” with no alerts or triage workflow. Fix: route events into your ticketing/SOC queue with defined response steps.
• Mistake: Exceptions become permanent. Fix: require expirations and periodic review, and tie exceptions to compensating controls (quarantine VLAN, ACLs, or restricted switchport profiles).
• Mistake: Ignoring third-party spaces. Fix: include colocation cages, managed office buildings, and shared telecom rooms in sc-07.14_odp and in your evidence plan. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, SC-7(14) maps to incident patterns assessors recognize: rogue devices, unauthorized taps, and lateral movement originating from exposed physical ports. If you cannot demonstrate port-level controls and physical access discipline, you will struggle to defend your boundary protection story across related NIST families during an assessment. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and obvious gaps)

• Assign a control owner (network/security) and a facilities partner for physical controls.
• Define sc-07.14_odp: list in-scope sites and connection point types. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify “publicly reachable live ports” and disable or gate them.
• Stand up an exceptions register and approval workflow.

Days 31–60 (implement enforceable controls)

• Roll out NAC/802.1X (or strengthen existing enforcement) starting with highest-exposure locations.
• Implement switchport security standards and push config baselines.
• Lock and inventory network closets; reconcile access lists to current roles.
• Implement alerting for new devices/link-up events on sensitive ports.

Days 61–90 (make it repeatable and audit-ready)

• Run a control test: pick a sample of sites, verify physical protections, verify port configs, and verify monitoring/triage works.
• Convert findings into tracked remediation tickets.
• Package evidence: scope register, configs, logs, alerts, and exception reviews.
• In Daydream, map SC-7(14) to your owner, procedure, and recurring evidence artifacts so future audits are less disruptive. (NIST SP 800-53 Rev. 5)

Frequently Asked Questions

Does SC-7(14) require 802.1X on every wired port?

The control requires protection against unauthorized physical connections at the locations you define, not a single mandated technology. Many teams meet the intent with 802.1X/NAC in higher-exposure areas and tighter physical controls plus port shutdown standards elsewhere. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What counts as an “unauthorized physical connection” in practice?

Any device, cable, or tap connected without approval to an in-scope port or cross-connect, including rogue Wi‑Fi access points, unmanaged switches, or laptops plugged into exposed jacks. Treat “temporary” connections the same way; require tickets and approvals. (NIST SP 800-53 Rev. 5)

How do we handle printers, badge readers, and other non-802.1X devices?

Put them into a documented exception process with compensating controls such as restricted VLANs, ACLs, and monitoring for device changes. Keep approvals and expirations so exceptions do not become permanent. (NIST SP 800-53 Rev. 5)

Are patch panels and cross-connects in scope, or only switch ports?

If someone can patch around your intended boundary controls through a panel or cross-connect, it belongs in your sc-07.14_odp scope. Auditors commonly treat meet-me rooms and wiring cabinets as critical connection points. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is most persuasive to an assessor?

A clear scope list, enforceable technical configs (NAC/port security), and operational proof such as alerts, tickets, and exception reviews. Photos of locked closets help, but they rarely carry the control alone. (NIST SP 800-53 Rev. 5)

We have colocation and managed network services. Who “owns” this control?

You still own the requirement outcome. Push physical access restrictions and change controls into third-party contracts/SLAs, then collect evidence (access logs, change records, attestations) that the third party followed them. (NIST SP 800-53 Rev. 5)