Safeguard
Security Guides•

Remote access policy: what to require and what to approve first

A remote access policy defines each allowed access type, approves it before use, and requires encryption, managed entry points and monitoring.

Safeguard Security Team
3 min read

A remote access policy lists each way people may reach company systems from outside, approves each before use, and requires encryption, managed entry points, monitoring, and the ability to cut access fast. Anything not on the approved list is not allowed.

What the control says

NIST SP 800-53 AC-17 asks organisations to define and document rules, connection requirements and implementation guidance for each type of remote access they allow, and to approve each type before any connection is permitted. Remote access here means reaching systems from outside networks such as the internet. Public web servers built for public access are out of scope.

Step 1: list the access types

Typical entries: VPN to the corporate network, browser access to SaaS through single sign-on, SSH or database access to production through a bastion or access proxy, remote desktop for support, and vendor access.

For each, record who may use it, from which devices, with what authentication, and what it reaches.

Step 2: set the connection requirements

Common requirements:

  1. Strong authentication. Multi-factor, ideally phishing-resistant for admin access. See which MFA to require.
  2. Encryption. AC-17(2) describes cryptography protecting confidentiality and integrity of remote sessions.
  3. Managed entry points. AC-17(3) describes routing connections through managed access control points. One gateway is easier to monitor than ten.
  4. Device conditions. Managed or compliant devices for sensitive access, such as disk encryption and current updates.
  5. No direct exposure. Production management ports should not be open to the internet.

The control notes that VPNs are a common safeguard, though they do not improve availability and can make inspection for malicious code harder. A VPN is a tool, not a policy.

Step 3: monitor and limit

AC-17(1) describes automated monitoring and control of remote access methods. Log connections and privileged sessions. AC-17(4) says privileged commands and access to security-relevant information remotely should be allowed only for defined needs, with the justification recorded.

Alert on impossible travel, new devices for admins, and access at odd hours.

Step 4: have a kill switch

AC-17(9) describes being able to disconnect or disable remote access within a defined timeframe. Decide who can do this and how fast, then try it. During an incident you need to cut an account or a whole method quickly. See joiner, mover, leaver procedure.

Step 5: handle vendors separately

Third-party access should be named, time-limited, logged and scoped to the systems needed. For control system contexts see securing vendor remote access.

Pitfalls

  • Shared remote desktop passwords.
  • A forgotten test VPN profile with broad access.
  • Exemptions for executives.
  • Split tunnelling decisions made without anyone owning them.

Safeguard's asset discovery can help find exposed or forgotten remote entry points. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Do we need a VPN?

Not necessarily. Single sign-on to SaaS and an access proxy for servers can replace it. The policy should state which methods are approved and why.

Who approves a new remote access method?

The security owner, before anyone connects. That is the point of the approval rule.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.