The CISO’s guide to implementing Zero Trust: Making adaptive access control work in practice

AAnna PaykinaMarch 18, 2026 18 min read

“Zero Trust” is a favorite mantra in security, but how do you actually implement it? Static roles, over-permissioned identities, and legacy perimeter models continue to fall short. Especially in fast-moving, cloud-native environments. In this article, we look at how adaptive, context-aware access controls bring Zero Trust to life, and why dynamic authorization is central to making it operationally real.

This piece is part of a three-part series based on a deep conversation between Aram Andreasyan, Head of Solutions at Cerbos, and Giao Nguyen, IAM advisor at 1Kosmos. Giao brings decades of enterprise IAM experience - from identity proofing and governance to audit and access architecture. Together, they explored why identity has become a focal point for CISO accountability, and how modern access strategies can close the gap between compliance and actual control.

This third post of the series focuses on the how of Zero Trust: what adaptive access really means, how to move beyond role-based models, and how to introduce policy-driven authorization into daily operations, without overhauling your entire tech stack.

From slogan to reality: The Zero Trust gap

For years we’ve heard “never trust, always verify.” In theory, Zero Trust Architecture means no user or device is inherently trusted - every access request must be authenticated, authorized, and encrypted, every time. It’s a powerful idea, especially as organizations deal with dispersed workforces and cloud everything. Yet many companies find there’s a huge gap between Zero Trust as a strategy and Zero Trust in practice.

Executives might declare a Zero Trust initiative and invest in some new tools - say, a fancy network micro-segmentation solution or an identity threat detection product. But day-to-day, the organization may still be using the same old static access rules and broad network zones internally. The result is a kind of partial Zero Trust: perhaps the VPN was replaced with a stronger Zero Trust Network Access gateway, but once a user is “in” the environment, they still often have free rein among many systems. Or a company rolls out multifactor authentication everywhere (great!), but authorization - the decisions about who can do what inside our applications and data - remains largely static and coarse-grained.

As Giao Nguyen noted in our conversation, most security leaders “get” Zero Trust conceptually and want to embrace on-demand, adaptive models. But complexity is the enemy of execution. It’s not that they don’t understand the goal; it’s that operationalizing Zero Trust requires rethinking longstanding approaches across identity, infrastructure, and applications all at once. It’s a journey to implement, not a flip of a switch. Everyone’s on board with the idea, but how to do it, without breaking the business, is another matter.

Let’s break down a common scenario: A company has invested in strong identity verification at login (say, SSO with MFA - so far, so good). However, once a user is authenticated, they are dumped into an internal network or given roles that grant a broad set of permissions. Traditional IAM often works on a “trust but verify later” model - you verify identity at login, then issue a token that might be valid all day and grants access to many systems. Static roles (RBAC) further mean that if you’re in Role X, you have the same access at 9 PM from a personal device at Starbucks as you would at 9 AM in the office, even though the risk profiles differ greatly. This is not Zero Trust; this is implicit trust after initial auth.

Zero Trust in practice demands continuous verification: evaluating context like device, location, behavior, and looking at each action rather than just the initial login. It also means minimizing inherent privileges (sounds like least privilege again) - ideally even eliminating permanent privileges in favor of just-in-time elevation.

The gap for many organizations is that their current IAM tools and policies were built for a world of static assumptions: corporate network = safe, user with role = let them do anything that role allows anytime. Moving to a world where every access is conditional and might be re-checked or limited can seem daunting. And indeed, it requires new capabilities.

Identity: The new perimeter

One major factor driving Zero Trust is the shift in what constitutes the “perimeter” of your IT environment. It used to be the firewall and corporate LAN - everything outside is untrusted, inside is trusted. Today, with cloud services, SaaS apps, remote work, and mobile devices, that network-centric perimeter has dissolved. Identity is the new perimeter, as both Aram and Giao emphasized. Each user (and device) becomes the gating point: you must verify them and continuously govern their actions, since you can no longer rely on a castle wall to keep bad actors out.

Giao put it plainly: “We all understand that identity is actually the new perimeter of security… at this point, identity is really your weakest point when you think about it. We as humans are more prone to errors than systems.” In other words, in a Zero Trust world, the focus is on securing identities and their access pathways, because a firewall or VPN won’t save you if an identity is compromised or misused. Every access request must be treated as coming from an open, untrusted network, because it effectively is.

