If you've read any cybersecurity article in the last few years, chances are it referenced the concept of "Zero Trust". What is Zero Trust, and why has it captured the attention of cybersecurity practitioners across industry and the government? These questions are addressed in this article, which covers the following topics:

Businessman with a puzzle pieces on the background


What is Zero Trust?

Based on ideas first captured by the Jericho Forum in 2004, “Zero Trust” as a term was coined in 2010 by Forrester to describe a movement to replace implicit trust relationships with explicit authentication and policy-defined access control.

The core tenet of Zero Trust is “never trust, always verify.” But what does Zero Trust mean?

How does "never trust, always verify" work in practice? >

Here's a familiar and easy-to-understand example: to print a document, an employee needs to be "on the same network" as the printer. The network topology creates an implicit trust relationship. Just being "on the network" implies the employee is authorized to access the printer.

If, instead of the printer, the resource is now a database containing customer credit card information, now we need to be very careful about who has access to the network.

If instead, we relied on first authenticating the employee to ensure that they are who they claim to be, then granting authorized access based on a corporate policy, we wouldn't need to ke

ep track of who has access to which network. This means our credit card database has some level of protection against attackers who happen to be in the same network.

With a Zero Trust framework in place, all networks are assumed to already be breached.  The term "Zero Trust" suggests that access to any resource isn't assumed based on network access; it's granted only after trust is established through authentication and authorization.

The Zero Trust model promotes a kind of "perimeterless security" that protects resources and data even in the event of compromise somewhere on the network. Replacing implicit trust with explicit trust surfaces any hidden security assumptions, making it easier to manage security and risk.


Why do we need Zero Trust?  What's wrong with today's security?

The traditional enterprise security model is based on a “hardened” perimeter. There were fewer applications, running in a few centralized datacenters, completely under the control of enterprise IT; in those days, securing the enterprise at the perimeter was good enough for the average company.

However, modern enterprise applications run in an increasingly complex environment. Applications and data have increasingly moved beyond the traditional corporate perimeter into the public cloud, already stressing the perimeter model. Add to that an increasingly mobile workforce, increasing requirements for ecosystem collaboration, and multi-cloud initiatives – the increased complexity is clear. At the same time, more of the business operations are digitized than before – companies are more susceptible to cyber threats than they used to be.

The tried-and-true tools in IT’s arsenal – namely, firewalls, VPNs and VLANs – are now over twenty years old. With these tools, policy is defined by topology. They were defined to support static networks, and change management to support complex and dynamic requirements is a struggle.

Access from point A to point B is defined by the programming of IP addresses and all of the routers and firewalls along the path.  It's difficult enough to visualize what's connected to what, let alone try to manage the risk based on the interaction of these separately-managed components.

Consider the connection shown below, between a cloud and resources in a factory environment.


image of a factory connecting to cloud using complex legacy tools


Path connectivity is defined by as many as 6-12 different routers, switches, and firewalls along the path, each potentially managed by a different team. It’s a difficult enough problem to analyze that the best way to validate connectivity is to try it – with a ping. It’s even more difficult to prove that that’s the only connectivity allowed.

Zero Trust dramatically simplifies this problem, by reframing the distributed policy into a single statement of who can access what.  For the example above, a Zero Trust architecture can allow you to dramatically simplify the cross-border connectivity, with just one place to check to configure policies and verify access.


a factory connecting to cloud with ZTNA


What is the difference between Zero Trust and SASE?

Zero Trust is more of a security philosophy that defines how authentication should be performed (granular and identity-based), and how authorization is performed (always). It does not define a specific implementation.

SASE, or Secure Access Service Edge, proposes a new deployment model for security services. SASE incorporates Zero Trust, insofar as it recommends that its security services access layer follow Zero Trust principles, but it is inherently less focused on the details of the security than on the deployment model.

For more information on SASE, check out our explainer article:

What is SASE? >

What is Zero Trust Network Access?

Zero Trust Network Access (ZTNA) is the most secure method to allow remote users to access applications or endpoints, and is rapidly replacing traditional legacy VPNs as the remote access solution of choice.

The primary purpose of a VPN is for connectivity - not security. With a VPN, a user's device is virtually added to the corporate network The user can access everything in the corporate network. The rush of corporations to increase capacity to support work from home explains the recent emphasis hackers have put on new VPN exploits and phishing attacks – lots of corporate data is accessible with the right set of credentials.

ZTNA solutions, on the other hand, are built from the ground up with Zero Trust security. They typically use multiple trust factors, such as geolocation and other metadata in combination with standard user authentication and MFA, to authenticate both the user and the device at the same time. This reduces the risk that phished credentials could be used to access corporate data.

ZTNA solutions provide granular policy controls that define which services or endpoints the user is allowed to access, and with which clients the user may use to access them. For example, a typical ZTNA policy might specify something like:

"User Alice, from her Mac, can use the ssh client to connect to server A, using TCP port 22."


"User Bob, from his Windows laptop, can use a proprietary client to connect to the building management system, using TCP port 80 or 9987-9989."

A ZTNA never builds "connectivity" - it grants "access" at a granular level.  As a result, successful compromise of ZTNA credentials dramatically limits the scope of actions an attacker can take.

For more information on ZTNA, check out our solution page on the topic or our product page for Zentera Secure Access (ZSA).


Aren't all Zero Trust solutions the same?

While there isn't yet an industry standard for a Zero Trust architecture, NIST is rapidly working to change that through architecture guidelines such as SP 800-207.

Because there are a wide variety of implementations, customers defining their Zero Trust strategy are advised to evaluate the type and strength of the trust factors, the ease of implementation and end-to-end policy definition, and whether the solution will require an infrastructure upgrade to be effective in both on-premises and cloud environments..


What are the properties of an ideal Zero Trust architecture?

Simple Policy Definition

Enterprises need tools to define and enforce simplicity. Security policies should be human- readable; they should be easily mapped to business requirements to streamline implementation and increase auditability for compliance, and should support automation for repeatability.

Access That Follows Least Privilege

Hybrid environments are complex, yet most corporate resources (VMs, containers, etc) are service-oriented and single-purpose – the in- house git server is not also hosting the Active Directory service. As a result, the ideal solution should have strong mechanisms to define whitelist policies to minimize the attack surface.

Supports Policy Discovery and Evolution

It's difficult for admins to be able to guarantee that policies are properly defined when the service is first turned on. Applications can have undocumented behavior, and even "well understood" applications might have surprise dependencies somewhere in the network. It's important to look your Zero Trust tools to help you discover these dependencies and suggest actions that help increase security over time..

Portable to Any Environment

Streamlining cloud adoption and enabling user mobility means companies need to be able to secure their applications and data wherever they happen to be. The ideal Zero Trust solution must shift the focus from network-level architecture to the application-level, operating in every environment and across traditional security boundaries. It should not be dependent on firewalls.

Co-Exists with Existing Networks and Applications

Enterprises cannot switch to this new paradigm overnight. It is important that a Zero Trust solution be deployable to protect critical applications without requiring a forklift upgrade, not only for cost reasons, but also to avoid disrupting the enterprise’s infrastructure and operations.


CoIP Access Platform satisfies all of the properties of an ideal Zero Trust solution.



What's the difference between Zero Trust and Micro-Segmentation?

Zero Trust and Micro-segmentation are aligned topics, but don't refer to the same thing. Zero Trust has to do with security and the factors that drive security policies; micro-segmentation has more to do with how and where security functions are inserted to protect workloads. For more detail, check out the explanation on our resource page, Micro-Segmentation, Explained.

Micro-Segmentation, Explained - Read Now >