Replacing your VPN with Cloudflare Access for a small team

Most small teams end up with a VPN not because someone chose it, but because it was the only answer anyone knew to “how do people reach the internal app from home.” So a box gets installed, everyone gets a client, and for a while it works. Then the friction accumulates: the client that will not connect on hotel Wi-Fi, the credentials that grant a laptop the run of the whole network, the licence renewal, the person who left three months ago whose access nobody is sure was removed.

There is a different model now, and for a small team with a handful of internal tools it is often simpler to run than the VPN it replaces. This is a practical look at what changes, what it covers, and what it does not.

What a legacy VPN actually does

A traditional VPN puts a device onto your private network. Once connected, the laptop is treated as if it were plugged into the office wall. That is the core of both its convenience and its problem.

The convenience is that everything internal becomes reachable at once. The problem is the same sentence: everything internal becomes reachable at once. A VPN authenticates the connection, then largely trusts whatever happens over it. If a laptop is compromised, or a login is phished, the attacker is not on one app — they are on the network, able to scan for and reach anything else on it. The model is “verify once at the front door, then trust the whole house.”

For a small business that adds up to real cost and real exposure: client software to maintain on every device, a concentrator to keep patched, broad access that is hard to scope down, and offboarding that means remembering to pull a VPN certificate along with everything else.

The zero-trust idea, without the jargon

Zero trust inverts the model. Instead of trusting the network and guarding its perimeter, you trust nothing by default and check every request against who is making it and what they are allowed to reach. There is no “inside the network” to be on. Each application is protected individually, and access to one grants nothing toward the others.

In practice this means a request to your internal app is evaluated on its own: Is this a known person from your identity provider? Are they in the group allowed to use this app? Does their device meet your conditions? Only then does the request go through — and only to that app.

How Cloudflare Access works

Cloudflare Access sits in front of your applications and enforces identity before any request reaches them. The mechanics are worth understanding because they explain why it removes so much of the VPN’s overhead.

Identity comes from what you already use. Access connects to your existing identity provider — Microsoft Entra ID, Google Workspace, and others — so it is the same login and the same multi-factor prompt your team already knows. You do not maintain a separate user directory.

Policies decide who reaches what. You write rules per application: this group can reach the internal dashboard, that contractor can reach only the one tool they were hired to use, and access can require multi-factor or be limited by country. The rules are readable and specific, which is what makes least-privilege access practical rather than aspirational.

Web apps need no client at all. For anything that runs in a browser — an internal dashboard, a wiki, an admin panel — the user just visits the URL, gets sent to your normal login, and lands on the app. There is no VPN client to install, configure, or troubleshoot. This alone removes the support burden that makes VPNs painful for non-technical staff.

Your apps do not need a public IP. Paired with a lightweight connector (Cloudflare Tunnel), the application makes an outbound connection to Cloudflare and is never directly exposed to the internet. There is no open inbound port for anyone to scan or attack. The app is reachable only through Access, only by people who pass policy.

Offboarding is one place. Because Access uses your identity provider, disabling the person’s account there cuts their access to every protected app at once. There is no separate VPN certificate to remember. That single point of control is one of the quiet reasons the model suits small teams, and it pairs naturally with keeping devices centrally managed — we wrote about what managed devices involve.

What it covers, and what it does not

This is the honest part, because Access and a full VPN are not identical tools and pretending otherwise leads to a bad rollout.

Access covers the common case well: browser-based internal apps, and — with the WARP client on the device — SSH, remote desktop, and other private services scoped per application rather than per network. For most small teams, “let staff reach our few internal tools securely from anywhere” is exactly this, and it is where Access is strongest.

A full VPN still does some things Access is not shaped for. If you have an application that expects a device to sit on a specific internal subnet, or legacy software that assumes broad flat-network access, or a need to route all of a device’s traffic through one place, those are cases to map carefully rather than assume. Cloudflare has a broader networking layer for site-to-site and full private-network connectivity, but that is a design conversation, not a swap. Some of it overlaps with how you think about your wider infrastructure, which is where these decisions are best made together rather than piecemeal.

The right framing is not “VPN versus Access” as a religious war. It is: list the things people actually need to reach, and for each one pick the least-privilege way to allow it. For a small team, that list is usually shorter than expected, and most of it fits Access cleanly.

A sane rollout

You do not migrate everything on a Friday and hope. A calmer sequence:

1. Inventory what people reach over the VPN today — every internal app, service, and share, and who uses each.
2. Start with one browser app. Put a single internal tool behind Access, connect your identity provider, write the policy, and let one group use it. This proves the login flow and the group logic with low stakes.
3. Add applications one at a time, running Access alongside the VPN so nothing breaks while you migrate.
4. Handle the non-web services — SSH, RDP, private hosts — with the client-based path once the web apps are stable.
5. Retire the VPN only when the inventory is empty, and confirm each item is reachable the new way before you turn the old one off.

Done this way, the team barely notices the change except that the connect-first ritual disappears and logins become the same identity prompt everywhere.

Where to start

If your team is small, mostly reaches a few internal tools, and the VPN has become a source of tickets rather than confidence, this is usually a good trade — less software to maintain, tighter access, and offboarding in one place. If it is more tangled than that, the inventory above is the honest first step before committing to anything.

If you want a second pair of eyes on it, send us two paragraphs about what your team reaches remotely today and what has been frustrating about it, and we will reply in writing within one business day.