---
title: "How AppGate ZTNA is Zero trust based through the 6-layer model"
slug: "zero-trust-based-v6-7"
description: "AppGate ZTNA offers a secure Zero Trust Network Access model, ensuring real-time, context-aware control through the six-layer model."
tags: ["Software Defined Perimeter", "Zero Trust Access"]
updated: 2026-08-21T14:19:46Z
published: 2026-08-21T14:19:46Z
canonical: "support.appgate.com/zero-trust-based-v6-7"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.appgate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zero trust based

## AppGate ZTNA Overview

AppGate ZTNA uses a Zero Trust Network Access (ZTNA) model that hides systems from unauthorized users and requires detailed contextual information for trust establishment before network access is granted.

The Software Defined Perimeter (SDP) implements ZTNA through appliances using Single Packet Authorization (SPA), blocking port 443 connections unless a pre-agreed, cryptographically signed SPA packet is received first.

- Clients and appliances utilize SPA before establishing any TLS connection.
- Controllers authenticate and authorize new user/device sessions, providing necessary tokens for the Gateway.
- Gateways render protected networks invisible and grant access through individual micro-firewall instances, with rules defined by the token payload.

### Trust Establishment via the 6-Layer Model

AppGate ZTNA employs a multi-layer authorization model for real-time, context-aware user access control. The following numbers correspond to the process layers in the accompanying diagram.

1. [Single Packet Authorization](/v1/docs/spa-v6-7) hides the system, allowing only clients with the pre-shared key to establish a communication channel. The system accepts one or more SPA keys included in the [client profile](/v1/docs/client-profiles-v6-7).
2. [MFA at sign-in](/v1/docs/multi-stage-authorization-v6-7) registers a user's device as a second trusted authentication factor, blocking authentication attempts with stolen credentials. Configured multi-factor authentication (MFA) can be used, and once a device is registered, users do not need to perform MFA at every sign-in.
3. [Authentication](/v1/docs/authentication-services-v6-7) verifies user or device credentials against trusted sources like a local database or LDAP.
4. [Authorization](/v1/docs/using-policies-v6-7) evaluates user or device claims data to assign specific entitlements.
5. [Access controls](/v1/docs/applying-access-controls-v6-7) monitor entitlements to check if additional access criteria are needed in real-time before granting access, with the Gateway dynamically managing access rights based on defined actions.
6. [Alert actions](/v1/docs/configure-entitlements-v6-7) trigger system responses to bad behaviors, such as unauthorized port scans.

![](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/appgate-six-layer-trust-model.png?sv=2026-02-06&spr=https&st=2026-10-26T22%3A55%3A36Z&se=2026-10-26T23%3A55%3A36Z&sr=c&sp=r&sig=cdWoCu%2Flakyhs6l%2F6s2sAiekkj2fOAuWKqNEKv%2FRqRk%3D)

After the client receives the profile link and the device is onboarded, the user can select *Keep me signed-in*, making the 6-layer model transparent and requiring fewer interactions than a standard VPN. User interaction may only be necessary if a condition demands it.