Issue 1

Zero Trust Architecture

and Solutions
 Zero Trust Architecture and Solutions

Zero Trust Architecture and
Solutions 2
Research from Gartner architecture comes into being. The zero trust security architecture
Market Guide for Zero Trust
Network Access 14
About Qi An Xin Group 21
In the era of cloud computing and big data, the network security
perimeter is gradually disintegrating, and internal and external
threats are intensifying, leading to the failure of the traditional
perimeter-based security architecture, therefore the zero trust security
establishes a dynamic digital identity-based perimeter with four
key capabilities, which are identity-based schema, resource secure
access, continuous trust evaluation and adaptive access control.
It helps enterprises realize a new generation network security
architecture with comprehensive identity, dynamic authorization, risk
measurement, and management automation.

This paper begins with the background, definition and development

history of zero trust security, then proposes a general zero trust
reference framework, and takes Qi An Xin Zero Trust Security
Solution as an example to interpret the application scheme of zero
trust reference framework, finally discusses the zero trust migration
methodology, and puts forward the migration ideas with defining the
vision, planning first and constructing step by step.

1. Introduction
The enterprise network infrastructure is becoming more and more
complex with gradually blurred perimeter. The digital transformation
has driven the rapid evolution of information technology, new IT
technologies such as cloud computing, big data, Internet of Things
and mobile internet have brought new productivity to all industries,
in the meantime, they also have brought great complexity to the
enterprise network infrastructure. On one hand, the adoption of cloud
computing, mobile internet and other technologies makes enterprise’s
staff, businesses and data go outside of the enterprise’s digital walls;
on the other hand, the open and collaborative demands for new
technologies, such as big data and Internet of Things, lead the outside
staff, platforms and services pass through the digital walls and go into
the enterprises. The modern enterprise network infrastructure has no
single, well-recognized and clear security perimeter anymore, in other
words, enterprise security perimeter is gradually disintegrating, and the
traditional perimeter-based network security architecture and solutions
are found difficult to adapt to modern enterprise network infrastructure.

Zero Trust Architecture and Solutions is published by Qi An Xin Group. Editorial supplied by Qi An Xin Group is independent of Gartner analysis. All Gartner research is © 2020 by Gartner, Inc. All rights reserved.
All Gartner materials are used with Gartner’s permission. The use or publication of Gartner research does not indicate Gartner’s endorsement of Qi An Xin Group’s products and/or strategies. Reproduction or
distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties
as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The
opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research
should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For
further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity” on its website.

2

In addition, the network security situation is
not optimistic. External attacks and internal
threats are intensifying, organized attacks,
weaponized attacks, and advanced attacks
with data and services as targets can still
easily find loopholes that break through the
perimeter of the enterprise, while internal
threats such as unauthorized access to
internal businesses, employee mistakes and
intentional data theft have been popping out.
Faced with such severe security challenges,
the industry’s security awareness has
been paid more attention, and the security
investment becomes also higher. However,
the security effect is not that satisfactory,
and security incidents emerge one after
another. What is the root cause of the failure
for the traditional security architecture? The
fundamental basis of security is to deal with
risks, and the risks are closely related to
“loopholes”. What “loopholes” lead to the
failure of traditional security architecture? The
answer is trust. The traditional perimeter-
based network security architecture assumes
that the people and devices in the internal
network are trustworthy, therefore the security
strategy is to build the digital walls of the
enterprise, and the security products such as
firewalls, WAF, IPS are sufficient to protect the
perimeter of the enterprise network. However,
one should assume that there are always
undiscovered loopholes in the network
systems, there are always discovered but
unpatched loopholes in the systems, the
systems have always been infiltrated and that
the insiders are always unreliable. These four
“always” assumptions overturn the technical
methods of traditional network security by
segmenting network and building the walls,
and overturn the abuse of “trust” under the
perimeter security architecture, which the
perimeter-based security architecture and
solutions have been found difficult to deal
with today’s network threats.
A new network security architecture is needed
to cope with the modern and complex
enterprise network infrastructure, and to cope
with the increasingly severe network threat
situation. Zero Trust Architecture emerges in
this context and is an inevitable evolution of
security thinking and security architecture.
1
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks (O’Reilly Media, 2017)
2
NIST, Zero Trust Architecture, 2019.09, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft.pdf
1.1. Definition of Zero Trust
Zero Trust Architecture has been developing
rapidly and been gradually mature, while
different versions of the definition are
described in different dimensions. In the book
Zero Trust Networks: Building Secure Systems
in Untrusted Networks, Evan Gilman and
Doug Barth definite that a zero trust is built
upon five fundamental assertions:1
• The network is always assumed to be
hostile.
• External and internal threats exist on the
network at all times.
• Network locality is not sufficient for
deciding trust in a network.
• Every device, user, and network flow is
authenticated and authorized.
• Policies must be dynamic and calculated
from as many sources of data as possible.
In short, no person/device/application in
the enterprise network should be trusted
by default, no matter it is in the internal or
external network. The fundamental basis of
the trust should be based on the refactored
access control using right authentication
and authorization. Zero Trust Architecture
has paradigmically changed traditional
access control mechanism, and its essence
is adaptive trusted access control based on
identity.
In the recently published “Zero Trust
Architecture (NIST.SP.800-207-draft)”, NIST
points out that “Zero Trust Architecture
is an end-to-end approach to network/
data security that encompasses identity,
credentials, access management, operations,
endpoints, hosting environments, and the
interconnecting infrastructure”. It considers
zero trust as an architectural approach to
data protection, while traditional security
solutions focus only on perimeter defense
with too much access open to authorized
users. The primary goal of zero trust is
3
to perform fine-grained access control
based on identity in order to cope with the
increasingly severe risk of overpowered
lateral movement.
Therefore, NIST defines Zero Trust
Architecture as follows:
Zero Trust Architecture (ZTA) provides
a collection of concepts, ideas, and
component relationships (architectures)
designed to eliminate the uncertainty in
enforcing accurate access decisions in
information systems and services.2 This
definition identifies key issues that zero trust
needs to address: eliminating unauthorized
access to data and services, underscoring
the importance of fine-grained access
control.
1.2. History of Zero Trust
Analyzing the development history of zero
trust, it is not difficult to find that the different
perspectives of zero trust finally show strong
consistency after developing and merging.
The earliest prototype of zero trust came
from Jericho Forum, founded in 2004, whose
mission was to define cyber security under
de-perimeterization trends and to find
solutions. The actual term “zero trust” was
officially coined in 2010, indicating that all
network traffic is untrusted by default, and
all access requests for all resources need to
be securely controlled. In the beginning, zero
trust came up with a solution that focuses on
fine-grained access control over the network
through micro-segmentation to limit the
attacker’s lateral movement.
With the continuous evolution of zero
trust, identity-based architecture has
gradually gained mainstream acceptance
in the industry. The transformation of this
architecture is closely related to the adoption
of mobile computing and cloud computing. In
2014, Google has published several papers
on how to build Zero Trust Architecture for
its employees internally, based on its own
project BeyondCorp. BeyondCorp’ s starting
point is that it is no longer enough to build
3
security controls just for corporate perimeter,
requiring access control to be moved from
the perimeter to each user and device. By
using Zero Trust Architecture, Google has
successfully abandoned the adoption of
traditional VPNs and ensured that all users
from insecure networks have secure access
to the enterprise business through a new
architecture.3
With the continuous improvement of zero trust
theory and practice of the industry, zero trust
has gone beyond the scope of the original
micro-segmentation in network layer, evolved
into a new generation of security solutions
based on identity, which can cover many
scenarios, such as cloud environment, big
data centers and micro-services. Research
organizations are also ready to optimize their
security architectures and systems.
By analyzing various definitions and
frameworks of zero trust, it can be seen that
the essence of Zero Trust Architecture is
adaptive identity-based access control, the
security capability of focusing on identity, trust,
resource access and adaptive access control,
and the multi-dimensional factors such as
people, process, environment and access
context based on business scenarios, and
continuous assessment and evaluation of the
zero trust is needed. The adaptive adjustment
of authority by trust levels can help form a
dynamic adaptive security closed loop with
strong risk coping ability.
2. Zero Trust Reference Framework
The key capabilities of zero trust security can
be summarized as follows: identity-based
schema, resource secure access, continuous
trust evaluation and adaptive access control.
These capabilities map to a set of interacting
core architectural components that are highly
adaptable to various business scenarios.
2.1. Key Capability Model
The essence of zero trust is to establish
an adaptive identity-based access control
system between the access subject and the
access object. Through the key capabilities
of identity-based schema, resource
3
Google, https://cloud.google.com/beyondcorp/
4
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks, Aug., 2019
4
secure access, continuous trust evaluation
and adaptive access control, it encrypts,
authenticates and enforces all untrusted
access requests, based on the digital identity
of all participating entities of the network,
aggregates a variety of data sources for
continuous trust evaluation, and adjust the
permissions dynamically according to the
trust levels, and eventually establish an
adaptive trust relation between the access
subject and the access object.
In Zero Trust Architecture, the access object is
the core protected resource, which should be
protected by the protection surface, including
the enterprise’s business applications, service
APIs, operations, and asset data, and etc.
The access subject includes digital entities
such as people, devices, applications, and
systems, all of which can be identified. In
certain access contexts, those entities can
also be combined to further clear and define
the subject.
Key capabilities of Zero Trust Architecture
include: identity-based schema, resource
secure access, continuous trust evaluation
and adaptive access control. (See Figure 1 for
a conceptual model.)
1) Identity-based Schema
In order to construct access control system
based on identity rather than network
location, it is necessary to give digital identity
Figure 1 Key Capabilities of Zero Trust Architecture
Source Qi An Xin Group, 2019
to the people and device in the network, and
combine the identified people and device at
run-time to set up access subjects, and set up
the least privilege for the access subject.
Digital identity is the cornerstone of Zero
Trust Architecture and it needs to realize
“comprehensive identity “. It is not enough
to simply create identities for people and/or
devices, and all entities involved in network
interactions. In fact, in the age of Internet
of Things, things have become important
participating entities, whose cardinal number
has gone far beyond people.
In Zero Trust Architecture, based on different
access contexts, the access subject can
be a dynamic combination of numeric
digital entities, such as people, devices
and applications, which is called “network
agent” in the book Zero Trust Network. It is
the term given to the combination of data
known about the actors in a network request,
typically containing a user, application, and
device, which are the inextricable context
of an access request. It is generated on-
demand when authorization decision is
made and thus it is usually of short time.
Access agent’s constituent elements (users
or devices) information are generally stored
in the database for real-time query and
combination when authorized, so the network
agent represents the real-time state of the
attributes of users and devices in each
dimension at the time of authorization.4

