How to connect office, cloud servers and remote employees securely.

Start with requirements, not products

Every secure-access conversation should begin with a small set of unglamorous questions. Where do users connect from? What resources do they actually need to reach? What sits on cloud platforms, and what sits in your office rack? How sensitive is the data, and what is the realistic cost of an outage? These answers shape the architecture far more than any vendor brochure.

A common mistake is the reverse — picking a VPN product first and then trying to fit the network around it. The product may be excellent, and it can still be the wrong fit for how the business actually works.

Three places where business resources live

For most growing companies, internal resources end up in one (or more) of three places:

• Office server rack — physical servers in the office, virtualized with VMware, Proxmox, or another platform. Often used for file shares, internal databases, ERPs, and legacy line-of-business applications.
• Cloud platforms — AWS, GCP, Azure, or smaller providers hosting business applications, replicas, backups, or whole production environments.
• Hybrid — a mix of both, often by accident more than by design.

The architecture is different in each case. An office-only design typically centers on a firewall and VPN concentrator at the edge. A cloud-only design pushes more of the security perimeter into the cloud platform itself. Hybrid designs need to handle traffic that may cross both worlds inside a single user session — and that is where most architecture mistakes happen.

The remote access decision

“Should we use a VPN, or move to a zero-trust model?” is one of the most common questions we get. The honest answer is that the right choice depends on:

• How many users you have, and how that is likely to grow.
• Whether you control the endpoints (managed laptops vs. BYOD).
• The mix of internal-only apps vs. cloud apps that already enforce SSO.
• The sensitivity of what sits behind the access boundary.
• Your team's operational capacity to run the chosen model day to day.

Vendors like Fortinet, Palo Alto, and Cloudflare all sell credible solutions in both camps. None of them is universally right. We have recommended each of them in different customer environments — driven by what the business actually needs to support, not by what is currently fashionable.

VPN vendor choice is an architecture decision

Treating VPN selection as a procurement decision — “let's just choose the most popular vendor” — is a frequent source of long-term pain. The vendor choice depends on the firewall architecture, the support model, the placement of resources between cloud and on-premise, and the user model.

A small example: if 80% of your users only ever touch cloud applications that already sit behind SSO, deploying a heavyweight site-to-site VPN for everyone is overkill. A zero-trust style brokered access — or even just well-designed conditional access policies — may serve you better, at lower operational overhead. The opposite is also true. If your most sensitive applications still live on an office rack, a traditional VPN with strong segmentation and policy may be the right call.

Designing the security perimeter

Whatever the access model, the goal is the same: internal resources must be reachable by authorized users, and only by authorized users — never by the open internet. That means:

• The internet edge blocks inbound by default, allowing only what is explicitly justified.
• Remote access terminates at a controlled entry point — VPN concentrator, ZTNA broker, or cloud proxy — not directly on the servers themselves.
• Internal segmentation limits lateral movement. A compromised laptop should not have line of sight to every server.
• Cloud resources follow the same logic: private subnets, security groups, no public IPs on internal services.

None of these ideas are exotic. They are the things that distinguish a network that quietly serves a business for years from one that needs an emergency redesign after the first incident.

A practical example

Consider a 25-person company: half in the office on hybrid schedules, half fully remote. Some applications live on an office rack (file share, ERP). Some live in AWS (CRM, custom backend). Email is in Google Workspace. The design we would typically recommend looks something like:

• A capable next-generation firewall at the office edge, terminating VPN for remote users and enforcing policy between zones.
• The office rack on a private VLAN behind the firewall, with explicit allow rules for which user groups can reach which server.
• AWS resources in private subnets, reachable from the office via a site-to-site tunnel and from remote users via the same VPN — so the user experience is consistent regardless of where they sit.
• Email and other SaaS handled by SSO with conditional access, not routed through the VPN.
• Office Wi-Fi segmented into corporate and guest networks, with corporate authenticating against the same directory.

None of this is revolutionary. The value of the design is that each decision is justified by a business reason — and the team running it knows why each rule exists when something needs to change.

A good secure-access design is not the one with the most features. It is the one your team can still explain in six months.

Common mistakes to avoid

• Choosing a VPN before understanding the user model.
• Exposing internal services directly to the internet “just for now.”
• Treating cloud and on-premise security as two unrelated projects.
• Skipping segmentation because “we're small.”
• Deferring documentation, which makes every future change risky.

Closing

Secure connectivity for hybrid teams is rarely about choosing a single product. It is about understanding where your resources live, who needs to reach them, what the operational model can realistically support, and then designing an architecture that ties it together. The result should be a network that is secure, easy to operate, and ready to scale.