Security Tools - Research

Market Guide for Zero Trust Network Access Published: 29 April 2019 ID: G00386774

Analyst(s): Steve Riley, Neil MacDonald, Lawrence Orans

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.

■ 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

Page 2 of 15 Gartner, Inc. | G00386774

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 (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 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.

Gartner, Inc. | G00386774 Page 3 of 15

■ 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 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.)

Figure 1. Conceptual Model of Client-Initiated ZTNA

Page 4 of 15 Gartner, Inc. | G00386774

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 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.)

Figure 2. Conceptual Model of Service-Initiated ZTNA

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 mechanisms. The messy problem of authentication is handled by higher levels of the

Gartner, Inc. | G00386774 Page 5 of 15

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.

Page 6 of 15 Gartner, Inc. | G00386774

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.

Gartner, Inc. | G00386774 Page 7 of 15

■ 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.

■ 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?

■ 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?

Page 8 of 15 Gartner, Inc. | G00386774

■ 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 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

Gartner, Inc. | G00386774 Page 9 of 15

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 (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.

■ 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 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 — or use a ZTNA service instead.

■ It is possible to go full IaaS. When ZTNA or other isolation measures are not good enough, moving the application off-enterprise completely is the best alternative. Many of the suggested isolation mechanisms are available to workloads placed in the cloud and are designed more for primary protection, rather than enterprise isolation. The goal shifts to protecting the application and data, with less concern for isolation. However, this still leaves systems exposed to attack, especially if legacy DMZ architectures are replicated in the cloud.

Representative Vendors 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.

Page 10 of 15 Gartner, Inc. | G00386774

Market Introduction

ZTNA products and services are offered by vendors in one of two ways:

■ As a service from the cloud

■ As a stand-alone offering that the customer is responsible for supporting

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.

Table 1. Representative Vendors of ZTNA as a Service

Vendor Product or Service Name

Akamai Enterprise Application Access

Cato Networks Cato Cloud

Cisco Duo Beyond (acquisition by Cisco)

CloudDeep Technology (China only) DeepCloud SDP

Cloudflare Cloudflare Access

InstaSafe Secure Access

Meta Networks Network as a Service Platform

New Edge Secure Application Network

Okta Okta Identity Cloud (Acquired ScaleFT)

Perimeter 81 Software Defined Perimeter

SAIFE Continuum

Symantec Luminate Secure Access Cloud (acquisition by Symantec)

Verizon Vidder Precision Access (acquisition)

Zscaler Private Access

Source: Gartner (April 2019)

Gartner, Inc. | G00386774 Page 11 of 15

Table 2. Representative Vendors of Stand-Alone ZTNA

Vendor Product or Service Name

BlackRidge Technology Transport Access Control

Certes Networks Zero Trust WAN

Cyxtera AppGate SDP

Google Cloud Platform (GCP) Cloud Identity-Aware Proxy (Cloud IAP)

Microsoft (Windows only) Azure AD Application Proxy

Pulse Secure Pulse SDP

Safe-T Software-Defined Access Suite

Unisys Stealth

Waverley Labs Open Source Software Defined Perimeter

Zentera Systems Cloud-Over-IP (COiP) Access

Source: Gartner (April 2019)

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.

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.

Page 12 of 15 Gartner, Inc. | G00386774

■ Plan for user-to-application mapping. 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 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.

■ 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.

■ Evaluate the effectiveness of a vendor’s 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.

■ 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 (see “Market Guide for Cloud Workload Protection Platforms”). 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.

Gartner Recommended Reading Some documents may not be available as part of your current Gartner subscription.

“Zero Trust Is an Initial Step on the Roadmap to CARTA”

Gartner, Inc. | G00386774 Page 13 of 15

“Hype Cycle for Enterprise Networking and Communications, 2018”

“Hype Cycle for Cloud Security, 2018”

“Fact or Fiction: Are Software-Defined Perimeters Really the Next-Generation VPNs?”

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.

Page 14 of 15 Gartner, Inc. | G00386774

GARTNER HEADQUARTERS

Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 USA +1 203 964 0096

Regional Headquarters AUSTRALIA BRAZIL JAPAN UNITED KINGDOM

For a complete list of worldwide locations, visit http://www.gartner.com/technology/about.jsp

© 2019 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 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."

Gartner, Inc. | G00386774 Page 15 of 15