The principle of least privilege is one of the
key practices that should be followed by
any security architecture. However, Zero
Trust Architecture advances the principle of
least privilege, and follows the principle of
dynamic least privilege. If users do need
higher access rights, then they can and
only get those privileges when they need
them. On one hand, it emphasizes that the
authorized subject is not a single entity, but
a composite subject as network agent, not
only follows the principle of least privilege by
the user, as well as a principle followed by
the device; on the other hand, the authorized
subject can be further defined based on
the subject attribute, environment attribute,
trust level and the security level of the object.
In contrast, traditional identity and access
control related implementations generally
authorize people and devices separately.
Zero trust is a paradigm that uses network
agents as the authorized subject. It generates
temporary entities on demand at the time
of authorization decision, which has strong
dynamics and risk awareness, therefore it
can greatly mitigate security threats such as
credential loss and unauthorized access.
2) Resource Secure Access
Zero Trust Architecture focuses on the
construction of the business protection
surface to realize the protection of resources.
In Zero Trust Architecture, applications,
services, interfaces and data can be
regarded as business resources. Setting up
a protection surface to shrink the exposed
surface, all business resources are required
to be hidden by default, and all business
access requests are subject to full traffic
encryption and mandatory authorization
according to the authorization results. The
resource secure access mechanism needs
to work at the application protocol layer as
much as possible.
To build Zero Trust Architecture, it is necessary
to pay attention to the core assets that
need to be protected, sort out the various
exposed surface of the core assets, and
hide the exposed surface. Thus, the various
access paths of the core assets are hidden
behind the security components as not
visible to the access subjects by default
except for obtaining the access requests
that are authenticated, licensed, and trusted
in compliance with the security policies. In
addition to satisfying the principle of least
privilege, it can also effectively alleviate
security threats such as detection of core
assets, denial of service, vulnerability
utilization, illegal crawling, and etc.
Network eavesdropping and middleman
attacks are the most common causes of data
thefts. In the zero trust practice, it is necessary
to encrypt the traffic of all applications and APIs
calls with high-intensity TLS, and to consider the
support of the domestic cipher algorithm. Zero
trust emphasizes full-traffic encryption agent
rather than just local traffic of authentication
request, which also distinguishes the trusted
agent in Zero Trust Architecture from traditional
authentication gateway.
In order to prevent access control
mechanisms from being bypassed, it is
necessary to have a policy enforcement
point. In Zero Trust Architecture, all access
requests should be authenticated, licensed,
and have considerable trust level. Zero
Trust Architecture needs to adapt different
business scenarios, identify the subject from
different access protocols and methods, and
relate the multi-level and multi-layer accesses
to the subject. Only in this way, can it be
effectively ensured the access control without
loopholes.
3) Continuous Trust Evaluation
Continuous trust evaluation is a key method
to build trust from scratch in Zero Trust
Architecture. Through trust evaluation model,
identity-based trust evaluation capability
is realized. It also assesses the context
environment of access and identifies the
abnormal behavior of access request and
adjusts the result of trust evaluation at the
same time.
Entities in the physical world, such as people
and devices, are identified as digital identities
in the digital world, so trust evaluation of
entities first requires a trust evaluation of
them, which must cover at least two types of
digital identities: people and devices. Identity-
based trust evaluation systems need to be
5
established and cover all stages of the digital
identity life cycle, including: the configuration
of the digital identity, the trust evaluation of
states and attributes, and the trust evaluation
of the physical entity to digital identity
mapping process (identity creation and
verification). As mentioned above, the access
subject is the network agent composed of the
trinity of people, devices and applications,
therefore, on the basis of the identity trust,
it is necessary to evaluate the subject trust,
which is the dynamic adjustment of the
identity trust in the current access context,
and related to authentication intensity, risk
state and environmental factors. The identity
trust is relatively stable. Like the network
agent, subject trust is a kind of short-time
dynamic trust, and adaptive access control
based on subject trust levels is the essence
of zero trust.
Trust and risk are closely associated with
each other, even as the two sides of one
coin. In Zero Trust Architecture, besides the
trust evaluation, the influencing factors of
environmental risk need to be considered,
and all kinds of environmental risks need to
be assessed and responded to. However, it
is important to note that not all risks will affect
the trust degree of the identity or the subject.
For example, in the process of accessing
a business resource, device camera may
perceive that many people are surrounded
observing, which is risky to sensitive
resources and should be mitigated by
revoking the current access sessions. Frankly,
in most cases there is no need to degrade
the current device and user’s trust levels, if
this behavior constitutes an inherent pattern,
the subject may be deemed to be intentional,
and in other words, the subject’s trust should
be degraded therein.
The demand of ability of behavior-based
anomaly detection and trust evaluation
requires establishing models and maker
quantitative evaluation for the key factors
affecting the trust including baseline
deviation of the individual behavior of the
subject (corresponding digital identity),
baseline deviation of the subject and the
group, aggressive behavior of the main
environment, and risk behavior of the main
environment. Comprehensive assessment
5
needs to integrate the behavioral analysis
with identity situation to reduce misjudgment
and reduce the negative impact on the user
experience.
4) Adaptive Access Control
Adaptive access control is an important
embodiment of the security closed loop
capability of Zero Trust Architecture. It is
suggested that flexible access control
baselines should be implemented through
the combination of RBAC and ABAC,
hierarchical business access can be realized
on the basis of trust level, at the same time,
real-time intervention of access rights should
be performed when risks exists in the context
and environment of access, and assessed
whether the trust of the access subject should
be degraded.
The establishment of any access control
system is inseparable from the access control
model, and it is necessary to establish a
permission baseline based on a certain
access control model. There are many
access models, including RBAC, ABAC,
MAC, DAC, and other classical models
and their variants. Zero trust emphasizes
grayscale philosophy, there is no need to
worry about which is better between RBAC
and ABAC from the practical experience,
but take the integration into consideration. It
is suggested to implement coarse-grained
authorization based on RBAC model,
establish a baseline of authority to meet the
enterprise’s basic principle of least privilege,
and implement dynamic mapping and
filtering mechanism based on subject, object
and environmental attributes while giving full
play to the dynamics and flexibility of ABAC.
The permission baseline determines the full
set of permissions allowed by a subject, and
at different access times, the access context,
trust level, and risk state may be closely
related to the granted access rights.
Besides the access control baseline, the
hierarchical access control strategy should be
implemented according to the trust level of
the subject and the security level of the object.
When the trust level of the subject is higher
than that of the object, access will be actually
granted, otherwise denied to alleviate
6
the risk. According to the continuous trust
evaluation, the trust level of the subject will be
adjusted, dynamically within the baseline of
access control in real time.
It should be noted that not all risks have an
impact on trust, especially environmental
risks, a corresponding disposal strategy
should be implemented once the risk occurs.
The common approach is to cancel the
access session. Therefore, the control plane
will be able to receive the risk notification of
the external risk platform and process the
current access session on demands, so as to
realize the interaction of risk management,
and truly integrate Zero Trust Architecture
and other existing security solutions of the
enterprise.
2.2. Basic Principles
The section “Key Capability Model” describes
four zero trust key capabilities of “identity-
based schema, resource secure access,
continuous trust evaluation, and adaptive
access control” in detail. These security
capabilities need to be supported in Zero
Trust Architecture through architectural
components, interactive logic, and etc. In the
process of mapping security capabilities into
the architecture, some basic architectural
principles would apply in order to ensure that
the implemented architecture can effectively
meet the security requirements under the
new IT environment. The principles include:
• Principle of Comprehensive Identity
Far more than managing the identity of
people, all access subjects should be
identified, including people, devices, and etc.
The subjects of access control are network
agents, not isolated people or devices.
• Principle of Application-level Control
The access should work as much as possible
in the application layer rather than the
network layer, which is usually implemented
by an application agent. The application
agent should be full-flow and fully encrypted.
It is not allowed to only authorize the agent to
applications’ authentication request.
• Principle of Closed Loop Security
The trust level is evaluated based on the
attributes, behaviors and access context
of the subject, and the access authority is
dynamically and automatically adjusted in
real time based on the trust level to form an
automatic closed loop security.
• Principle of Business Aggregation
Zero Trust Architecture is a built-in security.
It is necessary to design the architecture
based on the actual business scenarios
and security conditions. It is recommended
to plan the zero trust security and business
simultaneously. Zero Trust Architecture should
have strong adaptability and can be tailored
or extended according to the requirements of
actual scenarios.
• Principle of Multi-scenario Coverage
Modern IT environment has a variety of
business access scenarios, including user
access resources, service API calls, data
center service interactions, and etc. Access
terminals include mobile, desktops, as well
as IoT devices. The deployment locations
of business are also various. Zero Trust
Architecture should cover various scenarios
and maintain its strong scalability to achieve
universal security capabilities for all business
scenarios.
• Principle of Component High Interactivity
The components of Zero Trust Architecture
should have high interactivity, and the
components should be adjusted to each
other to form a whole to mitigate all kinds
of threats and to form a secure closed loop.
In the practice of Zero Trust Architecture,
one should not stack or piece together
product components. The interactivity of each
product is an important foundation for the
implementation of zero trust.
2.3. Core Components
The core logical architectural components of
Zero Trust Architecture are shown in Figure 2:

