Federal agencies are facing growing pressure to evaluate ZTNA as an alternative to traditional VPN architectures, as cybersecurity threats expose weaknesses in internet-facing remote access systems. While VPNs provide encrypted connections for remote users, ZTNA follows a zero-trust model that continuously verifies users, devices, and access requests rather than assuming that authenticated users should receive broad network access.
The shift reflects a broader move away from the traditional “castle-and-moat” security model, where users inside an organization’s network are generally trusted while those outside must first pass through a security perimeter. As organizations adopted cloud services, mobile workforces, and geographically distributed infrastructure, this model became more difficult to maintain.
VPN Security Risks Drive ZTNA Considerations
A traditional VPN creates an encrypted connection between a remote user’s device and an organization’s internal network. The VPN appliance typically sits at the edge of the network and remains accessible from the public internet, where it authenticates users before granting access.
This architecture creates several security concerns. VPN appliances must maintain publicly accessible listening ports, making them discoverable and scannable by attackers. If vulnerabilities remain unpatched, those weaknesses can potentially be exploited remotely.
The memorandum also points to risks involving legacy code bases, key-exchange processes, and lateral movement. Attackers who obtain legitimate VPN credentials, exploit a vulnerability, or hijack an active session may gain broad access to the internal network. Unlike application-specific access, traditional VPN access operates at the network layer, potentially allowing an authenticated user to reach multiple permitted subnets.
Recent incidents involving vulnerable VPN appliances have further highlighted these concerns. The memorandum cites CISA directives addressing exploitation involving Pulse Connect Secure, VMware, and Ivanti Connect Secure products.
How ZTNA Changes Remote Access
ZTNA uses a “never trust, always verify” approach. Instead of treating users inside a network as inherently trusted, the architecture evaluates access requests based on factors such as identity, device health, user role, location, behavior, and risk.
The architecture is built around three core components: the Policy Engine, which makes access decisions; the Policy Administrator, which establishes or ends sessions; and the Policy Enforcement Point, which enables, monitors, and terminates connections.
Modern ZTNA deployments can also use outbound-only connections, removing the need for publicly accessible inbound listening ports. Rather than placing a user directly onto a corporate network, ZTNA can create an encrypted, application-specific micro-tunnel that limits the user to an authorized resource.
Continuous verification is another key difference. Access is not necessarily granted once and maintained for the entire session. Instead, policies can reassess access based on changing security and contextual signals.
ZTNA Also Brings New Security Risks
The shift to ZTNA does not eliminate cybersecurity risks. The memorandum identifies the control plane as a significant concern because it is responsible for authentication, device verification, policy enforcement, and connection management.
If an attacker compromises a ZTNA provider or components such as the Policy Engine or Policy Administrator, access decisions could potentially be manipulated. This could result in unauthorized access or prevent legitimate users from reaching resources.
Additional security controls, including cryptographic signing of device nodes, may help reduce the impact of a compromised ZTNA provider. The memorandum cites Tailscale Tailnet Lock as an example of this approach.
Federal Agencies Face a Complex Transition
For federal agencies, moving from VPN to ZTNA involves more than replacing one remote-access technology with another. Agencies must consider federal cybersecurity policies, budgets, legacy infrastructure, authentication requirements, and cryptographic standards.
NIST Special Publication 800-207 established foundational principles for Zero Trust Architecture, while Executive Order 14028 directed federal agencies toward zero trust, multifactor authentication, and secure cloud services. OMB Memorandum M-22-09 later established a federal zero-trust strategy centered on identity, devices, networks, applications and workloads, and data.
A transition could involve assessing existing VPN deployments, identifying applications and user groups, deploying ZTNA alongside VPN infrastructure, and progressively migrating applications. VPN infrastructure could then be decommissioned after applications and users are migrated and validated.
However, agencies must also account for recurring ZTNA subscription costs, legacy systems that may not support modern authentication, post-quantum cryptography requirements, NIST standards, FIPS requirements, and FedRAMP approval for cloud-based services.
The transition from VPN to ZTNA therefore represents a broader change in how organizations approach remote access. While ZTNA can reduce exposure associated with publicly accessible network perimeters and broad network-level access, agencies must evaluate the technology’s own control-plane risks, compliance requirements, costs, and technical limitations before making the shift.
