We've been rolling out Zscaler Private Access for our dev teams accessing Azure-hosted services. Microsoft's "Optimize Microsoft 365 for Zscaler" documentation is a maze of PAC files, tenant restrictions, and split tunneling exceptions.
I followed their core recommendations:
* Bypass Zscaler for all Microsoft 365 traffic (TCP 80/443) as per their IP/URL list.
* Configured tenant restriction to prevent tenant hopping.
* Set up PAC file for authenticated clients.
The result? Initial latency dropped, but we saw sporadic authentication failures and timeouts during peak sync operations. The "optimized" traffic flow seems to fight with our existing pipeline agent configurations.
Did anyone implement this specifically for CI/CD workloads (e.g., Azure DevOps agents, GitHub Actions runners on-prem hitting Microsoft 365 endpoints)? Did you:
1. Follow the guide to the letter, or did you modify it?
2. See any tangible performance gains for developer tooling (VS Code auth, NuGet restores from Microsoft feeds, Azure CLI)?
3. Run into issues with service principals or managed identities after applying the tenant restrictions?
Looking for concrete config snippets or pitfalls, not marketing slides.
We also followed the core guide, but for our marketing automation platform that pulls data from Microsoft 365 APIs. We saw a similar pattern of sporadic auth failures, especially during high-volume syncs.
Our biggest issue actually stemmed from the tenant restriction configuration. It seemed to interfere with service principals used by our CI/CD tooling for deployment, not unlike your pipeline agents. The failures weren't consistent, which made debugging a nightmare. We ended up having to create a very granular bypass list, far more specific than Microsoft's broad IP list, just for our integration service accounts.
Did you notice if the authentication failures correlated with specific OAuth flows, like client credentials versus device code? We found the tenant restrictions were far more problematic for non-interactive, automated flows.
We went through this exact scenario last quarter. We followed the guide, but only for endpoints proven to impact developer experience.
> The "optimized" traffic flow seems to fight with our existing pipeline agent configurations.
This was our biggest hurdle. The broad IP/URL bypass list created a split-tunnel scenario that our security team rejected. We had to pivot to a more surgical approach.
For CI/CD specifically (Azure DevOps agents on-prem), we found the performance gain wasn't from bypassing Zscaler for *all* M365 traffic. It came from pinpointing and bypassing only the core authentication endpoints (login.microsoftonline.com, login.windows.net) and key VS Code/NuGet feeds. The tenant restriction was the real killer for service principals; we had to create an allow policy that excluded our CI service accounts from those checks. Their token fetches would silently timeout otherwise.
The guide is a starting point, but treat it as a list of potential optimization points, not a checklist. You'll need to test each bypass segment with your actual pipeline workloads.
Ship fast, measure faster.