Figure 2 Architectural Components of Zero Trust Architecture
Source Qi An Xin Group, 2019
1) Trusted Proxy
A trusted proxy is a data plane component,
the first gateway to resource secure access,
and a policy execution point for adaptive
access control capability.
After the trusted proxy intercepts the access
request, the access subject is authenticated
through the adaptive access control engine,
and the authority of the access subject is
dynamically determined. Only the access
requests that pass the authentication and
have access rights are released. At the same
time, the trusted proxy should encrypt all
access traffic, which also demands its high
performance and high scalability. Supporting
horizontal extension is the core capability that
the trusted proxy must have.
According to different scenarios, the product
forms of the trusted proxy are quite different.
For example, for users accessing services,
the trusted proxy may be the application
gateway based on reverse proxy technology.
For service interface calls, the trusted
proxy may be an API gateway. For service
mesh scenario, a trusted proxy can be
simplified as an agent module running in
the service environment. Similarly, capability
requirements vary in different scenarios.
Trusted proxy is required to support not
only application-level reverse proxy, but
also TCP proxy technology for some legacy
applications according to different service
applications even in the same scenario
where users access services. In the actual
implementation of the scheme, trusted proxy
with various forms must work under the
unified management of the control plane
components to ensure the implementation
of the security strategy in various scenarios
without differences.
2) Adaptive Access Control Engine
The adaptive access control engine is linked
with the trusted proxy to authenticate and
dynamically authorize all access requests,
constituting the policy decision point of Zero
Trust Architecture control plane.
The adaptive access control engine
determines the authority of all access
requests. The authority determination is
based on context attributes, trust levels and
security strategies dynamically rather than on
static rules. It is based on identity repository,
authority repository and trust repository, with
the first providing the identity attributes of
the access subject, the second providing the
basic authority repository line, and the third
continuously maintaining the control by the
identity analysis engine through real-time
multidimensional risk association and trust
evaluation.
7
In order to implement the identity-based
access control strategy and dynamic
authority adjustment, the adaptive access
control engine components should
authenticate identities and manage sessions
of the access subject simultaneously to
ensure that all access requests are identity-
aware, visible, and controllable.
3) Trust Evaluation Engine
As the core component to realize the
capability of continuous trust evaluation in Zero
Trust Architecture, the trust evaluation engine is
linked with the adaptive access control engine
to provide the trust level assessment as the
basis of authorization decision.
It continuously receives the log reports of the
trusted proxy and the adaptive access control
engine, combines the data of the identity
repository and the authority repository,
carries out profiles on the identity and
continuous analysis on the access behaviors,
assesses continuously by using big data
and AI technology, and finally generates
and maintains the trust repository to provide
the decision for the adaptive access control
engine. In addition, the trust evaluation
engine can also receive the analysis results
from external security analysis platforms,
including: trusted environment awareness,
continuous threat detection, situation
awareness and other security analysis
platforms, which may well supplement the
data required for identity analysis and enrich
the context so as to carry out more accurate
risk identification and trust evaluation.
4) Identity Security Infrastructure
The identity infrastructure is critical for
building the identity-based capabilities of
Zero Trust Architecture.
The identity infrastructure includes at least
the functional components of identity
management and authority management,
the former may realize identity and identity
life-cycle management of various entities
while the latter may carry out fine-grained
management and tracking analysis of
authorization policies.
7
The identity security infrastructure of Zero Trust
Architecture should meet the complex and
efficient management requirements under
the modern IT environment. The traditional
static identity and authority management
fails to meet the requirements of the new
technological environment and cannot support
the enterprise’s strategic visions of building the
zero trust security architecture for not being
agile and flexible enough or manage identity
and authority management for more new
scenes and applications. In addition, in order
to improve the management efficiency, the key
capabilities of modern identity management
such as self-service and workflow engines are
also essential.
With the present situation of the existing
enterprise infrastructure, the identity security
infrastructure can be handled flexibly in the
Figure 3 Different Business Scenarios
Source Qi An Xin Group, 2019
Figure 4 Resource Access Scenario
Source Qi An Xin Group, 2019
8
implementation of specific schemes. Any
enterprise with a mature identity infrastructure
to meet the requirements may couple Zero
Trust Architecture with an existing system.
Any enterprise does not have an identity
infrastructure, or its maturity cannot meet
the requirements of Zero Trust Architecture
should build or optimize one.
2.4. Adaptability for Multi Scenarios
Under a modern IT environment, business
scenarios are diverse. Those scenarios may
be sorted out as: resource access scenario,
data exchange scenario, and service mesh
scenario according to their typical business
architecture, access subjects and objects, and
traffic modules. Zero trust reference framework
should be applicable to each scenario and
can combine multiple scenarios as needed to
form a unified zero trust security architecture.
(See Figure 3 for a conceptual model.)
The following presents the simplified
schematic diagram of the zero trust reference
framework for each business scenario
respectively, this article leaves out the
components of identity security infrastructure,
other security analysis platforms and the
differences there between.
1) Resource Access Scenario
Resource access refers to the scenario
where users access business applications,
and is also the main scenario of Zero Trust
Architecture. There are many sub-scenarios
in this one, such as desktop office scenario,
mobile office scenario, dumb device access
scenario, and etc. Types of users, devices and
applications may vary according to different
sub-scenarios, which put forward more
capability requirements for the implementation
of zero trust logic components. (See Figure 4 for
a conceptual model.)
The person/user of the access subject may be
an insider, an employee, an external partner,
or even the customer of the enterprise.
The device of the access subject may be a
PC, a mobile device, an enterprise-owned
device, or a BYOD device. In addition,
application types, especially access means
of applications, including WEB applications
based on HTTP protocols, some well-known
non-HTTP protocols, such as RDP, SSH, and
even some non-well-known private protocols,
may vary.
A mature zero trust solution should meet the
business access requirements of different
people and devices to various application
protocols, and have high adaptability while
maintaining the same architecture.
The above business access architecture
diagram does not cover the fine-grained
access control at the functional level or
even the data level within the application. In
terms of the specific implementation plan,
it is suggested that Zero Trust Architecture
and the business architecture are closely
coupled. The components of the Zero Trust
Architecture can transfer identity, trust,
and authority information to the business
application which can perform finer-grained
access control based on this information.
In this way, not only the zero trust can be

