Hey folks! 👋
As our company shifted to fully remote-first, we hit a wall with our old perimeter-focused firewall. Managing 50 people across three continents with zero-trust aspirations meant our legacy box just couldn't keep up. We evaluated Sophos XGS pretty thoroughly over the last quarter, and I wanted to share our integration-heavy, automation-first experience—both the brilliant parts and the frustrating "gotchas."
Our core need was enforcing zero-trust without killing productivity. That meant:
* User-to-application rules based on identity (Azure AD), not just IP.
* Seamless VPN-less access to internal tools via client-based access rules.
* Automated policy updates when someone joins/leaves a team in our HR system.
* Detailed logging piped into our SIEM for anomaly detection.
Here’s where the XGS shone and stumbled:
**The Good (Integration Wins):**
* The Azure AD SAML integration for User/Group recognition is solid. Once set up, firewall policies can dynamically allow/block based on Azure AD group membership.
* The REST API is fairly comprehensive. We automated firewall policy provisioning using Make. When BambooHR fires a webhook for a new hire, a Make scenario adds the user to specific Azure AD groups, and a separate scenario (after a delay) pushes a new firewall rule for that group. Here's a snippet of the Make HTTP call to add a rule:
```json
{
"action": "add",
"rule": {
"name": "Access-InternalApp-{{groupName}}",
"source_zones": ["VPN"],
"source_networks": ["any"],
"users": ["{{azureADGroup}}"],
"services": ["HTTPS"],
"destinations": ["InternalAppServer"],
"action": "allow"
}
}
```
* Webhook support for logging is a game-changer. We stream all threat logs to a Datadog endpoint, which lets us correlate firewall events with app performance.
**The Gotchas (The Devil's in the Details):**
* **API Idiosyncrasies:** The API expects some parameters in a specific order, and the error messages can be cryptic. We spent a day figuring out that `users` field requires the full distinguished name from Azure AD, not just the email or sAMAccountName.
* **Stateful Sync Delays:** There's a ~2-3 minute delay between a user's group membership changing in Azure AD and the XGS picking it up. Not a deal-breaker, but you must design access workflows with this lag in mind.
* **Certificate Management:** For clientless access, certificate management via the API is a bit manual. We ended up using a small PowerShell script on a schedule to handle renewals and pushes.
* **Log Volume:** The webhook logs are verbose. You *need* a middleware filter (we used a simple Node.js proxy) to trim noise before sending to your SIEM, or you'll get swamped.
For a 50-person remote team, the XGS can absolutely be the core of a zero-trust architecture, but it's not a "set and forget" appliance. It's a platform that requires thoughtful integration work. The payoff is a very dynamic, identity-aware perimeter. If your team has the automation chops to leverage its API fully, it's a powerful fit. If you're looking for something more out-of-the-box with pre-built SaaS connectors, you might feel some integration pain.
Would love to hear how others have automated user lifecycle management or handled the sync delays with cloud identity providers. Any clever Make/Zapier workflows or scripts to share?
-- Ian
Integration Ian
Nice breakdown! The bit about automating policy updates from BambooHR via Make is something I hadn't considered, that's clever for keeping things in sync. Did you run into any lag between the HR webhook and the policy actually being applied? I've seen sync delays cause headaches with temporary access requests.
We've been down the Azure AD integration path too, and while it's mostly solid, we had one gotcha: conditional access policies in Azure sometimes clashed with the XGS's own user-based rules. It created a weird loop for a few users where they'd get challenged twice. Took a while to untangle the session validation settings.
Would you use the same setup again, or has looking at the logs made you consider a pure ZTNA platform like Zscaler or Twingate instead?
cost first, then scale
Oh, that sync lag can be brutal. We got it down to about 90 seconds by having Make push to a small Lambda that updates a DynamoDB table. The XGS pulls from there every 60 seconds. Still a window, but we mitigated it by having the firewall assign a default "onboarding" policy for any unrecognized user ID. That policy just allows Slack and the help desk portal, nothing else. Dodged a few bullets with that.
The Azure AD conditional access loop is a classic. We fixed it by setting the XGS to use "passthrough" authentication for sessions already validated by Azure. Basically told it to trust Azure's token and not re-challenge. The logs were a mess until we figured that out.
As for ZTNA platforms, I benchmarked Zscaler and Twingate against our setup for a pet project. Zscaler crushed it on latency to our Asia-Pacific apps, but the XGS was cheaper and, honestly, gave us more control over the weird layer-7 rules we sometimes need. If you're *pure* SaaS, a platform might win. But if you've got any legacy on-prem nonsense clinging to life, the hybrid approach of the XGS still feels right.