The human element Giao mentions is crucial - people make mistakes (fall for phishing, use weak passwords, misconfigure apps). Zero Trust tries to mitigate the impact of those inevitable mistakes by not trusting that even a legitimate user or device is always doing the right thing. If Alice is logged in, we don’t assume every action she takes is okay - we check context, we maybe challenge again if the action is sensitive or unusual. This is the “never trust, always verify” ethos.

The first step for Zero Trust: Adaptive authentication

A common starting point for Zero Trust implementation is adaptive authentication, especially MFA that adapts to context. Many organizations have implemented conditional access policies such as: if user is coming from a new device or location, enforce MFA again or block; if it’s their normal device on the corporate network, allow seamlessly. This is a great step toward Zero Trust because it introduces the idea that not all access attempts are equal. For example, Microsoft Azure AD Conditional Access or Okta’s Adaptive MFA can do this out of the box.

Many CISOs report quick wins from adaptive MFA - it boosts security and can improve user experience by cutting down unnecessary prompts. For instance, if Bob always logs in from the same laptop daily, why prompt him every single time if device health and behavior look good? But if suddenly Bob’s account tries a login from another country at 3 AM, require MFA.

This kind of contextual authentication is one piece of Zero Trust. Many organizations cite MFA as one of the most crucial elements of Zero Trust models - it’s foundational to verify identity continuously. In the IDSA’s research, 96% of orgs believed MFA could have prevented or minimized an identity-related breach. So if you haven’t implemented adaptive MFA or conditional access policies yet, that is a tangible first step on the Zero Trust journey.

However, authentication is just the gate. What happens after the user is in? That’s where adaptive authorization comes into play.

The second step for Zero Trust: Dynamic authorization / ABAC / contextual access decisions

While Role-Based Access Control assigns permissions based on static roles, Attribute-Based Access Control and policy-based dynamic authorization take into account a variety of attributes and context each time a decision is made. This is key to implementing Zero Trust principles within applications and data.

ABAC policies might consider: the user’s role and department, the resource’s sensitivity, the action being attempted, the user’s device posture, time of day, regulatory requirements, and more - and then make a real-time decision to allow, deny, or step-up authenticate for that action.

For example, a policy could say: Engineers can access the production logs service during business hours from within the country on a managed device, but if outside those conditions, require a manager’s approval. A more simple one: Deny access to customer records system if the request comes from an IP outside our trusted range, unless the user has a special exception attribute. These kinds of rules go beyond the one-dimensional “user is in Role=Engineer, so yes to everything engineer-level” that traditional IAM does.

Why static roles fall short: Roles are a one-time assignment and typically don’t encode context. If someone is an “Engineer”, that role doesn’t change whether they’re using a secure device or not, whether they’re downloading 1 record or 10,000, whether they’re accessing a system they normally do or something completely outside their duties. ABAC lets you incorporate those contextual factors. It minimizes over-permissioning by being precise - only allow exactly what’s needed under the right conditions. And it’s naturally more scalable in complex environments.

In Zero Trust, every component should authenticate and authorize every request - policy decision points everywhere. Solutions like Cerbos allow defining these decisions centrally as policy, which each service can query. This externalizes and unifies the authorization logic, making it easier to implement consistent Zero Trust rules across a microservice architecture or multiple applications. For instance, Google’s BeyondCorp (their Zero Trust model) essentially does this: every user request to a resource is evaluated against policies that consider user, device, and context, rather than relying on network location.

A concrete win from dynamic authorization is reducing lateral movement risk. Even if an attacker steals a user’s token, ABAC policies can limit what that token can do if things don’t match the expected context. In classic attacks, once inside, attackers often exploit the fact that many internal systems trust an authenticated session token with broad access.

Challenges in implementing adaptive access, and how to overcome them

Moving to adaptive, continuous access control does come with challenges. Let’s address some common ones and how to tackle them.

Legacy systems

Older applications might not support modern protocols or external authorization checks. You may have a legacy HR system that can’t consult an API for policy decisions or include device context. These systems are roadblocks - you might need to place them behind a proxy or use an identity-aware gateway that can enforce policies on their behalf. Over time, plan to replace or modernize systems that simply can’t fit into a Zero Trust model, because one weak link can jeopardize the chain.

Tooling gaps

Many traditional IAM tools (IGA and even some PAM solutions) weren’t designed for the kind of fine-grained, cloud-speed decisions required for adaptive authorization. This is why new categories of tools are emerging - e.g., CIEM for cloud entitlements, modern authorization microservices for apps, etc. Organizations may have to augment their existing IAM stack. The good news is there’s a lot of innovation, there are services that now include contextual conditional policies.