regarded as the endogenous capability of the
business security, but also the development,
deployment and continuous evolution of
the security and business can be ensured
independently to a certain extent.
2) Data Exchange Scenario
Data exchange refers to a business scenario
in which external applications/platforms
exchange data through service interfaces
and enterprise services. In the era of big data,
open collaboration has become the trend of
information technology development, and
the data exchange scenario has gradually
become the mainstream. (See Figure 5 for a
conceptual model.)
Zero trust solutions for data exchange
scenario face the challenges of diverse
interfaces and computing environments
where access subjects run. Trust proxy which
is compatible with various data exchange
protocols or API interfaces is required. Trust
evaluation engine should collect and evaluate
data from the computing environment in
which access subjects run. Meanwhile the
Figure 5 Data Exchange Scenario
Source Qi An Xin Group, 2019
Figure 6 Service Mesh Scenario
Source Qi An Xin Group, 2019
data exchange protocols should be analyzed
to better identify abnormal access behaviors.
The adaptive access control engine should
perform fine-grained access control at the
content level.
In addition, under the data exchange
scenario, the access subject that directly
conducts the data exchange with the trusted
proxy is the external application, not the
user or the device, which requires identifying
and evaluating the user and the device that
accesses the external application through
certain technical means, so as to ensure end-
to-end trust establishment and fine-grained
access control of identity awareness.
3) Service Mesh Scenario
Service mesh refers to the multi-party
interaction scenario among servers within
the data center. With the large adoption
of container layout and micro-service
technology, the service mesh scenario is
increasingly evolving into the mesh access
control among the data center workloads.
(See Figure 6 for a conceptual model.)
9
Generally, the zero trust scheme in the
service mesh scenario does not use
independent trusted proxy as data plane
components, but disperses them, and takes
over each other’s access requests and
interacts with the control plane by deploying
trusted proxy. Numerous nodes and the
complex access control rules set higher
standards for both adaptive access control
engine and trust evaluation engine of the
zero trust solutions for service mesh scenario.
The service mesh scenario is also the
deepest embedded scenario in the
service architecture. It needs to be built
in combination with the service mesh or
container orchestration technology. It is best
to plan Zero Trust Architecture at the same
time as the service platform is built to achieve
a true built-in security.
3. Zero Trust Security Solution
This section analyzes the specific practice
of the zero trust reference framework by the
example of Qi An Xin ‘s zero trust security
solution. Qi An Xin has been paying great
attention to Zero Trust Architecture. Qi An
Xin Zero Trust Security Solution is designed
based on the zero trust reference framework,
making full use of the advanced technological
achievements, and making optimization in
combination with typical domestic business
and security status quo. At present, it is
strongly advanced and feasible as it has
been verified by a large number of practices
and widely recognized by large organizations
and enterprises in China.
3.1. System of Core Products
Qi An Xin Zero Trust Security Solution
includes: Qi An Xin TrustAccess Adaptive
Access Control Platform, Qi An Xin TrustID
Identity Platform, Qi An Xin ID Phone Token
and other agent compositions, as shown
in Figure 7. In Qi An Xin Zero Trust Security
Solution, Adaptive Access Control Platform
and Identity Platform are logically decoupled.
If the customer’s existing identity security
infrastructure meets the requirements of
Zero Trust Architecture, it is not necessary to
deploy the Identity Platform, and the cost of
construction can be reduced be making use
of the existing system.
9
Figure 7 Qi An Xin Zero Trust Security Solution
1) Qi An Xin TrustAccess Adaptive Access
Control Platform
Qi An Xin TrustAccess provides the core
capability of adaptive trusted access control in
Zero Trust Architecture to quickly set up Zero
Trust Architecture for enterprises and realize
the zero trust migration of enterprise data.
The main components of Qi An Xin
TrustAccess include: Trusted Application Proxy
(TAP), Trusted API Proxy (TIP), Trusted Access
Console (TAC), Identity Analysis (IDA), Trusted
Environment Sensor System (TESS) and Trusted
Network Sensor System (TNSS).
• Trusted Application Proxy (TAP)
Trusted Application Proxy (TAP) is the product
implementation of the trusted proxy in the
resource access scenario in the zero trust
reference framework.
Based on the requirements of enterprise
application-level access control, it realizes
the ability of layered secure access, one-stop
application access, application single sign-
on, and application auditing.
10
Source Qi An Xin Group, 2019
• Trusted API Proxy (TIP)
Trusted API Proxy (TIP) is the product
implementation of the trusted proxy in the
data exchange scenario in the zero trust
reference framework.
Based on the security requirements of API
service, it realizes the unified agent, access
authentication, data encryption, security
protection, application auditing and other
capabilities of APIs.
• Trusted Access Console (TAC)
Trusted Access Console (TAC) is the product
implementation of adaptive access control
engine in the zero trust reference framework.
TAC provides TAP/TIP with self-adaptive
authentication service, adaptive access
control and centralized management
capabilities. According to various business
access scenarios of the enterprise,
TAC implements the functions of self-
adaptive authentication service, unified
configuration management of access control
policies, centralized management of WEB
applications and API services, dynamic
authorization, risk aggregation correlation,
application auditing, etc.
• Identity Analysis (IDA)
Identity Analysis (IDA) is the product
implementation of the trust evaluation engine
in the zero trust reference framework.
IDA carries out comprehensive risk correlation
judgment based on identity and authority
information, TAP/TIP/TAC access logs,
attributes and risk assessment reported
by trusted environment sensor, logs and
events submitted by other external analysis
platforms. It uses big data analysis and AI
technology to build a trust evaluation model
for continuous trust evaluation and to provide
TAC with trust level as decision-making basis.
• Trusted Environment Sensor System
(TESS)
Trusted Environment Sensor System (TESS), as
an important data source of IDA, provides
the device environment security status and
environment awareness of various scenarios
and the real-time reliability judgment basis
for IDA.
 11

• Trusted Network Sensor System (TNSS) Figure 8 Relation between Qi An Xin Zero Trust Security Solution and Reference Framework

Trusted Network Sensor System (TNSS), also as

an important data source of IDA, provides the
security status and environment awareness
of the network environment and the real-time
judgment basis of network reliability for IDA.

2) Qi An Xin TrustID Identity Platform

Qi An Xin TrustID Identity Platform is a

product implementation of identity security
infrastructure in the zero trust framework,
and is a modern identity and authority
management product.

Qi An Xin TrustID can provide enterprises with

more advanced and flexible modern identity
and authority management capabilities.
When TrustAccess’s own basic identity and Source Qi An Xin Group, 2019
authority management capabilities or the
enterprise’s existing identity infrastructure
does not meet the enterprise’s management In addition, Qi An Xin Zero Trust Security 3.2. Scheme of Typical Scenarios
needs, the capabilities of identity and Solution can seamlessly interacts with other Here’s an example of a typical application
authority management can be improved by Qi An Xin’s security products and solutions. scenario that describes the logic principle
TrustID to meet the capability requirements For example, it can achieve the zero trust of Qi An Xin Zero Trust Security Solution. The
of the zero trust architecture to identity mobile solutions by linking with Qi An Xin’s resources including business applications
security infrastructure. In addition to serving mobile security solutions. It can achieve data and API services need to be protected in
TrustAccess, TrustID can also provide identity access scenarios by linking with Qi An Xin’s the data subnet. The user and the device
and permission-based services for the data security solutions. It can achieve zero in the user subnet need to access business
enterprise’s business systems and other trust solutions for cloud and virtualization applications, and external applications
scenarios that require identity, authentication, scenarios by linking with Qi An Xin’s cloud need to call API services. The scheme logic
and authorization. security management platforms. diagram is shown in Figure 9.
Qi An Xin TrustID also supports docking with
the existing external identity source systems
of the enterprise, including PKI, 4A, AD, etc. Figure 9 Scheme of Typical Scenarios
A healthy identity life cycle management
capabilities is formed to provide identity
infrastructure services for TrustID by
integrating and synchronizing the existing
identity sources of the enterprise.

