RMFInsider

AC-17 is two sentences of control text and four artifacts. The control text tells you to establish and document usage restrictions, configuration and connection requirements, and implementation guidance for each type of remote access you allow, and then to authorize each type before you let anything connect. The evidence an assessor asks for is a remote access policy, a list of approved remote access methods, configuration evidence for the virtual desktop infrastructure or VPN that carries those methods, and a monitoring record proving somebody actually watched the sessions. Hand over those four in agreement with each other and AC-17 closes in a twenty minute conversation. Let the policy name a method your configuration evidence does not cover, and you are explaining yourself for an hour.

What the control text actually requires

NIST SP 800-53 Rev 5 splits AC-17 into part a and part b, and they are different kinds of obligation. Part a is documentary: for each type of remote access you permit, write down the usage restrictions, the configuration and connection requirements, and the implementation guidance. Part b is a decision: authorize that type of access before connections are allowed. A policy that describes remote access in general terms satisfies neither, because the unit of work in AC-17 is the type, not the system. Government laptop over the enterprise tunnel, thin client into a VDI pool, and a vendor dialing in for maintenance are three types and want three authorizations.

The discussion under the control hands you two arguments worth keeping. First, if your encrypted tunnel uses cryptography that meets applicable federal requirements, you may treat that connection as internal rather than remote, which changes what else you have to say about it. Second, AC-17 does not reach systems built for public access, so your public-facing web server is not a remote access type and does not belong on the list. NIST also says the quiet part out loud in the same discussion: an encrypted tunnel protects your traffic from everyone, including the people paid to inspect it.

The enhancements a moderate or high baseline pulls

Four enhancements sit in the moderate and high baselines in SP 800-53B, which is the starting point a DoD package inherits before any overlay or tailoring decision moves anything:

• AC-17(1), Monitoring and Control. Employ automated mechanisms to monitor and control remote access methods.
• AC-17(2), Protection of Confidentiality and Integrity Using Encryption. Implement cryptographic mechanisms to protect remote access sessions.
• AC-17(3), Managed Access Control Points. Route remote access through authorized and managed network access control points.
• AC-17(4), Privileged Commands and Access. Authorize privileged commands and access to security relevant information over a remote session only in a form that provides assessable evidence, and document the rationale in the system security plan.

Three more enhancements exist that the standard moderate and high allocation does not pull, so when they appear it is through an overlay or a named requirement: AC-17(6) Protection of Mechanism Information, AC-17(9) Disconnect or Disable Access, and AC-17(10) Authenticate Remote Commands. If an assessor cites one of those, ask which overlay brought it. The answer belongs in your control implementation statement.

Three enhancement numbers no longer exist, and citing one tells an assessor you are working from an old reference. AC-17(5) was withdrawn and incorporated into SI-4. AC-17(7) was withdrawn into AC-3(10). AC-17(8) was withdrawn into CM-7. That last one changes where a real finding lands: an insecure protocol left enabled on the remote access gateway is a CM-7 problem now, and writing the POA&M against AC-17(8) gives your assessor an easy reason to send it back.

The four artifacts and what each has to prove

The remote access policy

Signed, dated, and currently in effect, with a section per access type rather than one paragraph covering all of them. For each type the policy states who may use it, from what device, under what conditions, what data may cross it, and what is forbidden: local storage, printing, personal equipment, split tunneling. The policy is also where you point at the rules of behavior under PL-4 and the training under AT-2, because an assessor who samples a teleworker will ask what that person signed and when.

The approved methods list

This is the artifact nobody owns, which is why it is usually the stalest thing in the set. It should be a short enumeration: each permitted remote access type, the name of the official who authorized it, and the date. Part b of the control is an authorization before connection, so a list dated after the method went live documents a finding rather than closing one. Nonlocal maintenance is the type that slips through most often, because a vendor session is arranged by an engineer under schedule pressure and governed by MA-4, and nobody thinks to add it to an access control artifact.

VDI or VPN configuration evidence

DISA publishes a Virtual Private Network Security Requirements Guide. Version 3 release 1 is dated 24 July 2024 and carries 83 rules, 11 of them severity high. Several map straight onto AC-17 and its neighbors, which means your STIG results are already AC-17 evidence if you cite them by rule ID:

• V-207190 requires a TLS VPN gateway to use TLS 1.2 at a minimum. It is a high.
• V-207193 requires an IPsec VPN to use a Diffie-Hellman group of 16 or greater for IKE phase 1.
• V-207191 requires remote access session integrity to rest on digital signatures produced by FIPS-validated algorithms with an approved hash function.
• V-207209 requires multifactor authentication such as DoD PKI for network access by non-privileged accounts, which is where your IA-2 story and your AC-17 story meet.
• V-207189 limits concurrent sessions per account, which maps to AC-10 rather than AC-17, and is worth knowing so you do not file it in the wrong place.

