AC-17: Remote Access

To meet the ac-17: remote access requirement, you must define and document what remote access types you allow (VPN, admin tools, SaaS consoles, vendor support), then enforce specific usage restrictions and connection configurations for each. Your goal is simple: remote access is permitted only through approved, hardened paths with clear, testable rules and retained evidence ¹.

Key takeaways:

• You need per-remote-access-type rules: who can connect, from where, to what, using which method, with which security settings ¹.
• “Documented guidance” must match reality: your policy, diagrams, and system settings must align and be provable in an assessment.
• Evidence is the control: remote access inventories, configurations, approvals, and logs are what auditors ask for first.

AC-17 is an operations control disguised as a documentation control. The text is short, but assessors expect you to show that remote access into your environment is deliberately designed, narrowly allowed, and consistently configured across every remote entry path you permit ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize AC-17 is to treat “remote access” as an inventory problem first, then a standardization problem second. Most organizations fail AC-17 in two common ways: (1) they only document “VPN” and forget browser-based admin access, cloud consoles, vendor support channels, and remote management tooling; or (2) they have a policy, but the technical settings differ by team, system, or business unit, so the evidence doesn’t line up.

This page gives requirement-level implementation guidance you can assign to control owners, convert into configuration baselines, and audit internally. It is written to help you pass an assessment without writing a novel, and to reduce the risk that remote access becomes the easiest path into your environment.

Regulatory text

Requirement (excerpt): “Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and” ¹.

Operator interpretation (what you must do):

1. Identify each type of remote access you allow (not just “VPN”). This includes employee remote access, administrator remote access, third-party support access, and remote access to cloud management planes ¹.
2. For each type, write down three things:
   • Usage restrictions: who may use it, approved endpoints, allowed destinations, prohibited activities, and approval requirements.
   • Configuration/connection requirements: the security settings that must be enforced (authentication method, encryption, session controls, network segmentation, routing, device posture).
   • Implementation guidance: the “how” teams follow so the configuration is repeatable and produces consistent evidence ¹.
3. Ensure what you document matches how access actually works so an assessor can validate by inspection and sampling.

Plain-English interpretation of the requirement

AC-17 expects you to run remote access like a controlled service, not an ad hoc convenience. If remote access is allowed, it must be:

• Explicitly approved by type (example: “User VPN to corporate apps” may be allowed, while “direct RDP from the internet” is prohibited).
• Constrained and hardened with clear technical requirements.
• Repeatable via written guidance so new systems don’t invent their own remote access patterns ¹.

A practical test: if a new IT manager asks, “How do I set up remote admin access to this system?” you should be able to point to a standard with mandatory settings and an approval path. If you can’t, you are not operating AC-17, even if you have a VPN.

Who it applies to

Entity scope:

• Federal information systems and contractor systems handling federal data commonly inherit AC-17 expectations when NIST SP 800-53 is the governing control set ².

Operational scope (where AC-17 shows up in real environments):

• Workforce remote access (VPN, ZTNA, VDI, remote desktop gateways).
• Privileged remote administration (bastion hosts, privileged access workstations, cloud admin portals).
• Third-party remote support (managed service providers, software vendors, incident response retainers).
• Cloud and SaaS administrative access (AWS/GCP/Azure consoles, M365 admin center, security tooling consoles).
• Remote management channels (out-of-band management, device management platforms) when they provide remote entry into enterprise assets.

If it can reach internal resources from outside your controlled network boundary, treat it as in-scope until proven otherwise.

What you actually need to do (step-by-step)

Step 1: Build a “remote access types” inventory (your AC-17 backbone)

Create a table with one row per remote access type you allow. Keep it short but complete.

Minimum columns to include:

• Remote access type name (example: “User VPN”, “Privileged bastion”, “Cloud admin console”, “Vendor support portal”)
• Purpose / business justification
• User populations allowed (employees, admins, vendors)
• Entry method/tool (product + protocol)
• Systems reachable (high level)
• Control owner (IT/SecOps/IAM)
• Evidence source (logs, config screens, tickets)