3) Relation between Qi An Xin Zero Trust

Security Solution and Reference Framework

Qi An Xin Zero Trust Security Solution splits

and extends the product components based
on the zero trust reference framework, but
remains highly consistent on the overall
architecture. Its product components
are mapped to the zero trust reference
framework as shown in Figure 8. Source Qi An Xin Group, 2019

11
In this scheme, an end-to-end zero trust
solution is set up by deploying a logical zero
trust access control area between the user
subnet and the data subnet. TAP takes over
access requests of all the user and device
business, and TIP takes over all the external
application API call requests. All the access
requests are authenticated and dynamically
authorized through TAC. TESS continuously
carries on the assessment to the device, and
TNSS continuously carries on the assessment
to the network traffic, and generates the
security event to IDA. IDA comprehensively
accesses log reports, the security event
reports, the identity and authority information
and carries on key information and trust
evaluation. It acted as the basis of permission
determination or revocation for the trust level
output from TAC platform.
Figure 10 Migration Methodology of Zero Trust
12
4. Migration Methodology of Zero Development Department, IT Service
Trust Department, Operation Department, and etc.
The key decision-makers of the company’s
As a new security architecture, Zero Trust
digital transformation should raise the new
Architecture has a certain connection with
generation of zero trust security architecture
the existing business conditions, security
to a strategic level and define a unified vision.
capabilities, and organizational structure of
It is recommended to establish a dedicated
the enterprise. Zero trust migration cannot
organization (or virtual organization) and
be accomplished overnight. It is necessary to
assign people with sufficient authority to carry
follow a certain methodology, combine the
out the whole process of zero trust migration.
current situation of the enterprise unify the
It is suggested that people at least at the CIO/
goal and vision, to make plans properly and
CSO or level CISO should promote zero trust
construct step by step.
projects with the support of the company’s
senior decision makers.
The zero trust migration methodology is
shown in Figure 10.
Usually Security Department’s words are not
valued that much in enterprises and security
4.1. Define Vision
projects are often blocked or even opposed
by Business Department. Zero trust is the start
The construction and operation of zero
point for the initiators of zero trust projects to
trust requires the active participation of
persuade the Business Department and the
all the leading departments of enterprise,
company’s senior decision makers.
including Security Department, Business
Source Qi An Xin Group, 2019

In addition, it needs more cooperation and
support from departments and personnel
during the process of zero trust migration,
especially the critical support from its
numerous end users, their own ordinary
staff. It is also important to suggest that all
personnel should enhance their recognition
to zero trust security through the continuous
security culture activities on company level.
4.2. Plan First
Zero Trust Architecture was born inevitably
under the evolution of security thinking
and security architecture with focus on the
security capabilities of identity, business,
trust and adaptive access control and other
dimensions, all of which are inseparable,
requiring zero trust being a built-in security
naturally. The construction path of zero trust
should combine the current situation and
requirement, embed the core capability
of zero trust and the component into the
business system, and construct the adaptive
built-in security mechanism. It is suggested
that make plans at the beginning of business
construction and carry on the in-depth
aggregation of security and the business.
The purpose of planning is to identify and
define the path. Zero Trust Architecture needs
to be combed and evaluated from two
dimensions, capability maturity and business
scope.
The key capabilities of Zero Trust Architecture
include: identity-based schema, resource
secure access, continuous trust evaluation
and adaptive access control. Each key
capability can be divided into several
skills. The enterprises need to evaluate
the current security capabilities, and
determine the priority of security capability
construction based on the risks, security
budget, compliance requirements and other
information.
Zero Trust Architecture ultimately needs to
cover all the resources of the enterprise and
build a protection surface for it. Enterprise
resources include applications, APIs,
functions, data, etc. During the planning
phase, business priorities for migration to
zero trust need to be determined. In general,
new businesses and core businesses are
considered as first priority.
After sorting out the current situation,
requirements, business status and priority of
security capability, it is necessary to further
sort out the exposed surface of the core
business, the access subjects and the rights
of access subjects of each exposed surface,
and determine the initial construction path
and the construction scheme of the first
phase.
4.3. Construct Step-by-step
The construction phase closely follows the
planning. According to the thought orientation
of planning, the division of construction phase
varies according to different enterprises. If it
is a capability- priority construction idea, it is
necessary to build a low-to-high capability
for a small number of services, verify the
complete capability of zero trust through a
local business scenario, and then gradually
migrate more services. Scope- priority is to
migrate as many businesses as possible in
a moderate capacity dimension, and then
gradually improve the capabilities. Both ideas
have their own key points, and the enterprise
should select the ideas and divide the
construction stages according to the specific
conditions in the planning phase.
A proposed step-by-step thought consists
of three main steps, proof of concept,
application migration, and capability
evolution. First, build a medium zero trust
security capability and validate the overall
scheme in a small business scope; then
13
optimize some local optimization points in
validation process, and move into more
business applications for further verification
and detect new security requirements; finally,
plan the evolution phase of subsequent
capacity based on validation results to
enhance the zero trust capabilities in all
aspects gradually and methodically.
Zero Trust Architecture continues its evolution
by improvement and progress of zero trust
capability based on business requirements,
security operation status and technology
development trends.
5. Conclusion
Zero Trust Architecture reevaluates and
examines the traditional perimeter-based
security architecture, and gives new
suggestions on security architecture idea:
By default, any user, device, system, or
application shall not be trusted inside and
outside the network, instead, the trust base
of access control shall be reconstructed
based on adaptive authentication,
authorization, and encryption technology
and be dynamically adjusted based on the
trust evaluation of access subjects. It is a
brand new security concept and architecture
other than a coarse-grained access control
on perimeter of enterprise network. The fine-
grained access control shall be made to all
access requests among the people, devices,
business applications and data assets of
enterprises. Moreover, the access control
strategy should be dynamically adjusted
based on trust evaluation of context request.
It is a “built-in security” mechanism to deal
with threats under the new IT environment.
Source Qi An Xin Group
13
 Research from Gartner
Market Guide for Zero Trust
Network Access
Zero trust network access replaces traditional
technologies, which require companies to
extend excessive trust to employees and
partners to connect and collaborate. Security
and risk management leaders should plan
pilot ZTNA projects for employee/partner-
facing applications.
Key Findings
• Digital business transformation requires
that systems, services, APIs, data and
processes be accessible through multiple
ecosystems anywhere, anytime, from any
device over the internet. This expands the
surface area for attackers to target.
• Secure access capabilities must evolve to
the cloud, where the users are and where
applications and services are moving.
Many software-defined perimeter offerings
are cloud-based.
• IP addresses and location are no longer
practical to establish sufficient trust for
network access.
• Zero trust network access provides
adaptive, identity-aware, precision access.
Removing network location as a position
of advantage eliminates excessive implicit
trust.
• ZTNA improves flexibility, agility and
scalability, enabling digital ecosystems to
work without exposing services directly to
the internet, reducing risks of distributed
denial of service attacks.
• Although virtual private network
replacement is a common driver for the
adoption of ZTNA, ZTNA can also offer a
solution for allowing unmanaged devices
to securely access applications.
Recommendations
Security and risk management leaders
responsible for secure network access
should:
• Go beyond using IP addresses and
network location as a proxy for access
trust. Use ZTNA for application-level
access only after sufficient user and device
authentication.
14
• Replace designs for employee- and
partner-facing applications that expose
services to direct internet connections.
Pilot a ZTNA deployment using a digital
business service that needs to be
accessible to partners as a use case.
• Phase out legacy VPN-based access for
high-risk use cases and begin phasing in
ZTNA. This reduces the ongoing need to
support widely deployed VPN clients and
introduces clientless identity- and device-
aware access. Support unmanaged
devices for employees.
• Choose ZTNA products/services that
expand identity assurance beyond a single
factor, which is an important supplement
to the ZTNA principle of context-based/
adaptive access control.
Strategic Planning Assumptions
By 2022, 80% of new digital business
applications opened up to ecosystem
partners will be accessed through zero trust
network access (ZTNA).
By 2023, 60% of enterprises will phase out
most of their remote access virtual private
networks (VPNs) in favor of ZTNA.
By 2023, 40% of enterprises will have
adopted ZTNA for other use cases described
in this research.
Market Definition
ZTNA, which is also known as a software-
defined perimeter (SDP), creates an identity-
and context-based, logical-access boundary
around an application or set of applications.
The applications are hidden from discovery,
and access is restricted via a trust broker to a
set of named entities. The broker verifies the
identity, context and policy adherence of the
specified participants before allowing access.
This removes the application assets from
public visibility and significantly reduces the
surface area for attack.
Market Description
The old security mindset of “inside means
trusted” and “outside means untrusted” is
broken in the world of digital business, which
requires anywhere, anytime, any device
access to services that may not be located
“inside” an on-premises data center. Similarly,
the old model expects all programmers to be
security engineers, building intrinsically secure
networked applications, and incorporating
sophisticated authentication and access
controls. That does not scale today.
The new model presents an approach in
which a trust broker mediates connections
between applications and users. ZTNA
abstracts away and centralizes the security
mechanisms so that the security engineers
and staff can be responsible for them. ZTNA
starts with a default deny posture of zero
trust. It grants access based on identity,
plus other attributes and context (such as
time/date, geolocation and device posture),
and adaptively offers the appropriate trust
required at the time. The result is a more
resilient environment with improved flexibility
and better monitoring. ZTNA will appeal to
organizations looking for adaptive and secure
ways to connect and collaborate with their
digital business ecosystem, remote workers
and partners.
ZTNA provides controlled access to resources,
reducing the surface area for attack. The
isolation afforded by ZTNA improves
connectivity, removing the need to directly
expose applications to the internet. The
internet becomes an untrusted transport and
access to applications occurs through an
intermediary. The intermediary can be a cloud
service controlled by a third-party provider or
a self-hosted service. In either case, incoming
traffic to applications always passes through
the intermediary after users have successfully
authenticated to it.
In many cases, entity behavior is continuously
monitored for abnormal activity, as described
in Gartner’s Continuous Adaptive Risk and
Trust Assessment (CARTA) framework. In a
sense, ZTNA creates individualized “virtual
perimeters” that encompass only the user, the
device and the application. ZTNA normalizes
the user experience, removing the access
distinctions that exist when on, versus off, the
corporate network.

