Zero Trust Foundations: How the Five Pillars Build Better Trust Decisions

How to use Identity, Device, Network, Application, and Data as the lenses for turning a legacy security environment into a working Zero Trust Architecture.

Summary: Before we start changing controls, this week takes a strategic pause to look at the Zero Trust Architecture we are trying to build. The Five Pillars: Identity, Device, Network, Application, and Data show how trust decisions are made, from allowing routine access to challenging, limiting, or blocking higher-risk actions. Next week, we will look at the cross-functional roles that keep those decisions visible, governed, automated, and improving over time.

 “Zero Trust doesn’t eliminate trust. It distributes trust deliberately.”

Grab a fresh cup of coffee and let’s keep going. In the last post, we picked our first protect surface: a messy hybrid business application with on-premises pieces, SaaS reporting, exported data, service accounts, admin tools, vendor access, and more than a few inherited assumptions. That was intentional. If we are going to build Zero Trust with the tools we already have, we need to start with the environment we actually own, not the one we wish we had.

But before we start changing firewall rules, rewriting access policies, tightening permissions, or turning knobs in management consoles, let’s pause for one cup and look at the architecture we are trying to create. What is this Zero Trust Architecture supposed to do? What does it need to prove? And how will we know the trust decision is based on reality instead of old assumptions?

This week is about that first layer of the big picture: the Five Pillars. Identity, Device, Network, Application, and Data are not just categories on a diagram. They are the inputs that help us decide whether a request should be allowed, limited, challenged, or denied. Next week, we will zoom out one more level and talk about the cross-functional roles that keep those decisions alive: visibility and analytics to see what is happening, automation and orchestration to respond consistently, governance to keep decisions tied to business risk, security operations to investigate and improve, and business owners to define what good access actually means.

Think about the kinds of decisions we want this architecture to make. A payroll employee may be allowed to view payroll records from a managed, healthy device during a normal processing window. That same user may be challenged if the request comes from an unfamiliar device or unusual location. An administrator may be allowed to make a production change only from a secured admin workstation with stronger authentication and approval. A vendor may be limited to one support path instead of receiving broad VPN access. A bulk export of sensitive customer data may be blocked, narrowed, or routed for approval when the device posture, timing, role, or data sensitivity does not support the request.

The Five Pillars Are Not Five Separate Projects

Think of the Five Pillars like five lenses you look through at the same time. One lens tells you who is making the request. Another tells you what device or workload is being used. Another tells you where the session can go. Another tells you what action is being attempted. The last one tells you what is actually at stake.

·         Identity asks who is making the request and whether that identity should be trusted under these conditions.

·         Device asks what is being used and whether it is healthy enough to influence the decision.

·         Network asks where the request can go and how far the session can reach if something goes wrong.

·         Application asks what action is being attempted, especially when that action has higher impact.

·         Data asks what is at stake and whether sensitivity should tighten, limit, or veto access.

Here is the important part: no single pillar proves trust on its own. A clean login on a risky device is still a problem. A healthy device with broad network reach is still a problem. A well-segmented network that cannot understand the action being taken is still a problem. Zero Trust starts to become real when the pillars constrain each other instead of operating like separate checkboxes.

Start by Asking What the Legacy Model Is Assuming

When we evaluate a legacy security architecture, we are not just looking for missing tools. We are looking for places where the environment quietly says, “we trusted this once, so we will keep trusting it.” That assumption may show up as standing admin rights, broad VPN access, unmanaged device exceptions, local application accounts, shared credentials, old firewall rules, or sensitive data labels that never change what users can actually do.

So pour the coffee, spread the diagram across the table, and start with this question: if this request happens right now, what does the system actually evaluate before allowing it? If the answer is only “the user logged in,” or “the device is corporate-owned,” or “the traffic came through the VPN,” then implicit trust is still doing more work than it should.

Identity: Is the Front Door Also Making Better Decisions?

