Gartner：Market Guide for Zero Trust Network Access 零信任网络市场指南

Page 1/18
Gartner, Inc. | 726817

Market Guide for Zero Trust Network Access

报告地址：link

Published 8 June 2020 - ID G00726817 - 27 min read
By Analysts Steve Riley, Neil MacDonald, Lawrence Orans
Initiatives:Infrastructure Security

代表性供应商：

以下是报告原文：

ZTNA augments traditional VPN technologies for application access, and removes the
excessive trust once required to allow employees and partners to connect and collaborate.
Security and risk management leaders should pilot ZTNA projects as part of a SASE strategy
or to rapidly expand remote access.

Overview
Key Findings
Digital business transformation requires systems, services, application programming interfaces,
data and processes to be accessible through multiple mechanisms anywhere, anytime, from any
user device over the internet. This expands the surface area for attackers to target.
■
Users and applications are already in the cloud. Hence, secure access capabilities must evolve
to cloud delivery, too. Many zero trust network access products are cloud-based.
■
IP addresses and network locations used by traditional networks, virtual private networks and
demilitarized zone architectures to establish access are often configured to allow excessive
implicit trust and unpatched vulnerabilities, leaving enterprises at risk for attack.
■
ZTNA provides adaptive, identity-aware, precision access. Removing network location as a
position of advantage eliminates excessive implicit trust, replacing it with explicit identity-based
trust.
■
ZTNA improves the flexibility, agility and scalability of application access, enabling digital
businesses to thrive without exposing internal applications directly to the internet, reducing risk
of attack.
■
Although VPN replacement is a common driver for its adoption, ZTNAs rarely replace VPN
completely.
■
Secondarily, organizations rely on ZTNA to allow unmanaged devices and external partners to
securely access applications without the need to trust the device connection.
■
Recent movements to largely remote workforces have accelerated the adoption of ZTNA to
address the hardware and bandwidth limitations of traditional VPN access.
■
Page 2/18
Gartner, Inc. | 726817
Recommendations
Security and risk management leaders responsible for infrastructure security should:
Market Definition
This document was revised on 16 June 2020. The document you are viewing is the corrected
version. For more information, see the Corrections page on gartner.com.
Gartner defines zero trust network access (ZTNA) as products and services that create an identityand
context-based, logical-access boundary encompassing a user and an application or set of
applications. The applications are hidden from discovery, and access is restricted via a trust broker
to a collection of named entities. The broker verifies the identity, context and policy adherence of
the specified participants before allowing access, and minimizes lateral movement elsewhere in
the network. ZTNA removes excessive implicit trust that often accompanies other forms of
application access.
Market Description
The old security model of “inside means trusted” and “outside means untrusted” is broken. When
users became mobile and when business partners on the “outside” required access, virtual private
Deploy a ZTNA product that relies on multiple contextual aspects to establish and adapt trust
for application-level access. Stop relying primarily on IP addresses and network location as a
proxy for trust.
■
Evaluate the use of a cloud-based ZTNA to offload some use cases if your traditional remote
access VPN is experiencing limitations in capacity or bandwidth limitations because of an
expanded remote workforce.
■
Replace designs for employee- and partner-facing applications that expose services to direct
internet connections. An especially beneficial use case is to pilot a ZTNA deployment of a digital
business service that needs to be accessible to partners.
■
Phase out legacy VPN-based access for users who don’t need full network access and begin
phasing in ZTNA. This reduces the ongoing need to support widely deployed VPN agents and
introduces agentless identity- and device-aware access, which can facilitate access from
managed and unmanaged devices.
■
Choose ZTNA products that integrate with common multifactor authentication products to
expand identity assurance beyond a single factor, which is an important supplement to the
ZTNA principle of context-based adaptive access control.
■
Choose ZTNA products aligned with an organization’s secure access service edge architecture
plans or exhibiting a strong vendor secure access service edge product roadmap to enable
future networking and security delivered as a service from the cloud.
■
Page 3/18
Gartner, Inc. | 726817
networks (VPNs) and demilitarized zones (DMZs) became common. They also granted excessive
implicit trust — trust that attackers abused. The reality of digital business is that it requires
anywhere, anytime access to any application, regardless of the locations of the users and their
devices.
The new model — zero trust networking — presents an approach that abstracts and centralizes the
access 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 the identity of the
humans and their devices, 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 more-flexible and responsive ways to connect and collaborate with their
digital business ecosystems, remote workers and partners.
ZTNA provides controlled identity- and context-aware 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 remains an untrusted transport; a trust
broker mediates connections between applications and users. The broker can be a cloud service
managed by a third-party provider or a self-hosted service (in the form of a physical appliance in
the customer’s data center or a virtual appliance in a public infrastructure as a service [IaaS]
cloud). Once the broker has evaluated a user’s credentials and his or her device’s context, the broker
communicates to a gateway function placed logically close to applications. In most cases, the
gateway establishes an outbound communication path to the user. In some ZTNA products, the
broker remains in the data path; in others, only the gateway does.
In many cases, user and device behavior are continuously monitored for abnormal activity, as
described in Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) framework (see
“Zero Trust Is an Initial Step on the Roadmap to CARTA”). 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
As more organizations transition to remote work, ZTNA 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 an increasingly crowded
market and seek ways to differentiate. Merger and acquisition (M&A) activity in this market is
underway, with multiple 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:
Page 4/18
Gartner, Inc. | 726817
Gartner has identified different approaches vendors have adopted as they develop products and
services for the market.
Endpoint-Initiated ZTNA
These offerings more closely follow the original Cloud Security Alliance (CSA) software-defined
perimeter (SDP) specification. An agent installed on authorized end-user devices sends information
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 denial of
service (DoS) attacks and other threats they would bear if they were placed in a traditional DMZ.
Some products remain in the data path once the controller establishes connectivity; others remove
themselves. Endpoint-initiated ZTNA is difficult, if not impossible, to implement on an unmanaged
device, because of the requirement to install some form of agent or local software. In some cases,
a third-party unified endpoint security (UES) 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.)
Removing applications and services from direct visibility on the ■ public internet.
Enabling precision (“just in time” and “just enough”), least-privilege access for named users to
specific applications only after an assessment of the user identity, device identity and hygiene
(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 primarily 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. Crucially, it also minimizes the ability to move laterally, a pernicious threat
afflicting many enterprises.
■
■ 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 behaviors, such as user
activity, session duration or bandwidth consumption.
■
Providing a consistent user experience for accessing applications — agentless or via a ZTNA
agent — regardless of network location.
■
Page 5/18
Gartner, Inc. | 726817
Figure 1: Conceptual Model of Endpoint-Initiated ZTNA
Service-Initiated ZTNA
These offerings more closely follow the Google BeyondCorp vision. A connector installed in the
same network as the application establishes and maintains an outbound connection (which some
implementations refer to as “inside-out”) to the provider’s cloud. Users authenticate to the provider
to access protected applications. In turn, the provider validates the user with an enterprise identity
management product. Only after validation succeeds will traffic pass through the provider’s cloud,
which isolates applications 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 service-initiated ZTNA 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. Recently,
a few newer vendors began offering additional protocol support. (See Figure 2 for a conceptual
model.)
Figure 2: Conceptual Model of Service-Initiated ZTNA
Page 6/18
Gartner, Inc. | 726817
Some vendors support hybrid use cases combining both alternatives. One flavor of such a mix is to
combine the models into a single product, enabling customers to choose endpoint-initiated
sessions for some applications and service-initiated sessions for other applications and for users
with unmanaged devices. Another flavor is to offer the service-initiated model with an end-user
agent to support legacy protocols.
Market Analysis
The internet was designed to connect things, not to block. With an IP address and a route, anything
could talk to anything (default allow). The messy problem of authentication was handled higher up
the stack.
However, attackers abused this trust, and, as enterprises started connecting to the internet, they
quickly moved to adopt network firewalls to create “trusted” areas on the inside, separated from the
“untrusted” areas on the outside. When employees went mobile, VPNs extended internal trust to
remote workers by extending the network. Attackers illicitly gained VPN credentials to abuse this
trust. When external access was required, services moved into DMZs, which exposed them to
attackers.
Excessive implicit network trust creates excessive latent risk that will be attacked. Network access
(even the right to “ping” or see a server or application) is not a given. It should be earned based on
the identity of the user, the device and context.
The increasing number of internet-connected services, and the growing likelihood that services and
users could be located at virtually any IP address, combined with the shift to a largely remote
workforce, exacerbate the weaknesses of the old model.
Benefits and Uses
The benefits of ZTNA are immediate. Similar to a traditional VPN, services brought into 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 borders 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 (POPs) worldwide to satisfy latencysensitive
requirements and to satisfy regional logging and inspection requirements.
Several use cases lend themselves to ZTNA:
Page 7/18
Gartner, Inc. | 726817
Risks
Although ZTNA greatly reduces overall risks, it doesn’t eliminate every risk completely, as these
examples illustrate:
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 users, applications and services.
■
Normalizing the user experience for application access — ZTNA eliminates the distinction
between being on and off the corporate network.
■
Deriving personas based on user behavior — for example, if a user’s phone is in one country, but
its PC is in another country, and both are attempting to log on to the same application, legitimate
access should be permitted while compromised devices should be blocked.
■
Carrying encryption all the way from the endpoint to the ZTNA gateway (which may run on the
same server as the application it is protecting) for scenarios where you don’t trust the local
wireless hot spot, carrier or cloud provider.
■
Providing application-specific access for IT contractors and remote or mobile employees as an
alternative to VPN-based access.
■
Controlling administrative access to applications (such as cloud-based applications) as a lowercost
alternative to full privileged access management (PAM) tools.
■
Extending access to an acquired organization during M&A activities, without having to combine
networks, combine directories or configure site-to-site VPN and firewall rules.
■
Isolating high-value enterprise applications in 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 moresecure
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.
■
The trust broker could become a single point of any kind of failure. Fully isolated applications
passing through a ZTNA service will stop working when the 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 vendors’ SLAs
■
Page 8/18
Gartner, Inc. | 726817
Evaluation Factors
When evaluating ZTNA technologies, here are the key questions to ask:
(or lack thereof) can indicate how robust they view their offerings. Favor vendors with SLAs that
minimize business disruptions.
The location of the trust broker can create latency issues for users, negatively affecting the user
experience. Well-designed ZTNA offerings provide multiple POPs, combined with peering
relationships, to improve redundancy, while decreasing latency.
■
Attackers could attempt to compromise the trust broker system. Although unlikely, the risk isn’t
zero. ZTNA services built on public clouds or housed in 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. In addition, verify that
vendors maintain their own security operations teams that diligently monitor their infrastructure
for issues affecting the integrity of the service.
■
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, when possible, MFA should accompany any ZTNA
project (see “Enhance Remote Access Security With Multifactor Authentication and Access
Management”).
■
Given the concerns with trust broker failure and user credentials, administrator accounts are ripe
for attack. Limit the number of administrators, and monitor their activities to reduce insider
threats and to favor vendors that require strong authentication for administrators by default.
■
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 technically challenging for vendors to develop and for customers
to deploy.
■
The market is in flux, and smaller vendors could disappear ■ or be acquired.
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 vendor support ZTNA for managed and unmanaged devices (ideally both)?
Page 9/18
Gartner, Inc. | 726817
Does the vendor offer ZTNA as a service, or does it require the customer to install and manage
the ZTNA broker (ideally, hybrid architectures using both could be used)?
■
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 use the local agent to determine device health and security posture as a factor
in the access decision? Does it require a secondary product to perform endpoint assessments,
such as network access control or a UEM? What vendors has the ZTNA vendor partnered with, or
do they provide their own products? Does the offering integrate with any leading UES or
endpoint protection platform (EPP)/endpoint detection and response (EDR) providers (such as
CrowdStrike or Microsoft) for deeper insight into device security posture?
■
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
MFA?
■
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 for data inspection and logging? Has the
vendor undergone one or more third-party attestations (e.g., SOC 2 or ISO 27001), and will the
vendor share the assessment reports with customers?
■
How geographically diverse are the vendor’s entry and exit points (referred to as edge locations
and/or POPs) worldwide? What edge/physical infrastructure providers or colocation facilities
does the vendor use?
■
Does the vendor offer “cold-potato routing,” which means bringing the end-user device into the
provider’s network as soon as possible, or does the vendor allow only “hot-potato routing,” which
means the end-user’s traffic traverses more of the public internet?
■
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 the fail-open capability 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?
■
Page 10/18
Gartner, Inc. | 726817
What algorithms and key lengths has the vendor chosen? Are unsafe versions of transport layer
security (TLS) disallowed? Does the vendor’s product description demonstrate an understanding
of contemporary and standard cryptographic practices, or is it laced with too-good-to-be-true
crypto “snake oil”?
■
After the user and device pass authentication, does the trust broker or gateway remain resident
in the data path? This approach deserves consideration. Trust brokers or gateways that remain
in the data path offer greater visibility and can monitor for unusual and suspicious activities.
However, they could become bottlenecks or single points of failure. Designs that include failover
support mitigate this concern, but could be vulnerable to distributed denial of service (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?
■
Does the offering support single packet authorization (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.
■
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.
■
Does the provider offer a secure API for programmatic management of user to application
segmentation?
■
How many applications are supported by the vendor? If you need more than maximum allowed,
how can you manage this (e.g., support for multitenant management through a single
management console)?
■
What is the licensing model? Is it per user or by bandwidth? What happens if you exceed usage
during the life of the contract? (Do you lose access, do you require true-up payments, or are you
extended a grace period to the next renewal)?
■
Does the vendor have other secure access service edge (SASE) components, such as the secure
web gateway (SWG), cloud access security broker (CASB), firewall as a service (FWaaS) and
software-defined WAS (SD-WAN; possibly partner-provided)? (Do they have a product roadmap
aligned with SASE, including networking components)?
■
Page 11/18
Gartner, Inc. | 726817
ZTNA Alternatives
Several alternative approaches to ZTNA for making applications are available to communities of
internal and external users:
Legacy VPNs remain popular, but they might not provide sufficient risk management for
exposed services and can be more difficult to manage, given the dynamic nature of digital
business. Legacy VPNs may also create scale and bandwidth issues for mostly mobile
workforces. Always-on VPNs that require device and user authentication provide similar
outcomes as ZTNA; 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 PAM tool can be a useful alternative to a VPN.
■
Exposing web applications through a reverse-proxy-based web application firewall (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 employeefacing
applications are not normally candidates for WAFs.
■
Deploying virtual desktops can be a useful way to make a set of applications available to users
on unmanaged devices, essentially “projecting” a corporate desktop policy to everyone. Onpremises
VDI is giving way to desktop as a service (DaaS), which is offered by large hyperscale
cloud providers, such as Amazon Web Services (AWS) and Microsoft Azure.
■
A remote browser isolation product (see “Innovation Insight for Remote Browser Isolation”)
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. Some ZTNA vendors also offer remote browser isolation products. Inquire about roadmap
plans and whether isolation will become part of a future converged service.
■
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.
■
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.
■
Page 12/18
Gartner, Inc. | 726817
Representative Vendors
Market Introduction
ZTNA products and services are offered by vendors in one of two ways:
As-a-service offerings (see Table 1) require less setup and maintenance than stand-alone offerings.
They 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.
Table 1: Representative Vendors of ZTNA as a Service
API gateways enforce authentication, validate authorization and mediate the correct use of
application APIs. This is especially useful if the application lacks mechanisms for ensuring API
security. Most API gateways also expose logs of all activity through a native monitoring tool or
integration with popular security information and event management (SIEM) tools. Favor API
gateways that integrate with enterprise directories and single sign-on (SSO) protocols.
As a service ■ from the cloud
■ As a stand-alone offering that the customer is responsible for supporting
Vendor Product or Service Name
Akamai Enterprise Application Access
Axis Security App Access Cloud
Broadcom Secure Access Cloud
Cato Networks Cato Cloud
Cisco Duo
Citrix Workspace Essentials
CloudDeep Technology (China only) DeepCloud SDP
Cloudflare Cloudflare Access
Page 13/18
Gartner, Inc. | 726817
Source: Gartner (June 2020)
Table 2: Representative Vendors of Stand-Alone ZTNA
Cognitas Technologies Crosslink
Google BeyondCorp Remote Access
Hangzhou Cloudaemon Technology Taiji Perimeter
InstaSafe Secure Access
NetFoundry Zero Trust Networking Platform
Netskope Netskope Private Access
Okta Okta Identity Cloud
OPAQ Secure Access Service Edge
Palo Alto Networks Prisma Access
Perimeter 81 Software-Defined Perimeter
Proofpoint Proofpoint Meta
SAIFE Continuum
TransientX TransientAccess
Wandera Wandera Private Access
Zero Networks Access Orchestrator
Zscaler Private Access
Vendor Product or
Service Name
Page 14/18
Gartner, Inc. | 726817
AppGate (split from Cyxtera) AppGate SDP
Banyan Zero Trust
Remote Access
Platform
BlackRidge Transport
Access Control
Google Cloud Platform (GCP) Cloud Identity-
Aware Proxy
(Cloud IAP)
Microsoft* Azure AD
Application
Proxy
Web Application
Proxy (Windows
server only)
Odo Zero trust
access platform
Pulse Secure Pulse SDP
Safe-T Secure
Application
Access
Systancia Systancia Gate
Unisys Stealth
Verizon Vidder
PrecisionAccess
Waverley Labs Open Source
Software
Defined
Perimeter
Page 15/18
Gartner, Inc. | 726817
Source: Gartner (June 2020)
Apparent in client interaction, the as-a-service flavor is rapidly outpacing the stand-alone flavor.
Gartner estimates that more than 90% of clients are implementing the as-a-service flavor. The
stand-alone flavor appeals primarily to enterprises that are cloud-averse. An emerging hybrid
approach with cloud and on-premises access brokers is a third option appealing to organizations
that want to optimize application policy rules applied for both remote and local access to
applications. Some vendors offer ZTNA as a service or deployment by the enterprise. (Table 1 lists
vendors that best match their core architecture.)
The vendors listed in this Market Guide do not imply an exhaustive list. This section is intended to
provide more understanding of the market and its offerings.
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, identity-based
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.
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
Zentera Systems CoIP Platform

• Microsoft’s Conditional Access feature is a form of adaptive access control. Many
  ZTNA products offer adaptive access capability; however, on its own, Conditional
  Access isn’t a full ZTNA product.
  Budget and pilot a ZTNA project to demonstrate the benefits of ZTNA to ■ the organization.
  Page 16/18
  Gartner, Inc. | 726817
  If VPN replacement is the primary goal, then plan to retain the VPN for a period of time, while
  verifying that the ZTNA product can replace all use cases for the VPN. Test latency of the ZTNA
  product for remote workers, and set realistic expectations requiring ZTNA-delivered application
  latency be no worse than the existing VPN.
  ■
  Plan for user-to-application mapping. Role-based access control (RBAC) can help with this.
  Avoid allowing all users to access all applications except in the observation phase to build
  policies.
  ■
  Identify which applications and workflows are not candidates for ZTNA, and exclude them from
  the scope. This includes access to and download of unstructured data and consumer-facing
  applications.
  ■
  The ZTNA market is emerging, so sign only short-term contracts (i.e., 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.
  ■
  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 SaaSdelivered
  access management providers.
  ■
  Don’t expect partners to use your identity store. Require support for SAML, OAuth, OIDC and
  similar identity federation capabilities.
  ■
  Evaluate the effectiveness of a vendor’s ability to query other kinds of device agents, such as
  UEM, EDR and mobile threat defense (MTD), to gain additional context for improved adaptive
  access decisions.
  ■
  Attackers will target ZTNA trust brokers. For cloud-based offerings, evaluate their DoS and
  failover architectures. Require vendors to support high levels of security and monitoring for
  administrator accounts. For on-premises ZTNA products, harden the host OSs using a cloud
  workload protection platform (CWPP) tool that supports on-premises deployments (see “Market
  Guide for Cloud Workload Protection Platforms”). Rely primarily on a default deny stance with
  ■
  Page 17/18
  Gartner, Inc. | 726817
  Evidence
  1 “Vulnerabilities Exploited in VPN Products Used Worldwide,” NCSC
  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 with a generally
  available offering at the time this research was published.
  Document Revision History
  Market Guide for Zero Trust Network Access - 29 April 2019
  Recommended by the Authors
  Zero Trust Is an Initial Step on the Roadmap to CARTA
  The Future of Network Security Is in the Cloud
  Solving the Challenges of Modern Remote Access
  Quick Answer: Cost Effectively Scaling Secure Access While Preparing for a Remote Workforce
  Hype Cycle for Enterprise Networking, 2019
  Hype Cycle for Cloud Security, 2019
  Fact or Fiction: Are Software-Defined Perimeters Really the Next-Generation VPNs?
  Enhance Remote Access Security With Multifactor Authentication and Access Management
  Recommended For You
  Magic Quadrant for Network Firewalls
  Critical Capabilities for Network Firewalls
  Gartner Peer Insights ‘Voice of the Customer’: Network Firewalls
  Magic Quadrant for Secure Web Gateways
  allow-listing to explicitly define the code permitted 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. Otherwise, limit vendor
  risk by favoring vendors that offer ZTNA as part of a strong SASE product base, considering
  strength of cloud infrastructure, SWG, FWaaS, CASB, and other products contained in a SASE
  architecture.
  ■
  Page 18/18
  Gartner, Inc. | 726817
  Critical Capabilities for Secure Web Gateways
  © 2020 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc.
  and its affiliates. This publication may not be reproduced or distributed in any form without Gartner’s prior
  written permission. It consists of the opinions of Gartner’s research organization, which should not be construed
  as statements of fact. While the information contained in this publication has been obtained from sources
  believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such
  information. Although Gartner research may address legal and financial issues, Gartner does not provide legal or
  investment advice and its research should not be construed or used as such. Your access and use of this
  publication are governed by Gartner’s Usage Policy. Gartner prides itself on its reputation for independence and
  objectivity. Its research is produced independently by its research organization without input or influence from
  any third party. For further information, see “Guiding Principles on Independence and Objectivity.”
  About Gartner Careers Newsroom Policies Privacy Policy Contact Us Site Index Help Get the App
  © 2020 Gartner, Inc. and/or its Affiliates. All rights reserved.