Zero Trust

In the context of this guidance, a private application is an application or service that is not exposed to the public internet. These resources may be hosted on‑premises or within customer‑managed cloud environments.

Common examples of private applications include internal business systems such as HR platforms, finance systems, software development and test environments, and administrative or management interfaces.

In this section, a reference architecture is used to describe how access to private applications can be brokered using network-level components. This is just one example, and in practice, similar outcomes can also be achieved using application proxy approaches, where access is provided at the application layer.

Architecture overview 

Figure 1 shows that the user’s access begins on a managed end user device, which establishes a secure tunnel to a network policy engine. To reduce their attack surface, the private applications are not hosted on the internet, so a tunnel is required to ensure traffic can reach the policy engine and the application. This tunnel may be provided using a VPN, VPN-as-a-Service or a cloud platform such as Secure Service Edge (SSE) or Secure Access Service Edge (SASE).

At the edge of each network segment, a component designed to be exposed to the public internet such as a connector, proxy or a VPN endpoint is deployed and will establish outbound (reverse) tunnels to the policy engine. This allows access to be brokered without requiring inbound network connectivity to the application or hosting environment.

When a user attempts to access a private application, the network policy engine evaluates the request. It assesses signals such as user identity, device identity, device health, and user behavior indicators, and compares them against defined access policies.

If the network-level policy requirements are satisfied, traffic is permitted through the secure tunnel to the network segment hosting the application. At this stage, the network policy engine grants access to the relevant network segment rather than directly to the application itself.

Access to an application is then controlled by a separate application policy engine. This typically takes place during the organisation’s single sign-on (SSO) process.  The application policy engine verifies that the authenticated user is authorised to access the specific application, evaluating signals such as user and device identity, device health, and behavioural indicators.

Private resources are hosted in network segments that are separated according to their business criticality. Local network controls – such as firewalls (virtual or physical) or network access control lists –  prevent traffic flowing between segments, unless explicitly permitted. This helps to limit lateral movement and reduce the potential impact of compromise.

Network segments should be kept as small as is practical, balancing security benefits with operational manageability. Where possible, automation techniques such as infrastructure as code should be used to support the creation and management of smaller, more granular network segments.

All architectural components – including client software, policy engines, connectors and proxies – generate security and access logs. These logs should be collected centrally to provide visibility of access decisions, user behaviour, and system health. Centralised logging supports monitoring, investigation, and audit activities.

Availability should be considered throughout the design. Policies should be monitored and tested regularly to reduce the risk of unintended access disruption. Controlled break-glass access mechanisms must be implemented to support recovery during exceptional circumstances and they must be tightly governed, monitored, and regularly reviewed. Configurations should be deployed using infrastructure as code as this supports automated restoration of the environment in the event of a disaster.

Organisations increasingly rely on SaaS and productivity applications that are hosted in the cloud. These products are often used to store and process sensitive data.

Architecture overview

Figure 2 shows that a client device initiates a connection to a SaaS or productivity application using a secure transport mechanism, such as TLS. Rather than granting access immediately, the application redirects the user to the organisation’s SSO process for authentication and authorisation.

During the SSO process, the access request is evaluated by an application policy engine. Centralising this decision point ensures that access policies are applied consistently, regardless of the user or device location or network.

The application policy engine evaluates the access request and assesses multiple signals such as user identity, device identity, device health, and user behaviour indicators, and compares them against defined access policies.

If the request satisfies the defined policy, the user is issued a short-lived access token that permits access to the application. Tokens are intentionally time-limited so that access is not assumed to remain valid indefinitely.

Ideally, before the access token expires, signals should be re-evaluated before the user session is extended. This ensures that continued access reflects the current risk associated with the user and device. Where supported, investigate using context-aware access features that can automatically block or revoke access if the user’s context or device state changes.

In this approach, all routine user access to SaaS and productivity applications is routed through the application policy engine. A tightly controlled break-glass mechanism provides a limited exception for use during exceptional circumstances, such as service disruption or incident recovery.

All components involved in SaaS access generate security and access logs. These logs should be collected centrally to provide visibility of access decisions, user behaviour, and system health, supporting monitoring, investigation, and audit activities.