How should IT teams secure remote access when users work from public or home networks?

IT teams should treat remote access as an identity and access problem, not just a network tunneling problem. A VPN can encrypt traffic on untrusted networks, but it should be paired with centralized authentication, device management, and MFA where possible. The goal is to reduce password reuse, keep access consistent across resources, and give admins one controlled way to provision and revoke access.

Why remote access should be secured as an identity problem

Remote access is not just a tunnel between a laptop and a corporate network. It is a controlled decision about who can enter, from which device, under what conditions, and with what level of trust. For users on public or home networks, the real security boundary is the identity flow around the connection, not the network path alone.

A VPN can still be useful because it protects traffic on untrusted networks, but it does not solve account abuse, weak passwords, stolen sessions, or unmanaged devices. The security question is whether the remote entry point enforces the same authentication, authorization, and revocation discipline everywhere it is used.

In practice, that means the access layer should be managed centrally, so users do not accumulate separate exceptions for remote work, third-party access, or one-off support. That is why remote access guidance needs to align with Remote Access Identity Guide, which treats VPN, MFA, device posture, and zero trust access as one control problem rather than isolated products.

What controls make remote access safe on untrusted networks

The first control is strong authentication at every meaningful entry point, especially where the remote session can reach sensitive systems. MFA reduces the value of stolen passwords, but it works best when it is enforced consistently and paired with centralized identity policy rather than left to individual applications.

The second control is device management. If the endpoint is unmanaged, compromised, or missing basic protections, a legitimate login can still become a high-risk session. For that reason, device posture checks and managed endpoints matter as much as the tunnel itself. This is also why the broader identity lifecycle matters: access should be granted, reviewed, and revoked in one place, not re-created service by service, a pattern covered well in IAM and IGA Basics.

The third control is consistent authorization. Users should receive only the access needed for their role, and that access should be removable without waiting for every downstream system owner to act. When access is tied to centralized policy, admins can reduce orphaned entitlements and limit the blast radius of a compromised account.

For a practical view of why this matters, the Change Healthcare breach 2024 shows how one remote login path without MFA can become a large-scale compromise. The lesson is not that VPNs fail by themselves, but that remote access becomes dangerous when authentication is weak and the entry point is overtrusted.

How to reduce remote access abuse and operational sprawl

Remote access becomes safer when teams reduce the number of standing exceptions. Dormant accounts, reusable passwords, shared admin access, and long-lived credentials all expand the chance that a remote session is authenticated in name only. The goal is to make access reviewable, revocable, and attributable every time it is used.

That is especially important for privileged or support access. Remote administration should be observed and constrained, not simply allowed because it is convenient. If a remote session can administer production systems, teams should be able to broker, record, and audit that session. Privileged Session Management Guide is useful here because it ties remote admin access to monitoring and control rather than blind trust.

Teams should also watch for access sprawl across VPNs, SSO portals, remote desktop gateways, and vendor tools. The more entry points there are, the easier it becomes to miss one that has weaker policy or weaker logging. Consistent identity policy across all remote paths is usually more important than any single transport mechanism.

Risk and Threat Considerations

Remote access on public or home networks is attractive to attackers because it concentrates trust at the login boundary. Stolen passwords, infostealer output, session theft, and MFA gaps can all turn a legitimate remote service into an entry point for lateral movement or ransomware. The risk rises further when remote access is exposed through legacy portals, dormant accounts, or unmanaged devices.

Failure mechanism: Attackers do not need to defeat the network tunnel if they can authenticate as a valid user or hijack an existing session. Once inside, weak segmentation and broad entitlements let a single remote login pivot into internal systems.

Impact: The result can be unauthorized access, privilege escalation, data theft, or operational disruption, especially when remote access is the shared path into multiple critical resources.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Remote access for employees depends on strong user authentication.
	IA-5 — Authenticator Management	Remote access risk is driven by password reuse, stale credentials, and revocation gaps.
	AC-6 — Least Privilege	Remote users should receive only the access needed once authenticated.
Recommendation — Require centralized user authentication for all remote access entry points. Rotate, protect, and revoke remote access credentials quickly. Restrict remote access permissions to the minimum required for the role.
NIST Zero Trust (SP 800-207)	§3.1 — Continuous verification and least privilege	Remote access on untrusted networks needs continuous verification, not implicit trust.
Recommendation — Apply zero trust verification to each remote access request and session.
CIS Controls v8	CIS-6 — Access Control Management	Remote access should be centrally granted, reviewed, and revoked.
Recommendation — Centralize remote access approval, review, and removal.

Practitioner Guidance

What to prioritise: Put authentication, device posture, and revocation speed ahead of network convenience. If remote access can be granted faster than it can be reviewed or removed, the control is too weak for high-value environments.

What to verify: Confirm that every remote entry point uses the same identity policy, MFA requirement, and logging standard. Also verify that admins can disable access centrally without waiting on separate app owners or network teams.

Common mistake: Treating VPN deployment as the end state. A VPN only protects the transport; it does not by itself solve account abuse, unmanaged endpoints, or excessive privilege.

Practitioner takeaway: secure remote access by treating it as a governed identity path with strong authentication, managed devices, and fast revocation, then use the VPN as one layer of protection rather than the control that carries the whole design.