Market Direction
The ZTNA notion has been gaining
momentum since an initial specification
for software-defined perimeters (SDP) was
introduced at the Cloud Security Alliance
Summit in 2014. The initial SDP specification
addressed web-based applications only, and
updates to the specification have lagged, but
they are expected later in 2019. Commercial
products roughly based on this initial
specification are available, as are products
based on Google’s BeyondCorp zero trust
networking vision — also limited to web-
enabled applications only. In addition, a large
number of alternative commercial products
using other approaches that are not limited to
web applications have entered the market.
The ZTNA market is still nascent, but it’s
growing quickly. It has piqued the interest
of organizations seeking a more flexible
alternative to VPNs and those seeking
more precise access and session control
to applications located on-premises and
in the cloud. ZTNA vendors continue to
attract venture capital funding. This, in turn,
encourages new startups to enter the market
and seek ways to differentiate. Merger and
acquisition (M&A) activity in this market has
begun, with three startup vendors now
having been acquired by larger networking,
telecommunications and security vendors.
Although ZTNA offerings differ in their
technical approaches, they provide generally
the same fundamental value proposition:
• Removing applications and services from
direct visibility on the public internet.
• Enabling precision (“just in time” and
“just enough”) access for named users
to specific applications only after an
assessment of the identity, device health
(highly encouraged) and context has been
made.
• Enabling access independent of the user’s
physical location or the device’s IP address
(except where policy prohibits — e.g., for
specific areas of the world). Access policies
are based on user, device and application
identities.
• Granting access only to the specific
application, not the underlying network.
This limits the need for excessive access to
all ports and protocols or all applications,
some of which the user may not be
entitled to.
• Providing end-to-end encryption of
network communications.
• Providing optional inspection of the traffic
stream for excessive risks in the form of
sensitive data handling and malware.
• Enabling optional monitoring of the
session for indications of unusual activity,
duration or bandwidth requirements.
• Providing a consistent user experience
for accessing applications — clientless or
via a ZTNA client regardless of network
location.
Gartner has identified different approaches
vendors have adopted as they develop
products and services for the market.
Client-Initiated ZTNA
These offerings more closely follow the
original Cloud Security Alliance (CSA)
SDP specification. An agent installed on
authorized devices sends information
FIGURE 1
Conceptual Model of Client-Initiated ZTNA
15
about its security context to a controller. The
controller prompts the user on the device for
authentication and returns a list of allowed
applications. After the user and device are
authenticated, the controller provisions
connectivity from the device through a
gateway that shields services from direct
internet access. The shielding protects
applications from distributed denial of service
(DDoS) attacks.
Some products remain in the data path
once the controller establishes connectivity;
others remove themselves. This approach is
difficult, if not impossible, to implement on an
unmanaged device, due to the requirement
to install an agent. In some cases, a third-
party mobile threat defense (MTD) product —
which users may be more willing to accept
than full device management — can provide
a posture assessment to the trust broker. (See
Figure 1 for a conceptual model.)
Service-Initiated ZTNA
These models more closely follow the Google
BeyondCorp vision. A connector installed
in the same network as the application
establishes and maintains an outbound
connection to the provider’s cloud. Users
authenticate to the provider to access
protected applications. The provider then
typically authenticates to an enterprise
15
identity management product. Application
traffic passes through the provider’s cloud,
which provides isolation from direct access
via a proxy. Enterprise firewalls require no
openings for inbound traffic. However, the
provider’s network becomes another element
of network security that must be evaluated.
The advantage of this model is that no agent
is required on the end user’s device, making
it an attractive approach for unmanaged
devices. The disadvantage is that the
application’s protocols must be based on
HTTP/HTTPS, limiting the approach to web
applications and protocols such as Secure
Shell (SSH) or Remote Desktop Protocol (RDP)
over http. (See Figure 2 for a conceptual
model.)
Some vendors offer both alternatives. This
provides enterprises with the ability to mix
and match, as needed, to address specific
use cases.
Market Analysis
The internet was designed to connect things
easily, not to block connections. The internet
uses inherently weak identifiers (specifically,
IP addresses) to connect. If you have an IP
address and a route, you can connect and
communicate to other IP addresses, which
were never designed to be authentication
FIGURE 2
Conceptual Model of Service-Initiated ZTNA
16
mechanisms. The messy problem of
authentication is handled by higher levels
of the stack, typically the OS and application
layers. For network connectivity, this default
allow posture creates an excessive amount of
implicit trust.
Attackers abuse this trust. The first companies
that connected to the public internet quickly
found out that they needed a demarcation
point where their internal network connected
to the internet. This ultimately created
what has become a multibillion dollar
market for perimeter firewalls. Networked
systems on the inside were “trusted” and
free to communicate with each other.
External systems were “untrusted” and
communications with the outside, inbound or
outbound, were blocked by default. If needs
arose for communication with the outside,
these required a series of exceptions (i.e.,
holes) in the firewall, which were difficult and
cumbersome to maintain and monitor.
This trusted/untrusted network security model
is a relatively coarse and crude control, but
it was initially effective. However, it creates
excessive trust (on the inside) that is abused
by attackers from the outside (once they
penetrate the defenses and reach the inside).
When external access to our systems and
services is needed, we typically do one of
two things. For some users, we create a VPN
to allow the user to pass through the firewall
and connect to the internal network. Once
“inside,” the VPN connection is treated as
trusted.
Alternatively, we place the front end to the
service in a segmented part of the network
with direct internet connectivity — referred
to as a demilitarized zone (DMZ) — so
users can access it. Both alternatives create
excessive trust and do little to restrict lateral
movement, resulting in latent risk. In the case
of VPNs, attackers with credentialed access
now have access to our networks. (The Target
HVAC breach is an example.) Likewise, if the
service is exposed in the DMZ, anyone on the
internet — including all the attackers — can
see it as well, even if it is protected by a web
application firewall (WAF).
Excessive network trust leads to excessive
latent risk. This will inevitably be exploited,
leading to breaches and bringing legal,
financial and regulatory exposure. Network
connectivity (even the right to “ping” or see a
server) should not be an entitlement; it should
be earned based on trust. Gartner believes
the time has come to isolate services and
applications from the dangers of the public
internet, and to provide compartmentalized
access only to required applications in any
given context. The tremendous increase in the
number of internet-connected services, and
the growing likelihood that services and users
could be located at virtually any IP address,
exacerbate the weaknesses of the old model.
Benefits and Uses
The benefits of ZTNA are immediate. Similar
to a traditional VPN, services brought within
the ZTNA environment are no longer visible
on the public internet and, thus, are shielded
from attackers. In addition, ZTNA brings
significant benefits in user experience, agility,
adaptability and ease of policy management.
For cloud-based ZTNA offerings, scalability
and ease of adoption are additional benefits.
ZTNA enables digital business transformation
scenarios that are ill-suited to legacy
access approaches. As a result of digital
transformation efforts, most enterprises will

