Zero trust alternatives to VPN for defense: ZTNA, software-defined perimeters, and identity-aware proxies

Legacy VPNs were designed for a network perimeter that no longer exists. When every application lived inside a data center and every user sat at a managed workstation on a known subnet, granting broad tunnel access to the corporate network was a defensible posture. Modern defense architectures -- with workloads distributed across on-premises enclaves, classified cloud, deployed forward nodes, and mobile command posts -- render that model not just inefficient but actively dangerous. The VPN concentrator becomes a single point of lateral-movement risk: one compromised credential or misconfigured tunnel grants an adversary the same implicit network-layer access that a legitimate insider holds. Zero trust architecture for military networks offers a fundamentally different model, and this article examines the specific components that replace VPN in practice: Zero Trust Network Access, software-defined perimeters, and identity-aware proxies.

Why legacy VPNs fail modern defense architectures

The architectural failure of legacy VPNs in defense contexts is not primarily a vulnerability in the VPN protocol itself -- IPsec and TLS tunneling remain cryptographically sound. The failure is in the access model the VPN enforces. Once a user authenticates to the VPN concentrator, the resulting tunnel grants network-layer reachability to an entire subnet or VLAN. The VPN does not know which specific application the user intends to reach, does not evaluate the health of the connecting device, and does not apply per-session policy based on the sensitivity of the requested resource. Every session receives the same implicit trust once the initial credential check passes.

In operational defense environments, this flat trust model creates concrete risk. Compromised endpoint devices -- laptops recovered by adversaries, credentials extracted from captured personnel -- carry the same VPN access grants as operational devices in good standing. Split-tunnel configurations, introduced to reduce bandwidth consumption at forward operating bases, create routing asymmetries that security teams cannot fully audit. And when VPN concentrators themselves carry unpatched vulnerabilities, the exposed attack surface is the gateway to the entire protected network segment, not a single application. Several high-profile intrusions into defense contractor networks have followed exactly this pattern: initial access through a VPN concentrator vulnerability, followed by lateral movement across subnets that the VPN model implicitly trusted.

Operational tempo adds a second layer of friction. Provisioning VPN access for a new contractor, a deployed unit, or a coalition partner requires manual firewall rule changes and VPN group assignments. Revoking access at the end of an engagement requires the reverse. In a threat environment where access should be granted for the duration of a specific task and revoked immediately when that task ends, the coarse granularity of VPN access management creates both over-privileged standing access and time-consuming administrative overhead. The operational case for replacing VPN is as much about access agility as it is about security posture.

Zero Trust Network Access (ZTNA) architecture: principles and components

Zero Trust Network Access (ZTNA) is the architectural pattern that directly replaces VPN for user-to-application connectivity. The foundational principle is that no connection is trusted by virtue of network location. Every session -- whether it originates from a workstation inside the data center or a tablet at a forward operating base -- must present a verified identity, a device posture attestation, and sufficient contextual justification before the policy engine authorizes access to a specific application. The VPN tunnel is replaced by a per-session, application-scoped connection mediated by a ZTNA gateway that enforces the policy decision.

The ZTNA architecture has four core components. The identity provider (IdP) issues the cryptographic identity assertion that the user carries into the session. In defense deployments, this is typically a PKI-backed system using smart cards, hardware tokens, or FIDO2 keys -- not password-only credentials. The policy engine evaluates the identity claim, the device posture signals, and the access request attributes against a policy ruleset to produce an allow or deny decision. The ZTNA gateway enforces that decision at the network layer, proxying only authorized application sessions and dropping all other traffic. The device posture agent, running on the endpoint, collects and attests the health signals the policy engine requires. These four components interact in a sequence that produces a time-limited, application-scoped access token for each authorized session, rather than a persistent network tunnel.

The practical effect is microsegmentation without the complexity of configuring per-application firewall rules across every network segment. Applications are not directly reachable from any network; all traffic flows through the ZTNA gateway, which knows the identity of every session it proxies. This architecture is described in detail in the context of Corvus QUANTUM zero trust architecture: design and components, which implements the full ZTNA stack for defense cloud and on-premises deployments.

Software-defined perimeters: single-packet authorization and controller design

