In Part 1 of our Zero Trust Office blog series, Jose Padin discussed how and why organizations should use Zero Trust to support their return-to-office strategies, replacing legacy network trust models with future-ready architectures. Building on those insights, this post shifts the focus to a specific challenge: adapting Zero Trust principles for on-premises environments to create a unified security framework for hybrid workforces.When the pandemic made remote work the norm, organizations everywhere embraced Zero Trust to secure remote access. Now, as employees return to physical offices, many organizations risk falling back into outdated practices such as network-based security policies, where the local office network is treated as inherently trustworthy.It’s time to rethink the traditional on-premises paradigm—not by reinventing the wheel, but by extending the proven principles of Zero Trust Network Access (ZTNA) to in-office operations.Traditional Perimeter Based SecurityIn the traditional perimeter-based network security model, connecting to the agency office put the workstation device on the trusted network:Connecting to the network provides a presumption of access – that is if you are on the network, you have access to all the applications, resources, and data that the network provides. To help mitigate the concerns of an unauthorized user or device connecting to the trusted network, you might implement a tool like Network Access Control (NAC) to control admission to the network – don’t let an untrusted device connect unless it has a certificate issued by the agency PKI for example. This is a good step, but it leaves a lot to be desired from a segmentation and least privilege access security model, mainly that the Trusted Network provides:Excessively Broad Access: Once on the network, devices gain access to any resource on the network. There might be firewall access control lists to prevent a general user VLAN from accessing a HVA network, but nothing to prevent a user administering grants from also connecting to the front door of a finance application. The network needs to provide transport and reachability to anyone who might need to access anything and isn’t necessarily aware of a user job role in relation to the applications they access.Lack of Granularity: Traditional tools work well for broad allow/deny decisions but don’t adapt well based on context. For example, if a device is behind on OS updates when it connects to the network, it might be put in a quarantine VLAN that only has access to SCCM. But what if the device’s security risk changes? – the EDR like CrowdStrike or Defender reports a drop in the device health score because of a recent threat seen? The device has already been admitted to the network, but now has a risk that should result in less access to internal apps and resources. Segmentation works for broad categories (e.g., isolating high-value assets), but fine-grained user or device-based controls are difficult to implement.Discoverability of Internal Network: Most importantly, since the user network is considered trusted, a device can discover the topology and layout of the network. The device can find the internal network addressing of services versus workstations, discover and enumerate queries against DNS servers, internal Active Directory resources, and if that device was compromised by an attacker, the attacker would be able to conduct reconnaissance as a normal user to identify attack vectors. A network’s currency is IP addresses – it’s not users, it’s not applications – the network simply isn’t aware because the network is Layer 3, not Layer 7. Trying to use the network as a Layer 7 access engine will always be challenging because ultimately network security rules are based on IP addresses and just aren’t aware of the Layer 7 context that’s needed for ZTNA.ZTNA offers a modern, scalable alternative that:Narrows access scope with granular app specific connectionsIntroduces dynamic policy enforcement based on identity and device postureEnables ongoing assessment with continuous, per-access evaluationBringing Zero Trust On-PremisesWith telework, agencies proved that users could securely access their applications through the Zscaler Zero Trust Exchange, a cloud-based policy enforcement point that evaluates the context of a connection request against the application being accessed and grants access based on need-to-know using least privileged access:Access to an internal application is only granted if a user has been granted access based on their role and the context of the connection. For example, a user in grants management won’t be able to access a finance application because there is an access policy in the Zero Trust Exchange that says only grants users can access grants applications. The GFE desktop is not on the agency internal network, knows nothing of the internal network addressing or DNS because it has no need to. The user can safely access their applications from their home ISP because all connections are encrypted end-to-end with TLS.Always-On Protection for UsersWhen coming into the office, that same security access model can be provided. Instead of considering the user access network at the field offices as part of the trusted network, in the ZTNA approach, the user access network is untrusted and provides nothing more than filtered and protected Internet access, similar to an Internet cafe. There is no presumption of trust by connecting to the network. As a result, the user workstations are no longer considered trusted, have moved out of the trusted network zone, and are protected the exact same way as a user working from home, using the same ZTNA access policies.Afterall, why should coming into a field office provide any difference in security from a user working from home? Coming into an agency office and connecting to the network shouldn’t give you any more access to applications and service than a user working from home on their Home ISP. The network should be transport-only without any presumptive privilege a.k.a. Cafe-style Internet access. Access and authorization is based on identity, device, and the application (not IP address) being accessed. A policy enforcement point arbitrates every access decision and makes a need-to-know access decision based on access policies, not network firewall ACLs, on which applications which users should access, from what devices.A question I often get – does this mean that users at a field office would have to go out to the Internet to access an application that might be sitting next to them – for instance in HQ offices that have data centers? Of course not! The technical solution that enables users in the field office to access their private applications without adding additional latency is called a Zscaler Private Service Edge which sits on the agency network and provides a local broker for stitching connections together between users and application connectors. The Private Service Edge is a VM or Linux RPM, just like the App Connector. To explain: with telework, a user connects to the closest Zscaler Public Service Edge of our FedRAMP cloud, that acts as a broker that stitches a connection together from of the App Connectors in the agency datacenter and hosting environments:When the user comes on prem to the Cafe-style untrusted network, the Zscaler Client Connector on their workstation will automatically find the local Private Service Edge and broker the data connection to a private application through the agency network without going out to the Internet and back:The only thing needed to implement is a simple ACL from the cafe-style Internet-only network to the Private service edge like so:SourceDestinationPort/ProtocolCafe User NetworkPrivate Service Edgetcp/443, outboundApp ConnectorPrivate Service Edgetcp/443, outboundThis enables secure access to private applications without any compromise to latency or performance for the end user. User’s Internet traffic continues to get protected against a Zscaler Public Service Edge, just like it would be for a user working remotely:In this architecture, ZCC is always-on regardless of whether the user is off-prem or on-prem, there is one policy engine protecting and securing all the traffic, Internet and Private.Zero-Trust for On-PremJust as it revolutionized remote work, Zero Trust can overhaul office access by eliminating misplaced trust in the network and focusing on user, device, and application policies. This shift in architecture requires a shift in thinking. Extend ZTNA Access Policies to On-Prem Users: Access policy follows the user, not the network they are connected to. Access is ubiquitous regardless of where a user is connecting from with the same policy enforcement for all connection forms.Move from Network Access to Resource Access: Traditionally, employees connect to the network first, then access resources. With Zero Trust, users jump straight to applications through policy-based, identity-driven connections. This eliminates the need to grant broad access to the network itself.Treat the Office Network Like the Internet: Think of your office Wi-Fi as “cafe-style internet.” It simply connects users to the Zero Trust Exchange, where security policies take over. No inbound traffic. No implicit trust. Just secure, conditional connections between users and their specific resources.Continuous Trust Validation: Zero Trust evaluates each access request dynamically, monitoring device posture, context, and risk signals. This guarantees that no connection remains static—a cornerstone of modern security.The beauty of Zero Trust is its ability to deliver consistency. Employees don’t need to worry about whether they’re “on-prem” or “remote.” They are accessing applications the same way no matter where they are working. This unified experience not only ensures users remain productive it also simplifies IT administration.The Road ForwardThe Zero Trust Office is readily achievable today. By applying the same principles used for telework to in-office operations, organizations can significantly reduce risk, improve user experience, and create a future-ready security architecture.In Part 3 of this blog series, we’ll examine how Zero Trust comes full circle with enhanced visibility and user experience, ensuring IT teams can continuously monitor and optimize connections no matter the location.Read Part 1: The Return-to-Office Blueprint: Modernizing the Workplace with Zero Trust
[#item_full_content] In Part 1 of our Zero Trust Office blog series, Jose Padin discussed how and why organizations should use Zero Trust to support their return-to-office strategies, replacing legacy network trust models with future-ready architectures. Building on those insights, this post shifts the focus to a specific challenge: adapting Zero Trust principles for on-premises environments to create a unified security framework for hybrid workforces.When the pandemic made remote work the norm, organizations everywhere embraced Zero Trust to secure remote access. Now, as employees return to physical offices, many organizations risk falling back into outdated practices such as network-based security policies, where the local office network is treated as inherently trustworthy.It’s time to rethink the traditional on-premises paradigm—not by reinventing the wheel, but by extending the proven principles of Zero Trust Network Access (ZTNA) to in-office operations.Traditional Perimeter Based SecurityIn the traditional perimeter-based network security model, connecting to the agency office put the workstation device on the trusted network:Connecting to the network provides a presumption of access – that is if you are on the network, you have access to all the applications, resources, and data that the network provides. To help mitigate the concerns of an unauthorized user or device connecting to the trusted network, you might implement a tool like Network Access Control (NAC) to control admission to the network – don’t let an untrusted device connect unless it has a certificate issued by the agency PKI for example. This is a good step, but it leaves a lot to be desired from a segmentation and least privilege access security model, mainly that the Trusted Network provides:Excessively Broad Access: Once on the network, devices gain access to any resource on the network. There might be firewall access control lists to prevent a general user VLAN from accessing a HVA network, but nothing to prevent a user administering grants from also connecting to the front door of a finance application. The network needs to provide transport and reachability to anyone who might need to access anything and isn’t necessarily aware of a user job role in relation to the applications they access.Lack of Granularity: Traditional tools work well for broad allow/deny decisions but don’t adapt well based on context. For example, if a device is behind on OS updates when it connects to the network, it might be put in a quarantine VLAN that only has access to SCCM. But what if the device’s security risk changes? – the EDR like CrowdStrike or Defender reports a drop in the device health score because of a recent threat seen? The device has already been admitted to the network, but now has a risk that should result in less access to internal apps and resources. Segmentation works for broad categories (e.g., isolating high-value assets), but fine-grained user or device-based controls are difficult to implement.Discoverability of Internal Network: Most importantly, since the user network is considered trusted, a device can discover the topology and layout of the network. The device can find the internal network addressing of services versus workstations, discover and enumerate queries against DNS servers, internal Active Directory resources, and if that device was compromised by an attacker, the attacker would be able to conduct reconnaissance as a normal user to identify attack vectors. A network’s currency is IP addresses – it’s not users, it’s not applications – the network simply isn’t aware because the network is Layer 3, not Layer 7. Trying to use the network as a Layer 7 access engine will always be challenging because ultimately network security rules are based on IP addresses and just aren’t aware of the Layer 7 context that’s needed for ZTNA.ZTNA offers a modern, scalable alternative that:Narrows access scope with granular app specific connectionsIntroduces dynamic policy enforcement based on identity and device postureEnables ongoing assessment with continuous, per-access evaluationBringing Zero Trust On-PremisesWith telework, agencies proved that users could securely access their applications through the Zscaler Zero Trust Exchange, a cloud-based policy enforcement point that evaluates the context of a connection request against the application being accessed and grants access based on need-to-know using least privileged access:Access to an internal application is only granted if a user has been granted access based on their role and the context of the connection. For example, a user in grants management won’t be able to access a finance application because there is an access policy in the Zero Trust Exchange that says only grants users can access grants applications. The GFE desktop is not on the agency internal network, knows nothing of the internal network addressing or DNS because it has no need to. The user can safely access their applications from their home ISP because all connections are encrypted end-to-end with TLS.Always-On Protection for UsersWhen coming into the office, that same security access model can be provided. Instead of considering the user access network at the field offices as part of the trusted network, in the ZTNA approach, the user access network is untrusted and provides nothing more than filtered and protected Internet access, similar to an Internet cafe. There is no presumption of trust by connecting to the network. As a result, the user workstations are no longer considered trusted, have moved out of the trusted network zone, and are protected the exact same way as a user working from home, using the same ZTNA access policies.Afterall, why should coming into a field office provide any difference in security from a user working from home? Coming into an agency office and connecting to the network shouldn’t give you any more access to applications and service than a user working from home on their Home ISP. The network should be transport-only without any presumptive privilege a.k.a. Cafe-style Internet access. Access and authorization is based on identity, device, and the application (not IP address) being accessed. A policy enforcement point arbitrates every access decision and makes a need-to-know access decision based on access policies, not network firewall ACLs, on which applications which users should access, from what devices.A question I often get – does this mean that users at a field office would have to go out to the Internet to access an application that might be sitting next to them – for instance in HQ offices that have data centers? Of course not! The technical solution that enables users in the field office to access their private applications without adding additional latency is called a Zscaler Private Service Edge which sits on the agency network and provides a local broker for stitching connections together between users and application connectors. The Private Service Edge is a VM or Linux RPM, just like the App Connector. To explain: with telework, a user connects to the closest Zscaler Public Service Edge of our FedRAMP cloud, that acts as a broker that stitches a connection together from of the App Connectors in the agency datacenter and hosting environments:When the user comes on prem to the Cafe-style untrusted network, the Zscaler Client Connector on their workstation will automatically find the local Private Service Edge and broker the data connection to a private application through the agency network without going out to the Internet and back:The only thing needed to implement is a simple ACL from the cafe-style Internet-only network to the Private service edge like so:SourceDestinationPort/ProtocolCafe User NetworkPrivate Service Edgetcp/443, outboundApp ConnectorPrivate Service Edgetcp/443, outboundThis enables secure access to private applications without any compromise to latency or performance for the end user. User’s Internet traffic continues to get protected against a Zscaler Public Service Edge, just like it would be for a user working remotely:In this architecture, ZCC is always-on regardless of whether the user is off-prem or on-prem, there is one policy engine protecting and securing all the traffic, Internet and Private.Zero-Trust for On-PremJust as it revolutionized remote work, Zero Trust can overhaul office access by eliminating misplaced trust in the network and focusing on user, device, and application policies. This shift in architecture requires a shift in thinking. Extend ZTNA Access Policies to On-Prem Users: Access policy follows the user, not the network they are connected to. Access is ubiquitous regardless of where a user is connecting from with the same policy enforcement for all connection forms.Move from Network Access to Resource Access: Traditionally, employees connect to the network first, then access resources. With Zero Trust, users jump straight to applications through policy-based, identity-driven connections. This eliminates the need to grant broad access to the network itself.Treat the Office Network Like the Internet: Think of your office Wi-Fi as “cafe-style internet.” It simply connects users to the Zero Trust Exchange, where security policies take over. No inbound traffic. No implicit trust. Just secure, conditional connections between users and their specific resources.Continuous Trust Validation: Zero Trust evaluates each access request dynamically, monitoring device posture, context, and risk signals. This guarantees that no connection remains static—a cornerstone of modern security.The beauty of Zero Trust is its ability to deliver consistency. Employees don’t need to worry about whether they’re “on-prem” or “remote.” They are accessing applications the same way no matter where they are working. This unified experience not only ensures users remain productive it also simplifies IT administration.The Road ForwardThe Zero Trust Office is readily achievable today. By applying the same principles used for telework to in-office operations, organizations can significantly reduce risk, improve user experience, and create a future-ready security architecture.In Part 3 of this blog series, we’ll examine how Zero Trust comes full circle with enhanced visibility and user experience, ensuring IT teams can continuously monitor and optimize connections no matter the location.Read Part 1: The Return-to-Office Blueprint: Modernizing the Workplace with Zero Trust