This inventory becomes your index for the rest of AC-17 ¹.

Step 2: Define usage restrictions per type (policy that can be tested)

For each remote access type, document restrictions that an auditor can sample. Good restrictions are binary.

Examples you can operationalize:

• Allowed roles/groups (IAM groups, RBAC roles).
• Allowed device types (corporate-managed only, or managed + BYOD with defined conditions).
• Allowed source geographies or networks (if you enforce it).
• Allowed destinations (specific subnets/apps; no blanket internal network reach unless justified).
• Prohibited protocols or activities (example: no split tunneling, no direct SSH to production except via bastion, no personal email forwarding from admin consoles).
• Approval requirements for exceptions (who approves, how long exceptions last, where they’re recorded).

Step 3: Set configuration/connection requirements (baseline settings)

Turn “requirements” into a baseline that engineers can implement consistently. Your baseline should cover:

Identity and authentication

• Centralized identity source and group-based authorization.
• Strong authentication requirement appropriate to the access type (document the method you require and where it is enforced).

Network path controls

• Approved ingress points only (no direct exposure of management ports).
• Segmentation and routing constraints (example: user remote access cannot reach admin networks).
• Administrative access forced through a controlled path (example: bastion pattern).

Session controls

• Session timeout/reauthentication expectations.
• Restrictions on concurrent sessions for privileged access where feasible.
• Administrative session recording expectations if you require them (document what you do, and for which access types).

Cryptography/secure channels

• Encryption requirements are implicit in “configuration/connection requirements.” Document the enforced secure transport and where it’s configured.

Keep the language implementable: “must be enforced in [system] configuration,” not “should be secure.”

Step 4: Write implementation guidance that prevents one-off builds

Assessors will look for evidence that teams can follow your standard. Provide short, role-based runbooks:

• Requester guidance: how to request remote access, required justification, required manager/system owner approvals.
• Implementer guidance: exact place to configure (IdP group, VPN profile, firewall object, ZTNA policy), required settings, and testing steps.
• Reviewer guidance: what to check during periodic reviews (enabled accounts, group membership, stale vendor access, unused VPN profiles).

If you use Daydream to manage controls, map AC-17 to a named control owner, link the runbook, and define recurring evidence artifacts so collection is routine instead of scramble-driven ¹.

Step 5: Prove operation with recurring reviews (make it audit-ready)

AC-17 breaks down when remote access grows quietly. Add an operational loop:

• Reconcile your inventory against actual systems (VPN portals, IdP apps, cloud admin roles, remote support tools).
• Review who has access (especially privileged and third-party accounts).
• Validate configuration drift against your baseline.
• Record exceptions and closures.

You don’t need perfect automation. You need repeatable results and retained artifacts.

Required evidence and artifacts to retain

Keep evidence tied to each remote access type. This is what reduces assessment time.

Core artifacts

• Remote access types inventory (table) with owner and scope.
• Remote access standard/policy with per-type usage restrictions (approved by appropriate authority).
• Configuration baselines ¹ and where they are enforced.
• Implementation runbooks or SOPs (request, provisioning, deprovisioning, break-glass, vendor access).
• Network diagrams showing approved remote access ingress and high-level routing/segmentation.
• Access approval records (tickets/workflow) for privileged and third-party remote access.
• Configuration exports/screenshots: VPN profiles, ZTNA policies, IdP conditional access policies, bastion configuration, cloud role assignments (sampled).
• Logging evidence: where remote access logs are generated, where they are stored, and sample queries/screenshots demonstrating availability.

Evidence hygiene tip: name artifacts using the same “remote access type” labels as your inventory. It makes sampling easy and prevents gaps.

Common exam/audit questions and hangups

Assessors tend to probe for coverage across remote access paths and for consistency between paper and reality.

Common questions

• “List all remote access methods into the environment, including cloud admin access and vendor support.”
• “Show usage restrictions for each method. Who can use it, and what can they reach?”
• “Show the configuration requirements and where they’re enforced.”
• “Provide implementation guidance: how does a system owner request/enable remote access?”
• “How do you prevent direct exposure of admin interfaces to the internet?”
• “Show evidence that remote access is logged and reviewed.”

