Most Zero Trust Conversations Start with the Wrong Question

Most zero trust conversations start in the wrong place. We ask what to buy before we ask what needs to change. And until that changes, the journey does not really begin.

“Zero trust is not something you buy and turn on. It is a choice to design for the world as it really is.”

The Zero Trust Shift That Changes Everything

I cannot tell you how many times I have been in a zero trust conversation where the first question on the table was, “Which platform should we buy?”

And honestly, I get it. That is a natural place to start. But most of the time, if the conversation goes on for even a few minutes, it becomes obvious that the platform is not really the main issue.

The real question is much bigger: are we trying to keep every attacker out, or are we trying to make sure that one compromise does not turn into a business-wide problem?

That is the shift that changes everything. Not a product demo. Not a checklist. A shift in thinking.

For a long time, a lot of security strategies were built on the idea that if we could just put enough controls at the edge, we could keep bad actors out. The problem is, that is not the world we live in anymore.

Attackers get in through stolen credentials, vulnerable apps, third-party access, misconfigurations, and all the complexity that comes with modern environments. Zero trust really begins when we are willing to say something out loud that a lot of people still resist: compromise is going to happen. And once we accept that, the next question becomes pretty hard to ignore: are we going to make the hard decisions now, or wait until intruders and headlines make them for us later?

When Convenience Drives the Strategy

I have also seen what happens when organizations skip that shift in thinking and go straight to the vendor roadmap.

On paper, it can look like progress. There is a plan, a stack of capabilities, a lot of motion, and a sense that things are moving in the right direction.

But underneath all of that, the old assumptions are often still sitting there untouched. Access is still too broad. Exceptions are still hanging around. Teams are still optimizing for convenience first and resilience second.

That is where zero trust starts to feel hard, because it asks us to do things that are not always comfortable. It asks us to narrow access, rethink old habits, tighten exceptions, and change workflows that feel efficient but carry more risk than we want to admit.

That is the tradeoff. A little discomfort now, or a lot more pain later. When those choices get pushed down the road, organizations end up layering new technology onto old thinking, and instead of meaningfully reducing risk, they often add complexity, confusion, and friction. I have watched teams work incredibly hard on transformations that looked mature from the outside but were still brittle underneath because they never stopped to redefine what trust should actually mean in a world where compromise is expected.

Here is a scenario that feels very familiar.

An organization rolls out a modern access platform, the project is on schedule, and the dashboard looks great. Everyone feels like progress is being made.

But the trust model underneath has not really changed. A service account still has broad permissions because nobody wants to disrupt a legacy workflow. A third-party integration is still getting more trust than it should because it has “always worked that way.”

In other words, the hard decisions were avoided while there was still time to make them calmly and intentionally.

Then a credential gets compromised. What should have been a contained event becomes lateral movement across applications, exposure of sensitive data, and a long, expensive response.

When the review starts, the issue is not that the organization lacked technology. It is that the trust decisions were never granular enough, never dynamic enough, and never revisited with compromise in mind. The decisions still got made in the end. They were just made by intruders, outage pressure, and the threat of headlines. That is the part I wish more leaders would sit with. Zero trust is really about choosing disciplined inconvenience now instead of chaotic consequences later.

Designing for Resilience, Not Illusion

Now, to be clear, none of this means prevention stops mattering. It absolutely matters. Strong identity protections, hardened systems, secure development practices, good monitoring, and disciplined operations are all still essential. But one of the most helpful things zero trust does is remind us that prevention cannot be the whole strategy. We also have to design for resilience. If something goes wrong, how do we reduce the blast radius? How do we limit lateral movement? How do we keep one bad moment from turning into a business-wide event? Those are the questions that move security from rigid control to durable defense.

The Hard Decisions We Need to Make Ourselves

That shift matters because no organization can protect everything equally, all the time. Most leaders know that at a high level, but zero trust makes it practical. Which data matters most? Which applications are truly mission critical? Which actions should only be allowed under certain conditions? The answer is not to spread controls so broadly that they become rigid, expensive, and disconnected from actual risk. The answer is to get more intentional and more granular. In practice, that usually means changing habits, tightening permissions, reducing exceptions, and adding a little friction where the risk justifies it. That is the discipline of zero trust. It is choosing precision over comfort. It moves us away from broad access and static assumptions and toward decisions grounded in resource sensitivity, identity, device state, observed behavior, and real-time context. That is a much more honest way to operate in modern environments.

Every Action Needs a Trust Decision

This is where the trust decision really comes into focus.

If there is one idea that helps people understand zero trust, it is this: access should never depend on a one-time check or a static label that says a user, device, or application is trusted forever.

In a zero trust model, trust is not granted by default. It is earned for a specific action, under specific conditions, for a limited period of time.

Guidance like NIST SP 800-207 describes zero trust as a move away from static, network-based trust and toward per-session access decisions that consider users, assets, and resources. CISA makes a similar point by emphasizing least-privilege, per-request decisions in an environment we assume could already be compromised.

In practice, that means every action needs a trust decision behind it, and that decision has to answer more than “Is this allowed?” It also needs to answer, “Under what conditions is this allowed, what signals lower our confidence, and when should that trust be narrowed or revoked?”

A normal login from a managed device during business hours may be fine. The same request from an unmanaged device, an unusual location, a risky session, or signs of suspicious behavior may justify tighter restrictions, step-up verification, or outright denial.

The same principle applies beyond the login itself. A finance employee who can normally approve invoices may be allowed to review records from a managed laptop, but blocked from releasing a high-value payment from a personal device late at night until stronger verification is completed.

That is not always convenient, and it is not supposed to be. Zero trust asks us to make those decisions intentionally, in line with risk, before they get made for us under the pressure of an incident.

Trust, in a zero trust model, is not permanent. It is conditional, situational, and continuously re-evaluated. Put simply, trust is not a one-time grant. It is a decision continuously tested by context. And if we do not decide carefully who and what to trust, when to narrow it, and when to take it away, an attacker eventually will decide for us.

So if you are at the beginning of your zero trust journey, my encouragement is simple: start with mindset before mechanics.

Challenge old assumptions before you change architecture. Get clear on the problem you are actually trying to solve before you follow a roadmap, buy a platform, or start reworking access across the environment.

Stop asking only, “How do we keep everything out?” and start asking, “If something gets in, how do we contain it, limit the damage, and make better decisions in the moment?”

For me, that is the heart of zero trust. It is not distrust for the sake of distrust. It is the discipline of making better decisions at every point of access so the organization can operate with more resilience, even in uncertainty. And yes, it usually means making some hard choices earlier, changing habits, and accepting a little friction now so we are not forced into much worse choices later by intruders or public fallout.

Zero trust is not a product decision. It is a leadership decision about how much risk you are willing to leave to chance.

If this resonates with you, take fifteen minutes this week and ask your team two simple questions: where are we still relying on static trust assumptions in a world that demands deny-by-default, dynamic decisions, and where have we failed to define the conditions under which trust should be tightened, modified, or revoked?

As always, I would love to hear what you think. If this sparked a thought, raised a question, or challenged something in your own zero trust journey, send me a note at hello@cletustaylor.com. I read the feedback, and I genuinely appreciate it.

Also, a quick update: my new book, ZT Foundations: Building Zero Trust with the Tools You Already Have, is currently being proof reviewed and should be out in the very near future. I am excited to share more on that soon. Until then, that is it for this week. Thanks for spending a few minutes with me, and I hope you will join me again next week.