Zero Trust Network Access
Zero Trust Network Access (ZTNA) enforces access decisions based on verified identity, device health, and request context rather than network location. The model eliminates the concept of a trusted internal network, requiring explicit verification for every connection attempt regardless of whether the user sits in a headquarters office, a field location, or a coffee shop. For organisations operating across multiple countries with staff connecting from diverse and unpredictable locations, ZTNA addresses the fundamental reality that perimeter-based security assumptions no longer hold.
- Zero Trust
- A security model requiring verification of every access request regardless of source location or prior authentication state. The core principle is “never trust, always verify.”
- ZTNA (Zero Trust Network Access)
- The application of zero trust principles to network access, replacing or augmenting VPN-based remote access with identity-aware, application-specific connectivity.
- Identity Provider (IdP)
- A system that authenticates users and issues assertions of their identity to relying applications. Keycloak, Authentik, Microsoft Entra ID, and Okta function as identity providers.
- Policy Enforcement Point (PEP)
- The component that intercepts access requests and enforces decisions made by the policy engine. In ZTNA architectures, this is the broker or proxy.
- Policy Decision Point (PDP)
- The component that evaluates access requests against policy and returns permit or deny decisions.
- Device Posture
- The security state of a connecting device: operating system patch level, disk encryption status, presence of endpoint protection, compliance with configuration baselines.
- Micro-segmentation
- Network security technique that isolates workloads and enforces access controls between them, preventing lateral movement after initial access.
The trust model
Traditional network security operates on implicit trust derived from network position. A device connected to the corporate LAN or authenticated through a VPN receives broad access to network resources because the security model assumes that reaching the internal network required passing through perimeter controls. This assumption fails in practice. Credentials leak through phishing. Devices become compromised. VPN concentrators grant access to entire network segments rather than specific applications. A single compromised credential can expose file servers, HR systems, financial applications, and infrastructure management tools simultaneously.
ZTNA inverts this trust model. No device or user receives implicit trust based on network location. Every access request undergoes evaluation against multiple factors: the identity of the requesting user, verified through the identity provider; the security posture of the requesting device, assessed at connection time; the sensitivity of the requested resource; and the context of the request including location, time, and behavioural patterns. The security boundary moves from the network perimeter to the individual application.
Consider a finance officer accessing the grants management system. Under perimeter security, authenticating to the VPN grants access to the network segment containing the grants system, the HR database, the file servers, and potentially the domain controllers. Under ZTNA, the finance officer authenticates to the identity provider, presents device posture evidence, and receives access specifically to the grants management system. The HR database, file servers, and domain controllers remain invisible and unreachable because no policy authorises that user to access those resources.
The trust evaluation happens continuously rather than at a single authentication moment. A session established at 09:00 with a compliant device can be terminated at 09:15 if the device falls out of compliance, if the user’s account shows signs of compromise, or if the access pattern deviates from established baselines.
Architecture components
ZTNA implementations vary across vendors and deployment models, but share common architectural components that interact to evaluate and enforce access decisions.
+------------------------------------------------------------------+| ACCESS REQUEST |+------------------------------------------------------------------+ | v+------------------+ +------------------+ +------------------+| | | | | || User + Device +---->+ ZTNA Broker +---->+ Application || | | (Policy | | || - Identity | | Enforcement) | | - Grants system || - Device cert | | | | - File storage || - Posture data | +--------+---------+ | - Email || | | | |+------------------+ | +------------------+ | +------------------------+------------------------+ | | | v v v+------------------+ +------------------+ +------------------+| | | | | || Identity | | Policy | | Device || Provider | | Engine | | Trust || | | | | Service || - Authenticate | | - Evaluate | | || - MFA | | context | | - Posture || - Group claims | | - Apply rules | | assessment || | | - Log decision | | - Compliance |+------------------+ +------------------+ +------------------+Figure 1: ZTNA component architecture showing verification flow from access request through policy enforcement to protected application
The ZTNA broker serves as the policy enforcement point, intercepting all access requests before they reach protected applications. The broker never grants network-level access; it proxies application-level connections after verifying authorisation. Users interact with applications through the broker without direct network connectivity to application servers. This design means protected applications can reside on isolated networks with no inbound connectivity from the internet or general corporate network.
The identity provider authenticates users and issues tokens containing identity claims: username, group memberships, role assignments, authentication strength, and other attributes relevant to access decisions. The ZTNA broker validates these tokens and extracts claims for policy evaluation. Federation between the identity provider and ZTNA system enables single sign-on, allowing users to authenticate once and access multiple applications without repeated credential entry.
The policy engine evaluates access requests against defined rules. Inputs include user identity claims, device posture data, resource sensitivity classification, and request context. Outputs are permit or deny decisions with associated logging. Policy engines range from simple attribute matching to sophisticated systems supporting complex conditional logic.
The device trust service assesses the security posture of connecting devices. Assessment mechanisms include agents installed on managed devices that report configuration state, certificate-based device identity that proves enrolment in device management, and postureless approaches that accept connections from unmanaged devices with correspondingly restricted access.
Authentication flow
A complete ZTNA authentication involves multiple verification steps executed in sequence. The following diagram illustrates a typical flow for a user accessing a protected application for the first time in a session.
User ZTNA Broker Identity Provider Application | | | | |----(1) Access request--->| | | | | | | |<---(2) Redirect to IdP---| | | | | | | |----(3) Authenticate-------------------------------->| | | | | | |<---(4) MFA challenge--------------------------------| | | | | | |----(5) MFA response-------------------------------->| | | | | | |<---(6) Token + claims-------------------------------| | | | | | |----(7) Token + posture-->| | | | | | | | |----(8) Validate token--->| | | | | | | |<---(9) Token valid-------| | | | | | | |----(10) Evaluate-------->| | | | policy (internal) | | | | | | | |----(11) Proxy request--------------------------->| | | | | |<---(12) Application response------------------------------------------------| | | | |Figure 2: ZTNA authentication sequence showing twelve steps from initial access request through application response
The flow begins when a user attempts to access a protected application. The ZTNA broker intercepts the request (step 1) and, finding no valid session, redirects the user to the identity provider (step 2). The user authenticates with credentials (step 3), receives a multi-factor authentication challenge (step 4), and completes verification (step 5). Upon successful authentication, the identity provider issues a token containing identity claims (step 6).
The user’s browser or agent presents the token along with device posture data to the ZTNA broker (step 7). The broker validates the token with the identity provider (steps 8-9) to confirm authenticity and check for revocation. With valid identity established, the broker evaluates the access request against policy (step 10), considering user claims, device posture, and request context. If policy permits access, the broker proxies the request to the application (step 11) and returns the response to the user (step 12).
This sequence requires three to five network round trips at minimum. On low-latency connections with round-trip times under 50 milliseconds, the entire flow completes in under one second. The latency implications for field deployment are significant; a connection with 600 milliseconds round-trip time to the broker requires four to six seconds for initial authentication.
Policy model
ZTNA policies combine multiple attributes to determine access decisions. Policies express conditions that must be satisfied for access to proceed, with the policy engine evaluating these conditions against current request context.
+-----------------------------------------------------------------------+| POLICY DECISION |+-----------------------------------------------------------------------+| || IF user.groups CONTAINS "finance-team" || AND device.managed = true || AND device.encryption = enabled || AND device.os_patch_age < 30 || AND request.resource = "grants-system" || AND (request.country IN ["GB", "KE", "UG", "CD"] || OR user.travel_exception = active) || || THEN allow || WITH session_duration = 8 hours || WITH reauthentication_interval = 4 hours || || ELSE deny || LOG decision with full context || |+-----------------------------------------------------------------------+Figure 3: Example ZTNA policy combining identity, device, and context attributes for finance team access to grants system
Policy attributes fall into four categories. Identity attributes derive from the identity provider: username, group memberships, role assignments, authentication method used, and time since last authentication. Device attributes come from the device trust service: management status, operating system version and patch level, disk encryption state, endpoint protection presence, and certificate validity. Resource attributes describe the target: application identifier, sensitivity classification, data types handled, and regulatory requirements. Context attributes characterise the request itself: source IP address and geolocation, time of day, connection type, and deviation from historical patterns.
Effective policies balance security requirements against operational usability. A policy requiring hardware security keys for all access achieves strong authentication but fails when staff lose keys in field locations with no replacement available for weeks. A policy requiring current operating system patches fails when satellite bandwidth constraints prevent timely updates. The policy model must accommodate legitimate operational constraints while maintaining meaningful security controls.
Policy decisions benefit from risk-adaptive evaluation that adjusts requirements based on assessed risk level. A user accessing public documentation from a managed device in a normal location requires minimal verification. The same user accessing beneficiary personal data from an unmanaged device in an unusual location requires step-up authentication, session recording, and restricted functionality. The system calculates a risk score from context factors and applies corresponding control levels.
Device posture assessment
Device posture assessment determines whether a connecting device meets security requirements defined in policy. Assessment depth ranges from none, accepting any device, to comprehensive evaluation of configuration state.
Certificate-based device identity proves a device has been enrolled in organisational device management. The device holds a certificate issued during enrolment, presenting this certificate during ZTNA authentication. The ZTNA broker validates the certificate against the issuing certificate authority and confirms the device has not been revoked. This approach proves enrolment but provides no insight into current device state; a device enrolled six months ago may have disabled disk encryption or removed endpoint protection since enrolment.
Agent-based posture assessment installs software on managed devices that reports configuration state in real time. The agent collects operating system version and patch level, disk encryption status, endpoint protection presence and definition currency, firewall state, and compliance with configuration baselines. During ZTNA authentication, the broker queries the agent or a central management console for current posture data. Agent-based assessment provides detailed visibility but requires software installation, limiting applicability to managed devices.
Agentless assessment uses external observation and inference rather than installed software. The broker can query directory services for device records, check certificate issuance dates as a proxy for recent management contact, and analyse connection characteristics. Agentless approaches work across device types but provide less comprehensive posture visibility.
Posture assessment occurs at connection establishment and, in sophisticated implementations, continues throughout the session. Continuous posture monitoring detects compliance changes during active sessions. If a user disables disk encryption after establishing a session, continuous monitoring detects the change and can terminate the session or restrict access to sensitive applications. Continuous monitoring requires agent capabilities and generates additional traffic, making it more suitable for headquarters locations than bandwidth-constrained field sites.
For unmanaged devices, including personal devices under bring-your-own-device policies and partner organisation equipment, posture assessment takes a different form. The system cannot install agents or enforce configuration on devices outside organisational control. Policy for unmanaged devices accepts reduced assurance in exchange for operational flexibility, permitting access to lower-sensitivity applications while blocking access to systems containing personal data or financial information.
| Device Type | Posture Method | Typical Access Level |
|---|---|---|
| Managed endpoint | Agent-based continuous | Full access per role |
| Managed mobile | MDM attestation | Standard mobile applications |
| BYOD enrolled | Certificate only | Collaboration tools, email |
| BYOD unenrolled | None | Public resources, basic services |
| Partner device | Certificate or none | Shared project resources |
| Kiosk or shared | Session-based | Designated kiosk applications |
Application access patterns
ZTNA systems grant access to specific applications rather than network segments. The mechanism for connecting users to applications varies by application type and deployment model.
Reverse proxy access places the ZTNA broker between users and web applications. The broker terminates user connections, performs authentication and authorisation, then initiates a new connection to the application on behalf of the authenticated user. Applications require no modification; they see connections originating from the broker with user identity conveyed in HTTP headers. This pattern works for web applications accessible via standard browsers.
+------------------+ +------------------+ +------------------+| | HTTPS | | HTTP | || User Browser +-------->+ ZTNA Broker +-------->+ Web Application || | | (reverse proxy) | | (internal) || | | | | |+------------------+ +--------+---------+ +------------------+ | +--------v---------+ | | | Adds headers: | | X-Forwarded-User| | X-Forwarded-Groups | | +------------------+Figure 4: Reverse proxy access pattern showing header injection for user identity
Agent-based access installs software on user devices that intercepts application traffic and routes it through ZTNA infrastructure. The agent presents a local interface that applications connect to, with the agent handling authentication and tunnelling to the actual application. This pattern supports non-web applications including thick clients, SSH connections, and RDP sessions. The agent can also enforce device posture requirements, blocking connections from non-compliant devices.
Clientless access provides browser-based access to applications that would normally require installed clients. The ZTNA broker renders application interfaces in the browser, translating between web protocols and native application protocols. This approach enables access from any device with a browser, at the cost of potentially degraded functionality compared to native clients.
Applications protected by ZTNA benefit from application hiding. Protected applications have no direct internet exposure; they accept connections only from ZTNA brokers on internal networks. Attackers cannot discover or directly attack applications they cannot reach. This contrasts with VPN models where applications remain network-accessible once the user establishes a VPN connection.
Integration with identity providers
ZTNA systems depend on identity providers for user authentication and attribute assertion. The integration uses standard federation protocols: SAML 2.0 for traditional enterprise federation, OpenID Connect for modern web-based authentication, and OAuth 2.0 for API access authorisation.
The identity provider serves as the authoritative source for user identity, group memberships, and authentication state. When a user authenticates to the identity provider, the provider issues a token containing claims about the user’s identity and attributes. The ZTNA broker validates this token and uses the claims in policy evaluation. Group memberships determine which applications a user can access; role assignments control what actions they can perform within applications; authentication method indicates the assurance level of the current session.
Claim mapping translates identity provider attributes into policy-relevant values. An identity provider may express group membership as full distinguished names, while ZTNA policy references simplified group names. The ZTNA system maintains mapping rules that transform provider-specific claim formats into normalised policy attributes.
For organisations using multiple identity providers, perhaps separate systems for staff and partner users, the ZTNA broker must federate with each provider. Users authenticate against their home identity provider; the broker accepts tokens from all configured providers and applies appropriate policies based on the token issuer. A staff member authenticating through the organisational identity provider receives different default access than a partner user authenticating through their organisation’s provider.
Session management spans the identity provider and ZTNA system. When a user logs out of the identity provider, active ZTNA sessions should terminate. Implementing this requires back-channel communication from the identity provider to the ZTNA broker notifying of session termination events. Without this integration, ZTNA sessions persist until their independent timeout expires, creating a window where a user could continue accessing applications after their identity provider session ends.
Field deployment considerations
ZTNA authentication latency increases with network round-trip time. Each authentication step requires communication between the user’s device, the ZTNA broker, and the identity provider. On satellite connections with 600 to 800 milliseconds round-trip time, initial authentication takes four to eight seconds. This delay, acceptable for beginning a work session, becomes problematic if repeated frequently.
| Connection Type | Typical RTT | Initial Auth Time | Impact |
|---|---|---|---|
| Office broadband | 20-50ms | Under 1 second | Negligible |
| Urban mobile 4G | 50-100ms | 1-2 seconds | Acceptable |
| Rural mobile 3G | 150-300ms | 2-4 seconds | Noticeable |
| Satellite GEO | 600-800ms | 4-8 seconds | Significant |
| Congested VSAT | 800ms+ variable | 8-15 seconds | Problematic |
Extended token validity reduces re-authentication frequency at the cost of increased exposure window if credentials are compromised. A token valid for eight hours requires authentication once per work day; a token valid for one hour requires repeated authentication that consumes satellite bandwidth and user time. Field deployments typically extend token validity to four to eight hours while maintaining device posture monitoring as a compensating control.
Session persistence across connectivity gaps prevents authentication loss during brief disconnections. When connectivity drops momentarily, the session should survive rather than forcing full re-authentication when connectivity resumes. Implementation requires the ZTNA agent to cache session state locally and resume without broker contact for short disconnection periods.
Regional broker deployment dramatically improves authentication latency for field locations. Rather than routing all authentication through a single broker location, organisations deploy brokers in regions close to field offices. A broker in Nairobi serves East African offices with 30 to 50 milliseconds latency rather than 180 milliseconds to Europe. Regional deployment requires identity provider federation across regions and policy synchronisation between broker instances.
+------------------+ | Primary Broker | | (EU region) | +--------+---------+ | +-----------------------------+-----------------------------+ | | |+--------v---------+ +---------v--------+ +----------v-------+| European | | East Africa | | Southeast Asia || Offices | | Regional Broker | | Regional Broker || (local) | | (Nairobi) | | (Singapore) |+------------------+ +---------+--------+ +----------+-------+ | | +---------v--------+ +----------v-------+ | EA Field | | SEA Field | | Offices | | Offices | | (50ms to broker)| | (50ms to broker)| +------------------+ +------------------+Figure 5: Regional broker deployment reducing authentication latency for field offices in East Africa and Southeast Asia
Regional deployment introduces complexity in policy management and logging aggregation. Policies must synchronise across broker instances; a user’s access rights should not vary based on which regional broker handles their connection. Security logs from regional brokers require aggregation for centralised monitoring and incident response.
Offline access presents a fundamental challenge to zero trust principles. Zero trust requires verification of every access request, but verification requires connectivity to authentication infrastructure. Field contexts frequently involve extended periods without connectivity, during which work must continue.
Approaches to offline access include pre-authenticated local caches that store application data for offline use, reducing but not eliminating connectivity requirements; grace periods that allow continued access for defined durations after connectivity loss, accepting the risk of stale authorisation; and hybrid models that distinguish between applications requiring real-time verification and those permitting cached access. Each approach compromises pure zero trust principles to accommodate operational reality.
Migration from perimeter security
Transitioning from VPN-based perimeter security to ZTNA proceeds incrementally rather than through immediate replacement. Organisations cannot disable VPN access until ZTNA covers all applications users require, and comprehensive ZTNA coverage takes months to years depending on application portfolio complexity.
The migration path begins with application inventory and classification. Every application requiring remote access needs identification, along with its authentication mechanisms, data sensitivity, and user populations. Applications with existing single sign-on integration migrate more easily than those with independent authentication. Applications handling sensitive data require careful policy design; applications serving public information may permit broader access.
Pilot deployment protects a small number of applications for a limited user population. Select applications with clear ownership, straightforward authentication, and engaged user communities. Success with pilot applications builds organisational confidence and identifies integration challenges before broader deployment. A reasonable pilot protects three to five applications for 50 to 100 users over two to three months.
Parallel operation runs ZTNA alongside existing VPN during transition. Users can access applications through either path, with ZTNA preferred and VPN available as fallback. This approach provides safety margin for migration issues and enables gradual user transition. Monitor both access paths to verify ZTNA handles expected traffic before disabling VPN access to specific applications.
VPN deprecation occurs application by application rather than organisation-wide. When ZTNA coverage is complete for a user population’s application set, VPN access becomes unnecessary for those users. Disable VPN access incrementally, maintaining it for applications not yet migrated and for contingency access during ZTNA outages.
Legacy applications present particular challenges. Applications with hardcoded authentication, non-standard protocols, or architectural assumptions about network location require workarounds. ZTNA connectors bridge from modern ZTNA infrastructure to legacy applications: the connector runs in the legacy application’s network, maintains outbound connectivity to the ZTNA broker, and proxies authenticated requests to the application. Users connect through the broker without awareness of the connector intermediary.
+------------------+ +------------------+ +------------------+| | TLS | | HTTP | || User Device +--------->+ ZTNA Broker | | Legacy App || (anywhere) | | (cloud) | | (on-premises) || | | | | No internet |+------------------+ +--------+---------+ +--------+---------+ | ^ | | | +------------------+ | | | | | +---->+ ZTNA Connector +----+ | (on-premises) | | Outbound only | +------------------+Figure 6: ZTNA connector enabling access to legacy on-premises application without inbound connectivity
Technology options
ZTNA implementations span open source projects suitable for self-hosting to commercial services offering managed deployment.
Open source
Pomerium provides identity-aware access proxy with policy enforcement. Configuration defines routes mapping external URLs to internal applications, with policies specifying access requirements. Pomerium integrates with any OpenID Connect identity provider and supports device posture through integration with endpoint management systems. Deployment requires container orchestration capabilities; Kubernetes is the primary deployment target, though Docker Compose works for smaller installations. Documentation quality is strong, and an active community provides support through GitHub discussions.
Boundary from HashiCorp focuses on infrastructure access: SSH, RDP, and database connections rather than web application proxying. Boundary establishes sessions to infrastructure targets after identity verification, suitable for administrative access to servers and databases. The session-based model differs from Pomerium’s continuous proxy approach. Boundary deployment requires a controller cluster and worker nodes positioned near target infrastructure.
Authentik combines identity provider functionality with application proxy capabilities. Organisations using Authentik as their identity provider gain ZTNA capabilities without additional software. The proxy functionality is less mature than dedicated ZTNA solutions but adequate for straightforward requirements. Self-hosting Authentik requires PostgreSQL and Redis dependencies.
Commercial with nonprofit programmes
Cloudflare Access provides cloud-hosted ZTNA as part of Cloudflare’s Zero Trust platform. The free tier supports up to 50 users, suitable for small organisations or pilot deployments. Configuration occurs through web dashboard or infrastructure-as-code tools. Data processes through Cloudflare’s network, which operates under US jurisdiction subject to CLOUD Act provisions regardless of data location. Organisations handling sensitive protection data should evaluate jurisdictional implications.
Microsoft Entra Private Access integrates ZTNA into Microsoft’s identity platform. Organisations already using Microsoft 365 with Entra ID gain ZTNA capabilities through their existing identity infrastructure. Nonprofit pricing applies through Microsoft 365 nonprofit licences. Integration depth with Microsoft services exceeds other options; integration with non-Microsoft applications requires additional configuration.
Zscaler Private Access offers enterprise-grade ZTNA with global points of presence. Nonprofit pricing requires direct engagement with Zscaler sales. The platform suits large organisations with complex requirements and dedicated security teams; smaller organisations find the complexity and cost difficult to justify.
Selection criteria
Evaluation of ZTNA solutions should address deployment model, identity provider compatibility, device posture capabilities, geographic distribution, application support, and exit path.
Deployment model determines operational responsibility. Self-hosted solutions provide complete control over data and configuration but require infrastructure, expertise, and ongoing maintenance. Cloud-hosted solutions reduce operational burden but introduce dependency on provider availability and potential jurisdictional concerns.
Identity provider compatibility affects integration complexity. Solutions tightly integrated with specific providers simplify deployment for organisations using those providers but create friction for organisations using alternatives. Solutions supporting standard protocols (OpenID Connect, SAML) integrate with any compliant identity provider.
Geographic presence matters for field deployment. Cloud solutions with regional points of presence reduce latency for distributed organisations. Self-hosted solutions can deploy regional instances but require infrastructure in each region.
Exit path describes migration options if the selected solution becomes unsuitable. Proprietary solutions with unique policy languages and configuration formats create migration difficulty. Solutions using standard protocols and exportable configuration ease transition to alternatives.
Implementation considerations
For organisations with limited IT capacity
ZTNA implementation need not require dedicated security teams or extensive infrastructure. A pragmatic approach begins with identity consolidation, continues with cloud-delivered ZTNA for critical applications, and defers device posture to later phases.
Identity consolidation establishes single sign-on across applications before implementing ZTNA. Applications authenticating against a central identity provider are ready for ZTNA protection; applications with independent authentication require integration work. Identity consolidation delivers security benefits independent of ZTNA and serves as prerequisite for effective implementation.
Cloud-delivered ZTNA reduces operational burden compared to self-hosted deployment. Cloudflare Access free tier or Pomerium Cloud (if available) handles infrastructure while the organisation configures applications and policies. Initial deployment protects three to five high-value applications: finance systems, HR information, administrative consoles.
Deferred device posture accepts identity-only verification initially. Full device posture requires MDM deployment or agent installation, adding implementation complexity. Starting with identity verification provides meaningful security improvement; device posture adds further protection when capacity allows.
A minimum viable implementation for a single IT person with limited budget takes two to four weeks of part-time effort:
- Keycloak or Authentik for identity (self-hosted or managed)
- Cloudflare Access free tier (50 users) or Pomerium
- Protection for three to five critical applications
- No device posture initially
- Policy based on user groups and geographic location
For organisations with established IT functions
Comprehensive ZTNA implementation incorporates device trust, sophisticated policy, and integration with security operations.
Policy design precedes technology deployment. Map applications to sensitivity classifications, define access requirements by role and context, identify exception scenarios and approval processes. Document policies before implementation; technology enforces policy rather than defining it.
Device trust infrastructure provides posture assessment for access decisions. Deploy MDM for mobile devices and evaluate agent-based assessment for endpoints. Open source options include osquery for device state collection combined with fleet management for aggregation. Commercial options integrate with ZTNA platforms directly.
Security operations integration feeds ZTNA logs into security monitoring. Access decisions, policy violations, and authentication anomalies should alert security teams. Integration with SIEM enables correlation of ZTNA events with other security telemetry.
Full implementation for a dedicated IT team spans two to four months:
- Identity provider with MFA and device trust integration
- Self-hosted or managed ZTNA broker with regional presence
- Policy engine with application-specific rules and risk adaptation
- Device posture assessment for managed devices
- BYOD policy with tiered access based on device assurance
- Security monitoring integration with alerting
Security considerations
ZTNA security depends fundamentally on identity provider security. A compromised identity provider compromises all ZTNA-protected applications. Protect the identity provider with phishing-resistant multi-factor authentication, privileged access controls for administrative functions, and comprehensive audit logging.
Device posture assessment verifies point-in-time state. A device passing posture checks at session establishment could become compromised minutes later. Continuous posture monitoring, where supported, reduces this window but cannot eliminate it. Assume that some compromised devices will pass posture checks; design defence in depth accordingly.
ZTNA brokers process sensitive data including authentication tokens, user identities, and access patterns. Broker compromise exposes this data and enables access manipulation. Protect broker infrastructure with the same rigour applied to identity providers: restricted administrative access, hardened configurations, security monitoring.
Logs from ZTNA systems contain extensive personal data subject to privacy regulations. Every access decision creates a record of who accessed what, when, from where. Retention policies must balance security investigation needs against data minimisation principles. Access to logs requires restriction to authorised personnel with legitimate need.
User friction from ZTNA controls can drive circumvention attempts. Staff frustrated by repeated authentication or access denials may share sessions, use personal devices to avoid posture checks, or seek direct application access bypassing ZTNA. Monitor for circumvention patterns; address through user education, policy adjustment, and technical controls preventing bypass.