Software-defined perimeters (SDP) extend the ZTNA principle to the network discovery layer: infrastructure is not merely access-controlled but made entirely invisible to unauthenticated parties. An SDP gateway does not respond to TCP SYN packets, does not appear in DNS responses visible to untrusted networks, and drops all traffic that has not been preceded by a valid single-packet authorization (SPA) knock. From the perspective of a network scanner or automated exploit framework, the infrastructure simply does not exist. This "dark network" property is the defining characteristic that distinguishes SDP from conventional firewall-enforced segmentation, where infrastructure is visible even if access is denied.

Single-packet authorization works through a precisely defined handshake. The SDP client collects the user's identity token, the requested service identifier, a timestamp, and a nonce, signs the combined payload with a private key from the device's hardware security module or TPM, and transmits the signed knock as a single UDP datagram to the SDP controller. The controller validates the knock's cryptographic signature against the user's enrolled public key, checks the timestamp for replay protection (typically a five-second validity window), evaluates the access policy for the requested service, and if the policy permits, instructs the SDP gateway to open a per-session firewall rule for that specific client IP and destination port. Only then does the client attempt the TCP connection. An observer monitoring the network sees the knock datagram -- which is encrypted and carries no plaintext service identifier -- but cannot replay it, cannot determine what service was requested, and cannot connect without a valid identity credential.

Controller design is the architectural decision that most affects SDP operational resilience. A single centralized controller is a single point of failure for the entire access control plane. Defense deployments typically use a distributed controller cluster with a consensus mechanism (Raft or Paxos-based) that tolerates the loss of a minority of nodes. For forward-deployed units that must retain access capability during communications disruption, a local SDP controller instance can be deployed at the unit's network edge, synchronized with the central controller when connectivity is available and operating autonomously on a locally cached policy snapshot when it is not.

Identity-aware proxies: enforcing access policy at the application layer

Identity-aware proxies (IAP) complement ZTNA and SDP by moving the access enforcement point from the network layer to the application layer. Where a ZTNA gateway controls whether a session can reach an application's network endpoint, an IAP terminates the session, inspects the application-layer protocol, evaluates identity and policy, and re-issues the connection to the backend only if the per-request authorization succeeds. The IAP understands HTTP verbs, URL paths, gRPC service names, and SSH subsystems -- it can enforce access policy at the granularity of individual API endpoints or command classes, not merely at the level of the application as a whole.

For defense applications, IAPs provide a capability that pure network-layer controls cannot: fine-grained, auditable authorization decisions that are logged with a verified user identity, not a source IP address. An IAP sitting in front of a classified data service can enforce that a logistics analyst may query the read endpoints but not write endpoints, that a coalition partner identity may access unclassified data objects but is denied when requesting classified ones, and that any access to a specific data category triggers an alert to the security operations team. These controls are independent of the network topology -- the backend application does not need to be modified to enforce them, and they remain effective even if the endpoint's network address changes due to roaming or VPN-less connectivity.

The IAP also solves the audit-trail problem that plagues IP-based access logs. Because the IAP authenticates every request and injects verified identity headers that the backend application logs, the audit trail associates every data access with a specific user identity rather than an IP address that may be shared, NATted, or spoofed. For classified environments subject to audit requirements, this identity-attributed access log is a significant operational improvement over the session-level logs produced by VPN concentrators.

Device posture assessment: verifying endpoint health before granting access

Device posture assessment is the mechanism by which ZTNA systems verify that the connecting endpoint is in a known-good state before issuing an access token. Posture assessment closes the attack vector that a network-credential-only check leaves open: a valid credential on a compromised device. The posture agent, installed on the managed endpoint fleet, collects signals that attest the device's security state and submits them to the policy engine as part of the session authorization request. Signals typically include the operating system version and patch level, the status and last-scan timestamp of the endpoint detection and response (EDR) agent, the state of disk encryption, the presence and validity of an enrollment certificate issued by the organization's PKI, and the absence of known-malicious processes.

Posture policy design requires balancing security stringency against operational continuity. A policy that requires a current EDR signature database will deny access to endpoints that have been offline in a communications-denied environment and have not received recent updates -- a scenario that is routine for deployed defense units. Defense ZTNA deployments typically define tiered posture levels: a fully managed device with current patches and active EDR receives unrestricted access to all authorized applications; a managed device with stale EDR signatures receives access to a reduced application set excluding the most sensitive resources; an unmanaged device with no enrollment certificate receives no access, or access limited to a read-only information portal, pending manual review. This tiered model preserves operational access for deployed personnel while maintaining meaningful posture enforcement.

