AC-17: Remote Access

What this control requires

AC-17 requires organizations to document usage restrictions, configuration requirements, and authorization for every type of remote access they allow. That single sentence captures the control’s intent, but the operational reality is far more demanding than most teams expect.

In practice, the control translates to two core obligations. First, you must establish and document usage restrictions, configuration and connection requirements, and implementation guidance for each allowed type of remote access. Second, you must authorize each remote access type before permitting connections.

The result is a current inventory requirement covering every method your workforce and third parties use to reach internal systems. That inventory spans virtual private network (VPN) tunnels, Secure Shell (SSH) sessions, cloud-based remote desktop tools, and application programming interface (API) gateways.

Where most organizations fall short isn’t the technology. It’s the documentation and lifecycle governance.

Specifically, AC-17 doesn’t just ask you to encrypt remote sessions. It asks you to prove that every remote access method was evaluated, approved, configured to policy, and monitored on an ongoing basis. The NIST SP 800-53 framework treats remote access as a persistent attack surface that requires continuous authorization, not a one-time deployment decision.

Why it matters

A single unmanaged VPN account can bring critical infrastructure to a halt. That risk isn’t hypothetical. It’s exactly what happened to Colonial Pipeline in May 2021, in one of the most consequential remote access failures in recent history.

Colonial Pipeline DarkSide ransomware

On May 7, 2021, the DarkSide ransomware group encrypted Colonial Pipeline’s IT systems, forcing the company to shut down pipeline operations for six days. Colonial Pipeline carries approximately 45% of fuel consumed by the US East Coast, and the shutdown triggered fuel shortages across multiple states along with a declaration of regional emergency.

Specifically, Congressional testimony on June 8, 2021 revealed the entry point. CEO Joseph Blount confirmed that the attackers gained initial access through a single compromised VPN account. The account was a legacy profile no longer in active use by any employee.

Specifically, the account had not been decommissioned, had no multi-factor authentication (MFA) enabled, and its password had appeared in a separate credential dump, suggesting reuse. The absence of a policy governing the lifecycle of remote access accounts represents a direct AC-17 failure.

The consequence was severe. Colonial Pipeline paid a $4.4 million ransom to DarkSide, of which the Department of Justice recovered approximately $2.3 million. CISA subsequently issued guidance recommending that organizations audit all remote access accounts and enforce MFA across every externally accessible service.

But the Colonial Pipeline incident isn’t an outlier. It’s a case study in what happens when VPN security governance stops at provisioning and never addresses decommissioning, monitoring, or re-authorization.

What attackers exploit:

• Dormant or orphaned VPN accounts that were never decommissioned after employees left or changed roles
• Remote access connections without MFA, allowing credential-stuffing attacks to succeed with a single password
• Unmonitored remote sessions where lateral movement goes undetected for days or weeks
• Misconfigured split-tunnel VPNs that expose internal networks to traffic from untrusted endpoints
• Third-party remote access tools deployed outside IT governance, creating shadow entry points

How to implement

The most common failure mode isn’t a missing VPN configuration. It’s the gap between deploying remote access technology and maintaining a living governance process around it. Organizations that treat AC-17 as a one-time technical project instead of a continuous lifecycle program are the ones that end up with orphaned accounts and unmonitored sessions.

For your organization

Specifically, start by building a complete inventory of every remote access method in use across your environment. The inventory should cover VPN clients, remote desktop protocols, SSH tunnels, cloud-based access brokers, and any API-based connections that allow external systems to reach internal resources.

Where most teams fall short is scope. Shadow IT remote access tools deployed outside formal governance are often the highest-risk vectors, so don’t limit the inventory to IT-sanctioned tools.

In practice, the next step is documenting usage restrictions and configuration requirements for each access type. Specify who is authorized to use each method, under what conditions, and what encryption and authentication standards apply. Every remote access type should require explicit authorization before it’s enabled, and that authorization should be recorded in a central system with timestamps and approver identities.

Specifically, deploy encryption for all remote sessions. Transport Layer Security (TLS) 1.2 or higher for web-based access and Internet Protocol Security (IPsec) or WireGuard for VPN tunnels are the most common configurations. Pair encryption with mandatory MFA for every remote access method, with no exceptions for legacy accounts or service accounts.

The result is a continuous monitoring requirement for remote access sessions. Log connection times, source addresses, authentication events, and session durations. Feed these logs into your security information and event management (SIEM) platform or equivalent monitoring tool so anomalous patterns trigger alerts.

