If you have unmanaged switches anywhere in the network path that touches Controlled Unclassified Information (CUI), you likely have a CMMC compliance gap — and it’s one assessors will find. The fix isn’t complicated, but ignoring it because the hardware ‘works fine’ is a mistake that can derail an assessment you’ve spent months preparing for.
What CMMC Actually Requires From Your Network
CMMC Level 2 maps directly to NIST SP 800-171. Several of those 110 practices speak directly to network visibility and control:
- 3.13.1 — Protect CUI during transmission using cryptographic mechanisms or physical safeguards.
- 3.13.5 — Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
- 3.3.1 / 3.3.2 — Create and protect audit logs of system activity.
- 3.4.1 — Establish and maintain baseline configurations for your systems, including network components.
An unmanaged switch cannot satisfy any of these in a meaningful way. It has no management interface, no VLAN capability, no port-level logging, no 802.1X authentication support, and no way to enforce a configuration baseline. It is, by design, invisible to your security stack.
The Specific Problems Unmanaged Switches Create
You Cannot Segment the Network
CUI should live on a defined, bounded network segment — not on the same flat layer-2 broadcast domain as the printer, the guest Wi-Fi bridge, and the conference room TV. Managed switches let you enforce VLANs and control which ports belong to which segment. Unmanaged switches do not. Any device plugged into an unmanaged switch that sits on your CUI segment is, effectively, on your CUI segment — whether you intended that or not.
You Have No Visibility Into What’s Connected
If you can’t query the switch, you can’t see MAC address tables, you can’t detect rogue devices, and you can’t tie port activity to your SIEM or log aggregator. NIST 800-171 practice 3.3.1 requires audit logging of system activity. A switch that produces no logs and accepts no management queries is a blind spot in your audit trail.
You Cannot Enforce a Configuration Baseline
Practice 3.4.1 requires documented baseline configurations for organizational systems. Network infrastructure is explicitly in scope. An unmanaged switch has no configurable state — there is nothing to document, nothing to harden, and nothing to verify hasn’t changed. That’s not a baseline; that’s an absence of control.
Physical Access Becomes Your Only Control
With an unmanaged switch, the only thing preventing an unauthorized device from joining your network at that point is whether someone can physically reach the switch and plug in a cable. That’s not a network access control — that’s a hope. Managed switches support 802.1X port-based authentication, which ties network access to verified credentials or certificates rather than physical proximity.
Where Unmanaged Switches Tend to Hide
Most organizations that have unmanaged switches didn’t deploy them as a deliberate architecture decision. They show up in predictable places:
- Under desks — someone needed more ports in a conference room or office and grabbed a cheap switch from a supply closet.
- In server rooms — an older switch that was ‘good enough’ when the network was smaller and never got replaced.
- At remote or satellite offices — locations that were set up quickly without the same infrastructure standards as the main site.
- In OT/manufacturing adjacency — areas where IT and operational technology intersect and network standards sometimes get relaxed.
Before your CMMC assessment, walk the network. Physically trace cables if you have to. Unmanaged switches don’t show up in most network discovery tools because they have no IP address and no SNMP agent. You find them by looking.
What to Do About It
The remediation path is straightforward, though it takes planning:
1. Inventory every switch in the CUI environment. Document make, model, managed vs. unmanaged status, and physical location. This is part of your asset inventory requirement under 3.4.1 anyway.
2. Replace unmanaged switches with managed alternatives. You don’t need enterprise-grade hardware everywhere. A managed switch from a reputable vendor that supports VLANs, 802.1X, port security, and SNMP or syslog forwarding is sufficient for most small-to-midsize environments. The cost difference between an unmanaged and an entry-level managed switch is not large enough to justify the compliance exposure.
3. Configure the switches, then document the configuration. A managed switch you haven’t configured is only marginally better than an unmanaged one. Define your VLANs, disable unused ports, enable port security, configure syslog forwarding to your log aggregator, and document the baseline. That documentation is what an assessor will ask to see.
4. Integrate switch logs into your monitoring. If your managed switches are forwarding syslog events but nobody is reviewing them, you’ve met the technical requirement but not the operational one. Make sure those logs flow into whatever SIEM or log management platform you’re using for your CUI environment.
5. Enforce 802.1X where the risk warrants it. Not every port in every location needs certificate-based authentication, but any port in a CUI-adjacent area that could be accessed by an unauthorized person should. Work with your network team or MSP to scope this appropriately.
The Assessment Reality
CMMC assessors doing a Level 2 assessment will review your network architecture, ask for configuration documentation, and in many cases walk the environment. An unmanaged switch in the CUI boundary is a finding — not a minor one. It touches multiple practices simultaneously and signals to the assessor that network controls weren’t taken seriously during the preparation phase.
The good news is that this is one of the more fixable infrastructure gaps. Replacing a switch and documenting its configuration is a defined, bounded task. Do it before the assessment, not after.