AC-17(3): Managed Access Control Points

To meet the ac-17(3): managed access control points requirement, you must force all remote access (users, admins, third parties, and remote services) to traverse approved, centrally managed access control points (for example, VPN gateways, ZTNA brokers, or bastion hosts), and block any “direct-to-internal” remote paths. Document the approved paths, enforce them technically, and keep evidence that remote sessions cannot bypass them. ¹

Key takeaways:

• Route every remote connection through a small set of approved gateways/brokers you manage and monitor. ¹
• Treat “remote access” broadly: workforce, admins, contractors, third parties, and remote management services.
• Auditors expect proof of enforcement (network controls), not just a policy statement.

AC-17(3) is a remote-access architecture requirement disguised as a single sentence. If your environment allows users or third parties to connect “straight in” to internal networks or workloads (for example, direct RDP/SSH from the internet, ad hoc port forwards, unmanaged remote desktop tools, or cloud security groups open to the world), you will struggle to show compliance.

Operationally, you are building a choke point (or a small set of choke points) for remote access. Those choke points must be authorized (explicitly approved, documented, and owned) and managed (centrally configured, monitored, logged, and maintained). Your job as a Compliance Officer, CCO, or GRC lead is to translate that into: (1) a clear remote access standard, (2) technical enforcement that prevents bypass, and (3) repeatable evidence that remote access is consistently routed through those control points.

This page gives you a requirement-level implementation recipe: scoping, design decisions, step-by-step execution, the evidence set to retain, audit questions you will get, and the implementation traps that create “policy-compliant but technically noncompliant” outcomes.

Regulatory text

Requirement (excerpt): “Route remote accesses through authorized and managed network access control points.” ¹

What the operator must do:
You must (a) identify which network entry points are approved for remote access, (b) ensure remote access can occur only through those entry points, and (c) manage those entry points as controlled infrastructure (standard configuration, change control, monitoring, logging, patching, access administration). Any remote access path that bypasses the approved control points violates the intent of AC-17(3). ¹

Plain-English interpretation

AC-17(3) means: remote access gets funneled through gateways you control. If someone can reach an internal system remotely without passing through your managed access layer, you have a bypass path.

“Access control points” can be physical or logical. Common patterns:

• VPN concentrators or remote access gateways
• ZTNA / identity-aware proxies
• Bastion/jump hosts for administrative access
• VDI gateways
• Managed reverse proxies for published internal apps

The control is less about the brand of tool and more about centralizing control and visibility so you can enforce authentication, authorization, session constraints, logging, and inspection in one place.

Who it applies to

Entity types and environments

• Federal information systems and contractor systems handling federal data. ¹
• Also commonly inherited into programs that map to NIST SP 800-53 Rev. 5 as a baseline (for example, when required by a customer contract or internal policy aligned to NIST). ²

Operational contexts in scope

• Workforce remote access (employees connecting from home/travel)
• Privileged administrator remote access (infra, cloud, DB, security tools)
• Third-party remote access (MSPs, incident response firms, SaaS support engineers, contractors)
• Remote access by services (automation, remote management agents, CI/CD runners) when they initiate connections into protected networks

Key scoping decision: define “remote” as “originating outside your controlled network boundary,” including the public internet and external networks, not just “working from home.”

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

1) Establish the approved remote access architecture (design + ownership)

1. Name your authorized control points: list the specific systems/services that are the only allowed remote access entry paths (for example, “Corporate ZTNA broker,” “Admin bastion cluster,” “VPN gateway X”).
2. Assign a control owner for AC-17(3) and technical owners for each control point (network/security engineering).
3. Define allowed remote access methods by use case:
   • End-user access to apps
   • Admin access to servers/cloud consoles
   • Third-party access to scoped resources

Deliverable: a one-page “Remote Access Standard” that states the rule in enforceable terms: “No inbound remote administrative protocols from the internet; all remote sessions must traverse approved access points.” Tie this directly to AC-17(3). ¹

