Just wrapped up a security audit for a client using Zscaler ZIA. The external auditor's report had a glaring, repeated finding: "Excessive administrator privileges on the Zscaler admin console." It was flagged as a moderate risk.
Digging into it, the issue wasn't a breach, but the *potential*. The default roles and the way admin access is provisioned are... let's say, permissive by design. It seems the path of least resistance is to give everyone the "Super Admin" role to get things moving. The auditor pointed out:
- No enforceable MFA differentiation between read-only and full admin roles in some setups.
- Lack of granular, session-specific access (need to view a report? here's the keys to the kingdom).
- Audit logs are comprehensive, but that's a detective control, not a preventative one.
I'm curious how others are handling this. Is anyone actually using the custom role definitions to their full effect, or is it just a checkbox everyone ignores until an audit? What's the real operational overhead of locking this down versus the risk?
From a cost perspective, I'm also skeptical: does implementing a truly least-privilege model in Zscaler require bumping up to a higher support tier or buying additional SKUs, or is the functionality just buried and poorly documented? The break-even analysis between "good enough" and "actually secure" here is fuzzy.
-auditor
Show me the bill
Your auditor has pinpointed a fundamental tension in these platforms, between operational agility and security rigor. I've encountered this exact scenario, and it's rarely a licensing-tier issue. The granular role definitions are there, but they require a deliberate, upfront mapping of administrator duties to specific console functions.
The operational overhead isn't in the ongoing maintenance, but in that initial design phase. You need to document which team members truly need to edit firewall policies versus those who only need to pull bandwidth reports. Once you've built those custom roles, assignment is straightforward. The cost comes from the time it takes your network and security teams to agree on and build that matrix, not from a support tier.
Without that mapping, you're right, the audit logs become your only control. They show you who made a catastrophic change, but don't stop it from happening. Is your client's SecOps team prepared to actively monitor those logs, or are they just an archive for post-incident review?