Identity & Access Management

What a zero trust security architecture means with multi-cloud identity

Image of lock | technology

It’s a dangerous world. Threats are lurking around every corner bad actors are constantly seeking ways to take advantage of weaknesses. It’s not the trailer for a new thriller film; it’s the reality for enterprises today. It’s also the basis of the zero trust security architecture: assume that everything is a threat to be checked and then rechecked at every step. 

Zero trust is critical in protecting organizations against a data breach when using the cloud — which is pretty much everyone today. Unlike in previous times when apps, data, and identity were protected behind the network perimeter, cloud computing requires users to access apps and data from outside the firewall. Remote access potentially increases the threat landscape and allows cybercriminals an open door. 

In the cloud (or multiple clouds), identity management is not centralized in one location. Instead, identity is distributed across multiple apps, each of which comes with its own identity system. Now, there’s a proliferation of identity systems, no way to manage them, no visibility across them, and only superficial integrations using federation and single sign-on (SSO).

Let’s explore what zero trust security is (and isn’t), how multi-cloud can derail plans to achieve a zero trust security architecture, and finally, how to get started on implementing zero trust through identity orchestration

What is zero trust?

Created in 2010 by a former principal analyst at Forrester Research John Kindervag, the zero trust security model is a framework for managing identity in the distributed world of cloud computing. Zero trust is not a piece of software, nor is there any single piece of technology. 

In the past, with older identity systems, a user authenticated just once. The authenticated user would sign in, then single sign-on worked for all of the apps they needed to access, and there was never a need to be rechecked. It’s not like that anymore.

Zero trust takes the security principles established for legacy, on-premises systems; then, it layers additional security measures so that the first login is more secure. And then, it keeps checking and rechecking that you are who you say you are at every step.

Modern cloud identity systems are checking you while doing while you are using a device. The assumption is that anyone could be an adversary, devices are all compromised, and no one is who they claim to be.

Enterprise systems — on-premises, hybrid, cloud, and multi-cloud — and data need to be protected at all times to keep cybercriminals at bay. The need continues to grow by the second as hackers get cleverer, technology gets faster, and new ways spring up constantly to expose and exploit vulnerabilities. The zero trust model is how to achieve security today for enterprises. 

How multi-cloud impacts a zero trust security architecture

Zero trust is harder to achieve when using multiple clouds. So why not just stick with one cloud? There are many reasons why an enterprise uses more than one cloud. Most commonly, though, the main reasons organizations adopt a multi-cloud approach are:

  • to better manage costs
  • to avoid vendor lock-in
  • to create redundancy as a failover precaution 
  • to leverage the special capabilities of a particular cloud

However, multi-cloud creates visibility gaps with policies, apps, and users. When a user signs into an account for an app on a public cloud, like Microsoft Azure AD, both the app and the cloud have their own set of policies and identities. When the same user accesses a different app on another cloud, such as Google Cloud Provider (GCP) or Amazon Web Services (AWS), it also has its own identity policies. And they don’t interoperate. 

Rather than keeping people in or out, as in the days of a network perimeter, today’s security is more about behavior profiling. With multi-cloud, SaaS apps and platforms are constantly checking for individual patterns to detect irregularities. For example, if you sign in to LinkedIn from a different device or geographic location, you’ll have to prove yourself before you get in.

From an identity perspective, successfully achieving a zero trust environment means identity systems must be more sophisticated than they were in the past to have more precision about knowing who the users are at all times. 

Getting started with zero trust 

Once an abstract concept, zero trust is now widely accepted, and the technologies that enable it are becoming ubiquitous. However, there’s no one-size-fits-all solution and, unfortunately, no easy path. Include some of these foundational elements in your journey to a zero trust architecture.

Zero trust technologies and solutions to implement

With the widespread adoption of employees working remotely, now more than ever, organizations must have the right technologies and identity policies in place to keep everyone protected. Achieving a zero trust security architecture should start with identity management, the technology at the heart of what zero trust is all about. Below are some of the critical elements to check off your list when getting started with zero trust.

Multi-factor authentication

In a zero trust world, the initial login is modified with additional layers to make it more secure. Authentication needs to be more sophisticated than in past eras. Two-step verification is a necessary first step but is no longer enough on its own. Organizations are moving to multi-factor authentication (MFA) practices. 

What is multi-factor authentication? According to Microsoft, multi-factor authentication is the process used when signing into accounts to prove you are who you say you are (authentication) with a username and password. The multi-factor part comes from when you sign into an account with a username and password; there is an additional factor checkpoint needed.

Additional factors could include biometrics (e.g., fingerprint, facial recognition), answering other security questions, inputting a unique code sent to you by email or text, or using an authenticator app such as the ones by Okta, Microsoft, or Duo.

Continuous Authentication

Continuous authentication is the backbone of zero trust security. When a person is authenticated on their first login, it’s just the first time. As the user continues to access data, there are constantly hooks and opportunities to authenticate them again and again. 

Imagine a security guard for an office building lets you in the front door when you show your ID. But then the security guard keeps popping up as you go about your business, saying, “Let’s recheck you — are you still who you say you are? Are you still on the same device, using the same browser… I’m just going to keep doing these checks because I don’t trust you.”

Authentication can’t be fragmented. This applies to on-premises, cloud(s), and — the most common — a hybrid of both. Each different place that a user enters shouldn’t be disconnected from the others. That’s where behavior profiling breaks down. If you have to keep figuring it out over and over again, at some point, it is going to be wrong in one of those places.


Policies are the ground rules that need to be applied across applications, platforms, and systems. It’s taking the coarse-grained rules at the cloud identity layer and making them more fine-grained (complex) inside the enterprise to extend across the on-premises level of a hybrid environment. More sophisticated policies than in the past are needed at that level to enable enforcement. 

Most SaaS platforms are fairly self-contained with really sophisticated internal security models. Once you get into the SaaS platform, they have really good ways to control access to parts of the app and the data and the things you can do inside the app. The apps on-premises are not as good at well-containing their authorization and security. 

Using Secure Hybrid Access through Strata’s Identity Orchestration for a zero trust security architecture

In hybrid and multi-cloud environments, it can be complicated to achieve a zero trust security architecture. Cloud systems haven’t adapted well to the on-premises world, while the on-premises identity systems can’t easily integrate with the cloud world. 

Is it better to take the on-prem system and adapt it to the cloud or take the cloud and adapt it to on-premises? Neither option is good. But the better choice is to migrate and adapt on-premises to the cloud to avoid taking a giant step backward. However, it really is the lesser of two evils because migrating legacy apps to the cloud involves rewriting the code of each app. 

The new systems we are adapting to inherently have things like threat intelligence or identity proofing because they assume zero trust. Technologies like Secure Hybrid Access help build a bridge between the old and new systems.

The Maverics Identity Orchestration Platform uses an abstraction layer called an identity fabric that comes in and encapsulates on-premises apps and makes them behave more like SaaS apps to enable Secure Hybrid Access.

To learn more about how Identity Orchestration can help you achieve a zero trust security model, watch the Maverics Platform overview video.

Identity orchestration allows you to avoid rewriting legacy apps to adapt to the cloud because it is no longer necessary. The apps can remain unchanged, and migration can happen quickly and easily and at a fraction of the cost of rewriting and rewiring. The platform integrates heterogeneous identity systems to unify policies, APIs, and sessions. 

When your legacy apps are behaving like your cloud apps, building a zero trust security architecture is possible. You can extend standards-based authentication from cloud identity systems to on-premises apps. The access policies support zero trust’s identity as the perimeter model.


Modernize any app with any IDP in minutes. Join the 'Orchestration Kitchen' workshops.