Remote Access Security Best Practices for IT Admins

Short answer: Remote access security best practices come down to eight controls: inventory every access path, require phishing-resistant MFA everywhere, scope access to named resources instead of the network, patch the access infrastructure first, check device posture before each session, limit and record sessions, block remote access tools you did not approve, and handle vendor access as its own control problem. Each one maps to a specific CISA or NIST control and produces evidence an auditor can check.

Who this guide is for

This guide is for an IT admin, security engineer or IT manager who already has at least one remote access path in place, a VPN, a ZTNA broker, RDP tools or a vendor access gateway, and needs the hardening practices, policy language and audit evidence to secure it. It does not compare access models or products. For the vendors in this category, see the remote access software hub.

Remote access security best practices at a glance

Each practice maps to the standard an auditor is likely to cite and to the evidence you would show to prove it is in place.

Start with an inventory of every remote access path

An inventory is the first practice because every other control depends on it. List every VPN gateway, ZTNA broker and agent, RDP and remote support tool, vendor privileged access gateway, jump host and RMM agent with access into the environment, and give each one an owner.

CISA's joint guide, co-authored with the NSA, FBI, MS-ISAC and INCD, recommends auditing remote access software and its configuration on every device to identify what is currently used and what is actually authorized. The guide names 15 remote access and remote monitoring products commonly abused by threat actors: AnyDesk, Atera, Bomgar, ConnectWise Control (formerly ScreenConnect), GoToMyPC, Kaseya, LogMeIn, N-Able, NetSupport, Pulseway, Remote Utilities, RemotePC, Splashtop, TeamViewer and Zoho Assist (Guide to Securing Remote Access Software, accessed September 29, 2026). None of these tools are malicious by design; the point of the list is that any of them can be running on a machine without IT's knowledge, since several can run as portable executables with no installation and no administrator privileges required.

Admin tip: Pair the inventory with an Active Directory audit for inactive and obsolete accounts, which CISA lists alongside the software audit. A remote access tool with a live account nobody uses is as much a gap as an unapproved tool.

Require phishing-resistant MFA on every path

MFA on remote access is not an advanced control. CIS Controls v8.1 Safeguard 6.4 states the requirement directly: "Require MFA for remote network access," and places it in Implementation Group 1, the baseline every organization, regardless of size or maturity, is expected to meet (CIS Controls v8.1 Safeguard 6.4, accessed September 29, 2026).

The reason it comes first is the entry point it closes. Coalition's 2025 Cyber Threat Index found stolen credentials behind 47% of all ransomware claims, the largest single initial access category the report tracks (Coalition Cyber Threat Index 2025, published March 11, 2025, accessed September 29, 2026). CISA's joint guide adds two specifics: enable just-in-time access or two-factor authentication based on the level of risk, and adopt MFA across every customer-facing service, treating any account with access to another organization's environment as privileged.

Watch out: Legacy protocols such as SSH to network devices and older RDP deployments often do not support MFA natively. That is where a broker earns its place: the admin authenticates to the broker with MFA, and the broker handles the legacy connection on the other side.

Scope access to resources, not the network

Least privilege on remote access means an authenticated session reaches only the specific applications or hosts it needs, not the whole internal network. CIS Controls v8.1 Safeguard 12.7 requires remote devices to authenticate to an enterprise's VPN and AAA infrastructure before reaching resources, and CISA's joint guide lists network segmentation as a control to minimize lateral movement and restrict access to devices, data and applications (CIS Controls v8.1 Safeguard 12.7, accessed September 29, 2026).

In practice this means access control lists that name resources rather than subnets, and disabling split tunneling on untrusted networks so an attacker who compromises a client device cannot use it as a bridge between the internet and the internal network. If your current tool authenticates once at the gateway and then trusts everything behind it, segmentation behind the gateway is the fix, not a replacement product.

Watch out: A gateway that authenticates a person to a network, not to an application, means one compromised credential or device reaches whatever that tunnel reaches. Segmentation and per-resource rules behind the gateway are what actually limit that.

Patch and harden the access infrastructure first

Remote access infrastructure is exposed by definition, and it shows in the incident data. Coalition's 2025 index found compromised VPN and firewall appliances behind 58% of 2024 ransomware claims, with compromised remote desktop products second at 18%, ahead of every other single entry category the report measured (Coalition Cyber Threat Index 2025).

