Remote Access Policy Template: Approved Methods, MFA and Third-Party Access

A single valid password on a VPN, Citrix or remote desktop gateway without MFA has been enough to start major ransomware incidents, with no exploit needed. This template gives you a remote access policy that closes those gaps. It sets out which remote access methods are approved, how users and devices authenticate, how dormant and shared accounts are prevented, and how vendors, managed service providers and remote support tools are controlled. It is written for security, IT operations and risk teams. Adapt the placeholders, then have it reviewed by legal, HR and compliance before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [CISO] and [30 days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Place this policy beneath your information security policy, next to the Access Control Policy Template, the Third-Party Access Policy Template and the BYOD Policy Template.

1. Purpose

This policy sets the requirements for connecting to [Organisation] systems, networks, applications and data from any location outside [Organisation]'s managed premises networks, and for remote administration of [Organisation] systems by staff and third parties. Its aim is that every remote session uses an approved method, an identified person or workload, a compliant device and least privilege, and is logged well enough to investigate misuse.

2. Scope

This policy applies to:

• All employees, contractors, temporary staff, consultants, vendors, managed service providers (MSPs) and other third parties who access [Organisation] resources remotely.
• All remote access methods, including zero trust network access (ZTNA), virtual private networks (VPN), virtual desktop and published application services (VDI, DaaS, Citrix, Remote Desktop Services), remote desktop protocol (RDP) and SSH gateways, bastion hosts, browser-based access to internal applications, and remote monitoring and management (RMM) and remote support tools.
• Corporate-owned devices and, where permitted by the BYOD Policy, personally owned devices used for remote access.
• Non-human identities that connect remotely, such as service accounts, integration accounts and automation used by third parties.
• Remote access to operational technology (OT), also subject to [OT remote access standard].

3. Roles and responsibilities

4. Policy statements

4.1 Approved remote access methods

1. Remote access must only be made through methods listed in the [remote access method register], which records each method, its owner, permitted user groups and the systems it reaches.
2. Per-application access through [approved ZTNA, VDI or identity-aware proxy service] is the default method for new remote access requirements. Full network-level VPN access should be limited to [user groups with a documented need].
3. Internet-facing remote access gateways must be patched at the highest priority tier of the [Vulnerability Management Policy].
4. Remote desktop protocol (RDP, TCP 3389), SSH (TCP 22), SMB and database ports must not be exposed directly to the internet. They must be reached only through an approved gateway or bastion.
5. Remote access sessions must be encrypted in transit using protocols and configurations defined in the [Cryptography Standard].
6. Any remote access method not in the register, including personal remote desktop software and unsanctioned tunnels, is prohibited.

4.2 Authentication and MFA

1. All remote access by people must require multi-factor authentication (MFA) through [identity provider], without exception for legacy, backup or emergency gateways.
2. Remote access to administrative interfaces, privileged accounts and systems holding [Confidential] or higher data must require phishing-resistant MFA, such as FIDO2 security keys, platform passkeys or certificate-based authentication.
3. Remote access platforms must use single sign-on to [identity provider]. Local accounts on gateways must be limited to documented break-glass accounts held under section 4.3.
4. Re-authentication must be required after [8 hours] of session lifetime and after [30 minutes] of inactivity, and for privileged actions after [1 hour].
5. Repeated failed logins and unexpected MFA push requests must alert [Security operations].

4.3 Accounts: no shared, generic or dormant access

1. Every remote access account must belong to one named individual or one registered non-human identity with a named owner. Shared and generic accounts must not be used for remote access.
2. Administrative work must use a separate administrative account, not the user's everyday account.
3. Remote access entitlements must be removed on the leaver's last working day, and within [4 hours] of a dismissal or a confirmed compromise.
4. Remote access accounts with no successful login for [45 days] must be disabled automatically and deleted after a further [45 days] unless re-justified by the owner.
5. Break-glass accounts must be stored in [approved password vault], monitored on every use and tested [quarterly].
6. Non-human identities used for remote connections must use certificates or short-lived tokens rather than static passwords where the platform supports it.

4.4 Device requirements

1. Full remote access must only be permitted from corporate-managed devices that meet [device compliance standard], including supported operating system, current patches, disk encryption, endpoint detection and response (EDR) and host firewall.
2. The device condition must be checked at sign-in by the identity provider or access broker, not only at enrolment.
3. Personally owned and unmanaged devices may only use [browser-based VDI, enterprise browser or app-protected access] as defined in the BYOD Policy, with download, print and clipboard restrictions.

4.5 Least privilege and segmentation

1. Remote users must be granted access only to the applications or network segments required for their role.
2. Remote access must not land users on networks that reach domain controllers, backup systems, hypervisor management or OT networks, unless the role requires it and [CISO] approves.
3. Privileged remote access must go through [privileged access management solution] with session recording and, for production systems, just-in-time elevation.

4.6 Third-party and vendor access

1. Third-party remote access must be requested by a business sponsor, approved by [system owner], time-bound to the engagement (no longer than [90 days] before re-approval) and recorded in the [third-party access register].
2. Third parties must use named individual accounts issued or federated by [Organisation]. Vendor-held shared accounts are prohibited.
3. Vendor access should be enabled on request for the duration of a task and disabled afterwards, rather than being always on.
4. All third-party privileged sessions must be brokered and recorded.
5. Contracts with vendors and MSPs that hold remote access must require MFA for their staff, notification of suspected incidents within [24 hours], prompt notice of staff leavers, no reuse of administrative credentials across customers, and [Organisation]'s right to audit access logs.
6. MSP accounts must be treated as privileged accounts and monitored as such.

4.7 Remote support and RMM tools

1. Only remote support and RMM tools listed in the [approved software list] may be installed or run. All others, including portable versions that run without installation, must be blocked through application control.
2. Each approved tool must be configured for SSO and MFA, with unattended access disabled unless approved for the specific device group.
3. RMM roles must be least privilege (for example read-only monitoring for routine work). Actions that push scripts or commands to [10] or more devices must require re-authentication.
4. RMM tools must not have the rights to modify or delete security logs.

4.8 Logging and session control

1. Every remote access platform must log authentication results, MFA method, device identifier and compliance state, source IP address, session start and end, and resources accessed, and forward logs to [SIEM] within [5 minutes].
2. Remote access logs must be retained for at least [12 months].
3. [Security operations] must be able to terminate any remote session and revoke its tokens within [15 minutes] of a decision to do so.

5. Exceptions

Exceptions must be requested by the system owner or business sponsor using [exception form], risk assessed by [Security team] and approved by [CISO] (or [risk committee] where the residual risk is rated [High]). Each exception must record the requirement that cannot be met, the compensating controls (for example IP allow-listing, session recording, additional monitoring), an owner and an expiry date no later than [6 months]. Exceptions to section 4.2.1 (MFA on all remote access) must not be granted for internet-facing access.

6. Compliance and monitoring

[Security team] will measure compliance with this policy at least [monthly] and report to [risk committee] [quarterly]. Measures include:

Non-compliant accounts, devices or tools may be disabled without notice. Breaches of this policy by staff may be handled under [disciplinary procedure]; breaches by third parties under the relevant contract.

7. Review and approval

This policy is owned by [CISO], approved by [approving body] and reviewed at least annually, or sooner after a significant incident, a change of remote access platform or a change in regulatory requirements.

Implementation guidance

Why the core rules exist

• MFA on every path, including legacy ones: at Colonial Pipeline, attackers used a leaked password on a dormant legacy VPN profile that had never been disabled and did not require MFA. Read the Colonial Pipeline Ransomware Attack 2021 analysis. At Change Healthcare, a Citrix remote access portal without MFA let attackers in with one compromised credential. See the Change Healthcare Breach 2024. Sections 4.2.1 and 4.3.4 address these patterns directly.
• Contractor devices and stolen credentials: in the Snowflake campaign, infostealer credentials, some from contractors' laptops, worked because accounts had no MFA and no network allow lists. See the Snowflake Breach 2024.
• Remote support tools as attack tools: CISA, NSA and MS-ISAC advisory AA23-025A describes phishing campaigns that used portable versions of legitimate remote support software, run without installation or administrator rights. The joint Guide to Securing Remote Access Software recommends auditing which tools are authorised, application allowlisting that covers portable executables, blocking common RMM ports at the perimeter and treating MSP accounts as privileged. See the RMM Tool Security Guide.

Choosing between remote access methods

A small organisation with one VPN can meet most of this policy with SSO and MFA on the VPN, device compliance checks and a monthly dormant account report. Larger organisations should move from network VPN to per-application access as gateways are renewed. See the ZTNA Guide, the SASE and SSE Guide and the VPN Security Guide.

Rolling it out

1. Inventory first: list every internet-facing remote access path, VPN profile, gateway local account and remote support tool seen by EDR, including forgotten backup gateways.
2. Close MFA gaps: put each gateway behind the identity provider. In Microsoft Entra Conditional Access, for example, use the grant controls "Require authentication strength" and "Require device to be marked as compliant", and start each new policy in report-only mode before enforcing.
3. Remove dormant and shared access: run the dormant account report, disable accounts past the threshold after notifying owners, and convert vendor shared accounts to named accounts.
4. Control tools: deploy application control rules for unapproved remote support tools in audit mode for [2 weeks], review hits with the service desk, then enforce.
5. Pilot ring, then everyone: enforce device conditions for IT staff first, then a business pilot group, then all users. Roll back through a time-limited exclusion group reviewed weekly.
6. Test detection: confirm that a dormant account login and a new remote support tool each raise an alert in [SIEM].

Detection and framework mapping

Relevant MITRE ATT&CK techniques are T1133 External Remote Services, T1078 Valid Accounts, T1219 Remote Access Tools, T1021.001 Remote Desktop Protocol and T1539 Steal Web Session Cookie. Prioritise alerts for dormant account logins, sessions from devices without compliance state and first execution of a remote access tool.

Standards and references

• NIST: SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• NIST: SP 800-207, Zero Trust Architecture
• CISA, NSA, FBI, MS-ISAC and INCD: Guide to Securing Remote Access Software
• CISA: AA23-025A, Protecting Against Malicious Use of Remote Monitoring and Management Software
• NCSC: Cyber Essentials Requirements for IT Infrastructure v3.2
• Microsoft Learn: Conditional Access grant controls

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Remote Access Identity Guide · Third-Party Access Guide · Phishing-Resistant MFA Guide · Privileged Session Management Guide · OT Remote Access Guide