Identity is the front door of Zero Trust, but it cannot be the only lock. In the legacy model, authentication often became the end of the conversation. If the username and password worked, the session was treated as legitimate. In a functional Zero Trust Architecture, identity becomes a decision input. Who is making the request? Is the role appropriate? Is the sign-in risky? Is this a normal action for this person or workload? Should the system allow, challenge, limit, or deny?

·         Look for accounts without MFA, stale identities, orphaned service accounts, shared credentials, and permanent admin roles.

·         Ask whether privileged actions require stronger proof than routine actions.

·         Pick one high-risk action, such as an admin change or bulk export, and define what identity context must be true before it is allowed.

Device: Stop Trusting Ownership More Than Health

A trusted identity on an untrusted device is still a breach waiting for a path. Legacy environments often treat “managed” as the same thing as “safe.” But a known device can still be missing patches, lacking endpoint coverage, carrying stale posture data, or operating outside expected conditions. Device trust has to be health-based, not ownership-based.

·         Look for unmanaged devices with meaningful access, stale EDR check-ins, missing patches, local admin sprawl, and device posture that never changes access.

·         Ask whether a risky or unknown device can still reach sensitive applications and data.

·         Define what happens when posture fails: step-up, view-only, quarantine, limited reach, or block.

Network: Turn Connectivity Into Containment

The network is no longer the source of trust, but it still defines blast radius. In legacy architecture, the network often proves that a session can connect. In Zero Trust, the network helps decide how far that session should be allowed to go. That difference matters. A broad VPN profile, an old any-any firewall rule, or a segmentation diagram that looks better than reality can quietly restore perimeter-style trust inside the environment.

·         Look for broad VPN reach, forgotten firewall rules, internal traffic treated as safe, and blind spots in east-west visibility.

·         Ask what systems the session can reach if the user, device, or workload is compromised.

·         Start tightening around the protect surface, not the whole enterprise at once.

Application: Separate Access From Action

Applications are where access becomes action. A user opening an application is not the same as exporting thousands of records, creating a token, granting a role, changing a payment destination, or modifying production configuration. Legacy applications often struggle here because authentication quietly becomes authorization. The app says, “they logged in, so let it happen.” Zero Trust asks the application to understand intent.

·         Look for local app accounts, overprivileged roles, hard-coded credentials, shared secrets, and APIs trusted because they are internal.

·         Ask whether the application can distinguish between viewing, changing, exporting, administering, and approving.

·         Protect high-impact actions differently with step-up, approval, just-in-time access, or stronger logging.

Data: Give Sensitivity a Vote

Data is the final boundary. It is why the other pillars exist. If sensitive data is labeled but the label does not influence access, then classification is only metadata. In a functional Zero Trust Architecture, sensitivity has authority. It can tighten the conditions, limit the action, require approval, restrict download, or veto the request when the risk is too high.

·         Look for unclassified sensitive data, overly broad access, shadow data stores, unmonitored transfers, and permissions that only ever increase.

·         Ask whether a bulk export, external share, or high-risk download should be allowed under the current conditions.

·         Make data sensitivity part of the decision, not a note someone reads after the incident.

When the Pillars Exist but the System Still Fails

Here is the uncomfortable part. Many organizations already have pieces of all five pillars. They have an identity provider, endpoint tools, firewalls, application roles, data labels, and logs. By checklist standards, the pillars are present. But Zero Trust does not fail only when controls are missing. It also fails when controls are isolated.

Imagine a familiar user signing in late at night to download a large set of sensitive customer records. Identity says the login succeeded. Device says the laptop is known. Network says the path is open. Application says the role allows export. Data says the records are sensitive, but nothing in the moment changes. Nothing breaks. Nothing alerts. Nothing looks obviously wrong. And yet, implicit trust just won.

The lesson is simple: each pillar can answer its own question and still miss the collective one. Given everything we know right now, should this action be allowed? That is the question a functional Zero Trust Architecture has to answer.

Use the Pillars as a Decision Contract

