The Trusted Office Fallacy: Why Every User Network Should Be Treated as Untrusted

The Assumption Nobody Revisited

Most corporate networks were designed around a simple mental model: there's an inside and an outside, a firewall sits between them, and anyone who makes it past the firewall — by being physically in the office, or by connecting through the VPN — is trusted with broad access to internal systems. This model made sense when it was built. It made a lot less sense the moment "inside the network" stopped reliably meaning "a company-owned device, on a physical office network, operated by a known employee."

That moment happened gradually and then all at once. Remote work made VPN access the norm rather than the exception. Bring-your-own-device policies put personal laptops and phones on networks that used to be exclusively company hardware. Cloud services meant a huge share of actual work happens outside the traditional network perimeter entirely. Contractors and vendors got partial network access for specific projects and kept it long after the project ended. Each of these changes was individually reasonable. Together, they quietly hollowed out the assumption the whole security model was built on, and most companies never went back and revisited the model itself.

What This Actually Looks Like as a Risk

The practical failure mode isn't abstract. An attacker who compromises one employee's laptop — through a phishing email, a malicious browser extension, or a vulnerability in software the employee happens to run — doesn't just get that one laptop. In a trusted-network model, they typically get whatever that laptop can reach, which in a lot of companies is a lot more than it should be: file shares, internal applications, sometimes entire subnets of other machines, because "you're on the network" has historically been treated as sufficient proof of trustworthiness for lateral movement.

This is exactly the pattern behind a large share of real-world ransomware incidents: initial access through one relatively low-value endpoint, followed by lateral movement across a flat, trusting internal network until the attacker reaches something that actually matters — backups, financial systems, customer data. The initial compromise is rarely the expensive part. The unrestricted lateral movement afterward is.

What "Zero Trust" Actually Means

"Zero trust" gets thrown around enough as a marketing term that it's worth being precise about what it actually means, separate from any specific product pitching it. The core principle: don't grant broad access based on network location. Verify every request — who's asking, what device they're using, what they're asking to access — regardless of whether the request originates from inside the office or from a coffee shop three states away.

In practice, this means access decisions get made based on identity and context rather than network position. A request to access the finance system gets evaluated on its own terms — is this a known user, on a recognized device, requesting something consistent with their role — rather than being implicitly trusted because it came from an IP address inside the corporate network. This sounds like more friction than the old model, and it can be if implemented poorly, but done well it's largely invisible to legitimate users and genuinely restrictive to anyone who shouldn't be there.

Why This Isn't Just an Enterprise Problem

There's a common assumption that this level of security architecture is overkill for a smaller or mid-market company — something Fortune 500 IT departments worry about, not a 50-person services firm. That assumption doesn't hold up against how attacks actually get chosen. Attackers, especially the automated and semi-automated tooling behind most ransomware campaigns, aren't primarily targeting specific large companies. They're targeting whoever has an exploitable weakness, and a flat, trusting internal network is exactly that kind of weakness regardless of company size.

Smaller companies are, if anything, more exposed to the consequences of this specific gap, because they're less likely to have the segmented, monitored environment that limits how far an attacker can get once they're in, and they're less likely to have the incident response resources to catch and contain lateral movement quickly once it starts.

A Realistic Starting Point, Not a Rebuild

The good news is that closing this gap doesn't require ripping out and replacing the entire network, which is the main reason most companies who know about this problem still haven't addressed it — the perceived cost of "doing zero trust properly" feels disproportionate to the actual first steps needed.

Identity-based access controls are the highest-leverage starting point. Multi-factor authentication on anything that matters, tied to actual identity rather than just network location, closes a huge share of the risk on its own. This is also usually the cheapest and fastest piece to implement, because it layers on top of existing systems rather than requiring new network architecture.

Network segmentation is the second highest-leverage step: breaking a flat internal network into smaller zones, so that compromising one machine doesn't automatically grant reach to everything else. This doesn't require a full zero-trust architecture to provide real value — even coarse segmentation (finance systems on their own segment, general office devices on another, servers on a third) meaningfully limits how far a compromise can spread before it gets contained.

Least-privilege access reviews — actually auditing who has access to what, and removing access that accumulated over time and was never revoked — close a surprising amount of risk for very little technical work. Most companies that haven't done this in a while find contractors with access from projects that ended a year ago, former employees whose accounts never got fully deprovisioned, and broad access grants nobody remembers the original justification for.

None of these three steps requires a multi-year security overhaul or a wholesale infrastructure replacement. They require someone treating this as a real, prioritized project instead of a background assumption that the perimeter firewall is still doing the job it was designed for in a world that no longer matches that design.

The Question Worth Asking Directly

The useful diagnostic question for any company, regardless of size: if someone's laptop got compromised right now, how far could an attacker actually get before hitting a wall that requires a separate verification step? If the honest answer is "pretty far, because most of our internal systems trust anything already on the network," that's not a hypothetical risk — it's the current, live architecture, and it's worth treating as a real project rather than a someday item.

Subscribe for more like this.

This article was drafted with AI assistance and reviewed and edited by Matt before publishing.

About the Author: Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. Network architecture and the shift away from perimeter-trust models has been a consistent thread across his infrastructure work.