This post is also available in Español, 简体中文, 한국어 and 日本語.
Starting today, you can build Zero Trust rules that require periodic authentication to control network access. We’ve made this feature available for years for web-based applications, but we’re excited to bring this level of granular enforcement to TCP connections and UDP flows.
We’re excited to announce that Zero Trust client-based sessions are now generally available. During CIO Week in 2021, we announced the beta program for this feature. We incorporated feedback from early users into the generally available version. In this post, I will revisit why Zero Trust client-based sessions are important, how the feature works and what we learned during the beta.
Securing traffic with Sessions
We built Zero Trust client-based sessions to enhance the security of Cloudflare’s Zero Trust Network Access (ZTNA). The Zero Trust client is software that runs on a user machine and forwards all traffic from the machine to Cloudflare before it is sent over the Internet. This includes traffic bound for internal IPs and hostnames that typically house sensitive business applications. These sensitive applications were traditionally accessed using a VPN. Unlike VPNs, Cloudflare’s ZTNA allows administrators to set granular policies about who can access a specific resource. The only piece missing was that once a user enrolled their machine with the Zero Trust client, they had a forever persistent session. This makes lost/stolen laptops, shared workstations and personal devices more of a risk than they should be. We built Zero Trust client-based sessions to solve this.
Zero Trust client-based sessions require a user to reauthenticate with their identity provider before accessing specific resources. The authentication pop-up is triggered only when a user attempts to access a protected resource. This prevents unnecessary pop-ups to users where a session may never be necessary. Administrators can specify how often they would like their users to reauthenticate, depending on the resource. This is possible because the user’s last successful authentication is saved and evaluated against any ZTNA policy with a session configured.
What we learned during the beta period
During the beta period of Zero Trust client-based sessions, we worked closely with our customers and Cloudflare’s own security team to identify areas for immediate improvement. We identified two major areas of improvements before releasing to General Availability: pop-ups, which can be intrusive, and browser-based authentication, which is not always possible. We identified new strategies for properly serving an authentication pop up to a user without being overly intrusive. In the future, users will have control over when they receive notifications to authenticate. The other area for improvement was that on certain machines and operating systems, browser-based authentication is not always possible. We are planning to add an option to authenticate directly from the Zero Trust client itself.
This is only the beginning for Zero Trust client-based authentication. In the future, we plan to add options for step-up multifactor authentication and automated enrollment options via certificates and Service Tokens. Getting started is easy! Follow this guide for setting up Zero Trust client-based sessions in your Cloudflare Zero Trust dashboard.