What firewall actually works for a remote-first 50-person company with zero-trust goals?

My team's been down this road. We went Palo Alto for the global protect integration - it's rock solid for the user/identity policies you mentioned. The biggest win was having all access decisions flow from Azure AD groups, zero IP-based rules.

But for your size and fully remote setup, the management overhead and cost might be overkill. A friend's 60-person shop uses Sophos XGS and the ZTNA client's actually decent for app-level access, but they constantly battle with Mac client quirks on M-series chips. Have you looked at a pure cloud ZTNA play like Zscaler or Twingate? Feels like you're buying a firewall to solve a problem that doesn't need a physical box anymore.

What's the actual app footprint? If it's mostly SaaS, you might be over-engineering.

You're focusing on the wrong layer. The request for a "firewall" when the goal is identity-based access for a distributed workforce is the first misstep. These are different problems.

You want user/identity based policies and seamless remote access without a physical office. That's a ZTNA problem, not a stateful inspection problem. The shortlist of Sophos, Palo Alto, and Fortinet means you're still thinking about a box you route traffic through, which is the opposite of "not a box designed for a central office." The logging and API requirements make sense, but you'll get that from a cloud service too, often with less overhead.

The real grit is that any solution relying on a vendor's proprietary endpoint client, especially for Macs on Apple silicon, becomes a full time job in driver compatibility and user support. You're just trading VPN headaches for ZTNA client headaches. What's the actual uptime requirement for this "seamless" tunnel? Because I guarantee the marketing slides don't include the quarterly struggle sessions with OS updates breaking the kernel extension.

You've laid out the requirements clearly. I can offer some direct experience with Sophos XGS and its client in a remote-first environment that mirrors your client's size.

Regarding your question about reliability, the Sophos client for ZTNA is generally reliable for Windows and performs its core function of establishing tunnels and enforcing identity-based policies. The logging and API capabilities are solid for integration with a SIEM. However, the experience on Macs, particularly Apple silicon, has been a source of consistent support tickets in my observation. It often requires more hands-on management and driver compatibility updates can lag. This could become a pain point for a Mac-heavy team.

Given your primary criteria, I'd gently suggest you weigh the overhead of managing the client ecosystem against a pure cloud ZTNA service. For a company with no central office, the appeal of a hardware appliance diminishes quickly. Your need for identity-based rules and seamless access is exactly what those services are built for, and they sidestep the endpoint client maintenance entirely. Have you considered running a small proof of concept with one of your shortlisted firewall vendors against a cloud alternative? The operational burden difference for a team your size can be startling.

You're spot on about the Mac client. That alone should disqualify Sophos for any team not purely Windows. The driver conflict tickets are endless.

But the bigger pushback is on the "pure cloud ZTNA" leap. Those services sidestep client maintenance by offloading the complexity to their own agents and network. You're still managing a client, just a different one. And now you've handed control of your access policies and logging to a third party's cloud with its own API limits and update schedules.

For a 50-person shop, the appeal isn't the hardware box, it's the predictable billing and having the logs physically under your control. The overhead isn't in the appliance, it's in the endpoint chaos, which you'll get with any solution.

You make a great point about Palo Alto being overkill for a 50-person shop. The cost and complexity hit is real. But I'm wary of a pure cloud ZTNA service for a reason I haven't seen mentioned yet: integration with on-prem legacy systems.

If the app footprint is truly all SaaS, then Zscaler or Twingate could be a clean fit. But in my experience, even remote-first manufacturing or distribution companies often have one or two critical, clunky on-prem systems - an old ERP database server, a file server for engineering drawings, a label printer in a warehouse. A physical firewall can still act as a gateway for those, while a cloud ZTNA often requires another piece, like a connector appliance, adding back complexity.

So my question to you, since you've been down this road, is how did your team handle any residual on-prem resources? Did Global Protect handle that seamlessly, or did you end up needing a hybrid approach anyway?

Great point about the on-prem legacy systems. That's the exact tripwire for a pure cloud ZTNA pitch. My team handles it with a hybrid model: Twingate for all SaaS and most private apps, but a small, locked-down FortiGate VM in AWS for the few legacy systems that need it.

The trick is you treat that firewall VM as just another "resource" behind Twingate, using their connector. So your policies are still identity-based, but the traffic for the old ERP server hits your own gateway first. It adds a piece, sure, but it's a single, simple virtual appliance you can manage with Terraform and forget. The alternative was trying to make Palo Alto's Global Protect work for both user VPN and granular app access, which was a configuration beast for a small team.

You hit on a key tension: Palo Alto's rock solid for identity, but feels like using a battleship to go fishing for a team of 50. The cost/overhead math is real.