Continuous posture reassessment during active sessions addresses the scenario of a device that passes the initial posture check and then degrades -- because the EDR agent is killed, because a user installs unauthorized software, or because a new high-severity vulnerability is published against a component on the device. The posture agent reports health deltas to the policy engine at a configurable interval. When the policy engine receives a posture signal that drops the device below the minimum required level for its current session, it revokes the access token and forces re-authentication. The session termination is logged with the specific posture signal that triggered it, giving security operations a precise record of when and why access was revoked.

Deploying ZTNA in air-gapped and classified environments: constraints and adaptations

ZTNA implementations designed for internet-connected enterprise environments assume that the identity provider, the policy engine, and the threat intelligence feeds the posture assessment relies on are reachable over the public internet or a cloud backbone. Air-gapped and classified networks impose a different set of constraints: no internet connectivity, strict data diode or cross-domain solution (CDS) requirements at any external boundary, and accreditation processes that govern which software components may run within the classification boundary. These constraints require architectural adaptations that preserve the zero trust access model while eliminating every dependency on external connectivity.

The primary adaptation is hosting all ZTNA control-plane components within the classification boundary. The identity provider, the certificate authority that issues device enrollment certificates, the policy engine, the SDP controller cluster, and the IAP deployment are all operated as on-premises workloads inside the enclave. Because there is no external PKI connectivity, certificate revocation must be handled by an internally hosted OCSP responder or a regularly distributed certificate revocation list (CRL) that is updated through the enclave's change management process. Threat intelligence feeds that inform the posture policy -- such as newly published CVEs against OS components -- are ingested through a controlled transfer process at a defined update cadence rather than in real time.

A second constraint is the device enrollment process. In enterprise ZTNA deployments, devices are enrolled by the user visiting an IdP-hosted enrollment portal over the internet. In air-gapped environments, enrollment must happen through an in-band process: the device is connected to a dedicated enrollment network segment, the PKI agent is installed and the enrollment certificate is issued, and the device is then reconnected to the operational network. This process must be documented and enforced in the accreditation package, and the enrollment network segment must be isolated from operational traffic to prevent certificate issuance being used as an attack vector. The hardening patterns for defense Kubernetes workloads that host ZTNA control-plane components apply the same principle of isolation and minimal exposure to the cluster's management interfaces.

Migration path: moving from legacy VPN to ZTNA without service disruption

The migration from legacy VPN to ZTNA is rarely a single cutover event in defense environments. The diversity of applications, the heterogeneity of the endpoint fleet, and the operational criticality of continuous access make a phased, parallel-operation approach the only realistic migration path. The migration proceeds in five phases that incrementally shift application groups from VPN-mediated access to ZTNA-enforced access while maintaining continuous operational availability.

The first phase is a comprehensive inventory of current VPN usage: which users access which applications, over which protocols, from which device types, and during which operational periods. This inventory reveals dependencies that are not obvious from network diagrams -- applications that use the VPN tunnel for service-to-service authentication, legacy systems that bind access control to source IP addresses, and automated processes that use VPN credentials for scheduled tasks. These hidden dependencies become the migration blockers that must be resolved before the corresponding application can be moved behind the ZTNA gateway. Shadow mode operation -- running the ZTNA policy engine in log-only mode while the VPN remains active -- surfaces these dependencies without disrupting operations, typically requiring two to four weeks of observation per application group before the policy is sufficiently complete to trust.

Incremental cutover proceeds from lowest-criticality to highest-criticality application groups. Each group is cut over in a maintenance window: the VPN split-tunnel routes for that application's subnets are removed, the ZTNA gateway becomes the only access path, and a heightened monitoring period follows to catch any access failures that the shadow-mode observation missed. The final phase -- decommissioning the VPN concentrators -- should be preceded by a full access review confirming that no application remains reachable through residual VPN tunnel access, and that all session access logs now carry user identity rather than tunnel IP as the primary access identifier. The operational result is a network where every application session is attributable to a verified identity, every endpoint's health state is continuously attested, and the lateral movement paths that legacy VPN topology created no longer exist.