have more applications, services and data
outside their enterprises than inside. Cloud-
based ZTNA services place the security
controls where the users and applications
are — in the cloud. Some of the larger ZTNA
vendors have invested in dozens of points
of presence worldwide for low-latency user/
device access.
Several use cases lend themselves to ZTNA:
• Opening applications and services to
collaborative ecosystem members,
such as distribution channels, suppliers,
contractors or retail outlets, without
requiring a VPN or DMZ. Access is more
tightly coupled to applications and
services.
• Normalizing the user experience for
application access — ZTNA eliminates the
distinction between being on and off the
corporate network.
• Carrying encryption all the way to the
endpoints for scenarios where you don’t
trust the carrier or cloud provider.
• Providing application-specific access
for IT contractors and remote or mobile
employees as an alternative to VPN-based
access.
• Extending access to an acquired
organization during M&A activities, without
having to configure site-to-site VPN and
firewall rules.
• Permitting users in potentially dangerous
areas of the world to interact with
applications and data in ways that reduce
or eliminate the risks that originate in those
areas — pay attention to requirements for
strong identity and endpoint protection.
• Isolating high-value enterprise applications
within the network or cloud to reduce
insider threats and affect separation of
duties for administrative access.
• Authenticating users on personal devices
— ZTNA can improve security and simplify
bring your own device (BYOD) programs by
reducing full management requirements
and enabling more-secure direct
application access.
• Creating secure enclaves of Internet of
Things (IoT) devices or a virtual-appliance-
based connector on the IoT network
segment for connection.
• Cloaking systems on hostile networks,
such as systems that would otherwise face
the public internet, used for collaboration.
• Enabling SaaS applications to connect
back to enterprise systems and data for
processes that require SaaS applications
to interact with enterprise on-premises or
infrastructure as a service (IaaS)-based
services.
Risks
Although ZTNA greatly reduces overall risks,
it doesn’t eliminate every risk completely, as
these examples illustrate:
• The trust broker could become a single
point of any kind of failure. Fully isolated
applications using ZTNA will stop working
when the ZTNA service is down. Well-
designed ZTNA services include physical
and geographic redundancy with multiple
entry and exit points to minimize the
likelihood of outages affecting overall
availability. Furthermore, a vendor’s SLA
(or lack thereof) can be an indicator of
how robust it views their offering. Favor
vendors with SLAs that minimize business
disruptions.
• Attackers could attempt to compromise the
trust broker system. Although unlikely, the
risk isn’t zero. ZTNA services built on public
clouds or major internet carriers benefit
from the provider’s strong tenant isolation
mechanisms. Nevertheless, collapse of the
tenant isolation would allow an attacker
to penetrate the systems of the vendor’s
customers and move laterally within and
between them. A compromised trust
broker should fail over to a redundant one
immediately. If it can’t, then it should fail
closed — that is, if it can’t deflect abuse, it
should disconnect from the internet. Favor
vendors who adopt this stance.
17
• Compromised user credentials could
allow an attacker on the local device
to observe and exfiltrate information
from the device. ZTNA architectures
that combine device authentication with
user authentication contain this threat
to a degree, stopping the attack from
propagating beyond the device itself. We
suggest that, wherever possible, stronger
authentication for access be used.
• Some ZTNA vendors have chosen to
focus their developments on supporting
web application protocols only (HTTP/
HTTPS). Carrying legacy applications and
protocols through a ZTNA service could
prove to be more difficult.
• The market is in flux, and smaller vendors
could disappear or be acquired.
Evaluation Factors
When evaluating ZTNA technologies, here
are the key questions to ask:
• Does the vendor require that an
endpoint agent be installed? What OSs
are supported? What mobile devices?
How well does the agent behave in the
presence of other agents?
• Does the offering support single packet
authentication (SPA) as an initial form of
identity verification to the trust broker? SPA
allows the broker to ignore any attempts
to communicate, unless the first attempt
contains a specialized, encrypted packet.
• Does the offering provide the ability to
perform a security posture assessment
of the device (OS version, patch levels,
password and encryption policies, etc.),
without requiring a unified endpoint
management (UEM) tool? Is any
option provided for achieving this on
unmanaged devices?
• Does the offering integrate with UEM
providers, or can the local agent
determine device health and security
posture as a factor in the access decision?
What UEM vendors has the ZTNA vendor
partnered with?
17
• What authentication standards does the
trust broker support? Is integration with
an on-premises directory or cloud-based
identity services available? Does the trust
broker integrate with the organization’s
existing identity provider? Does the trust
broker support common options for
multifactor authentication (MFA)? Can the
provider enforce strong user authentication
for administrators?
• Is there user and entity behavior analytics
(UEBA) functionality that can identify when
something anomalous happens within the
ZTNA-protected environment?
• Some ZTNA products are delivered partly
or wholly as cloud-based services. Does
this meet the organization’s security and
residency requirements? Has the vendor
undergone one or more third-party
attestations, such as SOC 2 or ISO 27001?
• How geographically diverse are the
vendor’s entry and exit points (referred
to as edge locations and/or points of
presence) worldwide? What edge/physical
infrastructure providers or colocation
facilities does the vendor use?
• What is the vendor’s technical behavior
when the ZTNA service comes under
sustained attack? Does the service fail
closed (thus blocking digital business
partners from accessing enterprise
services) or does the service fail open?
Is it possible to selectively choose fail-
closed or fail-open for specific enterprise
applications? If fail-open is a requirement,
don’t forget to add in other layers of
defense to protect applications no longer
shielded by the ZTNA service.
• Does the offering support only web
applications, or can legacy applications
also gain the same security advantages?
• What algorithms and key lengths has
the vendor chosen? What third-party
certifications has the vendor obtained?
Does the vendor’s product description
demonstrate an understanding of
contemporary cryptographic practices, or
18
is it laced with too-good-to-be-true crypto
“snake oil”?
• After the user and device pass
authentication, does the trust broker
remain resident in the data path? This
approach deserves consideration. Trust
brokers that remain in the data path
offer greater visibility and can monitor for
unusual and suspicious activities. They
could, however, become bottlenecks
or single points of failure. Designs that
include failover support mitigate this
concern, but could be vulnerable to DDoS
attacks that attempt to bypass inspection.
• Can the vendor provide inspection
of session flows and content for
inappropriate sensitive data handling,
malware detection and unusual
behaviors?
• To what extent is partial or full cloaking,
or allowing or prohibiting inbound
connections, a part of the isolated
application’s security requirements?
Perhaps the more minimal protection of a
content delivery network (CDN) is sufficient.
Different enterprise applications might
have different requirements.
• Does the provider maintain a bug bounty
program and have a credible, responsible,
public or private disclosure policy? It is
critical for software providers to constantly
test for and remove product vulnerabilities.
Favor providers that actively do so.
ZTNA Alternatives
There are several alternative approaches to
ZTNA:
• Legacy VPNs remain popular, but
they might not provide sufficient risk
management for exposed services
and may be difficult to manage, given
the dynamic nature of digital business.
Always-on VPNs that require device and
user authentication align with the ZTNA
model; however, basic network-access
VPNs do not. Factor security requirements
into VPN models and user satisfaction
expectations. For third-party, privileged
access into enterprise systems, a privileged
access management (PAM) tool can be a
useful alternative to a VPN.
• Exposing web applications through a
reverse-proxy-based WAF is another
option. With WAF as a service (i.e., cloud
WAF), traffic passes through the provider’s
WAF service for inspection before delivery
to its destination. To avoid false positives or
potential application malfunctions, cloud
WAFs, like any other WAF, typically require
some time for testing and adjusting rules.
Because the protected services are still
visible to attackers on the public internet,
the isolation is limited to the strength of the
WAF. However, partner- and employee-
facing applications are not normally
candidates for WAFs.
• Choosing to retain existing design patterns
and exposing digital business applications
in traditional DMZs remain alternatives.
However, DMZs provide limited isolation
against modern attacks (typically a
reverse-proxy WAF). Furthermore, DMZs
still leave the application discoverable to all
attackers.
• A remote browser isolation product offers
another option, specifically for the isolation
of web-enabled application access. Here,
the browser session itself is rendered from
the end user’s device and, typically, in a
service, from the enterprise network (e.g.,
a cloud-based remote browser service),
providing isolation on both sides.
• CDNs can absorb DDoS attacks, reduce the
noise and threats of bot attacks, and guard
against website defacement. However,
they offer no application-level protection
and no anonymity — attackers targeting
sites can discover the site is protected
with a CDN and might attempt to exploit
vulnerabilities present in the CDN. Many
CDNs include a basic cloud WAF.
• Applications that don’t require full,
interactive internet connectivity, but instead
expose only APIs to the public internet
could be protected by an API gateway,
although ZTNA can also work here. API
gateways enforce authentication, validate
 19