CISA's joint guide recommends establishing a regular patching frequency and prioritizing software and systems that face the internet, specifically naming remote access and management servers and agents. NIST SP 800-46 Rev. 2 makes the same point for the server itself: remote access servers should be kept fully patched, run on an organization-defined security configuration baseline, and managed only from trusted hosts by authorized administrators (NIST SP 800-46 Rev. 2, Section 3.1, accessed September 29, 2026). NIST also recommends placing the server at the network perimeter, in the organization's DMZ where a firewall can control access to it from both directions.

Admin tip: Put remote access gateways and RDP or vendor gateway hosts in a separate patch tier with a shorter target than the rest of the fleet, and track time from advisory to patched rather than patch count. Given the 58/18 split above, the appliance itself is where the exposure window matters most.

Check device posture before the session

Device posture answers a question authentication alone cannot: is the device on the other end safe to let in. CIS Controls v8.1 Safeguard 13.5 requires managing access for remote assets based on whether up-to-date antimalware software is installed, the device is compliant with the organization's secure configuration baseline, and the operating system and applications are current (CIS Controls v8.1 Safeguard 13.5, accessed September 29, 2026).

NIST SP 800-46 describes the mechanics as health checks performed by the remote access server before granting access: confirming antimalware is current, the operating system is patched, and, for mobile devices, that the device has not been rooted or jailbroken. A device that fails the check can be denied access, limited to a quarantine network, or granted reduced access rather than blocked outright.

NIST is direct about the limits of this control: many health checks can be circumvented by malware, so this kind of check is a policy enforcement mechanism, not a guarantee against a determined attacker. Use it to catch the common case, misconfigured or out-of-date devices, and pair it with the other controls on this list rather than relying on it alone.

Limit sessions, force re-authentication, and record them

Session controls limit how much damage a hijacked or unattended session can do. NIST SP 800-46 Rev. 2 notes that many organizations require teleworkers to re-authenticate after each eight hours of a session or after 30 minutes of idle time, and federal guidance requires agencies specifically to enforce a 30-minute idle timeout on remote access (NIST SP 800-46 Rev. 2, Section 3.3.1). The corresponding NIST SP 800-53 controls are AC-11, Session Lock, and IA-11, Re-Authentication.

Recording matters as much as timing out. CISA's joint guide recommends reviewing logs with complete data for every remote access session: the executing binary, the request type, the source IP address, and the date and time. Where the tool supports it, session recording for connections to sensitive systems turns "someone connected" into "here is what they did," which is the difference an investigation needs.

Block remote access tools you did not approve

Auditing tells you what is installed; this practice stops the rest from running. CISA's joint guide recommends allowlisting approved RMM programs through application controls, ideally paired with zero-trust principles and segmentation, and blocking both inbound and outbound connections on common RMM ports and protocols at the network perimeter. Remote access software should run as local instances inside the environment rather than over HTTPS port 443, and any authorized tool should be reachable only through an approved path such as a VPN or VDI, not directly from the open internet.

One operational detail matters for how you enforce this: several of the tools on CISA's list can run as self-contained portable executables that launch without installation and without administrator privileges. An allowlist built only from what software management shows as installed will miss these. Detection has to include monitoring for the process running in memory, not only checking what was installed through normal channels.

Treat vendor and third-party access as its own problem

Vendor and MSP access breaks the assumptions employee access is built on: the person is not in your directory, their device is not managed by you, and several of their engineers may share one login. CISA's joint guide addresses this directly in its recommendations for MSP and SaaS customers and for MSPs and IT administrators, and the practices translate to any organization granting a vendor or contractor remote access.

Require contract terms that spell out how and when a provider notifies you of an incident affecting your environment, and keep direct access to log servers, including the ability to delete or alter logs, out of reach of the provider's remote access tools. On the provider side of the relationship, require MFA on every account with access to your environment and treat those accounts as privileged, and confirm the provider does not reuse the same administrative credentials across its other customers. Avoid remote access tools that have reached end of life, since an unpatched, unsupported tool in a vendor's toolkit is still a path into your environment. For the equivalent controls on internal administrator accounts, see our privileged access management best practices guide.

Tier access by device type