The artifact is a checklist or scan result carrying rule IDs, a date, and the asset it ran against. It is not a screenshot of a settings page, because a screenshot carries no defensible date. VDI follows the same rule with a different product STIG behind it, plus evidence that the pool enforces the same restrictions the policy claims: no local drive mapping, no clipboard, no local print.

The monitoring record

AC-17(1) asks for automated mechanisms to monitor and control remote access methods, and the word that gets packages in trouble is monitor. Collection is not monitoring. The artifact is a report showing remote sessions by account and time, the name of the person who reviewed it, the date of the review, and what happened to the sessions that looked wrong. A tool that collects faithfully and is read by nobody produces AU-6 findings alongside your AC-17 one. Detection of unauthorized connections now lives in SI-4, since that is where AC-17(5) went, so split the story deliberately: AC-17(1) covers the approved methods and their oversight, SI-4 covers the connections you did not approve.

Privileged commands over a remote session

AC-17(4) is the enhancement that catches real programs, and the operative phrase is assessable evidence. Authorizing an administrator to run privileged commands from home is allowed; doing it in a way that leaves nothing an assessor can examine is not. In practice the evidence comes from a jump host or bastion that records command history per session, a privileged access management platform that records the session itself, or a management plane that writes an auditable log of privileged actions with the originating account attached. The enhancement also carries a documentation obligation people skip: the rationale for allowing remote privileged access goes in the system security plan, in words, because someone decided that risk was acceptable and the plan is where that decision lives.

The division of labor is clean once you see it. AC-6 defines who holds privilege and how often you prove you reviewed it, and AC-17(4) defines what the recording has to look like when that privilege is exercised from outside the fence.

Where AC-17 touches the rest of the package

AC-17 has a long related controls list in Rev 5, and five of those relationships generate the cross references you will field in a real assessment:

• AC-2 account management provisions, reviews and disables the very accounts that use remote access, so a terminated user still able to reach the VDI pool is both an AC-2 and an AC-17 problem.
• IA-2 supplies the multifactor requirement for the session itself, and IA-5 covers the certificates and credentials behind it, including the service accounts that quietly hold a tunnel open.
• SC-7 draws the boundary the remote session crosses, and the managed access control point AC-17(3) asks for is normally a device already named in your SC-7 implementation.
• MA-4 governs nonlocal maintenance, which is a remote access type with its own authorization, its own approved method entry, and its own session record.
• AU-6, AU-12 and SI-4 carry the audit and detection half of the monitoring story that AC-17(1) only starts.

Telework is where the paperwork fails, not the technology

The Department of Defense Inspector General looked at exactly this question when the workforce went remote at scale. DODIG-2021-064, dated 29 March 2021, audited whether components kept cybersecurity controls in place through maximum telework. The finding was not that the tunnels were broken. It was that Army, Navy and Air Force personnel teleworked without approved telework agreements or the required telework training, and component officials attributed that to supervisors who were unaware of their responsibilities or consumed by other pandemic duties. The report also recommended that the DoD CIO revise the VPN Security Requirements Guide, and the CIO disagreed without supplying the reasoning the IG asked for.

That shape repeats at the system level. A gateway either enforces TLS 1.2 or it does not. The documentary half of AC-17 has no scanner. If your teleworking population grew faster than your signed agreements, that gap is an AC-17 part a finding with PL-4 and AT-2 riding along, and it will be found by an assessor picking five names off a roster and asking for paperwork.

Stage these before the assessor arrives

Spend an afternoon pulling the set together and the control closes on examination rather than on a follow-up request. The policy, current and signed. The approved methods list with authorizing official and date per type, including vendor maintenance. STIG results for the gateway and the VDI pool with rule IDs and dates. One month of reviewed session reports with a reviewer name on them. The command history or session recording for one privileged remote session, chosen at random by you rather than by the assessor. Sample your own package first and you will find what they would have found, which is the whole point of knowing what assessors actually test in RMF Step 4 before they test it.

The findings you cannot close before the assessment need somewhere to live, with a milestone, a resource estimate and an owner who knows their name is on it, and AC-17 tends to generate the kind of finding that spans two quarters because it waits on a telework agreement cycle or a gateway configuration window. If you are still tracking that in a spreadsheet you rebuild every quarter, my POA&M Tracker is built around the fields an assessor and an authorizing official actually read, so a two quarter remediation still looks deliberate on the day somebody asks.