I’m sure your VPN is doing exactly what it was designed to do. Sure, there are occasional connection problems, authentication failures, and somebody who can't get their laptop to cooperate, but that's just another Tuesday in IT. Everything else is smooth as molasses in summertime
So why are we talking about replacing it? Because the problem isn't necessarily your VPN. It's everything your security team has to manage around it. Employees work from everywhere and anywhere, applications are scattered across cloud providers, and contractors come and go. Meanwhile, your security team is supposed to manage access, handle incidents, maintain compliance, and figure out what the hell everyone is doing with AI.
They probably have plenty of free time for a major infrastructure project, right?
Traditional VPNs establish a secure connection to a private network, authenticate the user, and the network's security controls determine what they can get to. That worked pretty well when most applications lived inside a corporate network and employees worked from an office. But that's not how shit is done anymore.
Your accounting system might be SaaS. Your customer information lives in a CRM somewhere else. Engineering uses another collection of tools, HR has its own systems, and somebody in Marketing just subscribed to a new service without telling IT. The network perimeter isn't exactly where it used to be.
Zero Trust approaches the problem differently. Instead of treating a connection to the corporate network as a reason to trust someone, access decisions are made around the specific resources they're trying to use.
NIST describes Zero Trust as removing implicit trust based on network location and focusing access decisions on individual resources. It's a different way of thinking about security, not a magic product.
And it doesn't mean your existing VPN is insecure. A properly configured VPN with MFA, network segmentation, and access controls can be perfectly reasonable. The question is whether it's still the best way to manage access across your evolving environment.
Let's use Cloudflare as an example, since it provides the components needed for many common VPN replacement scenarios.
Cloudflare Access controls access to protected applications based on identity and policies. Rather than giving someone general network access and relying entirely on internal controls, you can define which applications they're allowed to reach.
Cloudflare Tunnel connects private applications and networks to Cloudflare through outbound connections. That means you don't necessarily need to expose inbound ports on your firewall just to make an internal application available to authorized remote users.
Then there's the Cloudflare One Client, formerly WARP, which runs on employee devices and can route configured traffic through Cloudflare while providing information about the device's security posture.
Depending on the environment, Cloudflare Gateway adds DNS, network, and HTTP traffic controls, including capabilities for monitoring and restricting access to external services. Those components can replace a substantial amount of what traditional remote-access VPN infrastructure does.
Cloudflare Zero Trust connectivity between a remote user and a private application. Source: Cloudflare, Replace Your VPN learning path.
But notice something. We haven't eliminated the work. Someone still needs to configure identity providers, define access policies, establish device requirements, and connect applications. They also need to understand existing routes, DNS dependencies, and those legacy systems nobody wants to touch because they work and nobody remembers why.
Cloudflare's own documentation points out that connected devices may initially reach an entire private network unless additional restrictions are configured. The technology enables granular access. It doesn't make the decisions for you. Someone still has to design, implement, test, and maintain those policies.
This is the part of technology projects that doesn't always get the attention it deserves. Everybody likes the implementation. There's a project plan, milestones, testing, a cutover date, and hopefully somebody remembers to schedule a Go/No-Go meeting. Exciting stuff.
Then the project finishes. And somebody has to run the damned thing.
Employees join and leave. Contractors need temporary access. People change departments, devices fall out of compliance, applications move, and somebody inevitably needs an exception because their situation doesn't fit the policies everyone agreed to.
I've seen firsthand how easily something like this gets mucked up. At one company I worked for, we switched vendors on a project. We went through the transition, reviewed everything, and the changeover went smoothly. High fives all around.
About three months into the new vendor contract, I noticed someone accessing a file from a domain I didn't recognize. That got my attention, so I started digging.
It turned out to be someone from QA who had originally joined the project as an independent contractor and was later hired by our previous vendor. His original account had never been disabled because he was still working on the project. When we switched vendors, that account wasn't included in the transition review.
Nobody did anything wrong. The account just fell through the cracks, leaving an access point none of us knew was still there. That's the bullshit that keeps happening if nobody is responsible for reviewing access after the project is finished. It's also proof that security problems don't stop happening just because you've modernized the access infrastructure.
None of that is an argument against Zero Trust. It's an argument for understanding the enormous load of work you're taking on.
If your organization has a well-staffed security team with the expertise and capacity to operate the environment, managing it internally may be the right choice. But what if your security team is already buried?
Replacing a VPN with Zero Trust and handing all the ongoing responsibilities to the same overworked people doesn't really solve the staffing problem. You've improved the access architecture and you’ve added to their workload.
That's where managed Zero Trust becomes interesting.
A managed Zero Trust provider doesn't eliminate your organization's security responsibilities. What it can do is take on the specialized work of implementing, monitoring, and maintaining the access environment.
Instead of expecting your internal team to become experts in every component of Cloudflare, you can work with people who already operate it regularly. Your organization still makes the risk decisions and determines who should have access. It just doesn't have to perform every technical task involved in enforcing those decisions.
Of course, the word managed deserves some scrutiny. Does the provider monitor the environment? Who handles access changes? What happens when something breaks outside business hours? Who investigates suspicious activity? Who approves exceptions? How quickly are incidents escalated?
If the answers aren't clear, you haven't eliminated the ownership problem. You've just moved it somewhere else. A good managed service should make those responsibilities easier to understand, not harder.
Let's say you've replaced your VPN, established application-level access controls, and everything works as intended. Awesome.
Now somebody in Fundraising decides to use an AI assistant to prepare a donor outreach campaign. Nothing unusual about that. But what happens when the assistant starts working with donor information?
The employee has legitimate access to the donor management system. They need that information to do their job. Does the AI assistant need access to every donor record the employee can see? What about addresses, donation histories, financial details, or information belonging to donors outside that employee's responsibilities? And if an AI agent retrieves information it shouldn't have, can you determine what it accessed?
Those are different questions from whether the employee was authorized to connect to the application. A secure connection doesn't automatically mean every use of the information behind it is appropriate.
Cloudflare provides tools that can help organizations discover the SaaS and AI applications employees are using, restrict access to certain services, and inspect supported traffic for sensitive information.
But network and application security don't necessarily tell you which individual records an AI agent retrieved from an internal data platform, or whether those records were appropriate for its assigned task. For that, you need controls closer to the data itself.
This is where access security and data governance start to make sense together.
Cloudflare can help determine who or what is authorized to reach an application. But once they're connected, different questions come into play. What information can they retrieve? Are certain fields restricted? Can you establish which policies were applied and what information was returned?
Spitfyre's approach is interesting because it treats those as connected problems rather than separate projects. Their architecture combines Cloudflare-based access security with a governed data foundation. The idea is to establish identity and secure connectivity, then apply policies to the data being requested, with records of the activity.
An approved AI model or agent can be treated as a governed reader rather than being handed unrestricted access to whatever systems it can connect to. That doesn't mean every existing application magically gains record-level access controls. The actual protections depend on how the data and applications are integrated. But it's an approach I like.
One thing I've learned from managing technology environments is that what people think is running and what's actually running aren't always the same thing.
There's the documented architecture. And then there's the real environment, complete with temporary exceptions that became permanent, applications nobody remembered to retire, undocumented dependencies, and that one system Gary built that nobody dares touch because nobody knows how it works.
A VPN migration is a good opportunity to discover those surprises before they become production incidents. Which applications depend on the VPN? Are permissions broader than necessary? What AI tools are employees using, and what information can they reach?
You don't need every answer before starting a Zero Trust project, but you should know which questions to ask. That's why an assessment makes sense before jumping into a migration.
Spitfyre offers an Access and AI Exposure Assessment intended to identify concerns, and provide findings and a roadmap for what to address. It's a reasonable starting point for an organization that knows its existing approach needs work but doesn't have the spare capacity to figure everything out on its own.
Can Zero Trust completely replace our VPN?
For many remote-access scenarios, yes. But it depends on your applications, network architecture, and connectivity requirements. Some legacy systems and site-to-site connections may need different solutions or a gradual migration.
Do we need to hire a Zero Trust specialist?
Not necessarily. You need the expertise somewhere, but it doesn't have to be a permanent addition to your staff. A managed provider can handle agreed technical responsibilities while your organization retains control of its policies and business decisions.
Does Zero Trust stop employees from using unauthorized AI tools?
It can help. Depending on the tools and configuration, organizations can discover application usage and restrict access to particular services. But blocking an AI website isn't the same thing as governing what approved AI applications can do with company information.
If we use a managed provider, who's responsible when something goes wrong?
That should be answered before you sign anything. The agreement needs to define monitoring, incident response, escalation, policy changes, and which responsibilities remain with your internal team.
The Technology Changes. The Responsibility Doesn't.
Replacing your VPN with Zero Trust can give you more precise control over who and what can reach your systems. But someone still has to run it, maintain the policies, and respond when things go wrong. If your security team already has more work than people, that's the conversation worth having before the project starts.
Because the goal shouldn't be to replace one system with another system nobody has time to manage. It should be to make access more secure, more manageable, and a hell of a lot less dependent on everybody finding a few extra hours in the day.
References and Research Sources