Zero trust network access
Publish private applications with identity and posture checks rather than broad network access.
ZTNA grants access to named private applications using user identity, device posture, and an application policy. It gives a narrower authorization boundary than a remote-access profile exposing an entire network.
Publish an application
At Access → Applications → Add application, select the application asset, enrolled gateway, hostname or internal destination, supported protocol, and service port. The gateway must reach the backend without exposing that backend directly to unauthenticated clients. Verify ownership and internal TLS identity before enabling access.
Open Application → Access policy and choose permitted identity groups, MFA, posture, session lifetime, and re-evaluation behavior. New applications deny access until an explicit policy is published and applied. A device compliance exception does not implicitly grant application membership.
Verify authorization
Test with an approved account and device, then an account outside the permitted group. Open Access → Sessions → Session to inspect the identity provider, device identity, posture result and age, application ID, gateway, and expiry. A successful sign-in is only one input; application access can still be denied by policy or backend failure.
Guard authorizes the application connection. The application remains responsible for its own object permissions and transaction authorization. A network session to a database does not authorize every query that the database might accept.
Revocation and failure
Open Access → Sessions, select the compromised session, and choose Revoke. Wait for the gateway's termination acknowledgement in the session record. If the user's identity is compromised, also revoke their console sessions at Organization → Members → Member → Revoke sessions and disable the identity in its provider to prevent new sign-ins.
If the gateway is disconnected, the termination request can remain unacknowledged. It cannot admit new sessions that need fresh authorization, but existing sessions follow their adopted re-evaluation and expiry rules. Inspect the gateway's connection status under Access → Gateways → Gateway → Health and confirm termination after it reconnects.
At Application → Health, use the reported failure to choose the next check:
| Failure | Next check |
|---|---|
| Gateway unavailable | Access → Gateways → Gateway → Health for management and backend reachability |
| Identity or MFA rejected | The identity provider's sign-in result and the application's allowed groups |
| Posture stale or noncompliant | Endpoints → Endpoint → Compliance for the failed check and observation time |
| Backend unreachable | The gateway-to-backend route, listener, and TLS identity |
An approved access exception can change a posture decision for a bounded period. It cannot repair an unavailable gateway or backend.
To retire an application, notify owners, remove new access, revoke remaining sessions, verify termination, and select Application → Retire. Remove external DNS and gateway routes that are no longer needed. See Access API.