Zero Trust Foundations: Start Small, Protect What Matters

How to make Zero Trust manageable by starting with one meaningful, messy protect surface.

Summary: Zero Trust works best when we stop trying to fix everything at once and start with one meaningful protect surface. In this post, we look at how to choose that first surface, why it should be important but not business-breaking, and how a messy hybrid application can teach us more than a clean classroom example ever could.

Grab a fresh cup of coffee and let’s pick up where we left off. In the last post, we talked about the tenets of Zero Trust and how they help us replace broad, inherited trust with better security decisions. That sounds good on paper, but it leads to the next practical question: where do we actually begin?

The answer is not “everywhere.” That is the trap. Zero Trust is not something we roll out across the whole company in one heroic weekend and then declare finished on Monday morning. If we try to transform the entire environment in one big push, we will frustrate the business, overwhelm the technical teams, and probably end up with a binder full of diagrams instead of a working architecture. Zero Trust succeeds when we break the work into bite-sized chunks, learn from each one, and use those lessons to guide the next step.

Thankfully, Zero Trust gives us the perfect mechanism for doing exactly that: the protect surface. So instead of trying to secure everything at once, we pick one meaningful thing, pull it into focus, and start making better decisions around it.

What Is a Protect Surface?

A protect surface is the specific thing we are trying to protect. It is the collection of data, applications, assets, and services that support a meaningful business process. Instead of staring at the entire attack surface and trying to secure everything at once, we narrow the focus to something concrete enough to understand, map, and improve.

That distinction matters. The attack surface is enormous. It includes every endpoint, server, identity, application, cloud service, network path, vendor connection, API, and configuration mistake that could possibly be abused. The protect surface is smaller and more useful. It asks, “What business function are we protecting, what data matters, what applications touch it, and what services make those transactions possible?”

In a real environment, a protect surface might be the payroll process, including payroll records, the payroll application, the identity groups that can access it, the database behind it, the file exports it creates, and the administrative tools used to maintain it. It might be a customer portal, including the web application, customer records, authentication service, payment integration, logging platform, and support workflows. It might be a manufacturing control application, a claims processing workflow, an executive reporting dashboard, a research data repository, or a third-party vendor access process.

The point is not to make the protect surface tiny just so the work feels easy. The point is to make it specific enough that we can identify the transactions, ask the Kipling questions, understand the dependencies, and make better trust decisions.

Choosing the First One Is a Delicate Balance

So how do we choose the first one without either picking something meaningless or accidentally setting the building on fire?

Selecting the first protect surface to examine is a delicate balance. It must be important to the business, or we have to ask why we are spending time on it in the first place. If the application, data, or workflow does not matter, it will not create the urgency or executive interest we need to move the work forward.

At the same time, it should not be so business-critical that one mistake breaks the organization. Our first protect surface is where we are going to learn the process, discover uncomfortable dependencies, find old assumptions, and probably have a few hard conversations. We need room to learn without creating unnecessary business risk.

The first protect surface also needs enough challenge and complexity to be useful. If it is too simple, we may only test one or two Zero Trust capabilities and learn very little. If it is too large, we risk trying to boil the ocean. We want something that lets us examine identity, devices, networks, applications, workloads, data, logging, operations, and governance without turning the effort into a never-ending discovery project.

Finally, the first protect surface should touch as many teams as practical. That may sound like we are inviting friction, and we are. Identity teams, endpoint teams, network teams, application owners, cloud administrators, security operations, compliance, help desk, and business stakeholders all need to learn the new disciplines Zero Trust requires. The earlier those teams participate, the sooner the organization starts building shared language and shared habits.

No matter which protect surface we choose, there will be conflict and challenge. If nobody gets uncomfortable, we probably are not looking closely enough. That is not a sign that the process is failing. It is a sign that we are finally seeing how trust is actually being granted. The evaluation will reveal old shortcuts. The adoption of changes will disrupt familiar routines. Some teams will worry about performance. Others will worry about support tickets. The business will worry about friction. Those concerns are real, and they need to be part of the conversation.

Checklist: Choosing a Good First Protect Surface

Use this as a quick gut check before you settle on the first protect surface. It does not have to score perfectly, but if you cannot check most of these boxes, it may not be the right place to start.

·         It matters to the business. The application, data, or workflow supports a real business function people care about.

·         It is important, but not business-breaking. A mistake would create concern and learning, not a company-wide outage or crisis.

·         It has enough complexity to teach us something. The surface includes more than one team, system, identity type, data flow, or access path.

·         It is not so large that we are boiling the ocean. The scope can be described clearly and reviewed without pulling in the entire enterprise.

·         It includes real data movement. Data is created, viewed, exported, copied, reported on, shared, or stored in ways worth understanding.