Typical hangups

• “We only documented VPN” but engineers also use direct SaaS admin portals and remote support tools.
• “The policy says X” but the VPN/ZTNA profile allows broader access.
• Third-party access has no clear sponsor, no end date, and no review trail.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-17	Fix
Defining “remote access” as only VPN	Leaves cloud consoles, remote admin tools, and vendor channels unmanaged	Build the remote access types inventory first, then map controls per type 1.
One policy, no per-type rules	AC-17 asks for guidance “for each type”	Write one standard with per-type sections, or separate standards per type.
“Secure configuration” without specifics	Not testable; engineers can’t implement consistently	Convert requirements into baselines with named enforcement points (IdP policy, VPN profile, firewall rule).
Third-party remote access treated as informal	Highest likelihood of orphaned accounts and unclear scope	Require a sponsor, explicit scope, and documented disablement path; keep tickets and reviews.
Evidence scattered across tools	Hard to prove operation during audits	Define recurring evidence artifacts and store them centrally; Daydream can track control ownership and evidence cadence 1.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AC-17 primarily as an assessment and breach-exposure control rather than a “find a fine” control in this context.

Risk-wise, remote access is a common initial access path. AC-17 reduces that exposure by forcing you to constrain entry points, standardize settings, and maintain proof that the controls are real. The practical risk implication of weak AC-17 is simple: you will discover unknown remote access paths during an incident, not during a review.

Practical 30/60/90-day execution plan

First 30 days (stabilize and inventory)

• Assign a single AC-17 owner in GRC with named technical owners per remote access type.
• Produce the remote access types inventory, validated by IAM, network/security engineering, and IT operations.
• Identify any “unknown or unmanaged” remote access paths and decide: approve and standardize, or shut down.
• Draft the per-type usage restrictions and get sign-off from system owners.

Days 31–60 (standardize configurations and guidance)

• Convert restrictions into enforceable baselines per remote access type.
• Publish short runbooks: request, approve, implement, revoke, and exception handling.
• Align documentation to reality by sampling configurations and closing gaps.
• Centralize evidence collection locations (shared repository or GRC evidence store) and define what gets captured.

Days 61–90 (operate, test, and make it audit-ready)

• Run an internal “mini-assessment” for AC-17: pick samples from each remote access type and prove the chain from policy → configuration → access records → logs.
• Establish recurring review routines for access lists and configurations, with tracked outcomes.
• If you use Daydream, map AC-17 to owners, attach procedures, and schedule recurring evidence tasks so the next audit is a routine export, not a fire drill ¹.

Frequently Asked Questions

What counts as “remote access” under AC-17?

Treat any access path from outside your controlled internal network into systems or administrative functions as remote access. That includes VPN, ZTNA/VDI, cloud/SaaS admin consoles, and third-party support tools ¹.

Do we need a separate policy for each remote access tool?

No. You need documented usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed. One standard with clearly separated per-type sections is usually easiest to operate ¹.

How do we handle vendors or other third parties needing remote access?

Define a dedicated remote access type for third-party access with stricter restrictions: named sponsor, explicit scope, defined method, and documented disablement. Retain approvals and access logs as primary evidence.

What’s the minimum evidence to pass an AC-17 assessment?

Expect to show (1) your remote access types inventory, (2) per-type restrictions and baselines, (3) implementation guidance/runbooks, and (4) samples of actual configurations and logs that match what you documented ¹.

We have multiple business units with different remote access setups. How do we document AC-17 without rewriting everything?

Start with a single inventory that lists each allowed type and owner per unit, then standardize the baseline controls that must be consistent. Document exceptions explicitly, with approvals and scope, instead of letting differences remain informal.

How does AC-17 relate to other NIST access controls?

AC-17 focuses on remote access conditions by type. You typically pair it with broader access control governance (account management, least privilege, logging/monitoring) so restrictions are enforceable and reviewable ².

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5