Zero Trust
How to understand, apply and evolve Zero Trust to protect your organisation’s systems, data and users.
Pages
Page 14 of 18
Signals and policy engines
This section describes the role of signals and policy engines within a ZTNA architecture. A policy engine evaluates signals about the identity, security posture, and behaviour of users and devices to determine whether an access request should be authorised. The focus here is on how decisions are made, rather than on how they are enforced, often referred to as policy enforcement points.
This section should be read alongside the NCSC’s zero trust architecture design principles and the wider ZTNA guidance. It should be adapted to reflect your organisation’s architecture, threat model and risk appetite.
What are signals?
Signals are data points used by a policy engine to evaluate an access request. To support robust and reliable decisions, policy engines should consume signals from multiple, independent sources relating to both the user and the device. No individual signal is perfect, but combining signals increases assurance and reduces reliance on any single control, making bypass more difficult.
Selecting the most appropriate signals for an environment can be challenging as requirements will vary depending on your architecture. Requirements will also evolve over time as threats change or new capabilities become available, so you should seek to continually review and adapt your signals.
A practical starting point is to define a baseline set of signals aligned to the NCSC’s zero trust architecture design principles about your user, service and device identities and user behaviour, service and device health.
In practice, this means prioritising signals relating to:
- User identity
- Device identity
- Device health
- User behaviour
The following are common examples of signals for each of these categories.
- 1
User identity signals
User identity signals are typically sourced from the organisation’s Identity Provider (IdP) which provides single sign-on (SSO) for most corporate services. Integration between the IdP and the policy engine is critical.
Examples of user identity signals include:
User and group membership
Integrating user and group information from the IdP into the policy engine enables evaluation of user and group memberships as part of an access decision. Policies may allow access to specific users or groups while denying others. For example, users in an HR group may be granted access to HR systems, while other departments are denied.
Authentication strength
Authentication strength reflects the assurance level of the authentication mechanism used. This may range from a password and time-based one-time password (TOTP) to stronger methods such as phishing-resistant credentials backed by cryptographic hardware (for example, hardware security keys or passkeys). Policies can require stronger authentication for higher-risk or more sensitive applications.
- 2
Device identity signals
Device identity signals establish that a request originates from a device owned and managed by the organisation.
Device identity should be cryptographically bound to hardware where possible, for example using a Trusted Platform Module (TPM). Hardware-backed identity reduces the risk of device spoofing compared to software-only approaches.
Combining both user and device identity allows organisations to have greater confidence that a known user is accessing a resource from a managed corporate device.
Examples of device identity signals include:
MDM-managed device identity
Some mobile device management (MDM) platforms manage device identity and integrate directly with policy engines. The policy engine can query the MDM to confirm that a device is enrolled and recognised. Organisations should understand how device credentials are generated, stored and protected within the MDM platform.
Device certificates
Alternatively, organisations may issue hardware-backed device certificates, such as a TPM. Many policy engines can verify the presence and validity of such certificates before granting access. This model can provide greater control over how device identity is issued, stored, and protected. An MDM may still be used for deployment, but the organisation retains oversight of the credential’s security properties.
- 3
Device health signals
After establishing trusted user and device identity, policy engines can incorporate signals describing device security posture. These signals assess whether a device is securely configured and not actively compromised.
Examples of device health signals include:
MDM-compliance status
An MDM can assess compliance against defined configuration baselines. The policy engine may query compliance status before authorising access to a resource. However, compliance checks may not operate in real time and can lag behind changes made on the device.
Endpoint Detection and Response (EDR) risk score
Some EDR platforms can provide near real-time device risk signals to a policy engine. Where supported, this enables access decisions to reflect the device’s current security state. Combining compliance status and EDR risk scores provides assurance of both the device’s configuration and its current security state.
- 4
User behaviour signals
User behaviour signals assess patterns of activity, rather than static identity attributes. These signals can help detect anomalous or high-risk activity.
Examples of user behaviour signals include:
User risk scores
User risk scores quantify behavioural risk in near real time, based on factors such as unusual login times, impossible travel, or other anomalous activity. This capability is often provided by an IdP or Secure Access Service Edge (SASE) platform.
Sign-in location controls
Policies may restrict access based on geographic location or known high-risk regions. Location-based signals are relatively weak when used alone, but can strengthen decisions when combined with stronger baseline signals such as identity, device trust, and authentication strength.
Policy engines
A policy engine evaluates contextual signals about an access request and applies policy to decide whether the request should be authorised.
Unlike traditional ‘walled garden’ architectures, which typically trust traffic based primarily on network location (for example, a VPN IP address), a policy engine evaluates multiple signals to make more explicit, context-aware authorisation decisions. This directly adheres to the NCSC’s zero trust architecture design principle of using policies to authorise requests.
The specific signals and policies implemented will vary according to environment, threat model, and organisational risk appetite.
When designing a ZTNA solution, it's important to understand where policy decisions are made within the architecture. Two common approaches are:
- Network-level policy engines.
- Application-level policy engines.
Organisations may deploy one or both approaches depending on their requirements.
- 1
Network-level policy engine
A network-level policy engine controls which network destinations a client can reach. These capabilities are commonly provided by cloud-based access platforms such as VPN-as-a-Service, Secure Service Edge (SSE) or SASE.
The policy engine evaluates signals associated with the request and determines whether traffic may reach a network segment. If access is authorised, the policy engine instructs a policy enforcement point (such as a proxy or connector) to forward the traffic.
This approach limits network exposure prior to application interaction.
- 2
Application-level policy engine
An application-level policy engine authorises access to an application or service.
Typically, a client attempting to access an application is redirected to a policy engine, often provided by an identity provider or SSO service. The policy engine evaluates signals associated with the request and, if authorised, issues a short-lived token. The client presents this token to the application to gain access.
While legacy federation standards such as Security Assertion Markup Language (SAML) may still be used for browser-based human access, zero trust architectures increasingly favour OAuth 2.0 and OpenID Connect which better support API access, non-human identities, granular authorisation, and continuous policy enforcement.
Applying policy at different architectural layers
Access policies may be applied at different layers in ZTNA architectures.
Applying policy at multiple layers
In some architectures, access control is applied at multiple layers. For example:
- a network-level policy engine first controls which network segments traffic can reach
- an application-level policy engine then authorises access to specific applications, typically as part of an SSO process.
This layered approach can reduce application exposure while enabling more granular access control.
Applying policy at identity and application layers
In other architectures, particularly where organisations don't manage the underlying application-hosting environment or network boundary, access decisions are primarily made at the identity and application layers. In these cases, applications rely on strong authentication, short‑lived tokens, and secure transport mechanisms.
Wherever access policies are applied, access should be:
- explicitly authorised
- based on multiple signals
- centrally logged and auditable
Illustrative examples of these approaches are provided in the reference architecture section of this guidance.