Some sections of this post were written with the assistance of AI to clarify ideas and improve readability. All opinions and conclusions are my own.

Zero-Trust Is Already Happening

Your VPN goes down at 2 AM. Half your engineering team is locked out. The on-call engineer can’t access the database to diagnose the outage that triggered the VPN failure in the first place. You’re now troubleshooting infrastructure access during an infrastructure incident, a recursion problem that would be funny if it weren’t costing you money and sleep.

This is the perimeter security failure mode we’ve all lived with. One breach, one misconfigured firewall rule, one compromised credential, and you’re either locked out of everything or an attacker is locked into everything. The network perimeter model assumes an explicit inside and outside, but that assumption dissolved somewhere between “everyone works remotely now” and “half our infrastructure is in someone else’s data centre.”

Zero-trust isn’t new; the shift has been underway for years. Google published the BeyondCorp papers nearly a decade ago. The concept is older still (John Kindervag coined the term at Forrester back in 2010). NIST published SP 800-207 defining zero-trust architecture back in 2020. By 2022, the White House issued OMB M-22-09, requiring federal agencies to meet specific zero-trust goals by the end of fiscal year 2024.

That timeline matters. This isn’t a window suddenly opening; it’s an evolution that’s been underway. By 2023, Okta reported that 61% of organizations already had defined zero-trust initiatives and another 35% planned one within 18 months. What I’ve been noticing isn’t adoption starting, but rather where it’s spreading and how the tooling is maturing.

Why Adoption Has Been Uneven

The story of why zero-trust adoption has been uneven isn’t just about technology; it’s about organizational capacity and economic incentives. Vendor lock-in and enterprise pricing created an adoption barrier. Palo Alto, Zscaler, and the incumbents built powerful platforms, but priced them for organizations with dedicated security budgets and teams to match. Mid-size companies often face six-figure commitments or are stuck with their VPN.

But pricing alone doesn’t explain the pattern. There’s a cultural and structural piece that’s harder to quantify. Forrester’s research consistently points to organizational change management and role clarity as primary failure modes, not tooling limitations. Moving from “inside the network means trusted” to “verify everything, every time” requires rethinking how your infrastructure communicates. It means convincing your team that the old mental model - the one where you SSH into a bastion host and then you’re “inside” - needs to be retired. That’s not a technical change; it’s an organizational one.

And there’s the breadth problem. Zero-trust isn’t just about access; it spans identity, devices, networks, applications, workloads, data, visibility, and automation. CISA’s Zero Trust Maturity Model breaks this into distinct pillars because each requires different expertise and organizational alignment. You can’t just “deploy zero-trust”; you need to sequence it, prioritize pillars, measure maturity, and evolve practices over the years.

So zero-trust became something larger enterprises tackled first, after a breach, when compliance required it, or when they had security leadership with enough political capital to sustain a multi-year transformation. Federal mandates accelerated public sector adoption. For everyone else, it’s been a gradual process of figuring out where to start.

Where Tooling Is Improving

Here’s what’s changed over the past few years: the operational barrier is getting lower for specific use cases. Tools like Netbird are rethinking what zero-trust network access can look like when you strip away some of the enterprise baggage, Open-source, self-hosted options that don’t require a dedicated security team to operate. The mental model for ZTNA, zero-trust network access, is more approachable: you’re adding identity-aware access controls on top of what you already have, not replacing your entire infrastructure on day one.

This matters for experimentation. A mid-size engineering team can spin up Netbird, test it with a subset of internal tools, and decide whether the model works for them, without a six-month procurement process or a vendor call. That’s how architectural patterns spread beyond early adopters: through developer-led experimentation, not just executive mandate.

But let’s be realistic about what “getting easier” actually means. Gartner’s 2025 Strategic Roadmap for Zero Trust emphasizes multi-year planning and shows that zero-trust strategies often stall. Legacy systems remain major blockers. Identity management is still the choke point. Okta’s 2024 review shows passwordless adoption is still low, and machine identities are exploding faster than teams can manage them.

The timing of improved tooling isn’t arbitrary, though. Cloud migration has made perimeter security clearly insufficient; your “perimeter” now includes three AWS regions, a Cloudflare edge network, and someone’s laptop at a coffee shop. Remote work normalized the idea that users aren’t on your network. Compliance drivers such as OMB mandates and FISMA requirements drove large-scale adoption in the public sector. The tooling followed the pressure, and now there’s a broader ecosystem of options.

So zero-trust is becoming more accessible, but it’s not suddenly easy. The complex parts - identity management, policy definition, visibility across complex environments, organizational alignment - those haven’t disappeared. What’s changed is that you can start smaller, with better tools, and iterate your way forward rather than needing to boil the ocean on day one.

The Talent Retention Angle

There’s an implication here that technical leaders should take note of: security engineers want to work with infrastructure that aligns with current threat models. The best security talent — the people you actually want building your defences — don’t want to spend their careers nursing VPN configurations and arguing over firewall rules. They want to work with systems that assume hostile networks, that treat identity as the perimeter, that map to how distributed systems actually operate.

This isn’t about chasing trends. It’s recognizing that architectural decisions send signals about how your organization thinks about infrastructure. If your security model still assumes a trusted internal network in 2025, you’re signalling that you’re behind the curve. That compounds over time, the best people leave, the knowledge base stagnates, and you become the company stuck maintaining legacy infrastructure while competitors evolve.

But timing matters here, too. The calculus has been shifting gradually, not suddenly. As zero-trust tooling matured and adoption spread, the expectation baseline changed. The cost of adopting zero-trust has been declining over several years, while the price of not adopting it, in terms of security posture, compliance requirements, and talent appeal, has been rising. We’re in the middle of that transition, not at the start.

What the Maturation Process Actually Requires

But let’s be honest about what improved tooling doesn’t solve. Deploying ZTNA is one piece of a much larger puzzle. The more complex work is organizational, getting your team to internalize that “trusted network” is a fiction, that every request needs authentication and authorization, and that the old shortcuts don’t apply anymore. That takes time, and it takes leadership that understands why the shift matters.

It also requires answering some uncomfortable questions: How much of your current security posture depends on obscurity rather than actual controls? What happens when you can’t rely on “they’re on the VPN, so they’re trusted”? Who on your team actually understands your current authentication flows well enough to migrate them? Which legacy systems can’t participate in modern identity protocols, and what do you do about them?

And there’s the sequencing problem. As John Kindervag emphasises, zero-trust is a process, not a project. You can’t flip a switch. Most organisations start with identity and access, then layer in device posture, network segmentation, data protection, and continuous monitoring. Each pillar requires different capabilities and organizational alignment. NSA and CISA guidance on the visibility and analytics pillar alone shows the depth required, you need to see what’s happening across your environment before you can enforce granular policies effectively.

Zero-trust isn’t a silver bullet, it’s a different set of trade-offs and a multi-year commitment. You gain resilience, granular control, and better auditability, but you take on the operational overhead of managing identity and policy across every service, device, and data flow. The tools are better than they were five years ago, but they’re not magic. You still need to think through your threat model, still need to train your team, still need to maintain the discipline and visibility that makes zero-trust actually work.

Where This Leaves Mid-Size Organizations

So the question isn’t whether zero-trust is the right technical direction, for most organizations dealing with distributed systems, remote work, and modern compliance requirements, it is. The question is where you are in the adoption curve and what your next step should be.

If you’re a technical leader evaluating this in 2025, you’re not early. You’re also not impossibly late. Tooling has matured enough that you can start with network access, identity, or specific high-value resources without needing to rearchitect everything. Federal mandates and industry adoption mean you can learn from others’ implementations. Developer-friendly options mean you can experiment before committing to enterprise platforms.

But you’re also not entering a temporary window that will close. This is an ongoing evolution, and the organizations that succeed treat it as such, as a program that spans years, not a project that ends. The decision isn’t just about deploying a new tool. It’s about whether your organization is ready to change how it thinks about trust, and whether you can sustain that commitment through the messy middle of the transition.

The hard questions remain: Do you have the organizational capacity to drive this change? Can you sequence the work realistically given your resources and constraints? Who owns identity, device management, policy definition, and enforcement across your organization? What does success look like in one year, three years, five years?

If you can answer those questions and commit to the process, the tooling will support you. If you can’t, better tooling won’t save you.