This is where the Five Pillars become more than an assessment tool. They become a decision contract between security, IT operations, application teams, data owners, business leaders, and vendors. The contract does not have to be complicated. It just has to be clear enough that teams stop relying on tribal knowledge and start making repeatable decisions.

·         No access decision should rely on identity alone.

·         Network location should never imply trust.

·         Device trust should be based on current health, not ownership.

·         Least privilege should apply to actions, not just applications.

·         Data sensitivity should have veto power.

·         Every exception should have an owner, an expiration date, and a compensating control.

·         Every important decision should be observable enough to explain later.

From Legacy Architecture to Functional Zero Trust

The transformation does not happen by buying one tool or rewriting the whole environment in one move. It happens by taking one protect surface, evaluating how trust is granted today, and then improving the decision path one layer at a time. For our messy hybrid business application, that means we will start turning assumptions into requirements.

1.      Map the protect surface. Identify the data, application, assets, services, users, administrators, vendors, integrations, and supporting workflows.

2.      Map the transactions. Use the Kipling questions to understand who or what acts, what they do, when it happens, where it goes, why it is needed, and how it should be protected.

3.      Evaluate each transaction through the Five Pillars. Look for where trust is verified, where it is assumed, and where one pillar is making decisions alone.

4.      Find the implicit trust. Document broad access, stale permissions, unmanaged devices, flat paths, weak application roles, sensitive exports, and exceptions that never expire.

5.      Define the better decision. Decide what should happen under normal conditions and what should change when risk rises.

6.      Use existing tools first. Connect the controls already in place before reaching for a shopping list.

7.      Measure whether trust is shrinking. Track fewer standing privileges, narrower network reach, healthier devices, stronger application enforcement, better data constraints, and more explainable decisions.

What We Are Really Building

What we are building is not a perfect diagram. We are building a system that can make the same kind of access decision consistently, explain why it made that decision, and improve as conditions change. That is the difference between having Zero Trust pieces and operating a functional Zero Trust Architecture.

The mental shift is important: Zero Trust does not eliminate trust. It distributes trust deliberately. The Five Pillars help us decide where trust should come from, how much trust is enough, when trust should be reduced, and when the safest answer is “not like this.”

Before the Next Cup

Here is your homework before the next cup of coffee: pick one transaction in the protect surface you chose last week. Do not start with the whole application. Start with one action that matters, such as a user viewing sensitive records, a manager approving a change, an administrator modifying configuration, a service account moving data, or a vendor connecting for support.

Then ask the Five Pillar question: what would have to be true across Identity, Device, Network, Application, and Data before that action should be allowed? If one pillar is missing from the conversation, that is not a failure. It is the next place to learn.

This series is a light version of the full process I walk through in ZT Foundations: Building Zero Trust with the Tools You Already Have. If your team is trying to make Zero Trust practical instead of theoretical, this is the work: choose something real, evaluate how trust is granted today, and use the Five Pillars to turn assumptions into better decisions.

Next time, we will step into the cross-functional roles that keep a Zero Trust Architecture from becoming a one-time diagram. We will talk about visibility and analytics, automation and orchestration, governance, security operations, business ownership, and continuous improvement. Those functions help create the architecture, operate the trust decisions, measure whether they are working, and keep the system from drifting back into implicit trust. I’ll have the coffee hot when we connect the pillars to the operating model that keeps them working.

Call to action: Before next week, choose one real transaction in your environment and run it through the Five Pillars. Write down what the system knows, what it assumes, and what should change when risk rises. Keep this question from the book in front of you:

“Given everything we know right now, should this be allowed?” 

If the answer depends on habit, location, ownership, or old permissions instead of current context, you have found your first practical Zero Trust improvement.

And as always, I would love to hear from you. If this post sparked a thought, raised a question, or gave you an idea for a future topic, send it my way at hello@cletustaylor.com. Your feedback, pushback, and real-world examples help make this conversation better for everyone.