Remote Access Identity Guide: From VPN to ZTNA

Remote access is where many of the most damaging breaches begin. A VPN account without MFA, a dormant login nobody disabled, an unpatched remote access appliance or a vendor tool nobody monitors has opened the door to ransomware at pipelines, healthcare providers and technology companies. Traditional VPNs also grant broad network access once a user is in, so one compromised identity can reach far more than it needs. This guide covers the identity controls every remote access path needs, the move from network-level VPN to per-application zero trust network access (ZTNA), device posture, privileged and third-party access, the appliances themselves and the non-human identities that use remote paths. It is written for identity, network and security operations teams, and maps each control to NIST, ISO/IEC 27001, CIS and OWASP references.

Key takeaways

• Every remote entry point needs phishing-resistant MFA, with no exceptions for legacy profiles, service accounts or "temporary" access. Colonial Pipeline and Change Healthcare both began with a remote login that had no MFA.
• Dormant accounts are a standing invitation. CIS Controls v8.1 Safeguard 5.3 sets 45 days of inactivity as the point to delete or disable an account; automate it for every remote access system.
• ZTNA grants access per application, based on identity, device and context, instead of placing users on the network. CISA and partners describe it as a way to restrict what an attacker can reach from a compromised device.
• Remote access appliances are identity infrastructure. They store credentials and sessions, so after exploitation CISA advises assuming stored user and service account credentials are compromised: patching alone is not enough.
• Third parties, administrators and machines need their own brokered paths, with named accounts, time limits, recording and monitoring, including remote monitoring and management (RMM) tools that attackers increasingly co-opt.

Lessons from incidents

The incidents below share a pattern: the attacker did not need novel malware, only a working identity or session on a remote access path. The control column is what would most directly have broken the chain.

CitrixBleed recurred in 2025: according to the CitrixBleed 2 (CVE-2025-5777) analysis, leaked gateway memory could contain user session tokens and plaintext credentials, so every session that existed before the patch had to be killed.

Remote access paths and what they expose

NIST SP 800-46 Rev. 2 groups enterprise remote access into four types: tunnelling (VPNs), application portals, remote desktop access and direct application access. To those, most organisations now add vendor support tools, RMM agents and cloud administration consoles. Each path carries a different identity risk, and an inventory that misses one leaves a door nobody watches.

Identity controls for every remote access path

The same baseline applies to every path in the inventory. Where a path cannot meet it, treat that as a risk to be accepted at a senior level and given an end date, not as a permanent exception.

Authentication

• Integrate with the identity provider so remote access uses single sign-on and central policy, not local appliance accounts. CIS Safeguard 6.7 asks for access control centralised through a directory service or SSO provider.
• Enforce phishing-resistant MFA for all users. CIS Safeguard 6.4 requires MFA for remote network access, and the CISA-led Modern Approaches to Network Access Security guide recommends identity verification with phishing-resistant MFA. Push approval alone failed at Cisco in 2022. See the Phishing-Resistant MFA Guide and the MFA Guide.
• Protect enrolment and recovery. An attacker who can register a new MFA device or talk the help desk into a reset bypasses the strongest factor.

Account lifecycle

• Remove local and legacy accounts on appliances, and protect any that must remain as break-glass accounts.
• Disable dormant accounts automatically after a defined period of inactivity (CIS Safeguard 5.3 suggests 45 days) and immediately on leaver events. See the Joiner-Mover-Leaver Guide.

Sessions

• Limit session lifetime and re-evaluate sessions when risk changes, such as a new location or a failed device check. Session cookies from remote access gateways are bearer credentials that have already passed MFA. See the Token and Session Security Guide.
• Be able to revoke every session at once, per user and per gateway, and test it before you need it.

Logging

• Send authentication and session logs from every gateway to central monitoring, with user, device, source address and application in each record.

From VPN to ZTNA

According to the CISA-led Modern Approaches to Network Access Security guide (June 2024), CISA has found over 22 Known Exploited Vulnerabilities related to VPN compromise, and once a user connects to a VPN "the organization may be susceptible to compromise" through design weaknesses, misconfiguration or flaws in the product. The same guide notes that Volt Typhoon used VPN sessions with administrative credentials to move laterally and blend in with normal traffic.