2) Inventory and map every remote access path

Build (and keep current) an inventory that answers:

• Who connects remotely (user groups, admins, third parties)?
• From where (internet, partner networks)?
• To what (apps, subnets, management planes)?
• Through what path today (VPN, direct exposure, remote tools, cloud SG rules)?

Practical methods:

• Firewall rule review for inbound exposure
• Cloud perimeter review (security groups, NACLs, load balancers, public IPs)
• Endpoint tooling review (remote control agents, remote admin tools)
• Identity logs for remote sign-ins and app access

Output: “Remote Access Data Flow Map” showing the enforced choke points.

3) Eliminate bypass paths (this is the exam-maker)

For each bypass path, choose a remediation pattern:

• Block direct inbound (close ports, remove public IPs, restrict security groups)
• Force through gateway (publish via reverse proxy/identity-aware proxy)
• Require bastion for admin protocols (no direct SSH/RDP; only from bastion subnet)
• Replace unmanaged remote tools with approved remote access stack
• Constrain third-party access to brokered, time-bound, logged sessions via the control point

Your goal is binary: either the path goes through an authorized control point or it does not exist.

4) Configure the control points as “managed”

“Managed” should be evidenced as operational discipline:

• Standard build configuration (hardened baseline)
• Central authentication and authorization
• Logging enabled and forwarded to your monitoring stack
• Change control for config updates
• Patch/vulnerability management coverage
• Break-glass access controls for the control point itself

If you run multiple gateways, standardize them. Auditors often interpret “managed” as “consistently administered and monitored,” not “someone occasionally logs in and changes settings.”

5) Prove enforcement with technical controls

Policy is not enough. You need enforceable mechanisms:

• Network segmentation rules that prevent remote-to-internal except from gateway/bastion networks
• Cloud controls that prevent public exposure of admin interfaces
• Conditional access / identity policies that restrict access to only the brokered apps
• Route controls (where applicable) that ensure remote paths traverse the inspection point

A good internal test: attempt to connect to a representative internal target from an external network without using the approved remote access method. That attempt should fail.

6) Operationalize: recurring reviews, monitoring, exceptions

• Recurring access path review: confirm no new public exposures or alternate remote tools appeared.
• Monitoring: alerts for direct exposure, new inbound rules, unusual remote login patterns, and control-point health.
• Exception process: tightly scoped, time-bound, compensating controls, explicit approval, and documented rollback plan.

7) Package the control for assessment readiness (what most teams forget)

Map AC-17(3) to:

• Control owner
• Implementation procedure
• Recurring evidence artifacts (what you collect, how often, from where)

This is explicitly aligned to the provided best-practice guidance to map AC-17(3) to ownership, procedure, and recurring evidence. ¹

If you track controls in Daydream, treat AC-17(3) as a requirement with: (1) a single authoritative architecture diagram, (2) a standard evidence checklist, and (3) automated reminders tied to your change cycles so evidence stays fresh.

Required evidence and artifacts to retain

Keep evidence that shows design, enforcement, and operation:

Design / authorization

• Remote Access Standard naming authorized access control points
• Network/data flow diagram showing remote access routing through control points
• Inventory of remote access methods and users (including third parties)

Technical enforcement

• Firewall rules / security group configs showing blocked direct inbound access
• Bastion/ZTNA/VPN configuration snippets demonstrating routing constraints
• Screenshots/exports showing published apps go through proxy/broker, not direct exposure
• Results of a bypass test (documented attempt + failure evidence)

Operations (“managed”)

• Logging configuration and sample logs for remote sessions through control points
• Change records for gateway/bastion configuration
• Patch/vulnerability management records for the control points
• Monitoring/alerting configuration for remote access anomalies

Common exam/audit questions and hangups

Auditors and assessors typically probe these points:

