An identity-based Zero Trust Architecture is the only way to deliver secure access to resources and workforces distributed far beyond the office walls. Our recent white paper “Identity Providers (IdPs) Critical Role in Zero Trust Adoption‚ explores how federated identity services make this modern security paradigm work across today’s distributed networks.

This article will discuss why organizations of all sizes are on a path toward Zero Trust. We will also recap the importance of IdPs and explain how identity is only one element in a complete Zero Trust Architecture.

Zero Trust: How it Works

As its name implies, this new way of looking at security never assumes that a user, device, or network can be trusted. Modern security threats come from too many directions. Coffee shop WiFi sessions can be hijacked. Everyone’s email is flooded with phishing and other social engineering attacks. Vulnerabilities in legacy systems appear faster than network administrators can deploy patches.

Given these conditions, the only safe assumption is that every credential, device, and network is already compromised. Any incoming connection request is probably an attack — unless you can prove otherwise. This principle of “assume breach‚ lies at the heart of Zero Trust and informs this paradigm’s approach to authentication and authorization:

• Zero Trust Authentication - Using the principle of verifying explicitly every incoming connection request must be challenged and the user’s identity confirmed.

• Zero Trust Authorization - The principle of “least privilege‚ limits the access verified users receive to the bare minimum they need to do their work.

Combining assume breach, verify explicitly, and least privilege lets Zero Trust Architectures shrink attack surfaces and minimize the impact of successful breaches. Remote users no longer get access to entire networks. Privileged users can no longer share passwords. And hackers have a much harder time moving laterally through networks.

Accelerating Zero Trust Adoption

“Zero Trust‚ was little more than an academic concept or a buzzword until the 2010s. That is when Google responded to state-backed cyber attacks by developing its own Zero Trust Architecture. Even then, assumptions that Zero Trust required radical restructuring projects slowed the pace of adoption.

Today, things are different. In the wake of constant data breaches and ransomware attacks, industry leaders view Zero Trust as the solution to their security challenges. Last year, the White House erased any doubt about Zero Trust’s future. An Executive Order requires all federal agencies to migrate their networks to Zero Trust Architectures.

Identity’s Role in Zero Trust

Applying Zero Trust to distributed networks creates a problem. Since every on-premises resource and cloud service requires unique authentication credentials:

• Users must remember more passwords.

• Weak and recycled passwords have become more common.

• Repeat authentications undermine productivity.

• Users’ risk of identity theft increases.

Identity Providers solve this challenge by creating a single federated identity that applies to on-premises and cloud-based resources. Users authenticate once with a single credential to access the resources they are allowed to use.

Zero Trust: More Than Just Identity

While the role IdPs play is essential, identity is only one element in a Zero Trust Architecture. Authorizations based on least privileged access policies must consider more than a user’s identity, such as the context of a user’s session or the user’s role in the organization.

Context and device posture

Trust is not a true-or-false condition but a multi-dimensional expression of context that goes beyond user identity. For example, how should the nature of a user’s network connection influence least privilege access? An authorized user may get broader access to a database when they connect through an on-premises LAN than when they connect from a hotel’s WiFi.

Device posture is another trust factor that impacts least privilege access — especially as more companies adopt BYOD policies. The state of a device’s operating system and security software makes the device more — or less — trustworthy. Administrators may define policies that block access from outdated devices or limit access to the lowest-risk resources.

Role-based access control

The principle of least privilege does not specify how to structure access control policies. One approach would be to assign user-by-user permissions. However, this approach creates a huge administrative burden. Permissions must be added or removed with each change in user responsibilities. Failing to do so could lead to permission creep and makes successful breaches more dangerous.

Role-based access control makes least privileged access policies easier to manage. Administrators define limited sets of necessary permissions for the various roles people play within the organization. When users are assigned to roles, they automatically get access to the resources their jobs require. When they change roles, their permissions automatically change.

Reducing the Burden of Zero Trust Adoption

Restructuring network architectures — without disrupting business operations — can seem daunting. Twingate’s secure access solution makes Zero Trust as simple as possible for every stakeholder. Transparent client apps work in the background to enforce security policies without user involvement. Browser-based consoles let administrators quickly onboard users or change role-based access policies.

We also offer integrations with major Identity Providers. Rather than building everything from scratch, you can make your existing security stack part of your future Zero Trust Architecture.

To learn more about Zero Trust and Identity Providers, check out our “Identity Providers (IdPs) Critical Role in Zero Trust Adoption‚ white paper. Or contact us to find out how fast the journey to Zero Trust can be.