Skip to main content
NetStable
Level 2 AC.L2-3.1.14

Route remote access via managed access control points

📖 What This Means

This control requires that all remote access to your organization's systems (like employees working from home or vendors accessing your network) must go through a secure, centralized gateway that you manage. Think of it like a guarded checkpoint—everyone must pass through it, and you control who gets in and what they can do. This prevents unauthorized users from connecting directly to sensitive systems. For example, instead of letting employees connect straight to a server, they first connect to a VPN or secure remote desktop gateway that checks their credentials and logs their activity. Another example: a contractor accessing your cloud environment must use an approved jump server rather than connecting directly to databases.

🎯 Why It Matters

Uncontrolled remote access is a top attack vector—60% of breaches involve compromised credentials (Verizon DBIR). Without managed access points, attackers can exploit weak passwords or unpatched systems to move freely in your network. A real-world example: the 2020 SolarWinds breach started with attackers gaining remote access to update servers. The DoD mandates this control because CUI (Controlled Unclassified Information) is often targeted via remote workers or third parties. A single unsecured RDP (Remote Desktop Protocol) connection could lead to $4M+ in breach costs (IBM Cost of a Data Breach Report) and loss of contracts.

How to Implement

  1. 1. Configure a cloud VPN (e.g., AWS Client VPN, Azure VPN Gateway) or Zero Trust solution (e.g., Zscaler, Cloudflare Access).
  2. 2. Set up conditional access policies (e.g., Azure AD Conditional Access) requiring MFA and device compliance checks.
  3. 3. Deploy a bastion host/jump server (e.g., AWS Session Manager, Azure Bastion) for admin access to cloud resources.
  4. 4. Log all remote access attempts to a SIEM (e.g., AWS CloudTrail + GuardDuty, Azure Sentinel).
  5. 5. Disable direct RDP/SSH to cloud VMs—only allow connections via the VPN or bastion host.
⏱️
Estimated Effort
2-5 days (intermediate skill). Cloud setups are faster (1-2 days with pre-built templates). On-premise may require hardware configuration.

📋 Evidence Examples

Remote Access Policy

Format: PDF/DOCX
Frequency: Annual review or after major changes.
Contents: Defines approved methods (e.g., 'Only Azure VPN with MFA'), access request procedures, and logging requirements.
Collection: Export from policy management system or SharePoint.

VPN Gateway Configuration

Format: Screenshot/XML
Frequency: After configuration changes.
Contents: Shows MFA enforcement, allowed IP ranges, and session timeout settings.
Collection: Screenshot from admin console (e.g., Cisco AnyConnect admin UI).

Access Logs

Format: CSV/SIEM Export
Frequency: Weekly spot checks.
Contents: Timestamps, user IDs, source IPs, and accessed resources for all remote sessions.
Collection: Export from SIEM or VPN logs (retain 90+ days).

Network Diagram

Format: Visio/PNG
Frequency: Quarterly or after network changes.
Contents: Shows all remote access paths through controlled points (highlight VPNs, gateways).
Collection: Update topology tools like Lucidchart.

Pen Test Report

Format: PDF
Frequency: Annual or pre-assessment.
Contents: Confirms testers couldn't bypass access controls (include command attempts like 'nmap -Pn -p 3389').
Collection: 3rd-party test or internal scan with tools like Nessus.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For AC.L2-3.1.14 ("Route remote access via managed access control points"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"AC.L2-3.1.14 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to route remote access via managed access control points. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"AC.L2-3.1.14 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to route remote access via managed access control points. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"AC.L2-3.1.14 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

  • Identify all access points to CUI systems (VPN, direct network, cloud portals)
  • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
  • Map user roles to system access levels
  • Ensure this control covers all systems within your defined CUI boundary where route remote access via managed access control points applies
  • Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

  • 📄 Access Control Policy
  • 📄 IAM configuration documentation
  • 📄 Access request and approval records
  • 📄 Evidence artifacts specific to AC.L2-3.1.14
  • 📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Do you have a documented policy requiring all remote access to route through approved gateways (VPN, RDP Gateway, etc.)?

✅ YES → Proceed to Q2.
❌ NO → GAP: Draft a policy using templates from NIST SP 800-171A (Appendix D). Timeline: 1 week.
Remediation:
Use NIST SP 800-171A Appendix D template.

Question 2: Are direct RDP/SSH connections to systems (bypassing gateways) disabled in firewall rules?

✅ YES → Proceed to Q3.
❌ NO → GAP: Block ports 3389/TCP (RDP) and 22/TCP (SSH) at the firewall. Timeline: 1 day.
Remediation:
Firewall rule example: 'Deny TCP 3389 from 0.0.0.0/0'.

Question 3: Are all remote access sessions logged with user IDs, timestamps, and accessed resources?

✅ YES → Proceed to Q4.
❌ NO → GAP: Enable logging on VPN/RDP Gateway (e.g., 'Log all events' in Windows RD Gateway). Timeline: 1 day.
Remediation:
Enable Windows Event ID 1149 for RD Gateway.

Question 4: Is MFA required for all remote access methods?

✅ YES → Proceed to Q5.
❌ NO → GAP: Implement MFA via Duo, Azure MFA, or RSA. Timeline: 3 days.
Remediation:
Azure AD MFA setup guide: https://aka.ms/mfa-docs.

Question 5: Have you tested that unauthorized direct access attempts fail (e.g., trying RDP to a server IP)?

✅ YES → COMPLIANT.
❌ NO → GAP: Run test with 'telnet [server_ip] 3389'—should timeout. Timeline: 1 day.
Remediation:
Test with `Test-NetConnection -ComputerName [IP] -Port 3389` (PowerShell).

⚠️ Common Mistakes (What Auditors Flag)

1. Allowing 'just one exception' for direct access.

Why this happens: Pressure from executives/vendors who 'need quick access'.
How to avoid: Enforce policy consistently—provide temporary VPN credentials instead.

2. Not logging failed access attempts.

Why this happens: Default logging settings often exclude failures.
How to avoid: Enable 'Logon Failure' auditing (Windows) or 'auth.log' monitoring (Linux).

3. Using shared VPN credentials.

Why this happens: Easier to manage but violates accountability.
How to avoid: Issue individual certs/credentials (e.g., via Active Directory integration).

4. Missing gateway patches (e.g., unpatched RD Gateway).

Why this happens: Fear of breaking remote access functionality.
How to avoid: Schedule monthly maintenance windows for updates.

5. No alerting for suspicious access (e.g., logins at 3 AM).

Why this happens: Assuming logs alone are sufficient.
How to avoid: Set SIEM alerts for off-hours access or multiple failures.

📚 Parent Policy

This practice is governed by the Access Control Policy

View AC Policy →

📚 Related Controls