Zero-Trust Remote Access: Architecting Secure Connectivity for Enterprise and Government
Designing a zero-trust remote access architecture that satisfies both enterprise security teams and government compliance requirements — combining always-on VPN, conditional access, TPM attestation, endpoint health verification, and continuous authorization.
Zero trust has become one of the most overloaded terms in cybersecurity. Every vendor claims to deliver it. Every compliance framework references it. And yet, when you sit down to design a remote access architecture that actually implements zero-trust principles — one that works for both enterprise security teams managing thousands of remote workers and government agencies with strict compliance mandates — the gap between the marketing and the engineering becomes apparent quickly.
This post is about the engineering. Specifically, how we architect remote access infrastructure at IVO Networks that implements zero-trust principles in practice: no implicit trust based on network location, continuous verification of identity and device posture, least-privilege access, and real-time visibility into every connection. Not as a slide deck concept, but as a deployed architecture running in production environments across enterprise and federal customers.
What Zero Trust Actually Requires for Remote Access
NIST SP 800-207 defines the foundational principles of zero-trust architecture. For remote access specifically, the principles that matter most are: no resource is inherently trusted based on network location, every access request must be authenticated and authorized, access is granted per-session with least privilege, and the security posture of the requesting device is continuously evaluated.
For federal agencies, these aren't aspirational goals — they're mandated. OMB Memorandum M-22-09, issued in January 2022, established a Federal Zero Trust Architecture strategy aligned with CISA's Zero Trust Maturity Model. The strategy is organized around five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — with agencies required to meet specific objectives across each. On the Device pillar: agencies must maintain a complete inventory of every device authorized for government use and must prevent, detect, and respond to incidents on those devices. On the Network pillar: agencies must encrypt all DNS requests and HTTP traffic, and applications must not rely on network perimeter protections to guard against unauthorized access.
These requirements don't replace VPN — they redefine what VPN needs to do. A traditional VPN that grants broad network access after a single authentication event doesn't satisfy zero-trust requirements. But a VPN architecture that continuously validates identity, verifies device posture before and during connections, enforces granular access policies, and provides real-time telemetry into every session is fully consistent with zero-trust principles. The tunnel is the transport. The trust decisions happen around it.
The Device Identity Problem
In a zero-trust model, authenticating the user is necessary but not sufficient. You also need to authenticate the device — and not just at connection time. You need to know, continuously, that the device connecting to your network is a managed, authorized, healthy device that hasn't been compromised since it last checked in.
This is where the Trusted Platform Module (TPM) becomes a foundational component of the architecture. A TPM is a hardware security chip — physically embedded in the device's motherboard — that provides tamper-resistant storage for cryptographic keys and the ability to attest to the device's boot state and configuration. Unlike software-based credentials, a TPM key cannot be extracted, copied, or moved to another device. If a machine certificate is stored in the TPM, that certificate is bound to that specific physical device. Presenting it proves device identity at a hardware level, not just a software level.
In our architecture, device authentication relies on machine certificates stored in the device's TPM. When a device establishes a VPN connection, it presents its machine certificate as part of the IKEv2 authentication exchange. The concentrator appliance validates the certificate against the organization's PKI — verifying not just that the certificate is valid, but that it chains to the correct issuing CA and hasn't been revoked. Because the certificate is TPM-bound, this authentication proves the specific device's identity with a level of assurance that software-stored certificates cannot match.
ASAFE, our cloud-based management platform, provides centralized TPM security chip management across the deployed device fleet. IT teams can verify TPM health status, monitor certificate expiration, and enforce policies that require TPM-backed credentials for VPN access — all from a single dashboard without touching individual machines.
Always-On Connectivity: Device Tunnel and User Tunnel
Traditional VPN requires a user to launch a client, enter credentials, and connect. This model has two problems from a zero-trust perspective: managed devices are unprotected and unmanaged between connection events, and the user has to take an action to get on the network — which means there's a window where the device is online but not under organizational control.
Always-on VPN eliminates this window by establishing connectivity automatically, without user interaction. The architecture uses two distinct tunnel types that serve different purposes:
The device tunnel establishes before any user logs on. It authenticates using the machine certificate stored in the TPM — no user credentials involved. This tunnel provides the organization with connectivity to the device itself: the ability to push Group Policy updates, run management scripts, deploy software, and reach the device for remote administration. The device tunnel is always active whenever the device has internet connectivity, regardless of whether a user is logged in.
The user tunnel establishes after the user authenticates. It uses user credentials — typically with multi-factor authentication — and provides access to the resources the user is authorized to reach based on their identity, role, and the policies associated with their account. The user tunnel is where conditional access policies are evaluated: Is this user authorized? Is the device compliant? Is the MFA requirement satisfied? Is endpoint health within policy?
This two-tunnel architecture maps directly to the zero-trust principle of separating machine identity from user identity. The device tunnel proves the device is managed and authorized. The user tunnel proves the user is who they claim to be and that they're authorized for the resources they're requesting. Both assertions are required. Neither alone is sufficient.
Conditional Access: Making Trust Decisions Continuous
Authenticating the user and the device at connection time satisfies the initial trust decision. But zero trust requires continuous evaluation — the security posture of the session must be reassessed throughout the connection, not just at the beginning.
Conditional access policies provide this continuous evaluation layer. These policies evaluate a set of conditions every time a resource is accessed — not just at VPN connection time — and can enforce different requirements based on context:
Device compliance: Is the device's operating system patched to the required level? Is the endpoint protection agent running and reporting healthy? Is disk encryption enabled? Is the device still enrolled in the organization's management system? A device that was compliant at connection time but has since had its endpoint protection disabled should not continue to have the same level of access.
User risk: Has the user's account been flagged for unusual behavior? Has there been a sign-in from an unexpected location or a sign-in attempt that was blocked? Risk-based policies can require step-up authentication or restrict access when the user's risk profile changes during a session.
Application sensitivity: Not all resources require the same level of trust. Accessing a general intranet page might require only a valid user tunnel with a compliant device. Accessing a financial system or classified resource might additionally require phishing-resistant MFA, a specific device health posture, and connection from a managed network.
The concentrator appliance enforces the network-level access decisions — which traffic is allowed through which tunnel, which destinations are reachable, which ports and protocols are permitted. The identity provider evaluates the conditional access policies at the application layer. Together, they implement a layered enforcement model where the network layer provides coarse-grained access control and the application layer provides fine-grained authorization based on continuous policy evaluation.
Endpoint Health Verification
Device compliance goes beyond "is the device managed?" Zero trust requires visibility into the actual security posture of the endpoint — and the ability to act on that posture in real time.
Endpoint health verification in our architecture operates at multiple levels. At the network level, the VPN concentrator can evaluate health attributes presented during the connection handshake using standard protocols like Statement of Health (SoH) or device compliance claims passed through the authentication exchange. Devices that don't meet the minimum health requirements can be quarantined — placed on a restricted network segment with access only to remediation resources — rather than being granted full network access or being denied access entirely.
At the management level, ASAFE provides continuous visibility into endpoint health across the deployed fleet. Connection health, client status, failover state, and device posture data are collected and reported in real time. When a device falls out of compliance — a missed patch, a disabled security agent, an expired certificate — ASAFE's alerting system notifies the operations team immediately, and conditional access policies can automatically restrict the device's access until remediation is complete.
This creates a feedback loop that zero trust requires: verify posture, grant appropriate access, continuously monitor, detect drift, restrict access, remediate, re-verify, restore access. The loop runs continuously, not at point-in-time assessments.
High Availability and Failover
An always-on VPN architecture creates a dependency: if the VPN infrastructure goes down, remote users lose access to everything. In a traditional, user-initiated VPN model, an outage means users can't connect but can still work locally. In an always-on model, the VPN tunnel is the network — and losing it means losing connectivity to corporate resources entirely.
This makes high availability a security requirement, not just an availability requirement. If the concentrator fails and users can't connect, one of two things happens: either users find a way to work outside the VPN (which means working outside your security controls), or work stops. Neither is acceptable.
Our architecture addresses this through ASAFE's high-availability failover client technology (FC4AO). When the primary concentrator becomes unreachable, FC4AO detects the failure and automatically redirects VPN connections to a secondary concentrator — without user intervention and without dropping the tunnel longer than necessary. The failover is transparent to the user and transparent to the applications running over the tunnel.
For zero trust, this means the security controls — device authentication, conditional access, traffic filtering, telemetry collection — remain in force continuously, even during infrastructure failures. There's no window where devices revert to an uncontrolled state because the VPN concentrator is down. The architecture maintains the same trust model through failover as it does during normal operation.
Traffic Filtering and Segmentation
Zero trust rejects the notion that a device on the VPN should have unrestricted access to the corporate network. Historically, VPN meant "you're inside the perimeter now" — and once inside, lateral movement was largely unrestricted. That model is precisely what zero trust aims to eliminate.
Our concentrator appliances enforce traffic filtering policies that restrict VPN clients to only the resources they're authorized to access. These policies operate at the network level — specifying which destination IP ranges, ports, and protocols are permitted for each connection profile. A user in the finance department reaches finance systems. A field technician reaches the device management platform. Neither reaches resources they don't need.
This isn't microsegmentation at the application level — that's handled by the application layer and identity provider. This is network-level segmentation enforced at the tunnel termination point, which provides a coarse-grained but extremely effective first layer of access control. Even if an attacker compromises an endpoint and attempts lateral movement through the tunnel, the concentrator's traffic filtering limits what network segments are reachable from that tunnel profile.
App-triggered VPN profiles take this further. Rather than tunneling all device traffic through the VPN, specific applications can be configured to trigger VPN connections only when they need corporate resources. Non-corporate traffic goes directly to the internet. This reduces the attack surface on the concentrator, reduces bandwidth consumption, and ensures that only application-specific traffic reaches the corporate network — aligned with the zero-trust principle that access should be granted per resource, not per network.
Monitoring, Telemetry, and Continuous Authorization
You can't enforce zero trust without visibility. The continuous evaluation that zero trust demands requires continuous telemetry — who is connected, from what device, to which resources, with what posture, and for how long.
ASAFE provides this telemetry layer for the VPN infrastructure. Every connection is logged with its authentication details, device identity, health posture at connection time, and the resources accessed through the tunnel. Connection health is monitored continuously — not just whether the tunnel is up, but whether the connection quality, latency, and throughput are within expected parameters. Anomalies trigger alerts.
For government customers, this telemetry feeds directly into the agency's SIEM and security operations center. The data supports the Visibility and Analytics cross-cutting theme in CISA's Zero Trust Maturity Model — providing the operational visibility that agencies need to make risk-based authorization decisions. When an analyst can see, in real time, that a specific device has connected from an unusual location, has a degraded health posture, and is accessing resources it doesn't normally access, they have the information they need to intervene.
Continuous authorization means that the initial access decision isn't final. The system reassesses trust throughout the session and can revoke or restrict access based on changed conditions. A device that was healthy at 9 AM but had its endpoint protection disabled at 10 AM shouldn't maintain the same access at 10:01 AM. The combination of concentrator-level enforcement, conditional access policies, and ASAFE's real-time monitoring makes this possible.
Government Compliance Mapping
For federal agencies, zero trust isn't a design philosophy — it's a compliance requirement with specific deliverables and timelines. Here's how the architecture maps to the key frameworks:
NIST SP 800-207 (Zero Trust Architecture): The concentrator serves as both a Policy Enforcement Point (controlling network access) and contributes to the Policy Engine's inputs (providing device identity, authentication status, and connection telemetry). The separation of device tunnel and user tunnel maps to SP 800-207's principle that both the subject (user) and the device must be authenticated as discrete functions before a session is established.
OMB M-22-09 (Federal Zero Trust Strategy): The architecture addresses the Identity pillar (phishing-resistant MFA, enterprise-managed identities), the Device pillar (complete device inventory, TPM-backed identity, endpoint health monitoring), and the Network pillar (encrypted traffic, network-level access control that doesn't rely solely on perimeter defenses). ASAFE's monitoring capabilities support the Visibility and Analytics cross-cutting theme.
CISA Zero Trust Maturity Model: The architecture supports progression across maturity levels — from initial (basic VPN with MFA) through advanced (conditional access with device compliance) to optimal (continuous authorization with real-time telemetry and automated response). Organizations can adopt the architecture incrementally, starting with always-on connectivity and device tunnel, then layering conditional access, then integrating continuous monitoring and automated policy enforcement.
The Architecture as a Whole
Zero-trust remote access isn't a single product or a single technology. It's an architecture — a set of components that work together to implement the principle that trust is never implicit and always verified.
In the IVO Networks architecture, the components are: concentrator appliances that terminate VPN tunnels, authenticate devices and users, enforce traffic filtering policies, and provide the network-level enforcement point. ASAFE, the cloud-based management platform, provides real-time monitoring, high-availability failover, TPM management, and the operational telemetry that feeds continuous authorization decisions. And the endpoint — with its TPM-backed machine certificate, its compliance agent, and its always-on tunnel configuration — provides the device identity and health posture that the rest of the architecture depends on.
Each component addresses a specific zero-trust requirement. Together, they implement an architecture where every connection is authenticated at the device level and the user level, where access is continuously evaluated against policy, where endpoint health is monitored and enforced in real time, and where the operations team has full visibility into who is connected, from what, to where, and with what security posture.
That's what zero trust looks like when you move it from the whiteboard to the rack.
For more information about IVO Networks zero-trust remote access architecture, or to discuss how our concentrator appliances and ASAFE platform map to your organization's security and compliance requirements, contact our engineering team or reach out to your IVO Networks account representative.