• “Show me all ways an administrator can access production remotely.” Expect scrutiny of SSH/RDP exposure and cloud management plane access paths.
• “Can a third party connect without going through your approved method?” They will ask about support tools, remote desktop products, and temporary firewall openings.
• “Where are the logs, and are they complete?” They want proof that remote sessions are visible at the control point.
• “How do you prevent new bypass paths?” They will look for cloud guardrails and periodic exposure reviews.

Hangup to anticipate: teams document “VPN required,” but a few cloud instances still have public IPs and open management ports. That is a straightforward AC-17(3) gap because access can bypass the managed control point.

Frequent implementation mistakes and how to avoid them

1. Defining the control point too broadly (“the internet perimeter”).
   Fix: name specific systems/services as the only allowed entry points and show their configurations.
2. Leaving “temporary” inbound rules in place.
   Fix: require expiry and automated detection for public exposures; require post-change validation.
3. Allowing third parties to use their own remote tools.
   Fix: mandate brokered access through your control point, with scoped authorization and session logging.
4. Treating cloud console access as out of scope.
   Fix: include identity-based remote access paths (SSO/IdP to management planes) in your remote access mapping.
5. No evidence of “managed.”
   Fix: retain runbooks, change records, log forwarding proof, and monitoring configurations for the gateways/bastions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement, so this page avoids case claims.

Risk-wise, unmanaged or bypassable remote access paths are a common root cause pattern in security incidents: they create blind spots for authentication controls, logging, and rapid containment. AC-17(3) reduces that exposure by concentrating remote access into a controllable surface area. ¹

Practical 30/60/90-day execution plan

Days 0–30: Establish control points and kill obvious bypass

• Assign AC-17(3) control owner and technical owners.
• Publish a Remote Access Standard naming authorized access control points.
• Inventory all current remote access paths (workforce, admin, third party).
• Remediate high-risk exposures immediately (for example, direct inbound admin ports, ad hoc remote tools).
• Start a central evidence folder: diagrams, inventories, key configs, and log samples.

Days 31–60: Enforce routing and harden “managed” operations

• Implement network segmentation so only control point subnets can reach admin interfaces.
• Standardize gateway/bastion configurations, logging, and access administration.
• Implement monitoring for new exposure and control point health.
• Build the exception workflow for any nonstandard remote access.

Days 61–90: Prove repeatability and assessment readiness

• Run bypass testing and document results.
• Conduct an internal audit-style walkthrough using your evidence checklist.
• Formalize recurring evidence capture (config exports, log samples, access reviews).
• In Daydream (or your GRC system), map AC-17(3) to owner, procedure, and recurring evidence artifacts so it stays “evergreen” for assessments. ¹

Frequently Asked Questions

Does AC-17(3) require a VPN?

No. It requires remote access to be routed through authorized, managed access control points, which can be VPN, ZTNA, bastions, or similar patterns. Your evidence must show remote sessions cannot bypass those points. ¹

Are SaaS applications “remote access,” and do they need an access control point?

If users access SaaS directly, AC-17(3) is usually addressed through identity control points (IdP/SSO, conditional access) rather than network gateways. Document the authorized access path and show it is centrally managed and logged.

How do I handle emergency admin access if the bastion is down?

Define a break-glass process with explicit approval, tight scope, and strong logging, then treat it as an exception with post-event review. Auditors will accept controlled exceptions more readily than undocumented workarounds.

What about third parties that insist on direct SSH/RDP to “their” system?

Require third-party remote access through your approved control point, and give them scoped access to only what they support. If they refuse, treat it as a contracting and risk decision, document the exception, and add compensating controls.

Do I need to route remote access through a single gateway, or can I have multiple?

Multiple is fine if each is explicitly authorized, consistently managed, and you can show there is no alternate bypass route. Keep the list short and document ownership and configuration baselines.

What evidence is most convincing to an assessor?

A current remote access architecture diagram plus objective enforcement proof: firewall/security group rules blocking direct inbound, bastion-only admin pathways, and log samples showing sessions traversing the control point. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5