The CISA guide describes ZTNA as an access broker that verifies user identity, access requirements and policy rules, can monitor device posture and client geolocation, and enforces MFA; users reauthenticate periodically and the process restarts if they seek access to additional applications. This reflects NIST SP 800-207's tenets that access is granted per session and that authenticating to one resource "will not automatically grant access to a different resource".

ZTNA is usually delivered within security service edge (SSE), alongside a secure web gateway, cloud access security broker and firewall as a service, or within secure access service edge (SASE), which adds networking such as SD-WAN. For organisations still running VPNs during migration, CISA lists these steps: prevent access to the control plane, use a dedicated management interface, patch and analyse VPN telemetry, consider pre-authenticating users, use MFA and version control the running configuration.

Migration is usually phased: start with third parties and high-risk applications, then general users, and keep a minimal VPN only for use cases that genuinely need network-level access. CISA's Zero Trust Maturity Model 2.0 gives a way to track progress across its five pillars (identity, devices, networks, applications and workloads, data) from traditional through initial and advanced to optimal. See the Zero Trust Network Access (ZTNA) Guide and the Zero Trust Identity Guide.

Device posture

NIST SP 800-46 tells organisations to assume that telework devices will be lost, stolen or infected with malware, and to use network access control that checks a client's security posture before granting access. It also suggests tiered levels of remote access, so the most controlled devices get the most access.

• Bind device and user. A posture signal is only useful if the device itself authenticates; NIST SP 800-53 IA-3 covers device identification and authentication.
• Remember infostealers. Malware on personal devices harvests VPN credentials and session cookies, which is one reason unmanaged devices should not get full access. See the Device Compliance and Endpoint Posture Guide.

Remote access for privileged users and third parties

Privileged users

• Broker administrative access through PAM with just-in-time elevation and session recording, rather than a VPN profile with standing admin rights. See the Privileged Access Management Guide and the JIT Access Guide.
• Restrict VPN connections to unprivileged accounts. CISA's Ivanti advisory lists this among the actions to take today, so a stolen VPN credential is not also a domain admin credential.
• Record and review sessions on high-risk systems. See the Privileged Session Management Guide.

Vendors, contractors and MSPs

• Give each person a named account with sponsor approval, time windows and access to specific systems only. See the Third-Party Access Guide.
• Write logging into the contract. CISA's Guide to Securing Remote Access Software advises MSP customers to require visibility of the provider's presence, activities and connections, and to ensure MSP accounts are properly monitored and audited.
• Control RMM tools. The same guide notes RMM software is signed with valid certificates and its install paths are often excluded from EDR inspection. Audit which tools are installed, allowlist approved ones and block common RMM ports at the perimeter. See the Remote Monitoring and Management (RMM) Tool Security Guide.

Operational technology

The CISA-led guide describes hardware-enforced segmentation for the most consequential systems, including unidirectional screen viewing and time-limited hardware switches that give site staff physical control over how long remote access stays enabled. See the OT and ICS Identity and Access Guide.

Protecting the appliances

NIST SP 800-46 notes that a compromised remote access server can be a "jumping off" point for attacks on other hosts, and says servers must be kept fully patched and managed only from trusted hosts by authorised administrators. The Ivanti campaign showed how much identity material an appliance can hold.

• Patch as an emergency priority and track exposure of every internet-facing gateway. See the VPN Appliance Security Guide.
• Do not store privileged credentials on the appliance. CISA showed that domain administrator credentials, if saved when configuring an Active Directory authentication server on an Ivanti gateway, could be exfiltrated in clear text, along with cached credentials for active and inactive sessions.
• Do not trust a clean integrity check. In advisory AA24-060B, CISA reported that Ivanti's Integrity Checker Tool failed to detect compromise and that an attacker may keep root-level persistence despite factory resets.
• After a known exploit, rotate and revoke. CISA advises resetting all credentials that may have been exposed, "including user and service accounts", and assuming AD access on the appliance is compromised. Revoke sessions as well. See the Leaked Credential Response Playbook.
• Limit outbound connections from VPN appliances to required services, and keep management interfaces off the internet.

Remote access and non-human identities

Scripts, backup tools, monitoring systems and RMM agents use remote access paths too, typically through service accounts excluded from MFA. The appliances themselves hold non-human credentials: directory bind accounts, API keys and certificates. Several OWASP Non-Human Identities Top 10 (2025) risks apply directly: NHI1 Improper Offboarding (service accounts left active), NHI5 Overprivileged NHI (a domain admin used for directory lookups), NHI7 Long-Lived Secrets and NHI10 Human Use of NHI (staff using a shared service account over the VPN).

