Controlling external connections is a cornerstone of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (AC.L2-3.1.20); this post shows concrete, actionable ways a small business can combine VPNs, Zero Trust Network Access (ZTNA), and Conditional Access policies to reduce exposure of Controlled Unclassified Information (CUI), survive audits, and harden remote access without blocking business operations.
\n\nNIST/CMMC require that organizations control and monitor connections between internal systems and external networks to prevent unauthorized access or data exfiltration. For a small business handling CUI, that means: 1) ensuring only authorized identities and devices can access systems, 2) enforcing least-privilege and strong authentication for external connections, and 3) logging and monitoring all access to demonstrate compliance. Failure to do so risks loss of contracts, regulatory penalties, and reputational damage.
\n\nStart with an inventory: list all external connections (remote users, third-party contractors, APIs, cloud services, vendor portals) and classify the data they access (CUI vs. non-CUI). Next, create a network access decision matrix mapping identity, device posture, network location, and application sensitivity to an access outcome (allow, require additional controls, or block). Implement in phases: first apply Conditional Access (identity layer), then segment and harden network paths (VPN / ZTNA), then enable monitoring and logging.
\n\nUse your identity provider (Azure AD, Okta, Google Workspace) to create Conditional Access policies that require MFA, compliant device posture, and restrict legacy auth. Example policy for a small defense contractor: require MFA and a device marked \"compliant\" by Intune for any access to CUI-hosting cloud apps; block legacy protocols (IMAP/POP/SMTP) and require \"trusted locations\" only for administrative tasks. Include risk-based controls (e.g., block access when sign-in risk is high) and use session controls (limit downloads) where available.
\n\nTraditional IPsec or site-to-host VPNs (IKEv2/IPsec with AES-GCM, SHA-2, and strong DH groups) still have a role for trusted corporate-managed devices and site-to-site links. For remote user access to apps hosting CUI, prefer ZTNA (per-app access) or cloud-side microbastions (Cloudflare Access, Zscaler Private Access, Google BeyondCorp) to avoid broad network-level trust. If you must use VPN, enforce certificate-based client authentication (device or user certs issued by your PKI or MDM), disable split-tunneling for CUI traffic, and restrict tunnel routes to only required subnets and ports. For modern alternatives, deploy WireGuard or TLS-based VPNs (OpenVPN/TLS 1.3) with single-use keys or hardware tokens and ensure logs are forwarded to your SIEM.
\n\nConcrete settings that help you pass an audit: require certificate-based client authentication and machine certificates from your MDM (Intune/JAMF) or internal PKI; require MFA (hardware OTP or FIDO2) for all remote interactive logons; configure Conditional Access to require \"device is compliant\" and \"user is a member of approved group\"; block legacy authentication. On firewalls, restrict egress to specific IP ranges and ports (e.g., allow TCP 443 to specific vendor IPs or domain names); implement host-based firewalls to deny unexpected inbound traffic. Enable logging for VPN and ZTNA gateways and ship logs to a SIEM (Syslog/CEF) with retention aligned to your policy—for many CUI programs 1 year is a reasonable baseline but verify contract rules.
\n\nExample: Acme Engineering (50 employees) holds CUI for a DoD subcontract. They run Office 365 and host CAD files on an AWS S3 bucket. Implementation: enroll corporate laptops in Intune, publish a Conditional Access policy in Azure AD requiring device compliance + MFA for Office 365 and AWS Console access, replace broad VPN access with Cloudflare Access for internal web apps and a purpose-built bastion (AWS SSM or Azure Bastion) for administrative hosts, and restrict the S3 access via VPC endpoints and IAM policies tied to the same identity provider. Contractors are given short-lived access via ZTNA with time-limited sessions and audited via CloudTrail + SIEM alerts. Outcome: minimal lateral movement risk, clear audit trail, and policy evidence for AC.L2-3.1.20.
\n\nDocument every decision and policy: access matrices, Conditional Access rules, VPN configs, MDM posture baseline, and log retention. Maintain an access review cadence (quarterly) to remove stale accounts. Test your policies with break-glass procedures and a privileged access plan. Use least-privilege RBAC (role-specific groups for contractor, developer, admin) and pair with just-in-time (JIT) access tools where feasible. Automate certificate deployment via MDM and rotate VPN/PKI keys on a regular schedule. Finally, include Conditional Access and ZTNA tools in your System Security Plan (SSP) with screenshots, policy names, and control evidence to ease audits.
\n\nWithout these controls you expose CUI to credential theft, lateral movement from a compromised remote device, undetected exfiltration through broad VPN tunnels, and unauthorized third-party access. Practically, that leads to contract termination, loss of future bids, potential legal liability, and a higher chance of compromise. From a compliance perspective, auditors will flag missing enforcement of device posture, weak authentication, and lack of segmentation—elements at the core of AC.L2-3.1.20.
\n\nSummary: meet AC.L2-3.1.20 by combining identity-first Conditional Access, device posture and MDM, and network segmentation using ZTNA or hardened VPNs; document your configuration, monitor and retain logs, and automate enforcement where possible. These steps reduce risk, create audit evidence, and scale with your small business as you mature into a Zero Trust posture that satisfies NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2.
", "plain_text": "Controlling external connections is a cornerstone of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (AC.L2-3.1.20); this post shows concrete, actionable ways a small business can combine VPNs, Zero Trust Network Access (ZTNA), and Conditional Access policies to reduce exposure of Controlled Unclassified Information (CUI), survive audits, and harden remote access without blocking business operations.\n\nWhy this control matters (Compliance Framework perspective)\nNIST/CMMC require that organizations control and monitor connections between internal systems and external networks to prevent unauthorized access or data exfiltration. For a small business handling CUI, that means: 1) ensuring only authorized identities and devices can access systems, 2) enforcing least-privilege and strong authentication for external connections, and 3) logging and monitoring all access to demonstrate compliance. Failure to do so risks loss of contracts, regulatory penalties, and reputational damage.\n\nPractical implementation steps\nStart with an inventory: list all external connections (remote users, third-party contractors, APIs, cloud services, vendor portals) and classify the data they access (CUI vs. non-CUI). Next, create a network access decision matrix mapping identity, device posture, network location, and application sensitivity to an access outcome (allow, require additional controls, or block). Implement in phases: first apply Conditional Access (identity layer), then segment and harden network paths (VPN / ZTNA), then enable monitoring and logging.\n\nPhase 1 — Identity + Conditional Access\nUse your identity provider (Azure AD, Okta, Google Workspace) to create Conditional Access policies that require MFA, compliant device posture, and restrict legacy auth. Example policy for a small defense contractor: require MFA and a device marked \"compliant\" by Intune for any access to CUI-hosting cloud apps; block legacy protocols (IMAP/POP/SMTP) and require \"trusted locations\" only for administrative tasks. Include risk-based controls (e.g., block access when sign-in risk is high) and use session controls (limit downloads) where available.\n\nPhase 2 — Network controls: VPN vs ZTNA\nTraditional IPsec or site-to-host VPNs (IKEv2/IPsec with AES-GCM, SHA-2, and strong DH groups) still have a role for trusted corporate-managed devices and site-to-site links. For remote user access to apps hosting CUI, prefer ZTNA (per-app access) or cloud-side microbastions (Cloudflare Access, Zscaler Private Access, Google BeyondCorp) to avoid broad network-level trust. If you must use VPN, enforce certificate-based client authentication (device or user certs issued by your PKI or MDM), disable split-tunneling for CUI traffic, and restrict tunnel routes to only required subnets and ports. For modern alternatives, deploy WireGuard or TLS-based VPNs (OpenVPN/TLS 1.3) with single-use keys or hardware tokens and ensure logs are forwarded to your SIEM.\n\nTechnical specifics and configuration tips\nConcrete settings that help you pass an audit: require certificate-based client authentication and machine certificates from your MDM (Intune/JAMF) or internal PKI; require MFA (hardware OTP or FIDO2) for all remote interactive logons; configure Conditional Access to require \"device is compliant\" and \"user is a member of approved group\"; block legacy authentication. On firewalls, restrict egress to specific IP ranges and ports (e.g., allow TCP 443 to specific vendor IPs or domain names); implement host-based firewalls to deny unexpected inbound traffic. Enable logging for VPN and ZTNA gateways and ship logs to a SIEM (Syslog/CEF) with retention aligned to your policy—for many CUI programs 1 year is a reasonable baseline but verify contract rules.\n\nReal-world small-business scenario\nExample: Acme Engineering (50 employees) holds CUI for a DoD subcontract. They run Office 365 and host CAD files on an AWS S3 bucket. Implementation: enroll corporate laptops in Intune, publish a Conditional Access policy in Azure AD requiring device compliance + MFA for Office 365 and AWS Console access, replace broad VPN access with Cloudflare Access for internal web apps and a purpose-built bastion (AWS SSM or Azure Bastion) for administrative hosts, and restrict the S3 access via VPC endpoints and IAM policies tied to the same identity provider. Contractors are given short-lived access via ZTNA with time-limited sessions and audited via CloudTrail + SIEM alerts. Outcome: minimal lateral movement risk, clear audit trail, and policy evidence for AC.L2-3.1.20.\n\nCompliance tips and best practices\nDocument every decision and policy: access matrices, Conditional Access rules, VPN configs, MDM posture baseline, and log retention. Maintain an access review cadence (quarterly) to remove stale accounts. Test your policies with break-glass procedures and a privileged access plan. Use least-privilege RBAC (role-specific groups for contractor, developer, admin) and pair with just-in-time (JIT) access tools where feasible. Automate certificate deployment via MDM and rotate VPN/PKI keys on a regular schedule. Finally, include Conditional Access and ZTNA tools in your System Security Plan (SSP) with screenshots, policy names, and control evidence to ease audits.\n\nRisks of not implementing these controls\nWithout these controls you expose CUI to credential theft, lateral movement from a compromised remote device, undetected exfiltration through broad VPN tunnels, and unauthorized third-party access. Practically, that leads to contract termination, loss of future bids, potential legal liability, and a higher chance of compromise. From a compliance perspective, auditors will flag missing enforcement of device posture, weak authentication, and lack of segmentation—elements at the core of AC.L2-3.1.20.\n\nSummary: meet AC.L2-3.1.20 by combining identity-first Conditional Access, device posture and MDM, and network segmentation using ZTNA or hardened VPNs; document your configuration, monitor and retain logs, and automate enforcement where possible. These steps reduce risk, create audit evidence, and scale with your small business as you mature into a Zero Trust posture that satisfies NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2." }, "metadata": { "description": "Practical guidance for using VPNs, Zero Trust principles, and Conditional Access to control external connections and meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (AC.L2-3.1.20) requirements.", "permalink": "/how-to-use-vpns-zero-trust-and-conditional-access-to-control-external-connections-nist-sp-800-171-rev2-cmmc-20-level-2-control-acl2-3120.json", "categories": [], "tags": [] } }