Remote Access | Managed Access Control Points

To meet the Remote Access | Managed Access Control Points requirement, you must force all remote connections (users, admins, and systems) to enter through approved, centrally managed access points (for example, a VPN gateway, ZTNA broker, or bastion host) and block any “side door” paths. The goal is one controllable choke point for authentication, authorization, logging, and session controls. ¹

Key takeaways:

• Route remote access through authorized, managed gateways; eliminate direct-to-host remote paths. ¹
• Treat “managed” as enforceable configuration, monitoring, and change control, not a diagram. ¹
• Your audit win condition is evidence that only those control points can broker remote access, plus logs proving they did. ¹

“Managed access control points” is a design requirement masquerading as an access control detail. If your environment allows remote access from the internet (or from uncontrolled networks) to reach internal systems directly, you have multiple enforcement surfaces: inconsistent MFA, inconsistent logging, ad hoc firewall exceptions, and remote tooling that lives outside your normal oversight. AC-17(3) pushes you to concentrate that risk into a small number of approved entry points that are owned, configured, monitored, and change-controlled by the organization.

Operationally, this requirement is about creating a small set of “front doors” for remote access and closing everything else. It applies to workforce remote access (employees and contractors), privileged administrative access, and system-to-system remote administration paths (for example, remote management of cloud consoles, hypervisors, databases, and network devices). It also intersects with third-party access: if a third party can reach your environment remotely, that traffic still needs to traverse your managed control points.

For FedRAMP and NIST-aligned programs, assessors will look for two things: (1) architectural enforcement (remote access cannot bypass the gateway), and (2) operational management (the gateway is actually administered as a controlled security service). ¹

Regulatory text

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

What an operator must do: You must define which network access control points are approved for remote access, make them the only viable path into protected networks/systems for remote sessions, and manage them as controlled infrastructure (secure configuration, monitored logging, and governed change). “Remote access” includes user remote access and administrative remote access. ¹

Plain-English interpretation

You need a small set of controlled “choke points” for remote access, and you need proof that remote access routes through them. If someone can RDP/SSH/API-admin a system from the internet (or from an unmanaged network) without going through your sanctioned gateway, you have not met the requirement.

Think of the control point as the place where you consistently enforce:

• Identity checks (SSO, MFA, device posture if applicable)
• Authorization (group/role-based access, just-in-time where feasible)
• Session controls (timeouts, re-auth, jump-host routing for admins)
• Logging and alerting (who accessed what, from where, and when)

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating NIST SP 800-53 control baselines or FedRAMP-aligned programs. ¹

Operational contexts where it shows up:

• Workforce remote access to internal apps and admin tools
• Privileged access into production networks (bastion/jump servers)
• Remote access to cloud management planes (console access, kubectl, database admin)
• Third-party remote access (support, managed services, incident response retainers)
• Remote administration by automation (CI/CD runners, remote orchestration)

If remote access exists anywhere in scope, assessors will expect documented, enforced routing through your managed access control points. ¹

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

1) Define “remote access” and scope the pathways

Create a remote access inventory that answers:

• Who connects remotely (employees, contractors, third parties, service accounts)
• From where (internet, home networks, partner networks, mobile devices)
• To what (internal apps, admin endpoints, cloud consoles, production subnets)
• How (VPN, SSH, RDP, VDI, ZTNA, remote management tools)

Deliverable: a living “Remote Access Pathways Register” tied to systems in your SSP/control narrative. ¹

2) Declare your authorized managed access control points

Pick the supported entry mechanisms and name them explicitly. Examples (choose what fits your architecture):

• VPN concentrators / gateways
• ZTNA access brokers
• Bastion hosts/jump boxes for SSH/RDP
• VDI gateways for full desktop access
• Remote access proxies for admin interfaces

Document for each control point:

• Owner team and on-call
• Configuration baseline
• Identity provider integration and MFA enforcement
• Logging destinations and retention alignment to your program needs (avoid guessing; align to your documented logging standard)

Deliverable: “Authorized Remote Access Control Points Standard.” ¹

3) Enforce routing: eliminate bypass paths (“close the side doors”)

This is the technical heart of AC-17(3). Typical enforcement actions:

• Network controls: Security groups, NACLs, firewall rules that only allow management ports (SSH/RDP/admin UIs) from the bastion/VPN/ZTNA egress IP ranges.
• Private connectivity: Put admin endpoints on private subnets; avoid public IPs on systems that should never be directly reachable.
• Conditional access: Require access via managed broker (IdP + ZTNA) rather than direct exposure.
• Service controls: Disable direct remote management features that provide alternate tunnels unless they are integrated into your managed control point approach.

Acceptance criteria you can test:

• A remote user on the internet cannot reach admin ports directly.
• A remote admin cannot authenticate to a production host without transiting the bastion or broker path.
• Logs show the control point as the session initiator/mediator.

Deliverable: firewall/security group rule sets, plus a test record demonstrating failed bypass attempts. ¹

4) Make the control points “managed” in the audit sense

A managed control point has governance and operational rigor:

• Configuration management: Baseline configuration, hardening, versioning, documented changes.
• Access management: Admin access to the gateway itself is restricted and reviewed.
• Monitoring: Centralized logging and alerting for remote access events and failures.
• Capacity and resilience: Document how you prevent single points of failure from becoming a business blocker (the requirement does not mandate an architecture pattern, but auditors will ask about operational risk).

Deliverable: runbooks, change records, monitoring dashboards/alerts, and access reviews for gateway administrators. ¹

5) Align third-party remote access to the same entry points

Third parties often create the most persistent bypasses (temporary exceptions that never expire). Require that:

