The Zero Trust Capability Model
Posted: Monday May 4, 2026
Author: Numberline Marketing
How readiness and roadmaps combine into one coherent plan.
It’s clear and well-understood that Zero Trust is a holistic security strategy. This is an easy statement to make, but it actually has profound implications for the creation and execution of a Zero Trust initiative within the enterprise. And I’ve seen real-world challenges directly related to this. Just last week I had an hourlong conversation with a network security architect at a global manufacturing company about this topic.
This security leader definitely understood and was supportive of Zero Trust principles, but was struggling to get his team and his assigned workloads better aligned with them. Specifically, we talked about new capabilities that he was anticipating getting as part of a Zero Trust Network Access (ZTNA) system deployment, and his ideas for utilizing these capabilities in newly defined and enforced access policies. That is, contextual and dynamic access policies that use the rich vocabulary, signals, and events that we obtain from our modern Zero Trust systems.
This individual was trying to reconcile this highly-anticipated new world with his day-to-day-reality: Assigned workloads within his team’s traditional scope of managing firewall rules, and setting ALLOW / BLOCK firewall rules. He’s looking forward to taking on the work of educating and influencing security leadership and internal stakeholders, to help them better understand the need for and benefits of adopting a Zero Trust architecture. He and I are both optimistic that he’ll be able to transform his bottom-up Zero Trust advocacy into a broader and more impactful initiative, although it’s going to take some time and work to get there.
Want to automatically get these posts in your inbox? Sign up for a free subscription below.
On to Capabilities
As we talked about Zero Trust access policies, part of our conversation explored the concept of the improved capabilities that his enterprise anticipated obtaining as a result of deploying new technologies, and modifying supporting processes. It’s these new and improved capabilities that will then be available for use within new access policies, which are after all the key outcomes of our Zero Trust systems.
The idea of defining and modeling capabilities is a timely and fascinating concept, and one that I’m seeing as an emerging part of Zero Trust practices. I’ve spoken about publicly this a few times, most recently at the US Department of War’s Zero Trust Learning Exchange (note: their recording should be available soon )
And, the capability concept is also a key part of our in-progress research within the Zero Trust working group at the Cloud Security Alliance. So let’s dive in and explore it.
First, a Restaurant Detour
I love a good metaphor, and this one lends itself to a simple but meaningful one. Restaurants exist to serve food, and in order to do so they need ingredients, tools, and skills. If I want to cook an order of my world-famous fries, I need my ingredients (potatoes, oil, and salt), the tools (a deep fryer), and someone with skills to properly use the tools (in this case, a well-trained fry cook). If the restaurant doesn’t have one of these things, this is an easy problem to solve: order more ingredients, get a deep fryer, and train or hire a fry cook.
This metaphor applies surprisingly well to our Zero Trust world. Information security teams exist to serve appropriate and effective access policies to the business, and in order to do so they need to have a set of capabilities that their access policies utilize. For example, if we want to require that all privileged access go through a Privileged Session Management (PSM) system, we clearly need to have such a system deployed and operational in our environment. That is, the capability to force admin sessions through PSM must be ready for use in an access policy.
If this capability isn’t ready (or perhaps, doesn’t exist at all), we need to do some work to get it ready. These tasks may include PSM vendor selection and procurement, deployment and testing of the PSM solution, and admin and user training. These are all straightforward activities, but they all do require an investment of time, money, and effort, and need to be planned for.
Traffic Lights
It’s important to recognize that capabilities have different levels of readiness, and we believe that a simple Red-Yellow-Green model is the best way to think about this. It’s intuitive, yet captures the necessary readiness states, as follows:
🔴 Red : This capability is unavailable for use in any access policy. The enterprise either doesn’t have the supporting technology, it’s not enabled, or the people and processes are not in place to allow for it.
🌕 Yellow : This capability exists in the enterprise and can be used in access policies, with some caveats. It may not follow best practices, it may not have a sound architecture, it may require manual actions to support, or may have other limitations. The capability can be used in this state, although the team recognizes that they should improve it.
🟢 Green : This capability exists in the enterprise and can be used in access policies, without hesitation. Even though this capability may not be perfect, it’s aligned with best practices, has a sound architecture, and is generally acknowledged as being in “good shape”
Two Roadmaps Are Better Than One
Now that we have this capability readiness model in mind, we can put the full picture together. Specifically, the idea that there are actually two parallel roadmaps to work with. First, we have the Capability Roadmap, shown as the lower layer in the image below for our Payment System. This is where we plan for the sequence of Tasks that we’re planning to perform to improve our readiness from Red to Yellow to Green. The top roadmap is our Access Policy roadmap, which shows the time periods in which we are planning to begin enforcing the access policies for a given set of users.
Note that this gives us a clear picture of what our current access policy is, and our plans to refine and more precisely target users over time.
Looking Forward: Putting this to Work
There’s a lot to this concept, and we’re just getting started with it (both here in this article, as well as in practice). We’re excited to be sharing this as an emerging model. Within the Zero Trust Working Group at the Cloud Security Alliance, we have a research publication in progress that’s going to introduce this concept more formally. This document is currently under development, and should be available to public review in early June 2026.
And this model is also getting applied to real-world environments: In our advisory practice here at Numberline, we’re actively using this model with enterprise customers today, and anticipate having some success stories to share in the not-too-distant future.
Thanks for reading, and we welcome your feedback. Interested in receiving a briefing on this? Contact us, and let’s talk!
Want to automatically get these posts in your inbox? Sign up for a free subscription below.