Zero trust network access for defense: ZTNA architecture, policy engine and identity-aware proxy

The perimeter VPN has been the primary remote access control for defense networks for three decades. A user authenticates at the VPN gateway, a tunnel is established, and the user gains broad network-layer access to resources inside the perimeter. This model was designed for a world where applications were hosted in a single data center and users connected from organization-controlled sites. In a modern defense environment — where workloads span sovereign cloud, tactical edge, and air-gapped classified enclaves, and where users connect from managed and semi-managed devices across multiple locations — the VPN architecture introduces risk that its designers never anticipated. Zero trust network access (ZTNA) is the architectural replacement: application-level access brokered through an identity-aware proxy, conditioned on continuous verification of who is connecting and what device they are using. This article examines the engineering mechanics of ZTNA for defense: how identity and device signals are collected and evaluated, how the policy engine produces access decisions, and how to deploy ZTNA across the full spectrum from unclassified networks to air-gapped classified enclaves.

Why legacy VPN fails for defense zero trust

The fundamental problem with VPN in a zero trust context is not the encryption — VPN tunnels are cryptographically sound. The problem is what the VPN grants after the encryption is established. When a user authenticates to a VPN gateway and the tunnel comes up, the user's device receives a network address inside the defense enclave and can reach any resource on that subnet that does not have a separate host-based firewall. The VPN has performed a single authentication event at tunnel establishment and has made an implicit, sustained trust decision: this user and this device may access the full network segment for the duration of the session.

Implicit trust after authentication. VPN authentication is a gate, not a continuous evaluation. Once the gate is passed, trust is not re-evaluated until the session ends or a timeout occurs. If the user's account is compromised mid-session, if the device is infected with malware during the session, or if the user leaves the device unattended with an active tunnel, the VPN continues to provide enclave-level access until an administrator manually terminates the session or the tunnel times out. In a defense environment where session durations often extend across a full working day, this represents an extended window of undetected risk.

Flat network blast radius. A VPN places the user on a network segment. Flat east-west connectivity within that segment means that a compromised VPN session can reach not just the application the user intended to access, but every service, database, and management interface on the subnet. The attacker who steals a VPN credential gains a foothold with the same network reach as the legitimate user — or broader, since the VPN policy rarely restricts intra-subnet traffic. This is the blast radius problem: a single credential compromise exposes the entire flat network segment.

Inability to enforce fine-grained access policy. VPN access policy is coarse: a user is either allowed to connect to a VPN profile, or not. The profile may assign a VLAN or subnet, but per-application, per-resource, or per-action policy enforcement within the tunnel is not a VPN capability. Access control within the tunnel is delegated to each application's own authentication mechanism — which may vary wildly in rigor across the application portfolio. ZTNA moves access policy to a centralized policy engine that applies consistent rules across every application, evaluated at the point of every access request rather than once at session establishment. The related concept of zero trust microsegmentation defense addresses lateral movement within the network after the access decision, complementing the ZTNA layer at the perimeter.

ZTNA architecture: proxy vs endpoint agent models

ZTNA implementations divide into two primary architectural patterns based on how traffic interception is achieved: the reverse proxy (clientless) model and the endpoint agent model. Both models share a common logical structure — a policy enforcement point, an identity broker, a device trust service, and a session proxy — but differ in where the interception occurs and what level of device visibility they can achieve.

Reverse proxy (clientless) ZTNA

In the reverse proxy model, no software is installed on the endpoint. The ZTNA service publishes a proxy endpoint — typically a URL in the organization's domain — that sits in front of each protected application. The user navigates to the proxy URL in a browser, authenticates through the identity broker (presenting CAC/PIV credentials and completing MFA), and is issued a short-lived session token. The proxy validates the token on each request and forwards authenticated, authorized requests to the application backend. The user's device is never placed on the application network; only the proxy has a network path to the backend.

The clientless model's primary constraint is protocol coverage: it works naturally for HTTPS applications and can handle RDP and SSH over browser-based clients (HTML5 RDP/SSH gateways), but does not support arbitrary TCP/UDP protocols or thick-client applications that communicate over proprietary protocols. Device trust visibility is also more limited without an agent: the proxy can inspect TLS client certificates and browser user-agent strings, but cannot verify EDR health status or TPM attestation without local agent assistance.

Endpoint agent ZTNA