authorization and mediate the correct use Table 1. Representative Vendors of ZTNA as a Service
of application APIs. This is especially useful
if the application lacks mechanisms for Vendor Product or Service Name
ensuring API security. Most API gateways Akamai Enterprise Application Access
also expose logs of all activity through Cato Networks Cato Cloud
a native monitoring tool or integration
Cisco Duo Beyond (acquisition by Cisco)
with popular security information and
event management (SIEM) tools. Favor API CloudDeep Technology (China only) DeepCloud SDP
gateways that integrate with enterprise Cloudflare Cloudflare Access
directories and single sign-on (SSO) InstaSafe Secure Access
protocols — or use a ZTNA service instead.
Meta Networks Network as a Service Platform
• It is possible to go full IaaS. When ZTNA New Edge Secure Application Network
or other isolation measures are not Okta Okta Identity Cloud (Acquired ScaleFT)
good enough, moving the application
off-enterprise completely is the best Perimeter 81 Software Defined Perimeter
alternative. Many of the suggested SAIFE Continuum
isolation mechanisms are available to Symantec Luminate Secure Access Cloud (acquisition by
workloads placed in the cloud and are Symantec)
designed more for primary protection,
Verizon Vidder Precision Access (acquisition)
rather than enterprise isolation. The goal
shifts to protecting the application and Zscaler Private Access
data, with less concern for isolation. Source: Gartner (April 2019)
However, this still leaves systems exposed
to attack, especially if legacy DMZ
architectures are replicated in the cloud.
Table 2. Representative Vendors of Stand-Alone ZTNA
Representative Vendors
Vendor Product or Service Name
The vendors listed in this Market Guide do
not imply an exhaustive list. This section is BlackRidge Technology Transport Access Control
intended to provide more understanding of Certes Networks Zero Trust WAN
the market and its offerings. Cyxtera AppGate SDP
Google Cloud Platform (GCP) Cloud Identity-Aware Proxy (Cloud IAP)
Market Introduction
Microsoft (Windows only) Azure AD Application Proxy
ZTNA products and services are offered by
vendors in one of two ways: Pulse Secure Pulse SDP
Safe-T Software-Defined Access Suite
• As a service from the cloud
Unisys Stealth

• As a stand-alone offering that the Waverley Labs Open Source Software Defined Perimeter
customer is responsible for supporting Zentera Systems Cloud-Over-IP (COiP) Access
Source: Gartner (April 2019)
As-a-service offerings (see Table 1) require
less setup and maintenance than stand-
alone offerings. As-a-service offerings
typically require provisioning at the end-user
or service side and route traffic through
the vendor’s cloud for policy enforcement.
Stand-alone offerings (see Table 2) require
customers to deploy and manage all
elements of the product. In addition, several
of the major IaaS cloud providers offer ZTNA
capabilities for their customers.

19
Market Recommendations
Given the significant risk that the public
internet represents and the attractiveness
of compromising internet-exposed systems
to gain a foothold in enterprise systems,
enterprises need to consider isolating
digital business services from visibility by
the public internet. Don’t mistake Gartner’s
recommendation for the tried, yet true
“security by obscurity is no security at all”
axiom. Although ZTNA cloaks services from
discovery and reconnaissance, it erects
true barriers that are proving to be more
challenging for attackers to circumvent than
older notions of simple obfuscation.
For legacy VPN access, look for scenarios in
which targeted sets of users performing their
work through a ZTNA service can provide
immediate value in improving the overall
security posture of the organization. In most
cases, this could be a partner- or employee-
facing application. A ZTNA project is a
step toward a more widespread zero trust
networking (default deny) security posture.
Specifically, nothing can communicate (or
even see) an application resource until
sufficient trust is established, given the
risk and current context to extend network
connectivity.
them from the scope. This includes access
to and download of unstructured data not
protected by application- and consumer-
facing applications.
• The ZTNA market is emerging, so sign
only short-term contracts for no more than
12 to 24 months to retain greater vendor
selection flexibility as the market grows
and matures.
• For most digital business scenarios, favor
vendors that offer ZTNA as a service for
easier deployment, higher availability
and protection against DDoS attacks.
Favor vendors that require no openings
in firewalls for listening services (inbound
connections), which is typical for most as-
a-service flavors of ZTNA.
• When security requirements demand
an on-premises installation of a ZTNA
product, favor vendors that can reduce the
number of firewall openings as much as
possible.
• If unmanaged devices will be used by
named users, plan to deploy a reverse-
proxy-based ZTNA product or service to
avoid the need for agent installation.
• Attackers will target ZTNA trust brokers. For
on-premises ZTNA products, harden the
host OSs using a cloud workload protection
platform (CWPP) tool that supports on-
premises deployments Rely primarily on
default deny allow-listing to explicitly define
the code allowed to execute on the system.
Don’t rely solely on patching to keep the
system hardened.
• If you choose a smaller provider, plan
for potential acquisitions by placing
appropriate clauses in contracts and
having a list of alternative providers lined
up, if needed.
Note 1. Representative Vendor Selection❋
The vendors named in this guide were
selected to represent two types of ZTNA
offerings: as-a-service and stand-alone. For
these categories, we list the vendors known to
Gartner as of April 2019.
Note 2. Gartner’s Initial Market Coverage
This Market Guide provides Gartner’s initial
coverage of the market and focuses on the
market definition, rationale for the market and
market dynamics.
Source: Gartner Research Note G00386774, Steve Riley,
Neil MacDonald, Lawrence Orans, 29 April 2019

For DMZ-based applications, evaluate
what sets of users require access. For those
applications with a defined set of users, plan
to migrate them to a ZTNA service during the
next several years. Use the migration of these
applications to public cloud IaaS as a catalyst
for this architectural shift.
Specific Recommendations
• Budget and pilot a ZTNA project to
demonstrate the benefits of ZTNA to the
organization.
• Ensure that the vendor supports the
authentication protocols the organization
and partners use now, including the
enterprise’s standard identity store, as
well as any it expects to use in the future.
The wider the available range, the better,
including cloud SSO providers and SaaS-
delivered access management providers.
• Don’t expect partners to use your identity
store. Require support for SAML, OAuth,
OIDC and similar identity federation
capabilities.

• Plan for user-to-application mapping. • Evaluate the effectiveness of a vendor’s

Role-based access control (RBAC) can help
with this. Avoid allowing all users to access
all applications.
• Identify which applications and workflows
are not candidates for ZTNA, and exclude
ability to query other kinds of device
agents, such as UEM, endpoint detection
and response (EDR) and MTD, to gain
additional context for improved adaptive
access decisions.

20
 About Qi An Xin Group
Qi An Xin Group is leading security provider dedicated in protecting
critical and valuable internet assets in a wide range of areas including
governments, finance, energy, telecom, and etc. Qi An Xin Group is the
fastest growing company in the Chinese security market with over 90%
consecutive compound annual growth rate since 2015. Under hard work
of over 6500 employees, its technologies have been adopted in 90% of
government departments, state-owned companies, and large banks.
It starts our international development in 2019 and extend our global
business in Indonesia, Singapore, Canada, Hong Kong, Macao etc.
Qi An Xin takes “protecting the security in the big data era” as the
mission, “data-driven security” as technical thinking, and big data
collection and analysis as support to provide escort and protection for
enterprise customers.
Qi An Xin’s corporate vision is to comprehensively enhance security
protection ability and level of Chinese organizations and enterprises,
and build a reliable network environment for economic development.
Qi An Xin uses innovative means of “Internet+” such as big data
analysis to help Chinese organizations and enterprises better respond
to security threats.
Qi An Xin Identity Security Lab, a professional lab under Qi An Xin
Group, focusing on “Zero Trust Security Architecture”. The team takes
“Zero Trust Security, New Identity Perimeter” as its core concept
and explores new type of security architecture in the assumption of
“enterprise’s perimeter is vanishing and perimeter-based defense
measures are becoming ineffective”. It has launched Qi An Xin
Zero Trust Security Solution with four key capabilities: identity-based
schema, resource secure access, continuous trust evaluation and
adaptive access control. The team has invested heavily in the research
of Zero Trust Security Architecture and product standardization and
actively pushed forward the deployment and implementation of
the architecture, whose program has been deployed in the central
government agencies and state-owned enterprises and highly
recognized by the market and the industry.
21