But configuration alone isn’t sufficient without ongoing validation. Conduct periodic reviews, at minimum quarterly, to verify that all remote access accounts are still needed, that configurations match documented requirements, and that no unauthorized access methods have been introduced.

Common mistakes:

• Exempting service accounts or legacy systems from MFA requirements
• Documenting remote access policies once and never updating them as new tools are adopted
• Relying on network-level controls without monitoring individual session behavior
• Failing to revoke remote access when employees change roles or leave the organization

For your vendors

But where internal governance is directly under your control, third-party compliance requires verification rather than assumption. Start your security questionnaire by asking vendors to describe every remote access method they use to connect to your systems or to their own infrastructure that processes your data.

In practice, the assessment starts with requesting documentation of their remote access policy, including usage restrictions, authorized access types, encryption requirements, and MFA enforcement. Ask specifically whether they maintain an inventory of active remote access accounts and how frequently they review that inventory for orphaned or dormant entries.

Specifically, evidence to request includes VPN configuration documentation showing encryption standards in use, MFA enrollment records for remote users, remote access authorization logs showing who approved each account, and session audit logs from the past 90 days demonstrating active monitoring.

Where the verification breaks down, red flags include vendors who cannot produce a written remote access policy, vendors who acknowledge that some remote access methods don’t require MFA, and any vendor that cannot demonstrate a regular review process for decommissioning unused accounts. If a vendor reports that they “use a VPN” but cannot describe the specific configuration requirements or authorization workflow, the gap is worth escalating.

But self-attestation alone isn’t sufficient. Request screenshots or exports from their VPN management console showing current encryption settings and active user counts.

Specifically, ask for their most recent internal or external audit report covering remote access controls. If the vendor connects to your environment directly, validate their configurations against your own AC-17 requirements using network monitoring tools or access logs from your side of the connection.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 Account Management: Manages the accounts that remote users authenticate with.
• AC-03 Access Enforcement: Enforces access restrictions once remote connections are established.
• AC-04 Information Flow Enforcement: Controls the flow of information across remote network boundaries.
• AC-18 Wireless Access: Addresses wireless as a specific remote access vector.
• AC-19 Access Control for Mobile Devices: Governs mobile devices used for remote connections.
• AC-20 Use of External Systems: Covers access from systems not under organizational control.
• CA-03 Information Exchange: Manages agreements governing remote connections to other systems.
• CM-10 Software Usage Restrictions: Restricts software that may be used over remote connections.
• IA-02 Identification and Authentication (Organizational Users): Authenticates users before granting remote access.
• IA-03 Device Identification and Authentication: Authenticates devices connecting remotely.

Frequently asked questions

What is NIST SP 800-53 AC-17?

AC-17 is the NIST SP 800-53 control that requires organizations to establish, document, and enforce usage restrictions and authorization for every type of remote access they permit. It covers two assessment objectives: documenting configuration requirements and implementation guidance for each remote access method, and authorizing each access type before connections are allowed. In practice, this control demands a living governance process, not just a VPN deployment, that addresses remote access authorization, encryption, monitoring, and periodic review across the full lifecycle of every remote connection.

What happens if AC-17 is not implemented?

Without AC-17 controls, organizations lose visibility into who is connecting remotely, how they’re connecting, and whether those connections are still authorized. The Colonial Pipeline incident demonstrated the consequences directly when a single VPN account with no MFA and no lifecycle governance gave attackers access to systems that controlled 45% of the US East Coast fuel supply. Ungoverned remote access creates persistent entry points that attackers can exploit through credential stuffing, password reuse, or compromised endpoints, often without triggering any alerts.

How do you audit AC-17?

Auditing AC-17 starts with reviewing the organization’s remote access policy for completeness, confirming it defines authorized access types, usage restrictions, and encryption requirements. From there, examine VPN configuration documentation to verify that encryption and authentication settings match the policy. Review remote access authorization records, the account inventory, and session audit logs together to confirm that every active account has a documented approval, no dormant entries remain, and anomalous activity triggers alerts.

What are the AC-17 control enhancements?

AC-17 includes four enhancements that extend the base control: AC-17(1) requires automated monitoring of remote access methods, and AC-17(2) mandates cryptographic protection of session confidentiality and integrity. AC-17(3) routes all remote access through a limited number of managed access control points. AC-17(4) restricts privileged commands and access to security-relevant information via remote connections, requiring specific authorization and documentation for each such use.