The agent model installs a lightweight daemon on the managed endpoint. The agent runs continuously, intercepts traffic destined for protected application addresses (via a local virtual network adapter or OS-level packet filter), performs device trust checks locally, and establishes an encrypted tunnel to the ZTNA service edge. Protected application traffic traverses this tunnel rather than the open internet or a VPN. The application backend receives connections from the ZTNA proxy rather than directly from the endpoint — the backend network address is never exposed to the endpoint.

Agent-based ZTNA supports any application protocol, enables rich device trust signals (EDR integration, TPM attestation, patch compliance), and allows split-tunnel routing where only protected application traffic traverses the ZTNA tunnel while general internet traffic exits directly. For defense managed endpoints, the agent model is the standard choice because the device posture requirements for classified application access cannot be met without local agent-level visibility.

Cloud-delivered vs on-premises ZTNA

Cloud-delivered ZTNA runs the control plane and session proxy in a multi-tenant cloud service. This model suits unclassified programs where applications are hosted in commercial or government cloud environments. For classified programs — IL4, IL5, and air-gapped IL6 — the ZTNA control plane must be deployed within the accredited boundary. On-premises ZTNA places the policy engine, identity broker, and session proxy inside the classified enclave. Application traffic never exits the classified boundary. The control plane's external dependencies — certificate validation, EDR health queries, identity provider lookups — must all resolve within the accredited network without internet access.

Identity signals: who is connecting

ZTNA access decisions are conditioned on the identity of the connecting user. For defense personnel, identity verification anchors to the physical credential issued by the organization's personnel system — the CAC or PIV smart card — and is enriched by directory-sourced role and group attributes.

CAC/PIV certificate verification

The CAC (Common Access Card) and PIV (Personal Identity Verification) card carry an X.509 identity certificate issued by the organization's approved PKI. ZTNA certificate verification involves: presenting the certificate to the ZTNA identity broker via TLS client authentication; validating the certificate chain against the approved trust anchor (the root and intermediate CAs in the organization's trust store); checking the certificate against the certificate revocation list (CRL) or OCSP responder to confirm it has not been revoked; and extracting the subject distinguished name or UPN from the certificate to identify the user principal.

CRL and OCSP availability within an air-gapped environment is a common operational failure point. If the CRL distribution point is reachable only from the unclassified network and the ZTNA deployment is on a classified network, certificate revocation checks fail or time out. Air-gapped ZTNA deployments require a CRL caching proxy within the classified boundary that periodically syncs CRL updates through the cross-domain transfer mechanism.

Multi-factor authentication for ZTNA access

The CAC PIN entry satisfies the "something you have plus something you know" MFA requirement for most programs. However, applications designated as high-sensitivity may require an additional factor beyond the CAC — a TOTP code, a push notification to a registered authenticator app, or a hardware security key. The ZTNA policy engine can enforce per-application MFA tier requirements: standard CAC-PIN for general applications, CAC-PIN plus TOTP for sensitive command applications, and a time-limited out-of-band approval workflow for privileged administrative access. This per-application MFA tiering is not achievable with a flat VPN policy.

Identity provider integration: LDAP and Active Directory

Certificate authentication identifies the user principal but does not carry current role or group membership — those are managed in the directory and may change independently of certificate issuance. The ZTNA policy engine queries the identity provider — LDAP or Active Directory — at the time of each access request to resolve the user's current group memberships and role assignments. The resolved attributes become policy inputs: a user must be a member of the 'analysts-secret' Active Directory group to access the classified analytics application, regardless of what their certificate says. If the user is removed from the group in Active Directory, their next access request to the analytics application is denied by the ZTNA policy engine without requiring certificate revocation or VPN policy change. This attribute-based access control, backed by real-time directory queries, is a foundational capability of identity governance defense organizations apply to tighten the access control lifecycle.

Device trust signals: what device is connecting

User identity is a necessary but not sufficient condition for access in a defense ZTNA model. A legitimate user on a compromised or non-compliant device presents risk that user identity alone cannot mitigate. Device trust evaluation collects and evaluates signals about the connecting device independently of the user's identity assertion.

Device certificate

The first device trust signal is the machine certificate: a certificate issued by the organization's device PKI to the endpoint at enrollment time. The machine certificate proves that the device was enrolled by an authorized MDM or device management system and was at that time a managed asset. The ZTNA agent presents the device certificate alongside the user certificate at session establishment. The policy engine validates the device certificate chain against the device PKI trust anchor, checks revocation status, and confirms that the device identifier in the certificate matches the device identity recorded in the MDM inventory.

EDR health status

