Key Takeaways:

• Clientless ZTNA simplifies access but lacks strong device trust on its own. While clientless ZTNA enables agentless access for BYOD and contractors, its reliance on browser headers for posture information makes device trust weak and easily spoofable, limiting effective policy enforcement.
• Enterprise browsers provide trusted posture and in-browser security but lacks private access. Enterprise browsers offer centrally managed, cryptographically verifiable device posture and strong controls like DLP and phishing protection, but they cannot independently connect users to non-internet-facing applications.
• Together, clientless ZTNA and enterprise browsers enable true zero-trust, browser-native access. Clientless ZTNA integration with enterprise browsers delivers trusted posture validation, per-application access, dynamic policy enforcement on every request, and a seamless user experience without additional agents making this combination a key building block for modern SSE and SASE architectures. 

As enterprises accelerate towards cloud-first architectures, distributed workforces, and high levels of Software-as-a-Service (SaaS) adoption, the web browser has become the primary access point for corporate resources. In parallel, Zero Trust Network Access (ZTNA) has emerged as a modern alternative to Virtual Private Networks (VPNs), providing least-privilege access to applications instead of full network-level connectivity. ZTNA has been widely adopted and evolving for the AI era. 

This blog explores one such evolution of clientless ZTNA with enterprise browsers, as they complement one another to deliver stronger, simpler secure access for enterprise security.

Zero Trust Network Access (ZTNA)

Zero Trust Network Access (ZTNA)operates on a “never trust always verify” principle. In a traditional VPN model, once a user is authenticated, they gain broad access to the corporate network. This implicit trust exposes organizations to lateral movement, compromised endpoints, and privilege misuse.

ZTNA inverts this model, instead of granting entire network access, ZTNA brokers for each connection and allows access only to specific applications based on identity and policy. Each request is evaluated independently, enforcing a true Zero Trust as specified by NIST Zero Trust Architecture.

ZTNA Offerings:

Currently ZTNA is offered in two ways,

1. Client-Based ZTNA, where a lightweight agent is installed on the user’s device. The client intercepts traffic, applies policies, and securely routes allowed flows into the private network. 

2. Clientless ZTNA, where no agent installation is required. Users access private applications through a browser, and the ZTNA service proxies traffic based on authentication and policy. Clientless ZTNA is usually used for Bring Your Own Device (BYOD) and contractor/partner use cases where it’s difficult to install an agent on the device.

Limitation of clientless ZTNA

Clientless ZTNA depends on the browser headers for the posture information such as browser type, OS type, OS version, or other device attributes. These http headers are easily spoof-able, not cryptographically verifiable and often inconsistent. As a result, administrators’ capability to enforce rules such as blocking outdated OS, unpatched browsers, and requiring disk encryption is limited. This was noted by Etay Maor in his article that clientless ZTNA posture enforcement as the band aid solution to ZTNA.

Rise of Enterprise Browser

As browsers are increasingly becoming the workspace for cloud apps, SaaS, and internal web tools, enterprise has sought ways to enforce more security controls to manage browser activity. The enterprise browsers provide admins capabilities to centrally manage policy enforcement, enhance security with data loss prevention, phishing and malware detection, and more. Many of the commercial browsers have enterprise additional capabilities such as chrome enterprise, edge enterprise, etc. This makes adoption of enterprise browser by end users much easier.

Gartner predicts that by 2028, 25% of organizations will augment existing secure remote access and endpoint security tools by deploying at least one secure enterprise browser technology to address specific gaps."

Limitation of enterprise Browser

Enterprise browsers excel at controlling users’ behavior with the browser. However, they cannot still independently provide secure private access to the non-internet facing applications. They cannot create network connectivity to internal applications and admins still need to depend on VPN or tunnels.

Clientless ZTNA and enterprise browser made for each other

Clientless ZTNA and enterprise browsers each address a piece of the security puzzle, but neither is complete alone. Enterprise browsers are fully managed and trusted by administrators. This means they can provide cryptographically signed posture information and clientless ZTNA service can query secure browser Application Programing Interfaces (APIs) to verify device state such as posture checks (OS version, patch level, EDR status, extensions, policies) become tamper-proof.

Also, by integrating with clientless ZTNA, the enterprise browser gains secure private-app access without additional agents. Users can connect to internal apps directly from the managed browser. Enterprises reduce employees and contractors need to install and manage an additional client. 

Together they deliver

1. Trust device posture enforcement

2. Secure per app level access.

3. Browser level DLP, anti-phishing and activity controls.

4. Zero deployment overhead for end users.

By integrating the posture of enterprise browsers along with clientless zero trust capabilities, admins can achieve dynamic policy based governance on every request as suggested by Durgaprasad Balakrishnan in his RSAC blog article.  Due to these benefits, we will continue to see more integration of enterprise browsers and ZTNA across various vendors and enhanced adoption by administrators.