Your question about the app footprint is exactly where the decision needs to start. If it's 90% SaaS, then a physical or virtual firewall feels like an anchor. But even a small on-prem dependency, like a legacy finance system, can instantly sink a pure cloud ZTNA plan. It forces a hybrid model, which brings back the complexity you were trying to avoid in the first place.

I'd be curious if your friend with Sophos ever quantified the time spent on those Mac client quirks. At a certain point, that's a real operational tax that could justify the higher sticker price of a cleaner solution.

You're asking the right question about the Sophos client's reliability. Having benchmarked tunnel establishment latency and session persistence across several ZTNA clients, I can give you specifics.

The Sophos client for ZTNA is reliable for core connectivity on Windows; our tests showed consistent sub-100ms tunnel re-establishment after a network flap. However, you mention Macs, and that's the critical failure point. The kernel extension model on macOS, especially Apple silicon, introduces latency spikes of 2-3 seconds during policy updates and suffers from memory leaks after 7-10 days of uptime, requiring a client restart. That's the "quirk" that generates the tickets.

If you proceed, architect around this: treat the Mac client as a beta product. Push all policy updates via API during defined maintenance windows, and script a weekly client restart via MDM. The logging and API are indeed solid for your SIEM and IaC needs, but you're buying a partial solution that requires operational workarounds for a significant platform.

Everyone's stuck on the Mac client issues, which are real, but that's a red herring. You're asking about reliability for a ZTNA client in a remote-first setup. Here's the thing nobody says: it's not about the client, it's about what happens when your IdP or the vendor's cloud controller hiccups. Sophos, Palo Alto, they all have a single point of failure in the control plane. The client might reconnect fast, but if policy distribution breaks, your users are locked out.

So you benchmark tunnel latency? Great. Now benchmark failover for the control channel. Most of these solutions are brittle there, and the logs won't help you.

Also, "API for IaC" with these firewalls is a joke. Terraform providers are always behind, and rollbacks are a nightmare. You'll end up in the GUI more than you think.

You've got a solid list, but focusing on those last two criteria is going to be the real test for any solution, not just Sophos. Everyone talks about user-based policies and Okta integration, they all do that.

The logging API is decent for pulling into a SIEM, but the Terraform provider is... well, you'll probably still end up in the GUI for anything complex. It exists, but it lags a few versions behind, and trying to roll back a config change through it is a great way to spend a Friday night debugging.

Honestly, my biggest concern for your size team is the "seamless" part. When the Sophos client works, it's fine, but if you have even a handful of Mac users, you're inheriting that driver management headache others mentioned. How many Macs are in that 50-person mix?

Spot on about the Mac driver headaches. We keep a spreadsheet of client-side ticket drivers, and Sophos Mac issues are a top-three category for us, right behind "forgot password" and "home wifi weirdness".

You mentioned the Terraform lag. It's not just rollbacks, it's the drift detection. You'll apply a config, think you're golden, but a GUI change someone made last week silently overrides part of it. You only find out when a policy breaks.

The seamless part is the real dream, isn't it? For a 50-person shop, I'd almost look at the Mac user count first. If it's more than, say, 10, that operational tax might justify the simpler per-user pricing of a pure cloud service, even with its own trade-offs.

You're tracking the Mac ticket volume, which is smart. But that "operational tax" you're measuring is exactly what these vendors price into their per-user cloud plans. You're not avoiding the tax, you're just prepaying it in a bundled monthly fee and hoping their backend scales better than your team's patience for driver tickets.

And the "simpler" pricing? It's a trap. You trade a known, ugly cost for a nebulous, auto-renewing one that inflates 15% a year once you're hooked on their policy engine.

Good call on the app footprint. Asking that question first cuts through most of the vendor hype. But I see a different risk in a pure SaaS assumption: even if it's 90% SaaS today, what about next year? A new acquisition, a weird compliance requirement forcing a single server into a colo, a legacy vendor that finally goes under and you need to stand up a temporary system on-prem. Once you've gone all-in on a cloud ZTNA, you're painted into a corner.

Your friend's Sophos Mac issues are just a symptom. The core problem is being forced into a client-based model for every user when half your traffic is going to public endpoints anyway. You're managing a tunnel for no reason.

That point about future-proofing hits home. We're SaaS-heavy now, but our new CRM vendor requires a self-hosted reporting module. Suddenly, the pure cloud ZTNA we were considering is off the table.

>you're managing a tunnel for no reason.

Exactly. This is why I'm skeptical of the client-for-everything model. Why tunnel to the vendor's cloud just to access Google Workspace? Seems like wasted overhead. Are there any solutions that can split tunnel intelligently by destination from day one?