The endpoint detection and response (EDR) agent running on the device maintains a real-time assessment of the device's threat status. The ZTNA agent queries the local EDR agent or the EDR management platform API for a health attestation: is the EDR agent running, is its threat intelligence database current, and are there any active threats in quarantine or remediation? A device with a stale EDR signature database is effectively blind to recent threat families — ZTNA policy should treat such a device as non-compliant and either deny access or restrict it to a limited-access tier pending EDR update. An active threat quarantine event during a session triggers a continuous evaluation event that may result in immediate session suspension.

Patch compliance check

Operating system and application patch level is queried from the MDM platform or from the ZTNA agent's local inventory of installed patches. The ZTNA policy engine compares the device's patch state against a defined minimum: for example, all critical and high-severity CVEs published in the last 30 days must be patched before access to classified applications is permitted. Devices that are behind on patching are redirected to a remediation notice rather than the requested application. The patch compliance check also covers third-party applications in the device's managed software inventory — an unpatched web browser or PDF reader on a managed device represents an exploitation vector even if the OS is fully patched.

Hardware attestation via TPM 2.0

For defense managed endpoints equipped with a TPM 2.0 module, the ZTNA agent can request a TPM attestation quote — a cryptographically signed measurement of the device's boot chain, produced by the TPM and verifiable against a known-good reference manifest. The attestation proves that the device booted from an authorized firmware and OS image and that the boot chain was not tampered with since last attestation. This control is relevant for detecting boot-level malware — rootkits and bootkits that persist below the OS and would not be detected by an OS-level EDR agent. TPM attestation requires that the ZTNA control plane hold a reference manifest for each device model in the managed fleet; the manifest is populated during device enrollment and updated when authorized firmware changes are deployed.

Continuous policy evaluation engine

The policy engine is the decision-making core of the ZTNA architecture. It receives access requests — from the session proxy when a user initiates a connection, and from the continuous evaluation loop throughout an active session — and returns an access decision: permit, deny, or step-up (require additional authentication before permitting).

Policy-as-code with OPA and Rego

Defense ZTNA deployments benefit from expressing access policy as code rather than as GUI-configured rules. Open Policy Agent (OPA) with the Rego policy language is the dominant framework for this pattern. A Rego policy for ZTNA encodes all access conditions declaratively: the required user groups, the minimum device compliance level, the permitted access hours, the required MFA tier, and the risk score threshold. Policies are version-controlled in a source repository, reviewed through the same change control process as application code, and deployed to the OPA engine via a CI/CD pipeline. Every policy change has an author, a review record, a deployment timestamp, and can be rolled back to a prior version with a single pipeline revert. This auditability is a material advantage over per-application firewall rules that accumulate without version control.

Context-aware access decisions

ZTNA policy decisions can incorporate contextual signals beyond identity and device trust. Time-of-access policy restricts access to sensitive applications to defined working hours windows, reducing the exposure window for credential misuse outside normal working hours. Geolocation or network source policy — where the user is connecting from — can be evaluated by the policy engine: a classified application might permit access only from organization-managed network egress points or from specific approved remote access locations. Risk score integration allows the policy engine to consume a numerical risk signal produced by a user and entity behavior analytics (UEBA) platform: if the user's access pattern in the last 24 hours has produced a high anomaly risk score, the policy engine raises the access threshold, requiring step-up MFA before permitting access to sensitive applications.

Session risk re-evaluation

Traditional access control makes a decision at session start and does not revisit it. ZTNA continuous evaluation reassesses the access decision throughout the session at a configurable polling interval. The evaluation loop queries the identity provider for account status changes (account lock or group revocation since session start), the EDR platform for new threat events on the device, the device compliance service for patch status changes, and the risk scoring service for anomaly score changes. When a change crosses a policy threshold, the engine responds proportionately: a moderate risk increase triggers a step-up MFA challenge without terminating the session; a critical event — account lock, EDR active threat, certificate revocation — triggers immediate session termination. The continuous evaluation model means that an attacker who compromises a device mid-session faces a detection window bounded by the polling interval rather than the full session lifetime. The same principles that govern privileged access management defense programs — just-in-time access, session recording, and real-time risk re-evaluation — apply directly to the ZTNA continuous evaluation design for high-privilege sessions.

ZTNA for classified networks: IL4/IL5 deployment

Commercial cloud-delivered ZTNA services operate in multi-tenant shared infrastructure that is not authorized for classified workloads. Defense programs operating at IL4 (Controlled Unclassified Information) and IL5 (National Security Systems) impact levels require a ZTNA deployment model that keeps control plane operations and application traffic within the accredited boundary.

