ZTNA Revisited: Why Zero Trust Network Access Isn’t Really About the Network

Implicit trust—assuming the trustworthiness of a user, device, or application as opposed to explicitly verifying trustworthiness—remains a fundamental problem for cybersecurity. Some form of trust has to be established or else nothing ever happens. This is why some of the more rigid approaches to a zero trust implementation are impractical.

But eliminating implicit trust wasn’t originally called “zero trust.” Rumblings of the idea started as far back as 1975 with the design principle of complete mediation, where “every access to every object must be checked for authority.” It was also present in the concept of “deperimeterization,” as coined by the Jericho Forum in 2003, and in a presentation I gave in 2004 called “The Death of the DMZ.” John Kindervag coined the term “zero trust” in 2010 and the Cloud Security Alliance’s software defined perimeter brought greater awareness to zero trust principles—but that phrase really didn’t take off. Nor did the term that we were using at Gartner, where I was working as an analyst at the time—continuous adaptive risk and trust assessment (CARTA).

Around the time that “zero trust” started gaining traction, I helped coin the solution name zero trust network access (ZTNA). People had been typing “zero trust” into the search bar at Gartner.com, but we really didn't have much of anything to say about it yet other than the note “Zero Trust Is an Initial Step on the Roadmap to CARTA.” Noting that vendors were releasing products that resembled the CSA’s SDP architecture, we decided to write a guide to explore this emerging market.

I had already been formulating the idea that “zero trust” should be an adjective and not a noun by itself. The other analyst that I was working with on the guide suggested “network access” as the right noun because it was about accessing things that happen to be on a network. At the time, I agreed—so ZTNA became the name for the market we were writing about.

But even though the ZTNA moniker has stuck around, it really doesn’t tell the right story. That’s because the true need isn’t for network access—but rather application access. 

The Transition from Infrastructure to Applications

ZTNA products don't connect humans to networks—they connect humans (and their devices) to applications. At the same time, they allow application owners to exert more control. The application owner has the ability to express who is allowed to use it and under what conditions. Nobody on the networking side has to make a decision, or open a hole in the firewall, or grant approval.

Back when everything was on premises, we generally relied on network controls to gate access to destinations. The destinations themselves trusted that the network was going to make all the right decisions. When companies decided they wanted to get out of the business of managing physical data centers, they moved to the public cloud–infrastructure-as-a-service (IaaS). When you do that, you don't really have much of a network anymore.

Then people started to realize this wasn't providing much value either. They didn't want to manage networks and physical servers, or even virtual servers. That brought the shift from infrastructure to applications—platform-as-a-service (PaaS).

The “network access” part of ZTNA shielded the facts about this transition. If I had it to do over again, I would probably want to call it “zero trust application access.” The network isn't making any decisions. We're not placing any trust in the network. We're removing implicit trust and  crafting an environment where the applications themselves can state the level of trust needed for people to interact with applications.

Enabling Secure Remote Work at Scale

COVID-19 became an accelerator for the transition from infrastructure to applications, as well as the shift to ZTNA. With the onset of the pandemic, there was very suddenly a nine-fold increase in remote work—creating punctuated demand for secure application access at scale. The first inclination for many organizations was to expand their use of virtual private networks (VPNs).

But traditional VPN technologies have some inherent limitations with regard to security, which makes them difficult to scale. And many organizations discovered that the VPN concentrators in their basements hadn't been touched for 15 years—unpatched and prone to crashing.

In the original Gartner market guide, I stated that ZTNA could be a VPN replacement. When organizations had issues with instantly expanding their remote access capabilities in the first weeks of COVID, ZTNA seemed to instantly satisfy an accidental demand. It would be more accurate to say that ZTNA is an alternative to VPN because there are still some use cases where you actually need to put a person on a network (such as remote network administration). When I revised the Market Guide a year later, I switched the characterization from replacement to augmentation.

Continuous Adaptive Trust Application Access?

The “network access” part of the ZTNA name doesn’t quite fit anymore. And we can pull at the threads of “zero trust” by saying that it’s really about establishing continuous adaptive trust. ZTNA helps applications exert control by evaluating contextual information to determine the appropriate trust level for interactions.

Even if it isn’t a perfect descriptor, the ZTNA market name gained traction where others did not. But as long as we know that ZTNA represents a reallocation of responsibility from the network to the application, one that allows us to demand explicit trust measurements instead of relying on implicit trust, that’s all that really matters.

Steve Riley is Field CTO at Netskope.

Related articles: