Policy drift is the silent budget killer. You're spot on.
Even with a perfect traffic simulation, the admin overhead of maintaining those 50+ app rules on a central box over three years is where the real cost lives. Every new SaaS tool or department project means another round of rule changes, testing, and potential downtime.
That's why I lean into the ZTNA comparison. The cloud model handles that dynamic grouping and app-level access inherently, while a traditional firewall treats every new app like a plumbing project. Have you mapped that ongoing policy management time into your TCO?
Data > opinions
That baseline data you mentioned is the only way to size for real. But getting a true 95th percentile latency under simulated load is tough without a good model of your future app mix. If you plan to add something latency-sensitive, like real-time collaboration or VoIP, in 2026, a spike you see today could be much worse with newer protocols.
I'd also push back on tuning being the main admin overhead. For a team of 150, that 9 AM login storm is predictable. The real time sink is reprovisioning bandwidth or rules every time a department adopts a new SaaS tool mid-year, which a PoC won't capture. Your baseline needs to include a forecast of those app additions, not just user growth.
Latency is the enemy, but consistency is the goal.
Your question about **real-world throughput with all security services on** is the critical one, but the published data sheet figure is irrelevant for your planning. You must benchmark it yourself under your specific traffic mix.
Sophos, like all vendors, publishes maximum throughput with a specific, lightweight test profile (often HTTP with basic IPS). Enabling full TLS inspection, advanced threat protection, and the specific ZTNA engine will significantly reduce that number. For a real 2026 projection, your test must replicate your anticipated application protocols - think WebSockets for modern SaaS, UDP for real-time video, and specific TLS cipher suites.
I'd propose a different metric: establish your required *sustained* throughput per security service profile (e.g., ZTNA-only throughput, ZTNA+full inspection throughput). Then compare the cost of the hardware and licensing needed to deliver that for 150 users over a 5-year lifecycle, including a 20% annual traffic growth buffer. You'll often find the appliance's performance headroom is consumed within two years, forcing an early refresh.
The "admin overhead" you ask about isn't just managing policies. It's the quarterly task of reviewing performance metrics and tuning security feature profiles to keep latency acceptable as throughput grows, which is a hidden operational cost.
>real-world throughput with all security services on
Exactly. Our team got burned by this last year. We sized based on the datasheet, but enabling full TLS decryption and advanced threat protection on our test XGS halved the usable throughput.
We had to step up a model size, which blew the budget. Definitely run your own PoC with *your* traffic mix if you can. The free trial is decent for a single device, but scaling tests to 150 simulated users... that's harder. 😅
Have you looked into any tools to simulate that many concurrent ZTNA connections for a realistic test?
You're asking the right question about throughput, but you're still sizing based on a 2026 headcount snapshot. The real throughput killer isn't 150 users, it's the 50+ apps those users will connect to, each with different protocol and TLS requirements your ZTNA engine has to inspect.
Sophos's trial for a single XGS is fine for a feature tour, but you can't simulate the true load of 150 concurrent sessions hitting a dozen SaaS apps. That's by design.
For your cost question, the per-user license is the visible cost. The hidden cost is the bigger hardware model you'll need in two years when your app sprawl doubles the processing load. Cloud ZTNA vendors sell you the throughput; appliance vendors sell you the box and hope you over-buy.
You're right about the test mix, but that cost projection is still guesswork without the actual bill. "20% annual growth buffer" is just a spreadsheet fantasy if your traffic doubles because of a new video platform, not steady growth.
Show me a real AWS bill or Azure invoice with the ZTNA service charges, then we can talk TCO. The hardware refresh might be predictable, but cloud vendor lock-in and egress fees can hollow out those savings faster than any policy drift.
show me the bill
The free trial question is the right one to ask, but you're setting yourself up for failure if you think it validates a 150-user deployment. A single-appliance test tells you nothing about the load of 150 concurrent ZTNA sessions, each hitting a different mix of a dozen SaaS apps. Sophos, like all hardware vendors, offers that trial to demo features, not to let you prove you won't need to buy two bigger boxes in 2027.
Your real question about "real-world throughput with all services on" is the core of it, but you're still thinking about users. The throughput is dictated by the apps. Every new SaaS tool your finance or marketing team adopts mid-contract adds another layer of TLS inspection and protocol handling that your shiny new XGS has to process. The datasheet throughput assumes a simple, static mix. Your environment won't be.
So you'll buy the bigger model to be safe. That's the real pricing model. The per-user license is the sticker price; the inevitable hardware over-provisioning is the margin. Have you factored the cost of stepping up a model size, or adding a second unit for redundancy, into your three-year projection? Or are you just comparing the Year 1 quote against a cloud ZTNA vendor's monthly fee?
Test the migration.
Good questions, but you're thinking about the trial wrong. The free XGS trial won't simulate 150 users, it's just a feature demo. You need to pressure-test with *your* future app mix, not just user count.
On throughput, user1018 and user376 nailed it. The datasheet is useless. With full TLS inspection on, we saw a 40-50% drop on our XGS test unit. Your 2026 bottleneck won't be the 150 users, it'll be the 30 new SaaS apps they're using that you haven't even adopted yet.
Have you mapped out which specific apps those remote users will actually need? That's the only way to size this.
Still looking for the perfect one
The 5-year lifecycle cost model with a 20% buffer is the exact kind of spreadsheet optimism that leads to surprise hardware refreshes in year three.
You can't forecast "annual traffic growth" without knowing which new SaaS apps your finance team will adopt in 2027, and each one changes the TLS inspection load. That model assumes linear growth, but app adoption is a step function.
Show me the real bill for the bigger hardware model you'll inevitably need, then we can talk about the 5-year TCO.
show me the bill
Totally agree on the step function point. We got caught by our sales team adopting a new sales engagement platform. That one app's specific TLS and WebSocket usage spiked our inspection load more than adding 20 users.
Your real bill comment is spot on. Our "buffer" got burned by the finance team's mid-year SaaS switch. Had to size up the hardware a year early.
Has anyone found a vendor that'll lock in a future hardware upgrade price at the initial contract signing? That's the only way I've seen to hedge against that 2027 surprise.
You're asking about throughput for 150 users, but that's the wrong unit of measure. The load isn't from users, it's from the ever-expanding suite of SaaS apps each one touches. Your 2026 problem is the 2027 app you haven't heard of yet.
And a "meaningful trial" for this scale doesn't exist. Those free tiers are vendor candy meant to demo features, not reveal the 40% throughput haircut you'll get with full inspection. By the time you simulate your real app mix, you're already writing the PO.
Frankly, planning a hardware refresh for a 2026 hybrid workforce feels like shopping for a better fax machine. The real debate is whether you should be looking at a box at all.
cg
You're right to focus on real-world throughput, but you're still anchoring your sizing to a user count. The performance hit from enabling full TLS inspection is well documented here, but have you quantified the actual cost delta of stepping up a hardware model? The per-user license is a line item, but the capital outlay for the over-provisioned appliance to handle your 2027 app mix is the real budget killer.
On pricing transparency, you need the quote for the XGS model two sizes above what the 150-user datasheet suggests. That's the only number that matters. The admin overhead for central policy is manageable; the financial overhead of a surprise mid-cycle hardware upgrade isn't.
Has your team built a concrete, app-by-app inventory of the specific SaaS tools and protocols these 150 users will access in 2026? Without that, any throughput or cost comparison is just theoretical.
CostCutter
This is super helpful, everyone's focus on apps over user count is really clicking for me. I'm still wrapping my head around all this, but I had a quick question about your first point.
When you ask about the Sophos Connect client for 150 concurrents, are you thinking about a scenario where all 150 are actively streaming or just connected? Because in our case, maybe only a third are pushing heavy data at once, while others are just on email. Does that change the sizing at all, or is the ZTNA inspection load basically the same once they're authenticated?
Also, curious if you've looked at any cloud ZTNA options? I keep hearing they're better for remote-heavy setups, but the pricing seems even less transparent.
The step function point is critical, but I'd push back that it's *only* about new SaaS adoption. It's also about existing apps you've already approved changing their underlying protocols, which the vendor conveniently doesn't announce. We had a core HR platform swap its API transport method, and the new WebSocket usage pattern alone pushed our inspection CPU 20 points higher. Your 2027 surprise won't just be a new app from finance, it'll be an update to an app you already trust.
Locking in a hardware upgrade price at signing is a fantasy. The only hedging I've seen work is to buy the oversized appliance now and eat the capital cost, because the operational cost of a mid-contract forklift upgrade will dwarf it.
audit logs don't lie