Zero Trust Foundations: The Trust Problem Hiding in Plain Sight

Grab a cup of coffee and pull up a chair. This post kicks off a new series for ZT Foundations where we will walk through some of the key ideas from my new book, ZT Foundations: Building Zero Trust with the Tools You Already Have. My goal for this series is simple: take the mystery out of Zero Trust, talk about it in plain language, and show how it can be built from practical decisions instead of shiny buzzwords.

Over the next few weeks, we will compare traditional security strategy with Zero Trust, dig into the core tenets and concepts, introduce a methodology for evaluating existing applications and capabilities, use that methodology to walk through a real example, and then talk about how to keep a young Zero Trust Architecture from quietly drifting back into implicit trust.

For today, let’s start at the beginning: the difference between the trust model most of us grew up with and the way Zero Trust asks us to make trust decisions.

The Old Model: Build a Big Wall and Trust What Gets Inside

Traditional security was built around a pretty understandable idea: keep the bad folks out. Build a strong perimeter, put firewalls at the edge, require a VPN for remote users, monitor the doorway, and assume that anything already inside the network is probably okay.

That model made sense when most users sat in company buildings, most applications lived in company data centers, and most traffic stayed on company networks. The network was the castle, the firewall was the wall, and the internal network was the trusted courtyard.

To be fair, nobody just built the wall and walked away. We kept adding layers because the wall kept showing cracks. Vulnerability management found the weak spots. Patch management tried to close them. Internal firewalls, segmentation, and access rules tried to slow movement inside. Encryption protected data in motion and at rest. Endpoint tools, logging, monitoring, and awareness training all joined the stack for the same reason: the perimeter was never enough.

Those controls helped, and we still need them. But they each solved only part of the problem. Vulnerability and patch programs reduce known exposure, but they do not stop stolen credentials. Segmentation slows lateral movement, but broad rules and forgotten exceptions become hidden highways. Encryption protects the pipe or the file, but it does not prove the request should happen. Monitoring may spot trouble, but often only after the attacker has already taken a few steps.

Modern attacks live in the gaps between those layers. A phishing email gets a valid password, so the VPN lets the attacker in. A compromised laptop is fully patched, so it looks healthy enough to talk to internal systems. A service account has too much access, so an attacker uses it to quietly reach a database. Ransomware lands on one machine, then follows old file shares and permissive firewall rules like a road map. The tools may be working exactly as designed, but the trust model underneath is still too generous.

That matters when we adopt Zero Trust. Existing controls are not wasted money, and they should not be thrown away. They become raw material. Zero Trust asks us to connect those tools to better decisions: not just “is this system patched?” but “should this identity, from this device, using this path, perform this action on this application or data right now?” The shift is from stacked controls to coordinated trust decisions.

That is the danger of implied trust. If a system assumes that “inside” means “safe,” then anything that gets inside can often move around, look for more valuable systems, collect credentials, and quietly expand its reach. Ransomware crews, data thieves, and hands-on-keyboard intruders all take advantage of that same basic weakness: once trust is granted too broadly, it can be misused broadly.

And implied trust is not only about network location. We also see it in long-lived sessions that stay valid long after the original login, legacy authentication that cannot enforce modern checks, standing administrator access that is always available, and service accounts with passwords that rarely change. Each one quietly says, “we trusted this once, so we will keep trusting it.” That may be convenient, but it gives attackers more time, more room, and more ways to turn one small success into a much bigger problem.

The Zero Trust Shift: Stop Assuming and Start Deciding

Zero Trust starts from a different place. It does not say, “Nobody can be trusted.” That would be a pretty miserable way to run a business. Instead, it says, “Do not keep granting trust just because of where something is, what it was allowed to do yesterday, or how long a session has been open.”

In a Zero Trust model, every meaningful transaction should earn its trust. A transaction is any communication or action that touches the application, the data, or the services that support them. That includes a user opening a record, an API calling another service, a workload writing to storage, an administrator changing a policy, or automation updating configuration. We are looking at transactions on the data plane, the control plane, and the management plane.

The data plane is where the business activity happens: users, applications, services, and data talking to each other. The control plane is where decisions are made: identity, policy, routing, access, and security logic. The management plane is where environments are configured and changed: consoles, admin tools, APIs, scripts, and automation. If we only protect one plane, we leave the others open for abuse.

Before that action is allowed, we make a trust decision. Is this the right identity? Is the device or workload healthy enough? Is the request coming through an expected path? Is the application behaving normally? Is the data being handled the way it should be handled? That decision is not a one-time handshake at the front door. It is a series of small, sensible checks close to the transaction itself. We are not trying to make security annoying. We are trying to make trust specific.

The Five Pillars Behind the Trust Decision

The way I like to explain this is through the five Zero Trust pillars: identity, devices, networks, applications and workloads, and data. Each pillar gives us a different piece of the story we need before we can make a good decision.

·         Identity asks who or what is making the request. That could be a person, a service account, an application identity, or some other non-human actor. If we cannot clearly understand the identity, we cannot make a meaningful trust decision.