Skills and policy management

Designing adaptive policies often seems like a heavy lift. It’s part security analysis, part understanding user behavior, and part business logic. Many orgs don’t have someone with deep experience writing complex policies or analyzing access patterns. That’s why it’s important to start simple and choose tools that don’t make the process harder than it needs to be.

With Cerbos, you don’t need to be an authorization specialist to get going. Policies are written in human-readable YAML, so they’re understandable, version-controllable, and reviewable by both technical and non-technical stakeholders. You can start with clear rules like “deny access from foreign countries” or “allow this role only during business hours,” then layer in more context and signals over time as your needs evolve.

To help teams build confidence and test policies, Cerbos also has a hosted Playground where developers and security teams can test, simulate, and refine policies before pushing them into production.

Cultural resistance

People don’t like change, and users/IT teams might push back if new controls introduce friction. Early missteps, like an overzealous policy that blocks too much, can sour folks on Zero Trust, making them claim “it’s impractical.” To counter this, get buy-in and communicate. Explain to business leaders why adaptive controls are necessary - use stories of breaches that could have been prevented.

A phased rollout helps: maybe start with monitoring mode (just alerting on anomalies) before enforcing hard blocks, so you can adjust policies and prove the concept without disrupting work. Once people see that adaptive security can actually enhance their productivity, they’ll be more accepting of the times it asks for an extra step when something’s unusual.

In summary, yes - implementing real Zero Trust is not trivial. That’s why many firms are still in “talk” mode. But the momentum is there, and the challenges, while non-trivial, are surmountable with a thoughtful, staged approach.

Building toward adaptive, contextual IAM for true Zero Trust

The journey to Zero Trust is essentially a journey to adaptive IAM maturity. It means evolving from static, one-time authorization to continuous, context-aware authorization. You might imagine it in levels:

• Level 0 - Traditional: Trust is based on network or single auth event. Inside the perimeter, all is trusted. Roles are static, no dynamic checks.

• Level 1 - Perimeter and MFA improvements: Add strong authentication (SSO+MFA, maybe device certificates). Basic network segmentation. Still largely static authorization.

• Level 2 - Adaptive auth & limited adaptation: Introduce conditional access for authentication, start using some context in high-risk apps.

• Level 3 - Adaptive authorization (early stage): Deploy ABAC for a few critical applications or admin access scenarios.

• Level 4 - Pervasive adaptive access (Zero Trust achieved): Authorization and authentication are fully dynamic across the environment.

Reaching level 4 is a significant effort, but each step on the way provides incremental risk reduction. And importantly, it’s not an all-or-nothing; you can protect your most critical assets first with these techniques and expand outward.

Giao observed that many companies remain in a theoretical phase - they’ve adopted Zero Trust language and maybe some pieces, but haven’t operationalized it broadly. However, the direction is clear and inevitable: the future of IAM is adaptive.

The role of dynamic authorization platforms in Zero Trust

One practical enabler of Zero Trust is adopting a dynamic authorization platform that can serve policy decisions on demand. Cerbos is an example of such a solution, that helps teams externalize authorization logic. By using such a platform, security teams can write the policies that specify conditions for access.

These platforms also often provide audit logs of every decision - crucial for proving your Zero Trust controls are working. You can show an auditor: “Here, every time a user tried to access customer data, our policy evaluated their attributes and here’s the log of allowed vs denied attempts.”

One challenge is choosing the right places to apply dynamic authorization first. Good candidates: custom internal application where you have control to integrate a policy check, critical systems lacking fine-grained controls, and new projects (bake it in from start).

Zero trust is a journey - start now

Zero Trust is not a one-time deployment, but a continuous improvement journey. The payoff is worth it. Organizations implementing Zero Trust report measurable improvements in their security posture, including reduced attack surface through continuous verification and improved threat detection capabilities.

As a CISO, leading a Zero Trust initiative means orchestrating multiple teams - networking, IAM, endpoint, app dev, etc.

And remember user education. If everyone is mentally prepared that “this is how our security works now - it dynamically responds to risk,” then unusual prompts or the lack of a traditional network “free-for-all” won’t cause panic.

In short, Zero Trust for real is about weaving security into the fabric of every access decision. It’s not achieved overnight, but you can start with tangible steps today - and you must. The good news is many of the building blocks are available and maturing. With each incremental improvement - an added context check here, an unnecessary privilege removed there - you are shrinking the attack surface and strengthening your security posture.