·         It touches multiple Zero Trust pillars. The work will let us examine identity, devices, networks, applications and workloads, and data.

·         It involves multiple teams. The effort creates opportunities for identity, endpoint, network, application, cloud, security operations, compliance, help desk, and business stakeholders to learn together.

·         It has visible ownership. Someone can explain who owns the application, the data, the access model, the exceptions, and the risk decisions.

·         It exposes existing assumptions. The surface includes old permissions, shared accounts, informal processes, legacy authentication, broad network access, or other inherited trust worth challenging.

·         It can be measured and improved. We can identify the transactions, collect useful logs, document current controls, and define what better looks like.

If the candidate protect surface checks most of those boxes, it is probably messy enough to be useful and bounded enough to finish. That is the sweet spot for the first pass.

Here is your homework before the next cup of coffee: pick one candidate protect surface in your environment and walk it through the checklist. Do not overthink it. Just see where it feels strong, where it feels weak, and where the first hard conversation is likely to happen.

Our Example Protect Surface: A Messy Hybrid Business Application

For our example in this series, we are going to choose a hybrid on-premises and SaaS application that does not already have a lot of Zero Trust controls and capabilities enabled. Think of a departmental business application used by finance, operations, and customer support. The core application still runs on-premises. It uses a legacy database in the data center. Users authenticate through the corporate identity platform, but the application itself still has some older permission models. Reports are exported to a SaaS analytics platform. Files are occasionally dropped into cloud storage for collaboration. A small set of administrators manage the application through internal tools, while a vendor occasionally needs access for support.

That protect surface is messy on purpose. And that is exactly why it is useful.

It has users, service accounts, administrators, vendor access, on-premises infrastructure, SaaS integration, exported data, legacy assumptions, and operational dependencies. It is not the worst system in the company, but it is not clean either. That makes it useful. It gives us enough complexity to examine multiple Zero Trust capabilities without trying to redesign the entire enterprise at once.

Clean laboratory examples do not teach us much about real Zero Trust work. Real environments have old assumptions, strange dependencies, informal exceptions, and decisions nobody remembers approving. We should not expect any of our initial protect surfaces to be anywhere near our end goals. If they were already clean, well-documented, properly segmented, fully instrumented, strongly authenticated, tightly governed, and consistently monitored, we would not need to spend much time learning from them.

The mess is the point. Building Zero Trust from existing capabilities means we start with what is real, not what we wish the environment looked like. We identify the tools already available, the controls already in place, the gaps we can see, the assumptions we need to challenge, and the decisions we want to improve.

Do Not Start With a Shopping Spree

This is where I want to be very clear about our purpose. We are building a functional Zero Trust environment from existing tools and capabilities. The first stage is not a shopping spree. Before we buy anything, we need to know what problem we are actually trying to solve. It is not the time to invite every vendor into the room or ask for a roadmap that promises to solve everything by the end of the quarter.

There may come a time when new tools are needed. I am not against tools, and I am certainly not against vendors. But no vendor roadmap can tell you what your business values most, where trust is being assumed in your environment, which teams own the messy middle, or what tradeoffs your organization is willing to accept.

Before we buy anything, we need to find out what we already have and where we want to go next. We need to understand identity flows, device posture, access paths, data sensitivity, administrative processes, logging coverage, exception handling, and operational ownership. That discovery belongs to the organization. A product can support the journey, but it cannot define the destination.

What We Are Trying to Learn

Our first protect surface should help us answer practical questions. Who or what accesses the application and data? Which devices and workloads are involved? What network paths are required? Which SaaS services receive or process the data? Where do administrators make changes? What logs exist today? What decisions are already automated, and which ones still depend on tribal knowledge?

We also want to learn where the hard conversations will happen. Maybe the application team depends on a shared administrator account. Maybe the vendor access process is informal. Maybe data exports are copied into places nobody reviews. Maybe the network team has a firewall rule that nobody wants to touch because nobody remembers why it exists. Maybe the business needs the application available during odd hours, but the access policies assume a simple workday.

Those discoveries are not failures. They are the raw material for a functional Zero Trust Architecture. Each one gives us a chance to replace vague trust with specific decisions.

Of course, that only works if we choose the protect surface carefully. A poor choice can make the process feel either too easy to matter or too large to finish.

Common Pitfalls When Choosing a Protect Surface

This is one of those places where it is easy to make the work harder than it needs to be. The first protect surface does not have to be perfect, but the choice does matter. Pick the wrong one and the effort can stall before the organization learns anything useful.

One common mistake is choosing something too small or too isolated. If the protect surface only touches one team, one simple application, or one low-risk data set, the project may feel safe, but it will not teach us enough about how Zero Trust needs to work across the business.

