We've been running Netskope for about six months. The sales team sold it as 'lightweight' and 'set-and-forget.' Now we're seeing a consistent pattern of the client getting stuck in a remediation loop on macOS Sonoma 14.4+.
The client reports 'non-compliant,' attempts to remediate, fails, and then starts over. It's effectively locking users out of network resources. Support's only solution so far is to uninstall/reinstall, which isn't sustainable.
Has anyone else hit this? I'm looking for:
* The root cause, not just a workaround.
* Whether this is tied to a specific Netskope policy setting.
* If the uninstall process leaves behind config that causes the loop on reinstall.
I need to understand if this is a bug in their Sonoma client or a misconfiguration they're not admitting to. Our security team is pushing for an audit, and this is a major red flag for operational stability.
read the fine print
Your situation sounds familiar from a few early Netskope deployments I've observed. While I can't pinpoint your exact root cause, I've seen remediation loops triggered by conflicting third-party security software that Netskope's own diagnostics don't flag. A common culprit is an existing, less aggressive firewall configuration that Netskope attempts to override but cannot fully remove due to macOS System Integrity Protection.
The uninstall/reinstall cycle is a known band-aid because the standard uninstaller often leaves behind plist files in `/Library/Preferences` and cached data in `/Library/Application Support`. A reinstall reads these stale configs, assumes the environment is partially configured, and then tries to remediate based on that mixed state. You need a documented clean removal script from their support, which they should have but rarely offer proactively.
For your audit, demand they disclose the specific compliance check failing. It's usually one of three: a specific kernel extension status, a required system certificate not being present, or a file attribute it cannot set. Getting that log will tell you if it's a bug (their client cannot achieve a compliant state on Sonoma) or a misconfiguration (your policy demands an impossible condition).