Every company has remote access now, and every auditor asks about it. AC-17 asks two things. Establish and document usage restrictions, configuration and connection requirements, and implementation guidance for each type of remote access you allow. Then authorize each type before connections are permitted.
SP 800-53 binds US federal systems and, through contract, some suppliers. Others use it as a reference, and the questions in a customer questionnaire about VPNs and remote administration are close cousins.
What it means in practice
The guidance defines remote access as access through external networks such as the internet, including dial up, broadband and wireless. It says encrypted VPNs can let you treat connections as internal, if the cryptography meets applicable standards. It also adds two honest cautions: VPN traffic still crosses external networks, and encrypted tunnels can make it harder to inspect traffic for malicious code.
Controls for remote access do not apply to public web servers or systems built for public access. Agreements with other systems belong to CA-3, and the enforcement of access restrictions belongs to AC-3.
The enhancements are a practical hardening list:
- AC-17.1 Monitoring and Control
- AC-17.2 Protection of Confidentiality and Integrity Using Encryption
- AC-17.3 Managed Access Control Points
- AC-17.4 Privileged Commands and Access
- AC-17.5 Monitoring for Unauthorized Connections
- AC-17.6 Protection of Mechanism Information
- AC-17.7 Additional Protection for Security Function Access
- AC-17.8 Disable Nonsecure Network Protocols
Evidence to collect
- A remote access standard listing each type: VPN, bastion host, remote desktop, SSH, vendor access, and any zero trust access proxy.
- Authorization records for each type and for each group allowed to use it.
- Configuration showing encryption and multi factor authentication.
- Logs of remote sessions, and proof someone reviews them.
- Evidence that legacy protocols are disabled, such as telnet or plain FTP.
- A list of third parties with remote access and the approval for each.
Common gaps
- Direct SSH or RDP open to the internet.
- A VPN with a shared credential.
- Vendor accounts that stay active between engagements.
- Remote sessions logged but never reviewed.
- No multi factor authentication on administrative remote paths.
- An old VPN still running next to the new access tool.
How to implement it
List every way a person or system reaches your environment from outside. Remove what you do not need. For what remains, require multi factor authentication, route through a single managed entry point, and log each session.
Time limit vendor access, and tie it to a ticket. Disable weak protocols with configuration, and verify by scanning. Review the list of remote access types when infrastructure changes, since new tools tend to add new doors.
Watching for drift matters as much as the first setup. A continuous monitoring approach catches a newly opened port or a new remote tool before the next audit does.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does AC-17 apply to public web servers?
No. The guidance says remote access controls apply to systems other than public web servers or systems designed for public access.
What does the guidance warn about encrypted VPN tunnels?
They can reduce the ability to monitor traffic for malicious code, and a VPN does not improve availability.
Sources
- NIST SP 800-53 Rev 5, AC-17: https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17
- NIST OSCAL catalog of SP 800-53 Rev 5: https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