Not every device deserves the same ceiling. NIST SP 800-46 Rev. 2's worked example splits devices into seven categories, organization-issued devices in the office or on telework, BYOD in the office or on telework, contractor or vendor devices in the office or on telework, and third-party devices such as a hotel kiosk, and maps each against a set of applications by sensitivity (NIST SP 800-46 Rev. 2, Table 5-1). Adapted into a general-purpose policy an admin can fill in for their own resources, it looks like this:

Fill in your own resource list against these rows rather than adopting the examples as written; NIST's point is the tiering logic, not the specific applications.

Policy essentials you can copy

Adapt these into your remote access policy. Each maps to a control cited above.

1. Scope. This policy covers every remote access path into the organization's systems, including VPN, ZTNA, RDP, remote support tools and vendor access gateways, whether managed by IT or by a service provider.
2. Inventory. Every remote access tool is recorded with an owner, and unauthorized tools discovered on the network are removed or formally approved and added to the inventory.
3. Authentication. All remote access requires MFA. Legacy protocols that cannot enforce MFA natively are placed behind a broker that does.
4. Access scope. Remote access grants access to named resources, not to the network as a whole. Split tunneling is disabled on untrusted networks.
5. Infrastructure security. Remote access servers and gateways are patched on a shorter cycle than the general fleet and managed only from trusted administrative hosts.
6. Device posture. Access from a device that fails a posture check is denied, quarantined or reduced, never granted at full scope by exception.
7. Session control. Sessions time out after a fixed period of inactivity and re-authenticate after a maximum session length. Sessions to sensitive systems are logged with the executing binary, request type, source IP address, and date and time, and recorded where the tool supports it.
8. Vendor and third-party access. Providers with remote access into the environment are contractually required to use MFA, avoid shared credentials, and notify the organization of incidents on a defined timeline.
9. Review. The remote access tool inventory and access tiers are reviewed on a fixed schedule and after any change to which providers or tools have access.

Rollout plan

Roll out in phases so each one produces evidence before the next begins. No durations are given because they depend on the size of the environment.

Enforcement and monitoring

Enforcement works when violations are visible. Alert on remote access sign-ins without MFA, execution of an RMM binary not on the allowlist, sessions that connect outside normal business hours, and patch SLA breaches on internet-facing remote access appliances specifically, tracked separately from the general patch report. For vendor and MSP accounts, alert on activity outside the scoped systems or time window in the contract. Report monthly on the count of remote access tools discovered but not yet inventoried; that number should fall toward zero over time.

Common exceptions and how to handle them

• Legacy protocols without native MFA: route them through a broker that enforces MFA rather than leaving them exposed, and record the exception with an owner and review date.
• RDP that has to stay reachable for a legacy application: keep it off the open internet entirely. NIST SP 800-46 Rev. 2 recommends using remote desktop access only in exceptional cases after a careful risk analysis, since it decentralizes the problem to every reachable workstation; if it must exist, put it behind a broker or jump host, never a direct internet-facing listener.
• Vendor emergency access: grant a time-boxed exception with logging and a mandatory post-use review, never a standing account.
• BYOD that only needs webmail-tier access: keep it at that tier by policy rather than extending it because a request seems reasonable in the moment.

Mistakes to avoid

• Treating the VPN or ZTNA product as the whole control. Coalition's data shows the appliance itself is the leading ransomware entry point; patching and hardening it is not optional groundwork, it is the control.
• Requiring MFA on the admin console but not on the remote access path itself. Stolen credentials were behind 47% of ransomware claims in Coalition's 2025 index, and most of those credentials were used somewhere other than an admin console.
• Allowlisting installed software without watching for portable executables running in memory. Several of the tools on CISA's list do not require installation, so an allowlist based only on installed programs has a gap.
• Relying on device posture checks as a security boundary rather than a policy filter. NIST's own guidance notes that health checks can be circumvented by malware; pair posture checks with MFA and access scoping rather than trusting them alone.
• Letting a vendor reuse the same administrative credentials across multiple customers. A compromise at one customer becomes a path into every environment that shared provider touches.

Bottom line

If you do nothing else this quarter, inventory every remote access path, turn on MFA everywhere it is missing, and move your remote access appliances to a shorter patch cycle; those three close the entry points behind most of the incident data cited here. Vendor access, session recording and device-type tiering are the next layer once the baseline is in place. To compare the tools in this category against your requirements, start with the remote access software hub or build a scored list in the shortlist builder.