·         Devices ask what is being used to make the request. Is it a managed laptop? A server? A mobile phone? A workload? Is it healthy, patched, protected, and behaving the way we expect?

·         Networks ask how the transaction is moving. We care less about whether traffic is “inside” or “outside” and more about whether the path is appropriate, protected, segmented, and observable.

·         Applications and workloads ask what is actually being accessed and how it is behaving. Is this a normal request for this application? Is the workload doing what it was designed to do?

·         Data asks what is at stake. Is the transaction touching public information, internal records, regulated data, intellectual property, or something else entirely? The more sensitive the data, the more careful the decision needs to be.

Those pillars do not work alone. They are supported by three cross-functional capabilities: visibility and analytics, automation and orchestration, and governance. In plain terms, we need to see what is happening, respond consistently, and keep the rules tied to business needs instead of guesswork.

When those pieces work together, a Zero Trust Architecture can examine each transaction, validate that it is genuine, and confirm that it is doing what it was intended to do. That does not make everything perfect. It simply means we stop handing out broad trust based on old assumptions. The next question is where to focus first.

This is where the idea of a protect surface becomes useful. The protect surface is the specific thing we are trying to protect: the data, applications, assets, and services that matter to a particular business function. It is smaller and more practical than the whole attack surface. Instead of trying to secure “the entire network” all at once, we define the sensitive records, the application that uses them, the systems that support that application, and the services that make the transaction work.

Once we know the protect surface, we can map every transaction that reaches it across the data, control, and management planes. That gives us a much clearer question to answer: what has to be true before this communication should be allowed?

The Kipling Method: Simple Questions, Better Architecture

One of the practical tools we will use in this series is what is called the Kipling method. It comes from Rudyard Kipling’s familiar “who, what, when, where, why, and how” approach to understanding a situation. For Zero Trust, those questions become a simple way to document each transaction before we start designing controls around it.

Who or what is involved? What are they trying to access, change, or control? When should that happen? Where is the request coming from and going to? Why is the transaction needed? How should it be performed, protected, logged, validated, and limited?

The next step is to turn those answers into a Zero Trust policy statement. I do not mean a dense paragraph written for auditors and lawyers. I mean a plain-English statement that captures the transaction clearly enough that the business, security, and operations teams can all understand it. A good Zero Trust policy statement should explain who or what is acting, what action is being requested, what protect surface is involved, why the action is needed, and what conditions must be true before the action is allowed.

That statement becomes the bridge between the conversation and the architecture. It keeps us from jumping straight to products or broad rules. Instead of saying, “internal users can access the payroll app,” we can say something much more useful: “members of the payroll team may use managed, compliant devices to access payroll records through the approved application during normal payroll processing, when the user identity, device health, session risk, and requested action can be verified and logged.” That sentence gives us something to design around.

Here are a few more examples. For a customer portal: “an authenticated customer may view only their own account information through the customer portal, from a reasonable location and device posture, when the session risk is acceptable and all access is logged.” For an API call: “the order service may send approved order details to the shipping service through the authorized service identity, using the expected interface, when both workloads are healthy and the request matches the normal business process.” For an administrator: “an approved administrator may change production configuration through the management console only from a managed administrative workstation, with strong authentication, active approval, and full logging.”

Notice what those examples have in common. They are not just access rules. They are small descriptions of intended behavior. They tell us what normal looks like. They help us decide which identity controls, device checks, network paths, application protections, data safeguards, monitoring, and response actions need to be in place. They also give us a way to recognize when something has drifted away from the intended design.

So the connection is simple: the Kipling method helps us ask the right questions, and the Zero Trust policy statement captures the answers in a form we can build, test, monitor, and improve. Instead of starting with a product, a diagram, or a checklist, we start with the protect surface and the transactions that reach it. Kipling gives us the conversation. The policy statement gives us the design target. Together, they help us move from vague trust to specific, documented trust decisions that fit the application.

Before We Refill the Cup

I am still working on moving the more detailed discussions into Substack. Once that transition is done, these blog posts will become more generalized information on the subject, with the deeper details available to Substack subscribers. The Substack will be free, I do not share email addresses, and the only thing I sell is my books.

Speaking of books, both of the ZT Foundations books are available right now on my website, cletustaylor.com, at a steep discount. Once the books hit the majority of the distribution channels, the price will go up significantly.

I would also love for you to join the conversation. Drop a comment and tell me where you still see implied trust hiding in your own environment. Is it a legacy login, an always-on admin account, a service account nobody wants to touch, or a business process that still assumes “inside means safe”? If there is a Zero Trust phrase you wish someone would explain in plain English, or an application scenario you would like to see walked through with the Kipling method, send it my way. If you would rather reach out directly, you can email me at hello@cletustaylor.com.

Next week, we will talk about some of the basic tenets of Zero Trust and what they actually mean in practice. So be sure to come back next week. I will have another hot pot of coffee ready.