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

“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.

Check out our first post in this series, where we tackle IAM sprawl, visibility blind spots, and the operational chaos that hides in plain sight. And our second post, where we tackle a related silent threat: “privilege creep” - the buildup of excess access that can turn into a ticking time bomb.

 

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, which we discussed in the privilege creep post.

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 (think about accessing cloud apps from home, or an API call coming from a CI/CD pipeline-– network-based trust doesn’t apply).

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 - prompt for MFA only under certain risk conditions. As Giao noted, MFA fatigue and prompt-bombing attacks, where attackers bombard a user with push notifications hoping they’ll approve one, have made companies realize they need smarter triggers. The response is risk-based auth: don’t challenge when things look normal (to reduce user fatigue), but definitely challenge or block when something’s off.

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. Or even better, use device posture or deny outright.

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 because you can update attributes, like marking a device as compromised, or elevating a user’s risk score, and the policies automatically account for that, without needing to shuffle around role memberships urgently.

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. Maybe the token is valid for API calls, but if the device fingerprint or IP is different, the policy engine denies critical transactions. In classic attacks, once inside, attackers often exploit the fact that many internal systems trust an authenticated session token with broad access. ABAC + Zero Trust says “an authenticated session is not enough; it must continuously earn trust.”

 

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. For instance, you can front an old app with a reverse proxy that performs the adaptive checks before forwarding requests. 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. It’s a matter of identifying where your current tools fall short (maybe your IDaaS can’t evaluate device posture - then you bring in an endpoint compliance signal, for example) and integrating a solution for that. Be prepared to invest in some new capabilities, but focus them on your highest risk gaps first.

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.

For example, 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. You also get detailed audit logs showing every access decision made, along with the inputs that drove the outcome. That makes it easier to troubleshoot and fine-tune policies as you go.

Over time, some organizations will dedicate a formal “authorization engineer” or expand their IAM team’s remit to own policy development. But with platforms like Cerbos, you can scale up gradually without needing to train up an entirely new discipline from day one. Having that policy infrastructure in place, and accessible to your existing team, is a meaningful advantage.

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.

Also, emphasize the positive: often Zero Trust reduces user friction in low-risk cases by removing arbitrary obstacles. For example, smart SSO policies can eliminate VPN usage or not prompt MFA every single login - users appreciate that. Highlight those wins. And when you do introduce a new prompt or restriction, make sure users understand it’s protecting critical assets and not just red tape.

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 (by, say, letting them log in seamlessly when on a known device), 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. (Many organizations started here and are trying to move away from it.)

• Level 1 - Perimeter and MFA improvements: Add strong authentication (SSO+MFA, maybe device certificates). Basic network segmentation. Still largely static authorization once in, but better at keeping outsiders out. Most organizations today are at this stage.

• Level 2 - Adaptive auth & limited adaptation: Introduce conditional access for authentication, start using some context in high-risk apps. Maybe implement session timeouts or re-auth for sensitive transactions. Some awareness of device posture for key apps.

• Level 3 - Adaptive authorization (early stage): Deploy ABAC for a few critical applications or admin access scenarios. Use a policy engine to make fine-grained decisions in those contexts (e.g. admin actions in cloud console require certain conditions). Still limited to key areas.

• Level 4 - Pervasive adaptive access (Zero Trust achieved): Authorization and authentication are fully dynamic across the environment. Every application and data access is subject to context checks (user, device, behavior, sensitivity). There are no implicit trusts - even internal service-to-service calls are authenticated and authorized. Policies are centrally managed but enforced everywhere. Monitoring is continuous, and incident response can leverage the rich context from these systems.

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. Those who treat Zero Trust as a “program, not a project” will gradually bake it into the fabric of IT. That means continuously updating policies as the environment changes, continuously training the AI models that might underlie risk scoring, and continuously measuring success (e.g., time to detect anomalous access, reduction in attack surface, etc.).

 

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. Authorization is moving out of hardcoded application logic and static configs into flexible policy services. This is akin to how firewall rules moved from individual servers to centralized management - now we’re doing it for app-layer permissions.

By using such a platform, security teams can write the policies (in code or even low-code UIs) that specify conditions for access, without developers having to implement all that logic inside each app. This speeds up the rollout of adaptive controls. For example, if tomorrow you decide that any access to the finance system from an unmanaged device should be read-only, you could implement that in one place and have the policy engine enforce it, rather than modifying the finance app itself.

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.” That kind of evidence is powerful (and essentially impossible to gather if all you have are static role assignments).

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). Over time, you’ll cover more ground. The end state is policies uniformly protecting everything from APIs to UIs to databases, with context-awareness throughout.

 

Zero trust is a journey - start now

Zero Trust is not a one-time deployment, but a continuous improvement journey. You don’t “finish” Zero Trust - you maintain it and adapt it as threats and business needs evolve. This can be a tough sell to management used to project mindsets, but it’s important to set expectations: we are building a muscle, not delivering a single product.

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. Research consistently shows that Zero Trust implementations deliver specific outcomes like limiting lateral movement of malware and faster incident response. In a world where approximately 20-30% of breaches involve compromised credentials as the primary attack vector, the case for focusing on identity and access is self-evident.

As a CISO, leading a Zero Trust initiative means orchestrating multiple teams - networking, IAM, endpoint, app dev, etc. A good approach is to create a cross-functional Zero Trust task force or working group. Identify quick wins, like that adaptive MFA or tightening VPN to ZTNA transition, but also map out a 1-2 year roadmap for more complex changes, like rearchitecting how authorization works in legacy apps. Keep leadership in the loop with milestones and improvements: for instance, report how many high-risk access paths have been eliminated.

And remember user education. Part of Zero Trust is also training employees to expect that sometimes security will prompt them or restrict something for their own and the company’s good. 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 or workarounds. In fact, many users might not even notice a well-implemented Zero Trust system except that security incidents happen less frequently.

 

Conclusion

“Zero Trust” has indeed become a bit of a buzzword, but at its heart it’s about realism in security - assuming breach, and treating every interaction as potentially risky until proven otherwise. Making that real requires improving both visibility and control at a granular level. In the first two posts, we discussed getting visibility (continuous governance) and tightening control (least privilege). Zero Trust brings these together with continuous verification at every step.

By making access adaptive, you ensure that even if something slips through one layer (say a phished password), another layer (device check or behavior anomaly) can still catch it. By removing implicit trust, you close the internal doors that attackers love to find open. And by using dynamic policy tools, you give your security team the ability to refine and enforce these principles without constantly rewriting application code or manually updating configurations on dozens of systems.

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. Threat actors aren’t standing still, and they don’t mind that your identity architecture is complex; they will exploit any static trust assumptions you leave in place.

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. Over time, these add up to a fundamentally more resilient organization.

CISO takeaway: Zero Trust is not “enabled” by buying a product. It’s achieved by consistently applying the principle of least privilege and continuous verification everywhere. Start with adaptive MFA and high-value assets, use policy-as-code to enforce context-based rules, and iterate. The result is a proactive security posture ready for modern threats, rather than reactive policies from yesterday’s playbook.

Finally, remember that Zero Trust is as much a cultural shift as a technical one. It requires getting everyone on board with the mindset that security is dynamic and shared. There’s no finish line, but with each stride, your organization becomes that much harder to breach and that much more trusted by customers, partners, and regulators.

This concludes our three-part series on urgent IAM challenges for CISOs. By improving visibility and governance, cleaning up excess privileges, and embracing adaptive Zero Trust controls, security leaders can significantly reduce identity-related risks. To explore how policy-as-code and dynamic authorization can assist in these efforts, visit cerbos.dev.