On-premises ZTNA for air-gapped classified environments

An on-premises ZTNA deployment for a classified network replicates the functional components of a cloud ZTNA service within the classified enclave. The policy engine, identity broker, session proxy, and device trust service are all deployed as on-premises compute workloads — either on dedicated hardware or within the classified Kubernetes cluster. All control plane dependencies resolve within the enclave: the identity provider is the classified Active Directory instance, the EDR management console is deployed on-premises, the certificate authority and CRL service operate within the air gap, and no policy evaluation call leaves the classified network boundary.

The operational challenge unique to air-gapped ZTNA is policy update distribution. In a cloud ZTNA service, policy changes are deployed centrally and propagate within seconds. In an air-gapped environment, policy updates must be delivered through the authorized software transfer mechanism — typically a media transfer process through the accreditation boundary. This means ZTNA policy changes require advance planning and cannot be applied with the sub-minute latency available in cloud deployments. The change control process for air-gapped ZTNA policy must account for this lead time, and emergency policy changes (for example, immediate revocation of a compromised user's access) must have an expedited path through the change control process defined in the program's security plan.

Cross-domain ZTNA proxy design

Some defense use cases require users on a lower classification network to access a specific, filtered view of data produced by a higher classification system — a sanitized operational picture, a declassified intelligence summary, or a read-only data feed. A cross-domain ZTNA proxy addresses this by combining ZTNA access control with cross-domain content inspection at the classification boundary. The proxy receives the user's access request from the unclassified network, verifies identity and device trust against the unclassified ZTNA policy engine, and then queries the classified application on behalf of the user through the cross-domain solution. The CDS component inspects the application response content, applies the release rules for the data's classification, and filters or redacts elements that are not authorized for release to the unclassified requestor. Only the filtered response is returned to the user session on the unclassified network. The proxy must be accredited as part of both network ATOs and the cross-domain authorization, with the ZTNA + CDS architecture explicitly described as a combined control.

Migration from legacy VPN to ZTNA

VPN-to-ZTNA migration in a defense program is an operational transition that must preserve access continuity for mission-critical applications while progressively tightening access control. A phased migration strategy that runs VPN and ZTNA in parallel during the transition period is the standard approach.

Phased migration strategy

The migration proceeds in three phases. In the first phase, ZTNA infrastructure is deployed and validated for identity and device trust integration, but no applications are onboarded and users continue to access all applications via VPN. A pilot user group — typically the IT and security team — tests ZTNA access to a low-criticality application to validate the end-to-end flow before mission users are involved. In the second phase, applications are onboarded to ZTNA in priority order. During this phase, VPN remains available as a fallback for applications not yet onboarded. Users are trained on the ZTNA access portal and agent before their primary applications move to ZTNA. In the third phase, once all applications in scope are onboarded and the pilot population has validated access, VPN access is revoked for the migrated user population. The VPN gateway remains available only for applications excluded from ZTNA scope (if any) during the final phase, then is decommissioned when the remaining applications complete onboarding.

Application onboarding sequence

Applications are onboarded to ZTNA in a sequence designed to minimize risk and learn from early onboardings before tackling complex cases. Start with internal web portals and dashboards — HTTPS applications with browser-based frontends that work naturally with reverse proxy ZTNA and have broad user populations who can provide feedback quickly. Move next to productivity applications: email web interfaces, document management portals, internal wikis. Then tackle application categories that require the agent model: RDP-accessed Windows servers, SSH-accessed Linux systems, thick-client C2 or mission applications. Reserve for last the most complex integrations: applications with non-standard authentication mechanisms, high-criticality real-time systems, and any application that currently relies on VPN IP-based access control rather than application-layer authentication.

User training for ZTNA access patterns

The ZTNA user experience differs materially from VPN. Users accustomed to VPN connect once at the start of the day and access all applications transparently for the rest of the day. With ZTNA, the user accesses applications through the ZTNA portal or via agent-intercepted connections, and may encounter step-up MFA challenges during the day if continuous evaluation detects a risk change. Training must address three behavioral changes. First, the access portal: where to navigate to find applications and how to authenticate via CAC. Second, the agent: how the ZTNA agent appears in the system tray, what its status indicators mean, and how to report problems. Third, step-up authentication: what a mid-session MFA challenge looks like (so users do not mistake a legitimate step-up prompt for a phishing attempt) and how to complete it. Programs that invest in user training before onboarding the first mission user see significantly lower helpdesk ticket volumes and faster adoption than programs that deploy ZTNA without a training program.