Does the Secure Access client really need local admin rights? That's a dealbreaker.

I am currently conducting a technical evaluation of Secure Access Service Edge (SASE) platforms for a multi-cloud enterprise deployment, and Versa Networks is a finalist due to its integrated security stack and robust policy engine. However, during the proof-of-concept phase for the "Versa Secure Access" client (the endpoint agent), my security team has flagged a critical requirement: the client appears to demand local administrator privileges for installation and, more concerningly, for ongoing operation on Windows endpoints.

This is a significant architectural and security regression in a modern zero-trust framework. The principle of least privilege is non-negotiable. Mandating admin rights for a network access client creates an unacceptable attack surface. If the client process itself is compromised, the elevated privileges present a direct path for lateral movement and privilege escalation.

My specific questions for the community are:

* **Is this a documented hard requirement, or are there configuration nuances we are missing?** The official documentation is, in my experience, ambiguous on this point, often using the phrase "requires administrative privileges" without clarifying if it's solely for install or for runtime.
* **How does this compare with other major SASE/ZTNA vendors?** In our parallel evaluations, Zscaler's client and Palo Alto's GlobalProtect (with certain configurations) can operate under standard user privileges post-deployment. This is a key differentiator.
* **Has anyone successfully deployed the Versa client in a locked-down, standard-user environment?** If so, what specific Group Policy Objects, certificate configurations, or agent policies were necessary?

From an infrastructure architecture standpoint, the agent's need for elevated rights suggests it might be performing deep system-level networking modifications that could—and arguably should—be handled differently. For instance:
* Is it installing a network filter driver or virtual adapter that cannot be managed via user-space APIs?
* Does it require privileged access to the certificate store for machine certificates, rather than user certificates?
* Are the tunnel interface metrics and routing table modifications being performed in a manner that necessitates `SYSTEM` level access?

The operational burden is also non-trivial. Requiring admin rights complicates scalable, silent deployment via tools like Intune or SCCM and creates friction for unmanaged (BYOD) device scenarios. This single requirement may force us to disqualify Versa from our shortlist, which is unfortunate given the strengths of their controller and analytics plane. I am seeking concrete technical feedback to determine if this is a fundamental limitation of their architecture or a configurable element we have yet to uncover.