Another mistake is choosing the crown jewels first. I understand the instinct. If Zero Trust is about protecting what matters, why not start with the most critical system in the company? The problem is that the first pass through this process will be where we learn the most, and learning can be messy. Starting with the most fragile or mission-critical process may create pressure to move too fast, avoid hard changes, or stop at a surface-level assessment.

A third pitfall is picking a protect surface because the technology team owns it, instead of because the business depends on it. Zero Trust is not just an IT cleanup project. If the business process does not matter, the conversation will not have the right urgency. If the business stakeholders are not involved, we will miss the context that tells us which transactions are normal, which exceptions are acceptable, and which risks actually matter.

We can also get into trouble by picking something that is already too polished. A clean, modern, well-documented application may make for a nice diagram, but it may not reveal the inherited trust, informal workarounds, legacy authentication, awkward handoffs, and operational habits we actually need to learn from.

The last pitfall is letting the scope quietly expand. We start with one application, then add every integration, every adjacent workflow, every downstream report, and every future improvement idea until the project becomes a whale in a coffee cup. Keep the scope honest. Capture the related issues, but do not let them turn the first protect surface into the entire enterprise.

Zero Trust Capabilities to Examine First

Once we have chosen the protect surface, the next question is what we should look at first. For our messy hybrid application, we will emphasize some of the capabilities that help us understand how trust is being granted today and where we can make that trust more specific. When I say capabilities, I do not mean products. I mean the security functions, processes, controls, and visibility we can already bring to the conversation. Think of these as the first places to shine the flashlight, not a complete maturity model.

Identity and access. Who can reach the application, the database, the SaaS reporting platform, the file exports, and the administrative tools? Are those rights tied to individual identities, groups, service accounts, or shared credentials? Are there stale accounts, broad roles, or permissions that nobody can explain?

Authentication strength. Does access depend only on a password, or do we have stronger checks such as multifactor authentication, conditional access, phishing-resistant methods for privileged users, and session risk evaluation where appropriate?

Device and workload posture. What devices, servers, and workloads participate in the transactions? Are user devices managed and healthy? Are servers patched and monitored? Are workloads identified clearly enough that we know which service is making which request?

Network paths and segmentation. Which network paths are required, and which ones exist only because nobody has reviewed them in years? Can users, administrators, vendors, and services reach only what they need, or does the current design still assume that being on the network is enough?

Application and workload behavior. What does normal use look like? Which actions should users, services, administrators, and vendors perform? Are there risky functions, old admin interfaces, insecure integrations, or background jobs that deserve closer attention?

Data handling. What data is created, viewed, exported, copied, stored, or shared? Does the SaaS reporting platform receive sensitive information? Are file exports protected, expired, reviewed, or simply left in shared storage until someone remembers them?

Logging and visibility. Can we see sign-ins, access decisions, administrative changes, data exports, vendor activity, service account use, and unusual behavior? If we cannot see the transaction, we cannot validate it, troubleshoot it, or improve it.

Governance and ownership. Who owns the application, the data, the access model, the exceptions, the integrations, and the risk decisions? Zero Trust gets weak fast when ownership is fuzzy. Somebody needs to be able to say what good looks like and who gets to approve changes.

None of those questions require us to buy anything on day one. They require us to look honestly at the capabilities we already have, the controls we are already using, and the places where trust is still being handed out more generously than it should be.

Before the Next Cup

This series is a light version of the full process I spell out in ZT Foundations: Building Zero Trust with the Tools You Already Have, available now on cletustaylor.com and on major distributors. In the book, I go deeper into the methodology, the questions, the assessment process, and the way those pieces come together into a working Zero Trust Architecture.

Want to bring this conversation to your team or event?If your leadership group, security team, IT organization, conference, or professional association is trying to make Zero Trust practical instead of theoretical, I would be glad to help. I speak virtually and in person on Zero Trust, practical architecture, and building better security decisions with the tools you already have. If that would be useful for your group, reach out at hello@cletustaylor.com and let’s talk about what would help your audience most.

I would also love to hear from you. What kind of protect surface would you choose first in your environment? Where do you think the hardest conversations would happen? What examples would help make this process clearer? Send your feedback, questions, pushback, and real-world examples to hello@cletustaylor.com. If something in this post made you nod, disagree, or think, “that sounds exactly like us,” I want to hear about it.

Share this post with someone who is trying to make Zero Trust practical instead of theoretical, and come back next time as we begin turning this protect surface into a functional Zero Trust Architecture. I’ll have the coffee hot when we walk through the assessment and implementation process together.

Until then, keep the questions brewing and the coffee close.