The Qilin ransomware group hit Cleveland Municipal Court in early 2025. The court went dark for a week. Employees worked without internet access. Background checks stopped. Dozens of trials had to be rescheduled. The court's public website stayed down for nearly a month.
Cleveland isn't a small town with a two-person IT team. It's a major metropolitan court system — the kind of organization that has IT staff, policies, and some level of security infrastructure in place. And it still spent three-plus weeks recovering from a single ransomware event.
What incidents like this reveal isn't that local government IT teams aren't trying. They are. What they reveal is that perimeter-based security — the "keep the bad guys out" model most organizations still rely on — doesn't hold up the way it once did. Once an attacker is in, there's often nothing stopping them from moving laterally across every connected system.
That's exactly the problem Zero Trust is designed to solve. And it's why the distinction between "buying Zero Trust" and building it has never mattered more.
Every major cybersecurity vendor will tell you they sell Zero Trust. You can buy a Zero Trust firewall, a Zero Trust network access tool, a Zero Trust identity platform. The brochures all say the same thing: implement this, and you'll have Zero Trust.
But here's what those brochures leave out: no single product, no matter how good, delivers Zero Trust on its own. Zero Trust is not a tool. It's not a feature set. It's not even a compliance framework — though it maps closely to one.
Zero Trust is an outcome. And understanding that distinction may be one of the most important things a local government IT leader can do right now.
What Zero Trust Actually Means
The term comes from NIST Special Publication 800-207, which defines Zero Trust Architecture (ZTA) as a security model built on one foundational principle: no user, device, or system is trusted by default — regardless of whether it's inside or outside your network perimeter.
In traditional network security, the perimeter was the boundary. If you were inside the firewall, you were assumed to be trusted. That model made sense when employees worked in a single building, on agency-owned hardware, connecting to on-premises systems.
That world is gone for most local government IT environments. Today, city staff work remotely. Contractors access municipal systems from personal devices. Cloud applications sit outside any traditional perimeter. And increasingly, operational technology (OT) networks — the systems that control water treatment, traffic signals, and public facilities — are networked alongside the same IT infrastructure that runs email and finance.
Zero Trust responds to this reality. It operates from the assumption that a breach may already be in progress and designs the environment to limit how far damage can spread. The technical term for this is limiting the blast radius — and it's one of the most consequential concepts in modern public sector security.
Why "Buying Zero Trust" Misses the Point
When a vendor sells you a Zero Trust product, they're selling you one layer of a much larger architecture. Identity verification is one layer. Network segmentation is another. Device health checks, application access policies, continuous monitoring, and incident response procedures are additional layers.
NIST 800-207 describes seven tenets that together define a true Zero Trust architecture — and they span across people, processes, and technology. No single product addresses all seven. The organizations that achieve genuine Zero Trust do so through a deliberate, sequenced strategy that aligns tools, policies, and operations around a unified security posture.
For local government IT directors, this has real implications. When your leadership asks whether your agency is "Zero Trust compliant," the honest answer requires more than pointing to a vendor contract. It requires being able to describe how your environment verifies identity, validates device health, enforces least-privilege access, segments critical systems, and monitors continuously for anomalous behavior.
That's not a criticism — it's an opportunity. Because the IT leaders who understand Zero Trust as an architecture rather than a product category are the ones building security programs that actually hold up.
What This Looks Like in a Municipal Environment
Local government IT environments are uniquely complex. They often combine decades-old legacy infrastructure with modern cloud services, manage CJIS-sensitive data alongside public-facing applications, and may include OT networks that were never designed with cybersecurity in mind.
A genuine Zero Trust approach to this environment doesn't start with a product purchase. It starts with three questions — and if you can answer all three with confidence, you're further along than most:
Who has access to what — and should they?
Identity is the foundation of Zero Trust. Before you can enforce least-privilege access, you need an accurate picture of which users, service accounts, and devices can reach which systems. For many municipal environments, that picture is incomplete. Legacy accounts, shared credentials, and contractor access that outlasted the contract are common starting points for a breach.
If one account or device is compromised, how far can damage spread?
Network micro-segmentation — separating systems so that a compromised endpoint in one area can't freely communicate with systems in another — is one of the most effective tools for limiting the blast radius of an incident. In environments where OT networks are adjacent to IT networks, this becomes especially critical. The Cleveland court attack spread because systems were connected in ways that allowed lateral movement. Segmentation is how you stop that.
Do you have visibility to know something is wrong before it's catastrophic?
Continuous monitoring and analytics aren't optional components of a Zero Trust architecture — they're how you verify that the controls you've implemented are working. Without ongoing visibility, Zero Trust controls become a static snapshot rather than a living security posture.
The Compliance Connection
For local government IT leaders, Zero Trust isn't just a security best practice — it's increasingly woven into the regulatory landscape you're already navigating.
CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) incorporate Zero Trust principles throughout. AWIA 2018 requires water utilities to assess cyber risks to their operational technology — risks that a Zero Trust architecture directly addresses. And if your agency works with federal data or defense contracts, CMMC and CJIS requirements align closely with Zero Trust controls.
This doesn't mean Zero Trust is a compliance checkbox. It means that building toward a genuine Zero Trust architecture creates the kind of security posture that satisfies multiple regulatory frameworks simultaneously — reducing the reporting burden and giving you something concrete to point to when auditors ask questions.
Starting Where You Are
One of the most common concerns we hear from local government IT directors is that Zero Trust sounds like a large-scale, expensive overhaul that isn't realistic given budget and staffing constraints.
That concern is understandable — and it's also a misconception worth challenging.
Zero Trust isn't a destination you reach all at once. CISA's Zero Trust Maturity Model — the federal government's implementation framework that complements NIST 800-207 — describes a clear progression: organizations move from traditional network security, through initial and advanced stages, toward a fully optimized architecture over time. Progress along that maturity curve — even partial progress — meaningfully reduces risk.
Any of the following is a meaningful Zero Trust step:
- 1 Identity & access review — close orphaned accounts and enforce MFA on administrative systems.
- 2 OT network segmentation — separate your operational technology traffic from general IT infrastructure.
- 3 Endpoint detection deployment — gain visibility across agency devices before a compromise becomes a crisis.
The key is having a clear picture of where you are, a prioritized roadmap for where to go next, and a partner who can translate regulatory requirements and architectural principles into practical steps that make sense for your specific environment.
The Outcome That Matters
At the end of the day, Zero Trust exists for one reason: to make sure that if something goes wrong — if one device is compromised, one credential is stolen, one account is hijacked — it can't take down everything else with it.
For a local government IT director, that outcome translates directly to public trust, operational continuity, and the ability to keep delivering the services your community depends on. Whether it's water treatment, public records, emergency dispatch, or parks and recreation, the infrastructure you manage is not just an IT concern. It's a community concern.
The IT leaders who are getting ahead of this aren't necessarily the ones with the largest budgets. They're the ones who stopped thinking about security as a product category and started thinking about it as an architecture — and a commitment to an outcome.
That shift in thinking is where Zero Trust actually begins.
AllConnected is a Managed Service Provider based in Simi Valley, CA, serving local government agencies, water districts, municipalities, and critical infrastructure organizations throughout the region. We help public sector IT teams build toward Zero Trust as a business outcome — through assessment, architecture, and ongoing operations. If you'd like to talk through where your organization stands, we're happy to start with a conversation.