• Replace remote service accounts with workload identity or tightly scoped, source-restricted credentials, and keep them off the VPN used by people where possible. See the Service Account Security Guide.
• Inventory appliance secrets so every one can be rotated within hours of an advisory.
• Watch mass actions. CISA suggests that if an account pushes commands to 10 or more devices within an hour, security protocols such as MFA should be triggered again.

AI agents are the newest users of remote paths. An agent that connects to internal tools over a VPN or a long-lived API token inherits the broad reach of that path. Give agents their own identities, per-application access through a broker, short-lived credentials and an accountable human owner, and never let an agent reuse a person's VPN session. See the Zero Trust for AI Agents Guide.

Detection and monitoring

CISA's remote access software guide maps attacker use of remote paths to MITRE ATT&CK techniques including External Remote Services (T1133), Valid Accounts (T1078), Trusted Relationship (T1199) and Remote Access Software (T1219). Because these use legitimate tools and credentials, detection depends on knowing normal behaviour first.

• Authentication anomalies: impossible travel, new devices, logins from hosting providers and rapid logins across many accounts, as seen in the SonicWall compromises.
• Session anomalies: one session used from two addresses, or reuse after a reported patch, which is the CitrixBleed signature.
• MFA events: repeated push denials followed by an approval, and new MFA device enrolments shortly after a remote login.
• Dormant account use: any login by an account inactive for longer than your threshold should alert.
• Unapproved remote tools: RMM binaries running from user folders or only in memory.
• Appliance changes: configuration changes outside change windows and unexpected outbound connections.

See the ITDR Guide.

Common failure patterns

• The forgotten profile. A legacy VPN profile that is no longer used stays active with a password and no MFA, as at Colonial Pipeline.
• The portal nobody counted. One remote access portal is left without MFA, as at Change Healthcare, while effort goes into the main VPN.
• Patching without revoking. The appliance is patched but stolen sessions and credentials stay valid, as after CitrixBleed.
• Privileged credentials on the edge. A domain administrator account configured for directory lookups is stored on the gateway, as CISA demonstrated for Ivanti.
• Push MFA treated as strong. Push approval without phishing resistance gives way to fatigue and vishing, as at Cisco.
• Vendor access by default. Third parties get full VPN profiles or unmonitored RMM tools instead of named, time-limited access to specific systems.
• Service accounts excluded from policy. Machine accounts are exempted from MFA and conditional access, so they become the easiest way in.

Framework mapping

Control IDs below were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the ISO/IEC 27001:2022 Annex A control list, CIS Controls v8.1 and the OWASP Non-Human Identities Top 10 (2025).

Metrics that show progress

Implementation roadmap

Practitioner checklist

• Inventory every remote access path: VPNs, portals, remote desktop gateways, vendor and RMM tools, and cloud consoles.
• Integrate each with the identity provider and enforce phishing-resistant MFA, with no exempt profiles.
• Disable dormant accounts automatically and remove local and legacy appliance accounts.
• Limit session lifetime and confirm you can revoke every session on a gateway at once.
• Move third parties and high-risk applications to ZTNA first.
• Use device identity and posture tiers in access decisions.
• Broker privileged and vendor access with approval, time limits and recording.
• Keep privileged credentials off appliances and restrict VPN to unprivileged accounts.
• Patch appliances urgently and, after exploitation, rotate stored credentials and revoke sessions.
• Monitor remote sign-ins, sessions, MFA events and remote tools for anomalies.
• Give service accounts and AI agents their own scoped identities instead of shared VPN access.

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
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• CISA: Zero Trust Maturity Model, version 2.0
• CISA, FBI, GCSB, CERT NZ and CCCS: Modern Approaches to Network Access Security
• CISA, NSA, FBI, MS-ISAC and INCD: Guide to Securing Remote Access Software
• CISA: Threat Actors Exploit Multiple Vulnerabilities in Ivanti Connect Secure and Policy Secure Gateways (AA24-060B)
• CIS: Critical Security Controls Version 8.1
• OWASP: Non-Human Identities Top 10 (2025)

Related NHI Mgmt Group resources: Zero Trust Network Access (ZTNA) Guide · VPN Appliance Security Guide · Phishing-Resistant MFA Guide · Privileged Session Management Guide · Third-Party Access Guide