On-Premises ZTNA for Private Applications

On-premises ZTNA is a deployment of zero trust network access in which the policy enforcement point for private applications runs on infrastructure inside the organization’s own data centers and branches. Users and systems are authenticated and authorized per application, as with any ZTNA, but traffic between on-site users and on-site applications does not have to travel to a vendor cloud and back.

This article is part of the Hybrid Cloud Security guide.

How ZTNA works

ZTNA verifies each subject’s identity, device, and context, then connects it to a single application rather than a network.

NIST’s zero trust architecture, SP 800-207, separates the policy decision point (which decides whether a subject may reach a resource) from the policy enforcement point (which enables, monitors, and terminates the connection). ZTNA products implement that model for private applications:

1. A user or system requests access to an application.
2. The request reaches an enforcement point, usually a gateway, broker, or proxy.
3. Policy evaluates identity, group, device posture, location, risk, and the specific application requested.
4. If allowed, the enforcement point connects the subject to that application only. The rest of the network stays invisible.
5. The session is monitored and can be terminated if conditions change.

NIST’s practice guide SP 1800-35, Implementing a Zero Trust Architecture, published in June 2025, documents 19 sample implementations built with 24 vendors across on-premises and cloud environments, and is a useful reference for how these components fit together in practice.

Cloud-brokered vs. on-premises ZTNA

The difference is where the enforcement point runs: in the vendor’s cloud for every session, or on the customer’s own gateways for local sessions.

In a typical cloud-brokered model, a lightweight connector virtual machine runs next to the application and opens an outbound tunnel to the vendor’s gateway, so no inbound firewall ports are needed. Skyhigh Private Access works this way for remote access: client traffic is enforced at the SSE point of presence and routed over TLS tunnels to connectors deployed in the same data center, private cloud, or public cloud as the application.

On-premises ZTNA adds a local enforcement path so that users and systems inside the network get the same per-application control without leaving the building.

Why local enforcement matters

Local enforcement avoids hairpinning, reaches internal and AI agent traffic, and keeps working during cloud outages.

Hairpinning. Sending an office user’s traffic to a cloud broker and back to a server down the hall adds latency and internet dependency for no security benefit.

Internal traffic. Much of the traffic that zero trust should govern never crosses the internet edge: admin sessions, application-to-application calls, OT engineering access. Cloud-only enforcement does not see it.

AI agents and service accounts. Autonomous agents and service accounts can hold user-level access and move data between internal systems at machine speed. Skyhigh argues that enforcement for these flows must live inside the network where the traffic originates (Skyhigh Security).

Continuity. If the vendor cloud or internet link fails, local sessions continue under locally enforced policy. Confirm the supported disconnected window and the behaviour of posture and identity checks with your vendor.

Sovereignty. Local application traffic can stay on customer infrastructure. Record where policy decisions, identity checks, and session metadata are processed and stored. Where a Skyhigh session requires cloud-applied data protection, the relevant content is forwarded to the Skyhigh cloud for inspection under the same policy.

Identity checks

On-premises ZTNA should apply the same identity rigor as remote access:

• Authentication through the enterprise identity provider with phishing-resistant MFA
• Device posture: managed status, OS version, disk encryption, endpoint protection
• Group and role, mapped to per-application entitlements
• Context: location, time, risk score from behavior analytics
• Workload and agent identity for non-human access
• Continuous evaluation, with session termination if posture or risk changes

A common gap is exempting on-site users from device posture checks. Being on the corporate LAN is not a posture.

Connector and gateway placement

Place gateways close to the applications they protect, in redundant groups, with segmentation around them.

• Place gateways close to the applications they protect, on the same segment or adjacent to it, so the protected application is reachable only through the gateway.
• Deploy in groups for capacity and availability, and associate applications with groups rather than single gateways.
• Keep outbound-only connectivity for cloud-brokered paths, so applications are not exposed to inbound connections.
• Use customer-managed network segmentation to limit a compromised gateway from reaching unrelated systems.
• Plan for branches. Decide whether each branch gets a local gateway or reaches a regional one.

Local access paths

A hybrid ZTNA design needs three explicit access paths, all governed by one policy:

1. On-site user to on-site application: local gateway, no cloud round trip.
2. Remote user to on-site application: cloud broker to local connector or gateway.
3. On-site user to cloud-hosted application: local gateway or cloud broker to a connector in the cloud environment.

All three should use one policy definition, so a user’s entitlements do not change with location.

A zero trust architecture example for hybrid cloud

A hybrid zero trust architecture combines local and cloud enforcement under one identity and policy layer, as this example shows.

Consider a financial services firm with a headquarters data center, 40 branches, an IaaS environment, and a remote workforce.

• Identity: One identity provider with MFA; device posture from endpoint management.
• Headquarters: Local ZTNA gateways front the core banking admin interfaces and internal tools. Staff on site connect directly through the local gateway.
• Branches: Branch gateways enforce access to branch systems and forward to headquarters gateways for central applications.
• IaaS: Connectors in the cloud environment front workloads; remote and on-site users reach them through the appropriate broker.
• Remote staff: Cloud points of presence broker access to both data center and IaaS applications.
• AI agents: Service identities for internal AI assistants receive per-application entitlements and are enforced locally.
• Policy: One set of rules governs all paths, pushed from a single console.

If the internet link fails, headquarters and branch staff keep working against local applications, and local enforcement continues for the supported disconnected window.

Deployment requirements to evaluate

Evaluate on-premises ZTNA against these requirements before shortlisting vendors.

• Local enforcement for on-site users without cloud hairpinning
• Same policy and entitlements for local and remote paths
• Device posture enforcement for on-site users
• Support for non-human identities and AI agents
• Protocol coverage: web, SSH, RDP, database, and legacy TCP/UDP
• High availability and connector groups
• Defined behavior when the vendor cloud or identity provider is unreachable
• Logging location and SIEM integration
• Integration with web gateway and DLP so private-app sessions get data protection

Zero trust architecture software for hybrid cloud

ZTNA is one component of a hybrid zero trust architecture.

It works alongside identity providers, endpoint management, web gateways, CASB, DLP, and segmentation. Evaluate ZTNA as part of the platform that will enforce the rest of your policy, not as a standalone VPN replacement. See Hybrid Cloud Security Solutions: How to Compare Vendors.

How Skyhigh delivers on-premises ZTNA

Skyhigh delivers on-premises ZTNA through local gateways in Hybrid SSE Mesh, alongside cloud-brokered Private Access.

In Skyhigh Hybrid SSE Mesh, local ZTNA runs on the organization’s own on-premises and branch gateways on infrastructure the organization owns and changes under its own control, rather than on a vendor-operated local node, extending zero trust enforcement to internal users, resources, and AI agents. Skyhigh Private Access continues to broker remote access through Skyhigh points of presence, and both are managed under one console and policy engine alongside SWG, CASB, and DLP.

Sources

1. NIST. SP 800-207: Zero Trust Architecture (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST NCCoE. SP 1800-35: Implementing a Zero Trust Architecture (June 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
3. CISA. Zero Trust Maturity Model, Version 2.0. https://www.cisa.gov/zero-trust-maturity-model
4. Skyhigh Security. “How Skyhigh Private Access Works.” https://success.skyhighsecurity.com/docs/how-skyhigh-private-access-works
5. Skyhigh Security. “Modernizing Your Symantec Edge Secure Web Gateway With Skyhigh Hybrid SSE Mesh” (July 15, 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html