• Third-party remote access uses your authorized control points.
• Third-party identities are managed in your IdP (or federated with explicit controls).
• Contracts/SOWs prohibit unsanctioned remote tooling into your environment.

Deliverable: third-party access procedure + evidence of an enforced access method (for example, named group access to ZTNA app segments or a dedicated bastion path). ¹

6) Document the control narrative (what the assessor will read)

Write a tight control description that maps:

• Authorized control points (names, locations, ownership)
• Technical enforcement (how bypass is prevented)
• Logging/monitoring (what is captured, where it goes)
• How exceptions are handled (ideally: rare, time-bound, approved)

If you use Daydream to manage evidence collection, assign this requirement to the network/security owner and attach the current network diagrams, gateway configs, and a quarterly bypass-validation test result as recurring evidence tasks.

Required evidence and artifacts to retain

Keep evidence that proves both design and enforcement:

Policy/standards

• Remote Access Policy (or section in Access Control Policy) referencing authorized control points ¹
• Standard for “Authorized Remote Access Control Points” with ownership and configuration requirements ¹

Architecture & configuration

• Network diagrams showing remote access flows and control points ¹
• Gateway/bastion/connector configuration exports or screenshots (sanitized) ¹
• Firewall/security group rule evidence restricting admin ports to control point sources ¹

Operational records

• Central log samples showing remote sessions transiting the control point ¹
• Change tickets for gateway configuration changes ¹
• Access review evidence for gateway administrators and remote access groups ¹
• Exception approvals (time-bound) with compensating controls, if any exist ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me all approved remote access methods and where they’re documented.” ¹
• “Prove a user cannot SSH/RDP to production without going through the bastion or broker.” ¹
• “How do you prevent engineers from opening temporary firewall rules to their home IP?” ¹
• “Where are remote access logs stored, and who reviews alerts?” ¹
• “How does third-party support access your environment, and can they bypass your gateway?” ¹

Hangup: teams provide a diagram but can’t prove enforcement. Your strongest answer is a combination of restrictive rules plus a recorded negative test (bypass attempt blocked) and a corresponding log event.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AC-17(3)	How to avoid
Public IPs on admin endpoints “for convenience”	Creates direct remote paths that bypass the managed control point	Put admin interfaces in private networks; require bastion/VDI/ZTNA paths 1
Multiple remote tools adopted by different teams	Fragments enforcement and logging	Standardize on a short list of authorized control points; deprecate the rest with deadlines and owners 1
“Temporary” firewall exceptions that never expire	Becomes an unmanaged access point	Use time-bound rules, approval workflow, and automated cleanup; review exceptions routinely 1
Bastion exists, but hosts still allow direct SSH/RDP from wide ranges	The bastion is optional, not enforced	Restrict inbound management ports to bastion/VPN/connector egress addresses only 1
No ownership of gateways (shared responsibility blur)	“Managed” requires accountable operations	Name an owner, set change control, and maintain runbooks and monitoring 1

Risk implications (why assessors care)

Remote access is a common path for credential misuse, lateral movement, and operational surprises because it crosses trust boundaries. Concentrating remote entry through managed control points gives you consistent authentication, better session visibility, and fewer places to miss critical hardening. AC-17(3) is a forcing function for reducing remote “shadow paths” that undermine your access control program. ¹

Practical execution plan (30/60/90-day)

Use phases instead of day counts if your environment is large, but keep the work sequenced.

First 30 days (Immediate)

• Inventory remote access paths; identify any direct-to-host exposure.
• Name authorized access control points and owners.
• Freeze creation of new remote access methods without security review.
• Start collecting baseline evidence (diagrams, current rules, gateway configs). ¹

Next 60 days (Near-term)

• Implement enforcement: restrict admin ports to gateway/bastion sources; remove public exposure where feasible.
• Centralize remote access logs from the control points into your logging platform.
• Stand up a repeatable exception process with approvals and expiration.
• Bring third-party remote access into the standard pattern. ¹

Next 90 days (Stabilize and prove)

• Run bypass validation tests and document results (blocked attempts + logs).
• Conduct an access review for remote access groups and gateway admins.
• Finalize the control narrative and evidence map for your assessment package.
• Operationalize ongoing checks in Daydream: scheduled evidence pulls, owner attestations, and exception tracking. ¹

Frequently Asked Questions

Does AC-17(3) mean we must use a VPN?

No. The requirement is to route remote access through authorized, managed access control points; a VPN is one option, and ZTNA or bastion-based patterns can also satisfy it. Pick the approach you can enforce and manage consistently. ¹

What counts as an “access control point” in cloud environments?

Common examples include VPN gateways, ZTNA brokers/connectors, bastion hosts, and controlled VDI gateways. The key is that the component is authorized, centrally managed, and the only route permitted for remote access. ¹

We allow SSH to certain hosts from specific corporate IP ranges. Is that compliant?

It can be, if those corporate IP ranges are themselves an authorized, managed control point and remote users must enter through it (for example, corporate VPN egress). Auditors will still expect proof that other sources cannot connect. ¹

How do we handle emergency break-glass remote access?

Treat it as a controlled exception: route through the same managed control point if possible, restrict who can activate it, and retain activation approvals and session logs. Avoid “break-glass” paths that bypass the chokepoint entirely. ¹

Do third parties have to use our remote access gateway?

Yes, if they remotely access in-scope systems. Their access should route through your authorized and managed control points, with identities governed and sessions logged like any other remote user. ¹

What’s the simplest evidence package for an assessor?

Provide a remote access standard naming authorized control points, a diagram of enforced flows, firewall/security group rules that block bypass, and log samples showing remote sessions transiting the gateway. Add one documented bypass test to prove enforcement. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5