Zero Trust for the Estate You Actually Have

Read any zero trust implementation guide, including the one on this site, and notice what it assumes. It assumes workloads that carry identities, a policy engine that can evaluate a request, services speaking a protocol capable of carrying a token, and somewhere in there, usually, a service mesh.

Now walk the actual estate of a 300-person company. Five or six SaaS applications carry most of the business, a file server nobody wants to touch because the finance close depends on it, a badge controller from an integrator, a camera network on its own switch, a machine in a back office running the software that talks to equipment on the floor, and two laptops belonging to contractors. None of that has a workload identity, and none of it is going to get one.

Why the Guidance Does Not Land

This is not a criticism of the frameworks. The cloud-native version of zero trust is well specified because the problem is well specified: every component can present a cryptographic identity, every call goes through something that can enforce policy, and the whole environment is described in code.

Our own phased approach to zero trust architecture sets that out, and fine-grained authorization for microservices covers the enforcement layer. Both are correct for the environment they describe.

The problem is that the environment they describe is a minority of what exists. A badge controller cannot present a certificate to a policy engine. It sits on a flat network, trusts anything that can reach it, and the vendor’s answer to hardening is a firmware version from 2021. There is no phase of any maturity model where that device starts making authenticated requests.

So the guidance gets read, the gap between the diagram and the building becomes obvious, and the program stalls at the assessment stage. I have watched that happen more than once, and the failure is never technical.

The Principle Underneath, Which Does Transfer

Strip zero trust back to the actual claim and it is smaller than the architecture built on top of it. The claim is that being on the network should not by itself grant access, and that every request should be evaluated rather than assumed.

Identity is the best mechanism for that when it is available. It is not the only one. If a device cannot prove who it is, you can still constrain what it can reach, and constraint applied at the network gets you a large fraction of the same property with no participation from the device at all.

That reframing is what makes this tractable for a real estate. You are not trying to give a camera an identity. You are trying to make sure that a camera which has been taken over reaches nothing worth having.

Sort Your Estate Into Three Buckets

This takes an afternoon with a whiteboard and it is the entire planning exercise, because what you can do to something depends almost entirely on which bucket it lands in.

Things that can carry an identity. Your SaaS applications, your laptops, your servers with a modern operating system, anything that speaks SAML or OIDC. Here the standard guidance applies directly: single sign-on, conditional access, device posture, short-lived sessions. This is also where most of your data lives, so it deserves the effort.

Things that cannot, but can be reached over a network you control. Badge controllers, cameras, the file server, printers, building management, the machine that talks to the equipment. Identity is unavailable and placement is entirely available. That is where the work sits.

Things you have forgotten. The bucket that matters most and that nobody writes down. Devices bought on expense reports, a vendor’s remote access appliance, a test system somebody stood up in 2023. Everything in the previous article about what your assessment was not allowed to touch lives here.

What to Do With Bucket Two

Four controls, in the order I would apply them. The order matters more than the list does, because each one narrows the ground the next has to cover.

Give each category its own segment

Put the cameras together, the building systems together, and the file server on its own, with no routes between those segments, because a camera has no legitimate reason to reach a badge controller and the two vendors will never notice you separated them. This is the single highest-return action in the whole exercise and it is available to anybody with a managed switch.

Default-deny outbound, then allowlist

Every device in bucket two should be unable to initiate a connection to the internet unless you have specifically permitted a destination. If a camera needs a vendor’s update server, allow that one host and nothing else.

I keep arriving at this control from unrelated directions. Four separate stories in the last week turned on outbound being permitted by default, and in every one the containment would have come from an egress rule rather than from anything clever.

Put a chokepoint in front of the things people actually use

The file server that finance depends on cannot be replaced this quarter. It can sit behind something that requires an authenticated session to reach, which converts a flat-network resource into one that at least requires a person to be who they say they are first.

This is the pattern our secure remote access guide describes, turned inward instead of pointed at the perimeter. The mechanics are identical and the licensing usually already covers it.

Log the segment boundaries, not the devices

You will not get useful telemetry out of a badge controller. You will get excellent telemetry from the point where its segment meets everything else, and that is the only place an intrusion has to cross.

Instrument the boundary and you get detection for a whole category of device that can never report on itself, which is the only place that visibility is going to come from.

Sequence by Blast Radius

The usual failure in this work is starting with whatever is easiest to instrument, which is almost always the modern systems already in decent shape. Order it the other way. For each segment ask what an attacker who fully controlled it could reach next, and start where that answer is worst. In most buildings the honest answer is the vendor-administered system with a flat route to the corporate network, and it is nobody’s project.

That question also gives you the business case. Blast radius is a concept a finance director understands without translation, and a maturity level is not, which decides whether the work gets funded.

What This Buys You

You will not reach the architecture in the diagrams, and you should be clear with your leadership that you are not trying to. A 300-person company with a warehouse is not going to run a service mesh.

What you can reach is an estate where the untrustworthy things are contained, the identity-capable things use identity properly, and the boundary between them is watched. That is most of the value of zero trust, obtained through segmentation and egress control rather than through architecture nobody is going to fund.

The Afternoon That Starts It

Draw your network on a whiteboard, then draw a line around every group of devices that could be separated without anybody noticing. Count the lines. That number is how much of this you can do without buying anything, and in most organizations it is larger than the security team expects and smaller than the network team fears.

Want a segmentation plan built around what your estate actually contains? Contact Grab The Axe for an assessment, or start with our free Human Attack Surface Score.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →