This post explains how small businesses can implement network segmentation and zero-trust principles to verify and restrict external connections in order to meet FAR 52.204-21 and CMMC 2.0 Level 1 Control AC.L1-B.1.III requirements under the Compliance Framework.
What the control requires (high level)
AC.L1-B.1.III expects organizations to verify and restrict external connections to systems processing, storing, or transmitting controlled unclassified information (CUI) or other covered data — in practice this means applying controls that ensure only authorized, authenticated, and properly configured endpoints and users can establish external connections to your network or systems. For the Compliance Framework, that translates to documented network separation, enforceable access decisions, monitoring of allowed external flows, and evidence of verification steps (logs, attestations, or automated posture checks).
Network segmentation: practical, actionable steps
Start with a simple, enforceable segmentation plan: map assets, classify them by function and data sensitivity, and create VLANs/subnets to separate user workstations, servers (including CUI-handling systems), guest Wi‑Fi, and OT/IoT devices. Implement "deny by default" ACLs on your edge and core switches/routers so that cross-segment traffic must be explicitly allowed. For small businesses that lack enterprise gear, use a UTM (pfSense/OPNsense, Cisco Meraki, Fortinet) to enforce inter-VLAN routing rules: e.g., allow VLAN 10 (workstations) to reach VLAN 20 (CUI servers) only on TCP/443 and only to a specific server IP; block everything else.
Applying zero-trust principles to external connections
Zero trust means never trust, always verify: enforce identity and device posture before permitting external access. Replace broad VPN trusts with identity-aware access (ZTNA) or cloud access proxies that verify user identity (SAML/OIDC), require MFA, and check device posture (up-to-date OS, disk encryption, endpoint protection). For remote contractors or third parties, use per-application proxies (Cloudflare Access, Zscaler Private Access, or an open-source overlay) that issue short-lived session tokens and limit access to a specific application rather than the whole network.
Technical configurations and examples
Be specific: implement egress and ingress allowlists, not blacklists. Example iptables pattern for a workstation that may only contact a single external API endpoint over HTTPS: iptables -A OUTPUT -p tcp --dport 443 -d 198.51.100.10 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT; iptables -A OUTPUT -p tcp --dport 443 -j REJECT. On perimeter firewalls enforce source IP/VLAN to destination IP/service rules, log matches, and drop everything else. Use DNS filtering (Pi-hole, Cisco Umbrella) and TLS inspection for necessary traffic to verify SNI and certificate validity. For device-level verification, deploy 802.1X with RADIUS for wired/wireless NAC or use agent-based posture checks from your ZTNA provider; require NAC to place devices failing posture into a remediation VLAN with no external connectivity.
Small business scenarios and real-world examples
Example 1: A small software shop handles CUI on a single server. Create a DMZ VLAN for the server, put developer laptops on a separate VLAN, and only allow SSH from a jump host that requires MFA and hardware-backed keys. Log the jump host sessions and keep ACLs documented. Example 2: A marketing firm uses cloud-based CRM and accepts contractor uploads: grant contractors access via ZTNA to only the CRM app, require device attestation via an endpoint agent, and restrict uploads to the CRM’s IP ranges; avoid giving contractors VPN access to the internal network.
Compliance tips and best practices
Document everything: network diagrams, VLAN/subnet lists, firewall ACLs, ZTNA policies, device posture checks, and change control tickets. Automate verification where possible — use configuration management to generate evidence (e.g., export firewall rules and timestamped logs). Schedule quarterly reviews of allowlists and conduct penetration tests or vulnerability scans after segmentation changes. Ensure logging/retention meets evidence needs: centralized syslog/flow logs (NetFlow/IPFIX) or a lightweight SIEM for small shops (Elastic, Splunk Light, or cloud-native logging) to prove connections were restricted and verified.
Risks of not implementing these controls
Without segmentation and zero-trust verification, an external compromise (phishing, exposed credential) can pivot across your network and reach CUI systems, causing data loss, contract penalties under FAR 52.204-21, and failing a CMMC assessment. Unrestricted external connections increase attack surface, make forensic analysis harder, and reduce your ability to demonstrate that only authorized entities accessed covered systems — which can lead to audit findings, loss of contracts, and reputational harm.
Summary: For Compliance Framework adherence to FAR 52.204-21 / CMMC AC.L1-B.1.III, combine clear segmentation, strict firewall/ACl policies, identity- and device-based verification (zero trust), logging, and documentation. Start small (VLANs + UTM + ZTNA) and iterate, prioritize "deny by default," maintain allowlists, and keep evidence trails to demonstrate verification and restriction of external connections.
